idnits 2.17.1 draft-iab-rfc5741bis-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 12, 2015) is 3056 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5378' is defined on line 398, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3 (Obsoleted by RFC 10) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 5143 (Obsoleted by RFC 4842) -- Obsolete informational reference (is this intentional?): RFC 5741 (Obsoleted by RFC 7841) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Halpern, Ed. 3 Internet-Draft 4 Obsoletes: 5741 (if approved) L. Daigle, Ed. 5 Intended status: Informational 6 Expires: June 14, 2016 O. Kolkman, Ed. 7 Internet Society 8 Internet Architecture Board 9 (IAB) 10 December 12, 2015 12 On RFC Streams, Headers, and Boilerplates 13 draft-iab-rfc5741bis-01 15 Abstract 17 RFC documents contain a number of fixed elements such as the title 18 page header, standard boilerplates and copyright/IPR statements. 19 This document describes them and introduces some updates to reflect 20 current usage and requirements of RFC publication. In particular, 21 this updated structure is intended to communicate clearly the source 22 of RFC creation and review. This document obsoletes RFC 5741, moving 23 detailed content to an IAB web page and preparing for more flexible 24 output formats. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 14, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. RFC Streams and Internet Standards . . . . . . . . . . . . . 3 62 3. RFC Structural Elements . . . . . . . . . . . . . . . . . . . 4 63 3.1. The title page header . . . . . . . . . . . . . . . . . . 4 64 3.2. The Status of this Memo . . . . . . . . . . . . . . . . . 5 65 3.3. Paragraph 1 . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. Paragraph 2 . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.5. Paragraph 3 . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.6. Noteworthy . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Additional Notes . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Other structural information in RFCs . . . . . . . . . . . . 7 71 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 72 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 73 8. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 7 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 9.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Appendix A. IAB members at time of approval . . . . . . . . . . 10 78 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10 79 Appendix C. Initial Formating Details . . . . . . . . . . . . . 10 80 C.1. RFC Title Page Header . . . . . . . . . . . . . . . . . . 10 81 C.2. Constructing a "Status of this Memo" Section . . . . . . 11 82 C.2.1. First Paragraph . . . . . . . . . . . . . . . . . . . 11 83 C.2.2. Second Paragraph . . . . . . . . . . . . . . . . . . 12 84 C.2.3. Third Paragraph . . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 Previously RFCs (e.g. [RFC4844]) contained a number of elements that 90 were there for historical, practical, and legal reasons. They also 91 contained boilerplate material to clearly indicate the status of the 92 document and possibly contained "Notes" to indicate how the document 93 interacts with IETF Standards-Track documents. 95 As the RFC Series has evolved over the years, there has been 96 increasing concern over appropriate labelling of the publications to 97 make clear the status of each RFC and the status of the work it 98 describes. Chiefly, there is a requirement that RFCs published as 99 part of the IETF's review process not be easily confused with RFCs 100 that may have had a very different review and approval process. 101 Various adjustments have been made over the years, including evolving 102 text of "Notes" included in the published RFC. 104 With the definition of the different RFC streams [RFC4844], it is 105 appropriate to formalize the definition of the various pieces of 106 standard RFC boilerplate and introduce some adjustments to ensure 107 better clarity of expression of document status, aligned with the 108 review and approval processes defined for each stream. 110 This memo identifies and describes the common elements of RFC 111 boilerplate structure. It describes the content required for each 112 kind of information. Details of exact textual and layout 113 requirements are left to a web page maintained by the IAB, with due 114 consultation with the community, for ease of maintenance. This 115 document obsoletes [RFC5741]. 117 The changes introduced by this memo should be implemented as soon as 118 practically possible after the document has been approved for 119 publication. 121 2. RFC Streams and Internet Standards 123 Users of RFCs should be aware that while all Internet Standards- 124 related documents are published as RFCs, not all RFCs are Internet 125 Standards-related documents. 127 The IETF is responsible for maintaining the Internet Standards 128 Process, which includes the requirements for developing, reviewing 129 and approving Standards Track and BCP RFCs. These, and any other 130 standards-related documents (Informational or Experimental) are 131 reviewed by appropriate IETF bodies and published as part of the IETF 132 Stream. 134 Documents published in streams other than the IETF Stream are not 135 generally reviewed by the IETF for such things as security, 136 congestion control, or inappropriate interaction with deployed 137 protocols. They have also not been subject to approval by the 138 Internet Engineering Steering Group (IESG), including an IETF-wide 139 last call. Therefore, the IETF disclaims, for any of the non-IETF 140 Stream documents, any knowledge of the fitness of those RFCs for any 141 purpose. 143 Refer to [RFC2026], [RFC5742], [RFC4844], [RFC6410], and [RFC7127] 144 and their successors for current details of the IETF process and RFC 145 streams. 147 3. RFC Structural Elements 149 This section describes the elements that are commonly found in RFCs 150 published today. This document specifies information that is 151 required in these publications. Exact specification of the textual 152 values required therein are provided by an IAB web page 154 (URL to be provided during AUTH48). 156 As noted above, this web page is maintained by the IAB with due 157 consultation with the community. Initial proposed text to be used in 158 that web page is included in Appendix C. 160 3.1. The title page header 162 The information at the front of the RFC includes the name and 163 affiliation of the authors as well as the RFC publication month and 164 year. 166 There is a set of additional information that is needed at the front 167 of the RFC. Historically, this has been presented with the 168 information below in a left hand column, and the author related 169 information described above in the right. 171 This describes the area where the work originates. 172 Historically, all RFCs were labeled Network Working Group. 173 "Network Working Group" refers to the original version of today's 174 IETF when people from the original set of ARPANET sites and 175 whomever else was interested -- the meetings were open -- got 176 together to discuss, design and document proposed protocols 177 [RFC0003]. Here, we obsolete the term "Network Working Group" in 178 order to indicate the originating stream. 180 The is the name of the RFC stream, as defined in 181 [RFC4844] and its successors. At the time of this publication, 182 the streams, and therefore the possible entries are: 184 * Internet Engineering Task Force 186 * Internet Architecture Board 188 * Internet Research Task Force 190 * Independent Submission 192 Request for Comments: This indicates the RFC number, 193 assigned by the RFC Editor upon publication of the document. This 194 element is unchanged. 196 Some document categories are also 197 labeled as a subseries of RFCs. These elements appear as 198 appropriate for such categories, indicating the subseries and the 199 documents number within that series. Currently, there are 200 subseries for BCPs [RFC2026] and STDs [RFC1311]. These subseries 201 numbers may appear in several RFCs. For example, when a new RFC 202 obsoletes or updates an old one, the same subseries number is 203 used. Also, several RFCs may be assigned the same subseries 204 number: a single STD, for example, may be composed of several 205 RFCs, each of which will bear the same STD number. This element 206 is unchanged. 208 [:] Some relations between RFCs in the 209 series are explicitly noted in the RFC header. For example, a new 210 RFC may update one or more earlier RFCs. Currently two 211 relationships are defined: "Updates", and "Obsoletes" [RFC7322]. 212 Variants like "Obsoleted by" are also used (e.g in [RFC5143]). 213 Other types of relationships may be defined by the RFC Editor and 214 may appear in future RFCs. 216 Category: This indicates the initial RFC document 217 category of the publication. These are defined in [RFC2026]. 218 Currently, this is always one of: Standards Track, Best Current 219 Practice, Experimental, Informational, or Historic. This element 220 is unchanged. 222 3.2. The Status of this Memo 224 The "Status of This Memo" describes the category of the RFC, 225 including the distribution statement. 227 The "Status of This Memo" will start with a single sentence 228 describing the status. It will also include a statement describing 229 the stream-specific review of the material (which is stream- 230 dependent). This is an important component of status, insofar as it 231 clarifies the breadth and depth of review, and gives the reader an 232 understanding of how to consider its content. 234 3.3. Paragraph 1 236 The first paragraph of the Status of this Memo section contains a 237 single sentence, clearly standing out. The sentence will clearly 238 identify the stream-specific status of the document. The text to be 239 used is defined by the stream, with IAB and RFC Series Editor review 240 for clarity. 242 3.4. Paragraph 2 244 The second paragraph of the "Status of This Memo" will include a 245 paragraph describing the type of review and exposure the document has 246 received. This is defined on a per-stream basis, subject to general 247 review and oversight by the RFC Editor and IAB. The IAB defines a 248 specific structure defined to ensure there is clarity about review 249 processes and document types. 251 3.5. Paragraph 3 253 The boilerplate ends with a reference to where further relevant 254 information can be found. This information may include, subject to 255 the RFC Editor's discretion, information whether the RFC has been 256 updated or obsoleted, the RFC's origin, a listing of possible errata, 257 information about how to provide feedback and suggestion, and 258 information on how to submit errata as described in 259 [I-D.rfc-editor-errata-process]. The exact wording and URL is 260 subject to change (at the RFC Editor's discretion), but current text 261 is: 263 "Information about the current status of this document, any errata, 264 and how to provide feedback on it may be obtained at http://www.rfc- 265 editor.org//rfc.html" 267 3.6. Noteworthy 269 Note that the texts in paragraph 1 and 2 of the boilerplate indicate 270 the initial status of a document. During their lifetime documents 271 can change status to e.g. Historic. This cannot be reflected in the 272 document itself and will need be reflected in the information refered 273 to in Section 5. 275 4. Additional Notes 277 Exceptionally, a review and publication process may prescribe 278 additional notes that will appear as labelled notes after the "Status 279 of This Memo". 281 While this has been a common feature of recent RFCs, it is the goal 282 of this document to make the overall RFC structure adequately clear 283 to remove the need for such notes, or at least make their usage truly 284 exceptional. 286 5. Other structural information in RFCs 288 RFCs contain other structural informational elements. The RFC Editor 289 is responsible for the positioning and layout of these structural 290 elements. Note also that new elements may be introduced or obsoleted 291 using a process consistent with [RFC4844]. These additions may or 292 may not require documentation in an RFC. 294 Currently the following structural information is available or is 295 being considered for inclusion in RFCs: 297 Copyright Notice A copyright notice with a reference to BCP78 298 [BCP78] and an Intellectual Property statement referring to BCP78 299 and BCP79 [BCP79]. The content of these statements are defined by 300 those BCPs. 302 ISSN The International Standard Serial Number [ISO.3297.2007]: ISSN 303 2070-1721. The ISSN uniquely identifies the RFC series as title 304 regardless of language or country in which it is published. The 305 ISSN itself has no significance other than the unique 306 identification of a serial publication. 308 6. Security considerations 310 This document tries to clarify the descriptions of the status of an 311 RFC. Misunderstanding the status of a memo could cause 312 interoperability problems, hence security and stability problems. 314 7. IANA considerations 316 None. 318 8. RFC Editor Considerations 320 The RFC Editor is responsible for maintaining the consistency of the 321 RFC series. To that end the RFC Editor maintains a style manual 322 [RFC7322]. In this memo we mention a few explicit structural 323 elements that the RFC editor needs to maintain. The conventions for 324 the content and use of all current and future elements are to be 325 documented in the style manual. 327 Adding a reference to the stream in the header of RFCs is only one 328 method for clarifying from which stream an RFC originated. The RFC 329 editor is encouraged to add such indication in e.g. indices and 330 interfaces. 332 [The rest of this section contains specific instructions towards 333 editing this document and can be removed before publication] 334 This section of the document needs to be removed before publication. 336 This memo introduces a number of modifications that will have to be 337 implemented in various tools, such as the xml2rfc tool, the nit 338 tracker and the rfc-erratum portal. 340 The number "XXXX" is to be replaced with RFC number of this memo. 342 In section Section 5: For the final publication, it should be 343 warranted that the ISSN is *not* split by a line break, for clarity. 345 9. References 347 9.1. Normative References 349 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 350 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 351 . 353 [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for 354 Handling of Independent and IRTF Stream Submissions", 355 BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, 356 . 358 9.2. Informative References 360 [ISO.3297.2007] 361 Technical Committee ISO/TC 46, Information and 362 documentation, Subcommittee SC 9, Identification and 363 description., "Information and documentation - 364 International standard serial number (ISSN)", ISO Standard 365 3297, 09 2007. 367 [RFC0003] Crocker, S., "Documentation conventions", RFC 3, 368 DOI 10.17487/RFC0003, April 1969, 369 . 371 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, 372 DOI 10.17487/RFC1311, March 1992, 373 . 375 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 376 DOI 10.17487/RFC2629, June 1999, 377 . 379 [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF 380 Technology", BCP 79, RFC 3979, DOI 10.17487/RFC3979, March 381 2005, . 383 [RFC4749] Sollaud, A., "RTP Payload Format for the G.729.1 Audio 384 Codec", RFC 4749, DOI 10.17487/RFC4749, October 2006, 385 . 387 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 388 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 389 July 2007, . 391 [RFC5143] Malis, A., Brayley, J., Shirron, J., Martini, L., and S. 392 Vogelsang, "Synchronous Optical Network/Synchronous 393 Digital Hierarchy (SONET/SDH) Circuit Emulation Service 394 over MPLS (CEM) Encapsulation", RFC 5143, 395 DOI 10.17487/RFC5143, February 2008, 396 . 398 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 399 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 400 DOI 10.17487/RFC5378, November 2008, 401 . 403 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 404 Headers, and Boilerplates", RFC 5741, 405 DOI 10.17487/RFC5741, December 2009, 406 . 408 [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the 409 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 410 DOI 10.17487/RFC6410, October 2011, 411 . 413 [RFC7127] Kolkman, O., Bradner, S., and S. Turner, "Characterization 414 of Proposed Standards", BCP 9, RFC 7127, 415 DOI 10.17487/RFC7127, January 2014, 416 . 418 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 419 DOI 10.17487/RFC7322, September 2014, 420 . 422 [I-D.rfc-editor-errata-process] 423 Ginoza, S., Hagens, A., and R. Braden, "RFC Editor 424 Proposal for Handling RFC Errata", draft-rfc-editor- 425 errata-process-02 (work in progress), May 2008. 427 [BCP78] Bradner, S., Ed. and J. Contreras, Ed., "Rights 428 Contributors Provide to the IETF Trust", BCP 78, November 429 2008. 431 At the moment of publication:[RFC5378] 433 [BCP79] Bradner, S., Ed. and T. Narten, Ed., "Intellectual 434 Property Rights in IETF Technology", BCP 79, April 2007. 436 At the moment of publication:[RFC3979]and[RFC4749] 438 Appendix A. IAB members at time of approval 440 The IAB members at the time this memo was approved were (in 441 alphabetical order): 443 Appendix B. Acknowledgements 445 Thanks to Bob Braden, Brian Carpenter, Steve Crocker, Sandy Ginoza, 446 and John Klensin who provided background information and inspiration. 448 Thanks to the members of the RFC Series Oversight Committee (RSOC) 449 for assistance and review: Alexey Melnikov, Nevil Brownlee, Bob 450 Hinden, Sarah Banks, Robert Sparks, and Joe Hildebrand. 452 Various people have made suggestions that improved the document. 453 Among them are: Lars Eggert, Alfred Hoenes, and Joe Touch. 455 This document was produced using the xml2rfc tool [RFC2629]. 457 Appendix C. Initial Formating Details 459 This section provides suggested starting text for the use of the IAB 460 in order to simplify populating the web page to be used to maintain 461 the list of required verbiage. 463 C.1. RFC Title Page Header 465 An RFC title page header can be described as follows: 467 ------------------------------------------------------------------------ 468 469 Request for Comments: [] 470 [ ] [more author info as appropriate] 471 [:] 472 Category: 473 475 ------------------------------------------------------------------------ 477 For example, a sample earlier RFC header is as follows: 479 ------------------------------------------------------------------------ 480 Network Working Group T. Dierks 481 Request for Comments: 4346 Independent 482 Obsoletes: 2246 E. Rescorla 483 Category: Standards Track RTFM, Inc. 484 April 2006 486 ------------------------------------------------------------------------ 488 C.2. Constructing a "Status of this Memo" Section 490 The following sections describe mandated text for use in specific 491 parts of the "Status of this Memo" portion of an RFC. For 492 convenience, the RFC Editor maintains example expansions of all 493 permutations of the paragraphs described in this document (at the 494 time of publication, at http://www.rfc-editor.org/materials/status- 495 memos.txt). When in conflict, these following sections are 496 authoritative. 498 C.2.1. First Paragraph 500 The following are the approved texts for use in the first paragraph 501 of the "Status of this Memo" portion of an RFC. See RFCXXXX section 502 3.3. 504 For 'Standards Track' documents: "This is an Internet Standards 505 Track document." 507 For 'Best Current Practices' documents: "This memo documents an 508 Internet Best Current Practice." 510 For other categories "This document is not an Internet Standards 511 Track specification; ." 513 For Informational, Experimental, Historic and future categories of 514 RFCs, the RFC editor will maintain an appropriate text for . Initial values are: 517 Informational: "it is published for informational purposes." 519 Historic: "it is published for the historical record." 521 Experimental: "it is published for examination, experimental 522 implementation, and evaluation." 524 C.2.2. Second Paragraph 526 See RFCXXXX section 3.4. 528 The second paragraph may include some text that is specific to the 529 initial document category, as follows: when a document is 530 Experimental or Historic the second paragraph opens with: 532 Experimental: "This document defines an Experimental Protocol for 533 the Internet community." 535 Historic: "This document defines a Historic Document for the 536 Internet community." 538 The text that follows is stream dependent -- these are initial values 539 and may be updated by stream definition document updates and recorded 540 by the IAB on the web page.. 542 IETF Stream: "This document is a product of the Internet Engineering 543 Task Force (IETF)." 545 If there has been an IETF consensus call per IETF process, this 546 additional text should be added: "It represents the consensus of 547 the IETF community. It has received public review and has been 548 approved for publication by the Internet Engineering Steering 549 Group (IESG)." If there has not been such a consensus call then 550 this simply reads: "It has been approved for publication by the 551 Internet Engineering Steering Group (IESG)." 553 IAB Stream: "This document is a product of the Internet Architecture 554 Board (IAB), and represents information that the IAB has deemed 555 valuable to provide for permanent record." 557 If the document represents IAB consensus, this additional text 558 should be added: "It represents the consensus of the Internet 559 Architecture Board (IAB)." 561 IRTF Stream: "This document is a product of the Internet Research 562 Task Force (IRTF). The IRTF publishes the results of Internet- 563 related research and development activities. These results might 564 not be suitable for deployment." 566 In addition a sentence indicating the consensus base within the 567 IRTF may be added: "This RFC represents the consensus of the 568 Research Group of the Internet Research Task Force 569 (IRTF)." or alternatively "This RFC represents the individual 570 opinion(s) of one or more members of the Research 571 Group of the Internet Research Task Force (IRTF)". 573 Independent Submission Stream: "This is a contribution to the RFC 574 Series, independently of any other RFC stream. The RFC Editor has 575 chosen to publish this document at its discretion and makes no 576 statement about its value for implementation or deployment. 578 For non-IETF stream documents a reference to Section 2 of this RFC is 579 added with the following sentence: "Documents approved for 580 publication by the [stream approver -- currently, one of: "IAB", 581 "IRSG", or "RFC Editor"] are not a candidate for any level of 582 Internet Standard; see Section 2 of RFC XXXX." 584 For IETF stream documents a similar reference is added: "Further 585 information on [BCPs or Internet Standards] is available in Section 2 586 of RFC XXXX." for BCP and Standard Track documents; "Not all 587 documents approved by the IESG are candidate for any level of 588 Internet Standards; see Section 2 of RFC XXXX." for all other 589 categories. 591 C.2.3. Third Paragraph 593 See RFCXXXX section 3.5. 595 Authors' Addresses 597 Joel M. Halpern (editor) 599 Email: jmh@joelhalpern.com 601 Leslie Daigle (editor) 603 Email: ldaigle@thinkingcat.com 605 Olaf M. Kolkman (editor) 606 Internet Society 608 Email: kolkman@isoc.org 610 Internet Architecture Board 612 Email: iab@iab.org