idnits 2.17.1 draft-leiba-3967upd-downref-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3967, updated by this document, for RFC5378 checks: 2003-10-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 09, 2016) is 2692 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Leiba 3 Internet-Draft Huawei Technologies 4 Updates: 3967 (if approved) December 09, 2016 5 Intended status: Best Current Practice 6 Expires: June 10, 2017 8 Updating when Standards Track Documents may Refer Normatively to 9 Documents at a Lower Level 10 draft-leiba-3967upd-downref-03 12 Abstract 14 RFC 3967 specifies a process for allowing normative references to 15 documents at lower maturity levels ("downrefs"), which involves 16 calling out the downref explicitly in the last call notice. That 17 requirement has proven to be unnecessarily strict, and this document 18 updates RFC 3967, allowing the IESG more flexibility in accepting 19 downrefs in Standards Track documents. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 10, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 1. Introduction 54 [RFC3967] notes the importance of assuring that normative references 55 from Standards Track and Best Current Practice (BCP) documents are 56 appropriately mature, and specifies a process for allowing normative 57 references to documents at lower maturity levels ("downrefs"). That 58 process starts at Last Call (see Section 3 of [RFC3967]): 60 For Standards Track or BCP documents requiring normative reference 61 to documents of lower maturity, the normal IETF Last Call 62 procedure will be issued, with the need for the downward reference 63 explicitly documented in the Last Call itself. Any community 64 comments on the appropriateness of downward references will be 65 considered by the IESG as part of its deliberations. 67 Section 2 of [RFC3967] lists some conditions under which downrefs may 68 make sense. In addition to those, it has become common for working 69 groups to produce foundational documents at Informational status, 70 which contain important information such as terminology definitions 71 and architectural design and considerations, and those documents are 72 often needed as normative references in the Standards Track protocol 73 documents that follow. 75 The requirement to explicitly mention the downrefs and the need for 76 them in the Last Call message has proven to be unnecessarily 77 restrictive, and has often resulted in unnecessary repetitions of 78 Last Call, with the corresponding delay and with no real benefit. 80 2. The IESG's Responsibility with Respect to Downrefs 82 The process in RFC 3967 is hereby updated to specify that explicitly 83 documenting the downward references in the Last Call message is 84 strongly recommended, but not required. The responsible AD should 85 still check for downrefs before sending out the last call notice, but 86 if an undetected downref is noticed during last call or IESG review, 87 any need to repeat the last call is at the discretion of the IESG. 88 However, the process in RFC 3967 is not fundamentally altered: If the 89 IESG decides not to repeat the last call, the status of the affected 90 downrefs is not changed, and the process in RFC 3967 will still apply 91 if those downrefs are used in the future. 93 This gives the IESG the responsibility to determine the actual 94 maturity level of the downward reference with respect to the document 95 at hand, and to decide whether or not it is necessary to explicitly 96 ask the IETF community for comments on the downref on a case-by-case 97 basis. In making that decision, the IESG should take into account 98 the general discussion in RFC 3967. The responsible AD should make 99 sure that the omission is recorded as a comment in the datatracker. 101 3. IANA Considerations 103 There are no IANA considerations for this document. 105 4. Security Considerations 106 Referencing immature protocols can have security and stability 107 implications, and the IESG should take that into account when 108 deciding whether re-consulting the community is useful. 110 5. Normative References 112 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 113 Documents may Refer Normatively to Documents at a Lower 114 Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December 115 2004, . 117 Author's Address 119 Barry Leiba 120 Huawei Technologies 122 Phone: +1 646 827 0648 123 Email: barryleiba@computer.org 124 URI: http://internetmessagingtechnology.org/