Normative References in RFCs from Open Source
draft-atlas-external-normref-00

Abstract

IETF procedures generally require that a standards track RFC may not have a normative reference to a non standards track specification except those from other
standards bodies. This document creates an External Specification registry, similar to the DownRef registry that has been created based on [RFC3967] and permits normative references to community accepted external specifications.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 2, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. What Can Be Normatively Referenced?
• 3. Procedure to be Used
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

The IETF follows the Standards Process [RFC2026] that describes to what a standards track RFC can normatively refer. Information that is normatively referenced is required to be understood and may be necessary for implementation of the RFC. Essentially, if a technology can be normatively referenced, then a standards track RFC can be created that uses that technology.

Of course, the need to collaboratively build Internet technology is well discussed in [RFC2026] Section 7 and the ability to reference external Open Standard specifications as well as proprietary specifications is described. Specifically,

• Other proprietary specifications may be incorporated by reference to a version of the specification as long as the proprietor meets the requirements of section 10. If the other proprietary specification is not widely and readily available, the IESG may request that it be published as an Informational RFC.

The ID-nits checklist at https://www.ietf.org/id-info/checklist.html warns:

• Normative and informative references to non-IETF documents are permitted. However, it is best to minimize such normative references, because assessing their status when the IETF document advances on the standards-track is very difficult. It is important to use the exact title, author name(s), organization and publication date.

When a Working Group wishes to build based upon existing Open Source technology, the lack of clarity around how that technology’s status will be assessed can either discourage such a dependency or add unnecessary work by requiring republication as an Independent Stream RFC, which will still require a downwards reference [RFC3967].

This document provides clarity and a simple process to make it easy to reference Open Source technology that the IETF community agrees is acceptable.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119].

2. What Can Be Normatively Referenced?

There are five basic requirements for a normative reference.

1. Is it stable, mature, and immutable (except for errata)?
   
   Stable means that there are not expected to be frequent updated versions. Mature is equivalent to being at least similar to a Proposed Standard RFC. Immutable means that the referenced content is not expected to change after RFC publication, except for minor error corrections. This might be achieved by referencing a particular dated version or a subsection of the document.
2. Is it generally easily accessible and not subject to confidentiality restrictions?
3. Is it a specification that describes the technology in sufficient detail that someone else can design their own implementation to properly interoperate with it and others’ different implementations?
   
   The IETF generally prefers specifications over code. Code itself lacks context to fully understand the intent or support an interoperable different implementation. There may, of course, be exceptions where an algorithm or codec is really most clearly described in code. For example, while [RFC6716] has normative code, there is also detailed documentation. If it is necessary to reference code, a distribution is preferred because that can be clear on the public interfaces and intent of the code.
4. Is it intended as a public interface?
5. Are the IPR associated with the normative reference clearly and publicly documented so that the Working Group participants can make an informed decision about building on top of the specified technology?

3. Procedure to be Used

This procedure is modeled on that defined in [RFC3967] and [RFC8067] for managing down references in RFCs. A registry of external non-SDO references that have been accepted by the community, as indicated by at least the first published RFC with a normative references to a particular item, SHOULD be maintained for references that may see reuse. That registry should indicate the reference, the RFC(s) normatively referring to it, and a pointer to any IPR information that is provided by the same source (e.g. Open Source Organization) as the external non-SDO reference. A mechanism for this registry could be the same as is done in datatracker for the DownRef registry where the sponsoring AD updates the registry.

The following procedures apply to external non-SDO references that are not yet in the External References registry. Information included in calls for Working Group adoption, Working Group Last Call, and IETF Last Call SHOULD include any normative references to external non-SDO technology and a pointer to any IPR that is provided by the same source as the external non-SDO technology. Working Group and IETF participants should use this information in their evaluations. The Document Shepherd [RFC4858] SHOULD indicate in her or his report whether the document contains any external non-SDO references that are not in the external references registry. This will call the responsible Area Director’s attention to verify that the referenced item is acceptable.

The Working Group Chairs and responsible Area Director SHOULD verify that the referenced item meets the requirements described earlier. If the desired reference is to code, then the responsible Area Director MUST determine whether it provides sufficient context, clarity of intent, and intentional public interfaces. Judgement calls are expected here as circumstances will vary.

4. Security Considerations

It is possible that external technology does not meet the security or privacy expectations for Standards Track RFCs. This may require additional considerations from the referring document.

5. IANA Considerations

There are no IANA considerations.

6. Acknowledgements

Thanks to Lucy Lynch for encouraging more thought on what can be done to better the interaction between the IETF and Open Source work.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses