Movatterモバイル変換

Network Working Group                                            R. BushRequest for Comments: 3967                                           IIJBCP: 97                                                        T. NartenCategory: Best Current Practice                          IBM Corporation                                                           December 2004Clarifying when Standards Track Documents may ReferNormatively to Documents at a Lower LevelStatus 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 withSection 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 20043.  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 20046.  References6.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.comBush & Narten            Best Current Practice                  [Page 5]

RFC 3967            Document Down-Ref Clarifications       December 20048.  Full Copyright Statement   Copyright (C) The Internet Society (2004).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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]