RFC 3967

RFC 3967: Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level 🎀

Okay bestie, here's the deal. This is RFC 3967, a Best Current Practice (BCP 97) written by Randy Bush (IIJ) and Thomas Narten (IBM Corporation). It was published in December 2004, and it's in the Network Working Group series. Its header doesn't list any Obsoletes or Updates lines, so it isn't replacing or amending any other RFC. 💅

Status of this Memo ✨

Okay so this document is a BCP for the Internet Community, and it's basically inviting everyone to talk about it and suggest improvements 🫶 Distribution is unlimited, so share away!

Copyright Notice 🌸

Copyright (C) The Internet Society (2004).

Abstract 💜

Okay, so the IETF usually has a rule: a standards track RFC can't have a normative reference to another standards track doc at a lower maturity level, or to a non-standards-track spec (unless it's from another standards body) 🙈 For example, a standards track doc can't normatively point at an informational RFC. BUT sometimes the IETF needs informational RFCs to describe non-IETF standards, or IETF-specific ways of using those standards, so exceptions are sometimes needed 🦋 This doc clarifies and updates the procedure for those situations.

1. Introduction ✨

The Internet Standards Process [RFC2026] Section 4.2.4 says this, and it's giving strict:

Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies.

One goal is to avoid making a standard look more mature than it actually is 👑

Also, Best Current Practice documents [RFC1818] have usually been treated like Standards Track docs when it comes to what they can reference. For example, a normative reference to an Experimental RFC has been seen as an improper reference per [RFC2026] 💀

1.1. Normative References 🧚

So in an RFC, references to other docs fall into two buckets: "normative" and "informative" 🍓 Roughly, a normative reference is a doc you have to read to fully understand or implement the new RFC, or whose contents are basically part of the new RFC, because leaving it out would leave the new RFC incompletely specified. An informative reference isn't normative. It just gives extra background info ✨

Defining exactly what is (and isn't) normative has been tricky in practice, because the details can be subtle 😭 Also, whether something needs to be normative can depend on the context the RFC is being published in. For example, for an IETF Standard, all the dependent pieces need to be clearly specified and available in an archival form, so nobody argues about what counts as the standard. That's not always true for other docs.

This section gives guidance on what might (and might not) count as normative in the IETF standards process 🔥

In the IETF, it's a basic assumption that implementors need a clear understanding of what they have to implement to be fully compliant with a standard, and to interoperate with other implementations. For referenced docs, any doc that has key info an implementer needs is normative. For example, if you need to understand a packet format defined in another doc to fully implement a spec, the reference to that format is normative. Likewise, if a reference to a required algorithm is made, that reference is normative.

Some specific examples, bestie:

• If a protocol relies on IPsec for security, you can't fully implement the protocol unless the IPsec spec is available. So that reference is normative.

The referenced spec would likely include details about specific key management requirements, which transforms are required and which are optional, etc. 🫶

• In MIB docs, an IMPORTS clause is by definition a normative reference 🌈
• When a reference to an example is made, it doesn't have to be normative. For example, text like "an algorithm such as the one specified in [RFCxxxx] would be acceptable" is an informative reference, since that cited algorithm is just one of several possible algorithms that could be used 💖

2. The Need for Downward References 🦋

There are a bunch of situations where an IETF doc may need a normative reference to a doc at a lower maturity level, but that reference clashes with Section 4.2.4 of [RFC2026]. For example:

• A standards track doc may need to refer to a protocol or algorithm developed by an external body, but modified, adapted, or profiled by an IETF informational RFC. Examples are MD5 [RFC1321] and HMAC [RFC2104]. Note that this does not override the IETF's duty to make sure the spec is clear enough to enable interoperable implementations 🔥
• A standards doc may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs 🍓
• A migration or co-existence doc may need to define a standards track mechanism for migrating from, and/or co-existing with, a historic protocol, a proprietary protocol, or possibly a non-standards track protocol 🌸
• There are exceptional procedural or legal reasons that force the target of the normative reference to be an informational or historical RFC, or to be at a lower standards level than the referring doc 😭
• A BCP doc may want to describe best current practices for experimental or informational specs ✨

3. The Procedure to Be Used 📋

For Standards Track or BCP docs that need a normative reference to docs of lower maturity, the normal IETF Last Call procedure will be issued, and the need for the downward reference gets explicitly documented in the Last Call itself. Any community comments on whether the downward references are appropriate will be considered by the IESG as part of its deliberations 🧠

Once a specific down reference to a particular doc has been accepted by the community (for example, it's been mentioned in several Last Calls), an Area Director may waive later notices in the Last Call of down references to it. This should only happen when the same doc (and version) is being referenced, and when the AD believes the doc's use is an accepted part of the community's understanding of the relevant technical area. For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well known among cryptographers 🔐

This procedure should not be used if the proper step is to move the referenced doc into the appropriate category. It's not meant to be an easy way out of normal process 🙅‍♀️ Instead, it's for specific cases where getting particular docs into the required category is problematic and unlikely to ever happen.

4. Security Considerations 🔐

This document is not known to create any new vulnerabilities for the Internet. On the other hand, inappropriate or excessive use of the process might be considered a downgrade attack on the quality of IETF standards or, worse, on the rigorous review of security aspects of standards. 😱 Seriously, bestie, don't abuse this!

5. Acknowledgments 🫶

This document is the result of discussion within the IESG, with particular contributions from Harald Alvestrand, Steve Bellovin, Scott Bradner, Ned Freed, Allison Mankin, Jeff Schiller, and Bert Wijnen. Iconic squad 👑

6. References 📚

6.1. Normative References

• [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

6.2. Informative References

• [RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", BCP 1, RFC 1818, August 1995.
• [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
• [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

7. Authors' Addresses 💌

Randy Bush IIJ 5147 Crystal Springs Bainbridge Island, WA 98110 US

Phone: +1 206 780 0431 EMail: randy@psg.com URI: http://psg.com/~randy/

Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 US

Phone: +1 919 254 7798 EMail: narten@us.ibm.com

8. Full Copyright Statement 🌈

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. ✨