From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3967.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc3967.txt (limited to 'doc/rfc/rfc3967.txt') diff --git a/doc/rfc/rfc3967.txt b/doc/rfc/rfc3967.txt new file mode 100644 index 0000000..594f1ee --- /dev/null +++ b/doc/rfc/rfc3967.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group R. Bush +Request for Comments: 3967 IIJ +BCP: 97 T. Narten +Category: Best Current Practice IBM Corporation + December 2004 + + + Clarifying when Standards Track Documents may Refer + Normatively to Documents at a Lower Level + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + 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. + +1. Introduction + + The Internet Standards Process [RFC2026] Section 4.2.4 specifies the + following: + + 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 intent is to avoid creating a perception that a standard is more + mature than it actually is. + + + + + + + +Bush & Narten Best Current Practice [Page 1] + +RFC 3967 Document Down-Ref Clarifications December 2004 + + + It should also be noted that Best Current Practice documents + [RFC1818] have generally been considered similar to Standards Track + documents in terms of what they can reference. For example, a + normative reference to an Experimental RFC has been considered an + improper reference per [RFC2026]. + +1.1. Normative References + + Within an RFC, references to other documents fall into two general + categories: "normative" and "informative". Broadly speaking, a + normative reference specifies a document that must be read to fully + understand or implement the subject matter in the new RFC, or whose + contents are effectively part of the new RFC, as its omission would + leave the new RFC incompletely specified. An informative reference + is not normative; rather, it provides only additional background + information. + + An exact and precise definition of what is (and is not) a normative + reference has proven challenging in practice, as the details and + implications can be subtle. Moreover, whether a reference needs to + be normative can depend on the context in which a particular RFC is + being published in the first place. For example, in the context of + an IETF Standard, it is important that all dependent pieces be + clearly specified and available in an archival form so that there is + no disagreement over what constitutes a standard. This is not always + the case for other documents. + + The rest of this section provides guidance on what might (and might + not) be considered normative in the context of the IETF standards + process. + + In the IETF, it is a basic assumption that implementors must have a + clear understanding of what they need to implement in order to be + fully compliant with a standard and to be able to interoperate with + other implementations of that standard. For documents that are + referenced, any document that includes key information an implementer + needs would be normative. For example, if one needs to understand a + packet format defined in another document in order to fully implement + a specification, the reference to that format would be normative. + Likewise, if a reference to a required algorithm is made, the + reference would be normative. + + Some specific examples: + + - If a protocol relies on IPsec to provide security, one cannot + fully implement the protocol unless the specification for IPsec is + available; hence, the reference would be normative. + + + + +Bush & Narten Best Current Practice [Page 2] + +RFC 3967 Document Down-Ref Clarifications December 2004 + + + The referenced specification would likely include details about + specific key management requirements, which transforms are + required and which are optional, etc. + + - In MIB documents, an IMPORTS clause by definition is a normative + reference. + + - When a reference to an example is made, such a reference need not + be normative. For example, text such as "an algorithm such as the + one specified in [RFCxxxx] would be acceptable" indicates 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 number of circumstances in which an IETF document may + need to make a normative reference to a document at a lower maturity + level, but such a reference conflicts with Section 4.2.4 of + [RFC2026]. For example: + + o A standards track document may need to refer to a protocol or + algorithm developed by an external body but modified, adapted, or + profiled by an IETF informational RFC, for example, MD5 [RFC1321] + and HMAC [RFC2104]. Note that this does not override the IETF's + duty to see that the specification is indeed sufficiently clear to + enable creation of interoperable implementations. + + o A standards document may need to refer to a proprietary protocol, + and the IETF normally documents proprietary protocols using + informational RFCs. + + o A migration or co-existence document may need to define a + standards track mechanism for migration from, and/or co-existence + with, an historic protocol, a proprietary protocol, or possibly a + non-standards track protocol. + + o 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 document. + + o A BCP document may want to describe best current practices for + experimental or informational specifications. + + + + + + + + +Bush & Narten Best Current Practice [Page 3] + +RFC 3967 Document Down-Ref Clarifications December 2004 + + +3. The Procedure to Be Used + + For Standards Track or BCP documents requiring normative reference to + documents of lower maturity, the normal IETF Last Call procedure will + be issued, with the need for the downward reference explicitly + documented in the Last Call itself. Any community comments on the + appropriateness of downward references will be considered by the IESG + as part of its deliberations. + + Once a specific down reference to a particular document has been + accepted by the community (e.g., has been mentioned in several Last + Calls), an Area Director may waive subsequent notices in the Last + Call of down references to it. This should only occur when the same + document (and version) are being referenced and when the AD believes + that the document'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 + document to which the reference is being made into the appropriate + category. It is not intended as an easy way out of normal process. + Rather, the procedure is intended for dealing with specific cases + where putting particular documents into the required category is + problematic and unlikely ever to 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. + +5. Acknowledgments + + This document is the result of discussion within the IESG, with + particular contribution by Harald Alvestrand, Steve Bellovin, Scott + Bradner, Ned Freed, Allison Mankin, Jeff Schiller, and Bert Wijnen. + + + + + + + + + + + + +Bush & Narten Best Current Practice [Page 4] + +RFC 3967 Document Down-Ref Clarifications December 2004 + + +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 + + + + + + + + + + + +Bush & Narten Best Current Practice [Page 5] + +RFC 3967 Document Down-Ref Clarifications December 2004 + + +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; nor does it 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 and 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. + + + + + + + +Bush & Narten Best Current Practice [Page 6] + -- cgit v1.2.3