GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8067

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8067.txt · Last modified: 2017/01/25 01:15 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki