1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc4897.txt b/doc/rfc/rfc4897.txt
new file mode 100644
index 0000000..3fccf62
--- /dev/null
+++ b/doc/rfc/rfc4897.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                         J. Klensin
+Request for Comments: 4897
+BCP: 97                                                       S. Hartman
+Updates: 3967                                                        MIT
+Category: Best Current Practice                                June 2007
+
+
+       Handling Normative References to Standards-Track Documents
+
+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 IETF Trust (2007).
+
+Abstract
+
+   The Internet Engineering Task Force (IETF) and Request for Comments
+   (RFC) Editor have a long-standing rule that a document at a given
+   maturity level cannot be published until all of the documents that it
+   references as normative are at that maturity level or higher.  This
+   rule has sometimes resulted in very long publication delays for
+   documents and some claims that it was a major obstruction to
+   advancing documents in maturity level.  The IETF agreed on a way to
+   bypass this rule with RFC 3967.  This document describes a simpler
+   procedure for downward references to Standards-Track and Best Current
+   Practice (BCP) documents, namely "note and move on".  The procedure
+   in RFC 3967 still applies for downward references to other classes of
+   documents.  In both cases, annotations should be added to such
+   References.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin & Hartman        Best Current Practice                  [Page 1]
+
+RFC 4897                  Normative References                 June 2007
+
+
+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
+
+   The IETF and RFC Editor have a 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 cannot be
+   published until all of the documents to which it makes a normative
+   reference are at that maturity level or higher.  This rule has
+   sometimes resulted in very long publication delays for documents and
+   some claims that it was a major obstruction to advancing documents in
+   maturity level.  Recognizing the problems that this rule sometimes
+   caused, RFC 3967 established an exception procedure for normative
+   downward references under some specific circumstances.  Perhaps
+   because of its fairly stringent requirements, RFC 3967 has not proven
+   adequate either to clear the backlog of documents awaiting upgraded
+   documents or to prevent additional documents from joining that queue.
+
+   This document replaces the long-standing rule for downward references
+   to Standards-Track documents (including BCPs) that are already
+   published.  For normative references to Standards-Track and BCP
+   documents, that rule was to hold the newer, referencing, document
+   until the referenced ones could be brought to the appropriate
+   maturity level.  It is now possible, following procedures described
+   below, to simply 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 specified in that
+   specification, we recommend that the references in the approved
+   (source) document be annotated in the same way as references approved
+   under this rule.
+
+
+
+
+
+
+
+
+
+Klensin & Hartman        Best Current Practice                  [Page 2]
+
+RFC 4897                  Normative References                 June 2007
+
+
+2.  Terminology
+
+   A reference involves two documents, the one in which the reference is
+   embedded and the document referenced.  Where needed for clarity,
+   these documents are referred to as the "source document" and "target
+   document", respectively.
+
+   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 specifies an alternative to holding source documents
+   until all target documents referenced normatively are upgraded or by
+   applying the procedure of RFC 3967.
+
+3.1.  Source Documents Not Yet Processed by the IESG
+
+   An author or editor who requires a normative downward reference to a
+   Standards-Track RFC uses the following very simple procedure:
+
+   o  The reference text (i.e., in the "Normative References" section of
+      the source document) is written as usual.
+   o  A note is included in the reference text that indicates that 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 from which it is being referenced, and, optionally,
+      explaining 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 consider either the downward reference or the annotation
+   text to be inappropriate, those issues can be raised at any time
+   during the document life cycle, just as 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 be noted.  Absent 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.
+
+
+
+Klensin & Hartman        Best Current Practice                  [Page 3]
+
+RFC 4897                  Normative References                 June 2007
+
+
+   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 be applied to
+   source documents that are already in the RFC Editor queue, awaiting
+   target referenced documents.  The IESG should encourage authors with
+   documents in the RFC Editor queue awaiting 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 ensure that appropriate review is conducted and, if that
+   review agrees with that of 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 not on the
+   standards track 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 consideration of Last Call input, concludes it
+   is inappropriate.
+
+5.  Target Documents that Can Be Referenced This Way
+
+   The "downward reference by annotation" model specified here is
+   applicable only to published Standards-Track RFCs at lower maturity
+   levels.
+
+   Obviously, such downward references are part of the relevant source
+   document at IETF Last Call and subject to comments from the
+   community.
+
+   Advancing documents, when appropriate, is still considered preferable
+   to the use of either this procedure or the one specified in RFC 3967.
+   This specification does not impose a specific test or requirement to
+   determine appropriateness.  This is partially because it would be
+   impossible to do so for the general case, but more so because the
+   intention is to permit the IESG and the community to balance the
+   importance of getting a source document published against the time
+   and difficulty associated with upgrading a target document.  That
+   requirement is intended to be less stringent than the one of RFC
+   3967.
+
+
+
+
+
+Klensin & Hartman        Best Current Practice                  [Page 4]
+
+RFC 4897                  Normative References                 June 2007
+
+
+6.  Security Considerations
+
+   This document specifies an IETF procedure.  It is not believed to
+   raise any security issues although, in principle, relaxing the
+   normative downward reference rules for references associated with
+   security mechanisms could make a specification less stable and hence
+   less secure.
+
+7.  Acknowledgements
+
+   This proposal was suggested by a comment by Spencer Dawkins and many
+   complaints about the negative impact of the current rules.  The
+   author is unsure about the validity of some of those complaints; the
+   proposal is, in part, a way to test the validity question.  Spencer
+   also provided helpful comments on a preliminary version.  It was
+   revised in response to extensive discussion in the IESG and benefited
+   significantly by comments from Brian Carpenter.
+
+8.  Normative References
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+   [RFC3967]  Bush, R. and T. Narten, "Clarifying when Standards Track
+              Documents may Refer Normatively to Documents at a Lower
+              Level", BCP 97, RFC 3967, December 2004.
+
+Authors' Addresses
+
+   John C Klensin
+   1770 Massachusetts Ave, #322
+   Cambridge, MA  02140
+   USA
+
+   Phone: +1 617 491 5735
+   EMail: john-ietf@jck.com
+
+
+   Sam Hartman
+   Massachusetts Institute of Technology
+   77 Massachusetts Ave
+   Cambridge, MA  02139
+   USA
+
+   EMail: hartmans-ietf@mit.edu
+
+
+
+
+
+
+Klensin & Hartman        Best Current Practice                  [Page 5]
+
+RFC 4897                  Normative References                 June 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, 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, THE IETF TRUST 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 procedures with respect to rights in RFC 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.
+
+
+
+
+
+
+
+Klensin & Hartman        Best Current Practice                  [Page 6]
+