RFC 4897

Handling Normative References to Standards-Track Documents

πŸ“… published June 2007, from ietf

RFC 4897: Handling Normative References to Standards-Track Documents πŸ“œ

okay so bestie, this one is RFC 4897 πŸ’… It's a Best Current Practice (that's BCP 97 πŸŽ€), and it was written by J. Klensin and S. Hartman (from MIT 🧚) in June 2007. It updates RFC 3967 ✨, so keep that one in mind the whole time you read this. It's basically the new and improved version of how we handle downward references.


Status of This Memo πŸ“£

this doc is an Internet Best Current Practice for the whole Internet Community, and it's literally begging for discussion and suggestions to make it better πŸ™ Distribution of this memo is unlimited 🌈

Copyright (C) The IETF Trust (2007).

Abstract πŸ¦‹

so the IETF and the RFC Editor have had this long-standing rule 😀 that a document at a given maturity level can't be published until every document it references normatively is at that maturity level or higher. It's been the cause of really long publication delays, and some people said it was a major blocker for moving documents up in maturity level πŸ’€ The IETF found a way around it with RFC 3967. This document is a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, and it's called "note and move on" πŸƒβ€β™€οΈ The RFC 3967 procedure still applies for downward references to other classes of documents. In both cases, annotations should be added to such References πŸ“

Table of Contents πŸ—‚οΈ

1. Introduction ....................................................2
2. Terminology .....................................................3
3. Normative Reference Rule ........................................3
   3.1. Source Documents Not Yet Processed by the IESG .............3
   3.2. Documents Already in the RFC Editor Queue ..................4
4. Target Documents Not on the Standards Track .....................4
5. Target Documents that Can Be Referenced This Way ................4
6. Security Considerations .........................................5
7. Acknowledgements ................................................5
8. Normative References ............................................5

1. Introduction 🌸

okay so the IETF and RFC Editor have had this long-standing rule (see, e.g., RFC 2026, Section 4.2.4 [RFC2026] and the extended discussion in RFC 3967 [RFC3967]) πŸ“š that a document at a given maturity level can't be published until all of the documents it makes a normative reference to are at that maturity level or higher. Sometimes this caused super long publication delays, and people claimed it was a major obstruction to advancing documents in maturity level 😭 Recognizing that problem, RFC 3967 set up an exception procedure for normative downward references under some specific circumstances. But RFC 3967 has fairly stringent requirements, so it hasn't really been enough to clear the backlog of documents waiting on upgraded documents, or to stop more documents from joining that queue πŸ™ƒ

so this document replaces that long-standing rule for downward references to Standards-Track documents (including BCPs) that are already published. Under the old rule, the newer, referencing document was held until the referenced ones could be brought up to the right maturity level. Now, following the procedures below, you can just note the downward normative reference and move on ✨

This document also updates RFC 3967. When downward references from a source document are approved under the procedure in that specification, we recommend that the references in the approved (source) document be annotated the same way as references approved under this rule 🫢

2. Terminology πŸŽ€

a reference involves two documents: the one where the reference is embedded, and the document being referenced. When it's needed for clarity, these get called the "source document" and "target document" 🧠

The term "Standards-Track document", as used in this specification, is assumed to include BCPs but not Informational or Experimental documents of any variety or origin πŸ’œ

3. Normative Reference Rule πŸ¦„

this document gives you an alternative to holding source documents until all the target documents referenced normatively are upgraded, or to applying the procedure of RFC 3967 🫧

3.1. Source Documents Not Yet Processed by the IESG πŸ“

an author or editor who needs a normative downward reference to a Standards-Track RFC uses this super simple procedure:

  • The reference text (i.e., in the "Normative References" section of the source document) is written as usual.
  • A note is included in the reference text that says the reference is to a target document of a lower maturity level, that some caution should be used since it may be less stable than the document it's being referenced from, and, optionally, explains why the downward reference is appropriate.

The Internet Engineering Steering Group (IESG) may, at its discretion, specify the exact text to be used, establish procedures regarding the text to use, or give guidance on this text. When establishing procedures, the IESG should seek appropriate community review πŸ—£οΈ

these annotations are part of the source document. If members of the community think either the downward reference or the annotation text is inappropriate, they can raise that at any time during the document life cycle, just like with any other text in the document. There is no separate review of these references πŸ‘€

With appropriate community review, the IESG may establish procedures for when normative downward references should delay a document and when downward references should just be noted. Without specific guidance, authors and reviewers should use their best judgment. It is assumed that, in a significant majority of cases, noting a downward reference is preferable to delaying publication 🌈

At the option of the author, similar notes may be attached to non-normative references πŸ“

3.2. Documents Already in the RFC Editor Queue 🧚

the IESG may, at its discretion, specify a procedure to apply to source documents that are already in the RFC Editor queue and waiting on target referenced documents. The IESG should encourage authors with documents in the RFC Editor queue that are waiting on downward references to Standards-Track RFCs to evaluate whether this new rule is appropriate for their documents. If authors believe that adding an annotation and releasing the document is the best way forward, then the IESG should make sure appropriate review is conducted and, if that review agrees with the authors' evaluation, allow the annotations to be added. The IESG will announce its decision via the normal Protocol-Action or Document-Action mechanisms πŸ“£

4. Target Documents Not on the Standards Track πŸ”

in the case of a normative reference to a document that isn't on the standards track, and that is approved under the procedures defined in RFC 3967, the annotation described in Section 3.1 or the retrospective annotation described in Section 3.2 SHOULD be added to the reference, unless the IESG, after considering Last Call input, concludes it is inappropriate πŸ’…

Intellectual Property ✨

okay so this part is all about who owns what πŸ’… the IETF is not taking a side on whether any patents or other IP rights apply to the tech in this doc, or whether you can even get a license for them. it also hasn't gone hunting for any of that stuff on its own, so no promises from them 🫢 if you want the rules about rights in RFC documents, check out BCP 78 and BCP 79 πŸ’œ

if you're an implementer or user and you want copies of IPR disclosures that were sent to the IETF Secretariat, or assurances that licenses will be available (or the results of someone trying to get a general license or permission to use the proprietary rights), those live in the IETF on-line IPR repository at http://www.ietf.org/ipr πŸ”₯

and if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, the IETF wants to hear about it! πŸ¦‹ just send the info to ietf-ipr@ietf.org and they'll take it from there πŸŽ€


Acknowledgement 🌸

last bit, and it's a shoutout πŸ™ˆ funding for the RFC Editor function is currently coming from the Internet Society ✨ so yeah, the Internet Society is keeping the RFC Editor running right now, iconic πŸ‘‘

πŸ“¦ where this page comes from