idnits 2.17.00 (12 Aug 2021) /tmp/idnits40874/draft-kucherawy-bcp97bis-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC8067, but the abstract doesn't seem to directly say this. It does mention RFC8067 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC4897, but the abstract doesn't seem to directly say this. It does mention RFC4897 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC3967, but the abstract doesn't seem to directly say this. It does mention RFC3967 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (17 October 2021) is 209 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) == Missing Reference: 'RFCxxxx' is mentioned on line 155, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kucherawy, Ed. 3 Internet-Draft 17 October 2021 4 Obsoletes: 3967, 4897, 8067 (if approved) 5 Intended status: Best Current Practice 6 Expires: 20 April 2022 8 Procedures for Standards Track Documents to Refer Normatively to 9 Documents at a Lower Level 10 draft-kucherawy-bcp97bis-01 12 Abstract 14 IETF procedures generally require that a standards track RFC may not 15 have a normative reference to another standards track document at a 16 lower maturity level or to a non standards track specification (other 17 than specifications from other standards bodies). For example, a 18 standards track document may not have a normative reference to an 19 informational RFC. Exceptions to this rule are sometimes needed as 20 the IETF uses informational RFCs to describe non-IETF standards or 21 IETF-specific modes of use of such standards. This document defines 22 the procedure used in these circumstances. 24 This document merges and updates, and thus obsoletes, RFC 3967, RFC 25 4897, and RFC 8067. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 20 April 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Normative References . . . . . . . . . . . . . . . . . . 3 62 2. The Need for Downward References . . . . . . . . . . . . . . 4 63 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Authors and Editors . . . . . . . . . . . . . . . . . . . 5 66 4.2. The IESG . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. IETF Target Documents . . . . . . . . . . . . . . . . . . . . 7 68 6. Non-IETF Target Documents . . . . . . . . . . . . . . . . . . 7 69 7. Downref Registry . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 9 75 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 The Internet Standards Process [RFC2026] (BCP 9) Section 4.2.4 81 specifies the following: 83 Standards track specifications normally must not depend on other 84 standards track specifications which are at a lower maturity level 85 or on non standards track specifications other than referenced 86 specifications from other standards bodies. 88 One intent is to avoid creating a perception that a standard is more 89 mature than it actually is. 91 It should also be noted that Best Current Practice documents (BCPs; 92 see [RFC2026]) have generally been considered similar to Standards 93 Track documents in terms of what they can reference. For example, a 94 normative reference from a BCP to an Experimental RFC has been 95 considered an improper reference. 97 This document describes a process for allowing normative references 98 to documents at lower maturity levels ("downrefs"), after due notice 99 and consideration as the document progresses toward publication. The 100 original process was defined in [RFC3967] and later amended by 101 [RFC4897] and [RFC8067]. This document consolidates those, and 102 presents further guidance regarding normative references to non-IETF 103 documents. 105 1.1. Normative References 107 Within an RFC, references to other documents fall into two general 108 categories: "normative" and "informative". Broadly speaking, a 109 normative reference specifies a document that must be read to fully 110 understand or implement the subject matter in the RFC, or whose 111 contents are effectively part of the RFC, as its omission would leave 112 the RFC incompletely specified. An informative reference is not 113 normative; rather, it provides only additional background 114 information. 116 An exact and precise definition of what is (and is not) a normative 117 reference has proven challenging in practice, as the details and 118 implications can be subtle. Moreover, whether a reference needs to 119 be normative can depend on the context in which a particular RFC is 120 being published in the first place. For example, in the context of 121 an IETF Standard, it is important that all dependent pieces be 122 clearly specified and available in an archival form so that there is 123 no disagreement over what constitutes a standard. This is not always 124 the case for other documents. 126 The rest of this section provides guidance on what might (and might 127 not) be considered normative in the context of the IETF standards 128 process. 130 In the IETF, it is a basic assumption that implementers must have a 131 clear understanding of what they need to implement in order to be 132 fully compliant with a standard and to be able to interoperate with 133 other implementations of that standard. For documents that are 134 referenced, any document that includes key information an implementer 135 needs would be normative. For example, if one needs to understand a 136 packet format defined in another document in order to fully implement 137 a specification, the reference to that format would be normative. 138 Likewise, if a reference to a required algorithm is made, the 139 reference would be normative. 141 Some specific examples: 143 * If a protocol relies on IPsec to provide security, one cannot 144 fully implement the protocol unless the specification for IPsec is 145 available; hence, the reference would be normative. The 146 referenced specification would likely include details about 147 specific key management requirements, which transforms are 148 required and which are optional, etc. 150 * In MIB documents, an IMPORTS clause by definition is a normative 151 reference. 153 * When a reference to an example is made, such a reference need not 154 be normative. For example, text such as "an algorithm such as the 155 one specified in [RFCxxxx] would be acceptable" indicates an 156 informative reference, since that cited algorithm is just one of 157 several possible algorithms that could be used. 159 2. The Need for Downward References 161 There are a number of circumstances in which an IETF document may 162 need to make a normative reference to a document at a lower maturity 163 level, but such a reference conflicts with Section 4.2.4 of 164 [RFC2026]. For example: 166 * A standards track document may need to refer to a protocol or 167 algorithm developed by an external body but modified, adapted, or 168 profiled by an IETF informational RFC, for example, MD5 [RFC1321] 169 and HMAC [RFC2104]. Note that this does not override the IETF's 170 duty to see that the specification is indeed sufficiently clear to 171 enable creation of interoperable implementations. 173 * A standards document may need to refer to a proprietary protocol, 174 and the IETF normally documents proprietary protocols using 175 informational RFCs. 177 * A migration or co-existence document may need to define a 178 standards track mechanism for migration from, and/or co-existence 179 with, an historic protocol, a proprietary protocol, or possibly a 180 non-standards track protocol. 182 * There are exceptional procedural or legal reasons that force the 183 target of the normative reference to be an informational or 184 historical RFC or to be at a lower standards level than the 185 referring document. 187 * A BCP document may want to describe best current practices for 188 experimental or informational specifications. 190 3. Definitions 192 A reference involves two documents, the one in which the reference is 193 embedded and the document referenced. Where needed for clarity, 194 these documents are referred to as the "source document" and "target 195 document", respectively. 197 The term "Standards-Track document", as used in this specification, 198 is assumed to include only Standards-Track documents at any maturity 199 level, plus BCPs, but not documents with any other status. 201 4. Procedure 203 The following sections describe the procedures to be used by authors/ 204 editors and the IESG when handling downrefs. 206 4.1. Authors and Editors 208 When a Standards-Track or BCP document requires a normative reference 209 to a document of lower maturity, the authors/editors should apply the 210 following very simple procedure: 212 * The reference text (i.e., in the "Normative References" section of 213 the source document) is written as usual. 215 * A note is included in the reference text that indicates that the 216 reference is to a target document of a lower maturity level, that 217 some caution should be used since it may be less stable than the 218 document from which it is being referenced, and, optionally, 219 explaining why the downref is appropriate. 221 The Internet Engineering Steering Group (IESG) may, at its 222 discretion, specify the exact text to be used, establish procedures 223 regarding the text to use, or give guidance on this text. When 224 establishing procedures, the IESG should seek appropriate community 225 review. 227 These annotations are part of the source document. If members of the 228 community consider either the downref or the annotation text to be 229 inappropriate, those issues can be raised at any time during the 230 document life cycle, just as with any other text in the document. 231 There is no separate review of these references. For example, when 232 the downref is to a document of a lower maturity level that is 233 understood to be stable, the annotation can be omitted. Such 234 decisions should be noted in the document shepherd writeup [RFC4858] 235 so the IESG is aware at the time of its review why the annotation is 236 absent. 238 At the option of the author/editor, similar notes may be attached to 239 non-normative references. 241 4.2. The IESG 243 With appropriate community review, the IESG may establish procedures 244 for when normative downref should delay a document and when downrefs 245 should be noted. Absent specific guidance, authors and reviewers 246 should use their best judgment. It is assumed that, in a significant 247 majority of cases, noting a downref is preferable to delaying 248 publication. 250 When a document is presented to the IESG for publication that 251 contains a downref not called out by the author/editor(s) as 252 described in the previous section, it is strongly recommended that 253 the normal IETF Last Call procedure will be issued, with the need for 254 the downref explicitly documented in the Last Call itself. Any 255 community comments on the appropriateness of downrefs will be 256 considered by the IESG as part of its deliberations. 258 If, by oversight, the Last Call does not identify the downref, the 259 IESG may choose to repeat the Last Call with the downref properly 260 identified. If it elects not to do so, then any future downref to 261 the same target document is subject again to the procedures described 262 in this document. In making this decision, the IESG should take into 263 account the general discussion in Section 2. 265 Once a specific downref to a particular document has been accepted by 266 the community (e.g., has been mentioned in one or more Last Calls), 267 an Area Director may waive subsequent notices in the Last Call of 268 downrefs to it. This should only occur when the same document (and 269 version) are being referenced and when the Area Director believes 270 that the document's use is an accepted part of the community's 271 understanding of the relevant technical area. For example, the use 272 of MD5 [RFC1321] and HMAC [RFC2104] is well known among 273 cryptographers. Such documents are added to the "Downref Registry". 275 In the case of a downref approved in this manner, the annotations 276 described above should be added to the reference unless the IESG, 277 after consideration of Last Call input, concludes it is 278 inappropriate. 280 This procedure is not to be used if the proper step is to move the 281 document to which the reference is being made into the appropriate 282 category. It is not intended as an easy way out of normal process. 283 Rather, the procedure is intended for dealing with specific cases 284 where putting particular documents into the required category is 285 problematic and unlikely ever to happen. 287 5. IETF Target Documents 289 The "downward reference by annotation" model specified here is 290 applicable only to published Standards-Track RFCs at lower maturity 291 levels. 293 Obviously, such downward references are part of the relevant source 294 document at IETF Last Call and subject to comments from the 295 community. 297 Advancing documents, when appropriate, is still strongly preferred to 298 the use of either this procedure or the one specified in Section 4.2. 299 This specification does not impose a specific test or requirement to 300 determine appropriateness. This is partially because it would be 301 impossible to do so for the general case, but more so because the 302 intention is to permit the IESG and the community to balance the 303 importance of getting a source document published against the time 304 and difficulty associated with upgrading a target document. That 305 requirement is intended to be less stringent than the one of 306 Section 4.2. 308 6. Non-IETF Target Documents 310 A reference to a non-IETF document provides a few challenges relative 311 to the RFC series: 313 * its development may not have been as rigorous as the Standards- 314 Track document referencing it; 316 * the actual reference to it (e.g., a web link) may have dubious 317 stability; 319 * it may be subject to unexpected revision in situ; or 321 * it may not be freely available. 323 The IESG may, at its discretion, establish policies regarding 324 external documents referenced normatively by Standards-Track RFCs in 325 light of these challenges. Such policies are to be developed with 326 solicitation of community input. 328 At a minimum, authors/editors of source documents need to secure 329 freely available copies of the target documents for use by all 330 anticipated reviewers during the source document's life cycle, which 331 includes working group participants, any member of the community that 332 chooses to participate in Last Call discussions, area review teams, 333 IANA expert reviewers, and members of the IESG. The mechanism for 334 acquiring access to those documents is to be be specified in the 335 shepherd writeup. 337 7. Downref Registry 339 The IETF has previously established a registry of downrefs to RFCs 340 that have been previously waived by the IESG in the manner described 341 in Section 4.2. The registry includes the name of the referenced RFC 342 and the Internet-Draft whose publication resulted it its addition to 343 the registry. The IESG is responsible for the maintenance of this 344 registry, adding new entries to it as appropriate. 346 Going forward, new registry entries should also record the reason the 347 registry addition was made, and the name of the Area Director making 348 the new entry. 350 Note that there is currently no registry of downrefs to non-IETF 351 documents. 353 8. Security Considerations 355 This document is not known to create any new vulnerabilities for the 356 Internet. On the other hand, inappropriate or excessive use of these 357 processes might be considered a downgrade attack on the quality of 358 IETF standards or, worse, on the rigorous review of security aspects 359 of standards. 361 9. References 363 9.1. Normative References 365 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 366 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 367 . 369 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 370 Documents may Refer Normatively to Documents at a Lower 371 Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December 372 2004, . 374 [RFC4897] Klensin, J. and S. Hartman, "Handling Normative References 375 to Standards-Track Documents", BCP 97, RFC 4897, 376 DOI 10.17487/RFC4897, June 2007, 377 . 379 9.2. Informative References 381 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 382 DOI 10.17487/RFC1321, April 1992, 383 . 385 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 386 Hashing for Message Authentication", RFC 2104, 387 DOI 10.17487/RFC2104, February 1997, 388 . 390 [RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, 391 "Document Shepherding from Working Group Last Call to 392 Publication", RFC 4858, DOI 10.17487/RFC4858, May 2007, 393 . 395 [RFC8067] Leiba, B., "Updating When Standards Track Documents May 396 Refer Normatively to Documents at a Lower Level", BCP 97, 397 RFC 8067, DOI 10.17487/RFC8067, January 2017, 398 . 400 Appendix A. Changes 402 The following are the changes in this document relative to the 403 current state of BCP 97: 405 * Apply erratum #2793. 407 * Remove references to RFC 1818, which is historic. 409 * Describe the downref registry's format and ownership. 411 * Discuss restricted-access documents. 413 * Allow for skipping downref annotations when the target document is 414 understood to be stable. 416 * Stronger language against using this process when advancing the 417 target document is The Right Thing To Do. 419 Appendix B. Acknowledgments 421 This editor offers a salute to the authors of and contributors to RFC 422 3967, RFC 4897, and RFC 8067: Randy Bush, Thomas Narten, John 423 Klensin, Sam Hartman, and Barry Leiba. 425 This revision benefited from contributions by Scott Bradner, Brian 426 Campbell, Russ Housley, John Klensin, Michael Richardson, and Rich 427 Salz. 429 Author's Address 431 Murray Kucherawy (editor) 433 Email: superuser@gmail.com