1 files changed, 339 insertions, 0 deletions
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]
+