Normative References in RFCs from Open Source
Juniper Networks
akatlas@juniper.net
Cisco
lear@cisco.com
Ericsson
Joel.Halpern@ericsson.com
RFC Editor
rse@rfc-editor.org
Individual
jefftant.ietf@gmail.com
General
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 and permits normative
references to community accepted external specifications.
The IETF follows the Standards Process 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 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 .
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
.
There are five basic requirements for a normative reference.
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.
Is it generally easily accessible and not subject to
confidentiality restrictions?
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 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.
Is it intended as a public interface?
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?
This procedure is modeled on that defined in and
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 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.
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.
There are no IANA considerations.
Thanks to Lucy Lynch for encouraging more thought on what can be done
to better the interaction between the IETF and Open Source work.
Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level
IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level
RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the Last Call notice. That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents.
The Internet Standards Process -- Revision 3
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Document Shepherding from Working Group Last Call to Publication
This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. This memo provides information for the Internet community.
Definition of the Opus Audio Codec
This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]