1 files changed, 171 insertions, 0 deletions
diff --git a/doc/rfc/rfc8067.txt b/doc/rfc/rfc8067.txt
new file mode 100644
index 0000000..2e4dab2
--- /dev/null
+++ b/doc/rfc/rfc8067.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          B. Leiba
+Request for Comments: 8067                           Huawei Technologies
+BCP: 97                                                     January 2017
+Updates: 3967
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+    Updating When Standards Track Documents May Refer Normatively to
+                       Documents at a Lower Level
+
+Abstract
+
+   RFC 3967 specifies a process for allowing normative references to
+   documents at lower maturity levels ("downrefs"), which involves
+   calling out the downref explicitly in the Last Call notice.  That
+   requirement has proven to be unnecessarily strict, and this document
+   updates RFC 3967, allowing the IESG more flexibility in accepting
+   downrefs in Standards Track documents.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It has been approved for publication by the Internet
+   Engineering Steering Group (IESG).  Further information on BCPs is
+   available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8067.
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Leiba                     Best Current Practice                 [Page 1]
+
+RFC 8067                 Document Downref Update            January 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  The IESG's Responsibility with Respect to Downrefs  . . . . .   2
+   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
+   4.  Normative References  . . . . . . . . . . . . . . . . . . . .   3
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   3
+
+1.  Introduction
+
+   [RFC3967] notes the importance of assuring that normative references
+   from Standards Track and Best Current Practice (BCP) documents are
+   appropriately mature, and specifies a process for allowing normative
+   references to documents at lower maturity levels ("downrefs").  That
+   process starts at IETF Last Call (see Section 3 of [RFC3967]):
+
+      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.
+
+   Section 2 of [RFC3967] lists some conditions under which downrefs may
+   make sense.  In addition to those, it has become common for working
+   groups to produce foundational documents (which contain important
+   information such as terminology definitions and architectural design
+   and considerations) at Informational status, and those documents are
+   often needed as normative references in the Standards Track protocol
+   documents that follow.
+
+   The requirement to explicitly mention the downrefs and the need for
+   them in the Last Call message has proven to be unnecessarily
+   restrictive and has often resulted in unnecessary repetitions of Last
+   Call, with the corresponding delay and with no real benefit.
+
+2.  The IESG's Responsibility with Respect to Downrefs
+
+   The process in RFC 3967 is hereby updated to specify that explicitly
+   documenting the downward references in the Last Call message is
+   strongly recommended but not required.  The responsible AD should
+   still check for downrefs before sending out the Last Call notice, but
+   if an undetected downref is noticed during Last Call or IESG review,
+   any need to repeat the Last Call is at the discretion of the IESG.
+   However, the process in RFC 3967 is not fundamentally altered: If the
+   IESG decides not to repeat the Last Call, the status of the affected
+   downrefs is not changed, and the process in RFC 3967 will still apply
+   if those downrefs are used in the future.
+
+
+
+Leiba                     Best Current Practice                 [Page 2]
+
+RFC 8067                 Document Downref Update            January 2017
+
+
+   This gives the IESG the responsibility to determine the actual
+   maturity level of the downward reference with respect to the document
+   at hand, and to decide whether or not it is necessary to explicitly
+   ask the IETF community for comments on the downref on a case-by-case
+   basis.  In making that decision, the IESG should take into account
+   the general discussion in RFC 3967.  The responsible AD should make
+   sure that the omission is recorded as a comment in the datatracker.
+
+3.  Security Considerations
+
+   Referencing immature protocols can have security and stability
+   implications, and the IESG should take that into account when
+   deciding whether re-consulting the community is useful.
+
+4.  Normative References
+
+   [RFC3967]  Bush, R. and T. Narten, "Clarifying when Standards Track
+              Documents may Refer Normatively to Documents at a Lower
+              Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December
+              2004, <http://www.rfc-editor.org/info/rfc3967>.
+
+Author's Address
+
+   Barry Leiba
+   Huawei Technologies
+
+   Phone: +1 646 827 0648
+   Email: barryleiba@computer.org
+   URI:   http://internetmessagingtechnology.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leiba                     Best Current Practice                 [Page 3]
+