idnits 2.17.00 (12 Aug 2021) /tmp/idnits50555/draft-iab-streams-headers-boilerplates-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 430. 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 Copyright Line does not match the current year -- 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 (June 27, 2008) is 5075 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: 'TBD' is mentioned on line 324, but not defined == Unused Reference: 'RFC3978' is defined on line 358, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Daigle, Ed. 3 Internet-Draft 4 Intended status: BCP O. Kolkman, Ed. 5 Expires: December 29, 2008 Internet Architecture Board 6 (IAB) 7 June 27, 2008 9 On RFC Streams Headers and Boilerplates 10 draft-iab-streams-headers-boilerplates-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 29, 2008. 37 Abstract 39 RFC documents contain a number of fixed elements such as the title 40 page header, standard boilerplates and a standard acknowledgement 41 section. This document describes them and introduces some updates to 42 reflect current usage and requirements of RFC publication. In 43 particular, this updated structure is intended to communicate clearly 44 the source of RFC creation and review. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. RFC Streams and Internet Standards . . . . . . . . . . . . . . 3 50 3. RFC Structural Elements . . . . . . . . . . . . . . . . . . . 4 51 3.1. The title page header . . . . . . . . . . . . . . . . . . 4 52 3.2. The Status of this Memo . . . . . . . . . . . . . . . . . 6 53 3.3. Additional Notes . . . . . . . . . . . . . . . . . . . . . 8 54 4. Security considerations . . . . . . . . . . . . . . . . . . . 8 55 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 56 6. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 8 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 61 Appendix B. Document Editing Details . . . . . . . . . . . . . . 9 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 63 Intellectual Property and Copyright Statements . . . . . . . . . . 11 65 1. Introduction 67 RFCs published before this document (e.g. the one immeditatly prior 68 to this one [RFCXXXX-1]) (??? or is it prior to approval of this 69 document?) contained a number of elements that were there for 70 historical, practical, and legal reasons. They also contained 71 boilerplate material to clearly indicate the status of the document 72 and possibly contained "Notes" to indicate how the document interacts 73 with IETF standard track documents. 75 As the RFC Series has evolved over the years, there has been 76 increasing concern over appropriate labelling of the publications to 77 make clear the status of each RFC and the status of the work it 78 describes. Chiefly, there is a requirement that RFCs published as 79 part of the IETF's review process not be easily confused with RFCs 80 that may have had a very different review and approval process. 81 Various adjustments have been made over the years, including evolving 82 text of "Notes" included in the published RFC. 84 With the definition of the different RFC streams [RFC4844] it is 85 appropriate to formalize the definition of the various pieces of 86 standard RFC boilerplate and introduce some adjustments to ensure 87 better clarity of expression of document status, aligned with the 88 review and approval processes defined for each stream. 90 This memo identifies and describes the common elements of RFC 91 boilerplate structure, and provides a comprehensive approach to 92 updating and using those elements to communicate, with clarity, RFC 93 document and content status. Most of the historical structure 94 information is collected from [RFC2223]. 96 2. RFC Streams and Internet Standards 98 Users of RFCs should be aware that while all Internet standards- 99 related documents are published as RFCs, not all RFCs are Internet 100 standards-related documents. 102 The IETF is responsible for maintaining the Internet Standards 103 Process, which includes the requirements for developing, reviewing 104 and approving Standards Track and BCP RFCs. These, and any other 105 standards-related documents (Informational or Experimental) are 106 reviewed by appropriate IETF bodies and published as part of the IETF 107 Stream. 109 Documents published in streams other than the IETF Stream are not 110 reviewed by the IETF for such things as security, congestion control, 111 or inappropriate interaction with deployed protocols. They have also 112 not been subject to IESG approval, including an IETF-wide last call. 113 Therefore, the IETF disclaims, for any of the non-IETF Stream 114 documents, any knowledge of the fitness of those RFCs for any 115 purpose. 117 Refer to [RFC2026] and [RFC4844] and their succession for current 118 detail of IETF process and RFCs streams. 120 3. RFC Structural Elements 122 3.1. The title page header 124 An RFC title page header can be described as follows: 126 ------------------------------------------------------------------------ 127 128 Request for Comments: 129 [ ] [more author info as appropriate] 130 [:] 131 Category: 132 ISSN: [TBD] 134 ------------------------------------------------------------------------ 136 For example, a sample earlier RFC header is as follows: 138 ------------------------------------------------------------------------ 139 Network Working Group T. Dierks 140 Request for Comments: 4346 Independent 141 Obsoletes: 2246 E. Rescorla 142 Category: Standards Track RTFM, Inc. 143 April 2006 145 ------------------------------------------------------------------------ 147 The right column contains author name and affiliation information as 148 well as RFC publication date. Conventions and restrictions for these 149 elements are described in RFC style norms and some individual stream 150 definitions. 152 This memo is primarily concerned with the information in left column: 154 This describes the area where the work originates. 155 Historically, all RFCs were labeled Network Working Group. 156 "Network Working Group" refers to the original version of today's 157 IETF when people from the original set of Arpanet sites and 158 whomever else was interested -- the meetings were open -- got 159 together to discuss, design and document proposed protocols.' 160 [Steve Crocker, private communication]. Here, we obsolete the 161 term "Network Working Group" in order to indicate the originating 162 stream. 164 The is the name of the RFC stream, as defined in 165 [RFC4844] and its successors. At the time of this publication, 166 the streams, and therefore the possible entries are: 168 * IETF Stream 170 * IAB Stream 172 * IRTF Stream 174 * Independent Stream 176 Request for Comments: This indicates the RFC number, 177 assigned by the RFC Editor upon publication of the document. This 178 element is unchanged. 180 Some document categories are also 181 labeled as a subseries of RFCs. These elements appear as 182 appropriate for such categories, indicating the subseries and the 183 documents number within that series. Currently, there are 184 subseries for BCPs, STDs and FYIs. These subseries numbers may 185 appear in several RFCs. For example, when a new RFC updates an 186 old one, the same subseries number is used. Also, several RFCs 187 may be assigned the same subseries number: a single STD, for 188 example, may be composed of several RFCs, each of which will bear 189 the same STD number. This element is unchanged. 191 [:] Some relations between RFCs in the 192 series are explicitly noted in the RFC header. For example, a new 193 RFC may update one or more earlier RFCs. Current relationships 194 are "Updates" and "Obsoletes". This document introduces the new 195 relation "Clarifies" which can be used when a new RFC updates a 196 previous RFC without making any normative changes. 198 Category: This indicates the RFC document category of the 199 publication. These are defined in [RFC2026]. Currently, this is 200 always one of: Standards Track, Best Current Practice, 201 Experimental, Informational, or Historic. This element is 202 unchanged. 204 The ISSN number is the International Standard Serial 205 Number[ISO3297]. Once such number has been assigned to the RFC 206 series this element will appear here. 208 3.2. The Status of this Memo 210 The "Status of This Memo" describes the category of the RFC, 211 including the distribution statement. This text is included 212 irrespective of the source stream of the RFC. 214 Going forward, the "Status of This Memo" will start with a single 215 line describing the status. It will also include a statement 216 describing the the stream-specific review of the material (which is 217 stream-dependent). This is an important component of status, insofar 218 as it clarifies the breadth and depth of review, and gives the reader 219 an understanding of how to consider its content. 221 The first paragraph of the Status of this Memo section contains a 222 single line. It depends on the category of the document. 224 This memo is an Internet Standards Track document. 226 This memo is documents a Best Current Practice 228 This memo is not an Internet Standard Track specification, it is 229 published for Informational purposes. 231 The second paragraph contains the current text [RFC2223] describing 232 categories is as follows: 234 Standards Track: "This document specifies an Internet standards 235 track protocol for the Internet community, and requests discussion 236 and suggestions for improvements. Please refer to the current 237 edition of the "Internet Official Protocol Standards" (STD 1) for 238 the standardization state and status of this protocol. 239 Distribution of this memo is unlimited." 241 Best Current Practice: "This document specifies an Internet Best 242 Current Practices for the Internet Community, and requests 243 discussion and suggestions for improvements. Distribution of this 244 memo is unlimited." 246 Experimental: "This memo defines an Experimental Protocol for the 247 Internet community. This memo does not specify an Internet 248 standard of any kind. Discussion and suggestions for improvement 249 are requested. Distribution of this memo is unlimited." 251 Informational: "This memo provides information for the Internet 252 community. This memo does not specify an Internet standard of any 253 kind. Distribution of this memo is unlimited." 255 The third paragraph of the "Status of This Memo" will now include a 256 paragraph describing the type of review and exposure the document has 257 received. This is defined on a per-stream basis. Going forward, 258 these paragraphs will be defined as part of RFC stream definition. 260 Initial paragraphs for the existing streams are: 262 IETF Stream: "This document is a product of the Internet Engineering 263 Task Force (IETF). Per the IETF's specification process, this 264 document represents a consensus of the IETF community. It has 265 received public review and has been approved for publication by 266 the IESG." 268 IAB Stream: "This document is a product of the Internet Architecture 269 Board (IAB), and represents information that the IAB has deemed 270 valuable to provide for permanent record. This document has been 271 approved for publication by the IAB and is therefore not a 272 candidate for any level of Internet Standard, see section 273 Section 2 of RFCXXXX." 275 IRTF Stream: "This document is a product of the Internet Research 276 Task Force (IRTF). The IRTF publishes the results of Internet- 277 related research and development activities. These results might 278 not be suitable for deployment. This document has been approved 279 for publication by the IRSG and is therefore not a candidate for 280 any level of Internet Standard, see section Section 2 of RFCXXXX." 282 In addition a sentence indicating the consensus base within the 283 IRTF may be added: "This RFC represents the consensus of the 284 Research Group of the Internet Research Task Force 285 (IRTF)." or alternatively "This RFC represents the individual 286 opinion(s) of one or more members of the Research 287 Group of the Internet Research Task Force (IRTF)". 289 Independent Stream: "This document is a contribution to the RFC 290 Series, independently of any other RFC stream. The RFC Editor has 291 chosen to publish this document at its discretion and makes no 292 statement about its value for implementation or deployment. It is 293 therefore not a candidate for any level of Internet Standard, see 294 section Section 2 of RFCXXXX." 296 3.3. Additional Notes 298 Exceptionally, a review and publication process may prescribe 299 additional notes that will appear as labelled notes after the "Status 300 of This Memo". 302 While this has been a common feature of recent RFCs, it is the goal 303 of this exercise to make the overall RFC structure adequately clear 304 to remove the need for such notes, or at least make their usage truly 305 exceptional. 307 4. Security considerations 309 This document tries to clarify the descriptions of the status of an 310 RFC. Misunderstanding the status of a memo could cause 311 interoperability problems, hence security and stability problems. 313 5. IANA considerations 315 None. 317 6. RFC Editor Considerations 319 [To Be Removed before publication] 321 The documents has two sections, including this one that need to be 322 removed after publication. 324 ISSN: [TBD] is where the International Standards Serial Number will 325 need to be appear once assigned. 327 The number "XXXX" is to be replaced with RFC number of this memo. 329 The Reference RFCXXXX-1 is to be replaced with the details of the RFC 330 published prior to this publication. 332 7. References 334 7.1. Normative References 336 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 337 3", BCP 9, RFC 2026, October 1996. 339 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 340 RFC 2223, October 1997. 342 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 343 Series and RFC Editor", RFC 4844, July 2007. 345 7.2. Informative References 347 [ISO3297] Technical Committee ISO/TC 46, Information and 348 documentation, Subcommittee SC 9, Identification and 349 description., "Information and documentation - 350 International standard serial number (ISSN)", 09 2007. 352 [RFCXXXX-1] 353 Blaaa Fooo, "[The RFC previous to this one]", --- 2007. 355 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 356 June 1999. 358 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 359 RFC 3978, March 2005. 361 Appendix A. Acknowledgements 363 Thanks to Bob Braden, Brian Carpenter, Steve Crocker and John Klensin 364 who provided background information and inspiration. 366 Various people have made suggestions that improved the document. 367 Among them are: Loa Andersson, Lars Eggert, Russ Housley, David Oran. 369 This document was produced using the xml2rfc tool [RFC2629]. 371 Appendix B. Document Editing Details 373 [To Be Removed before publication] 375 This section will contain a discription of the changes between the 376 various versions of this document. 378 Authors' Addresses 380 Leslie Daigle (editor) 382 Email: daigle@isoc.org, leslie@thinkingcat.com 383 Olaf M. Kolkman (editor) 384 Internet Architecture Board 386 Email: olaf@nlnetlabs.nl 388 Internet Architecture Board 390 Email: iab@iab.org 392 Full Copyright Statement 394 Copyright (C) The IETF Trust (2008). 396 This document is subject to the rights, licenses and restrictions 397 contained in BCP 78, and except as set forth therein, the authors 398 retain all their rights. 400 This document and the information contained herein are provided on an 401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 403 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 404 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 405 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 408 Intellectual Property 410 The IETF takes no position regarding the validity or scope of any 411 Intellectual Property Rights or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; nor does it represent that it has 415 made any independent effort to identify any such rights. Information 416 on the procedures with respect to rights in RFC documents can be 417 found in BCP 78 and BCP 79. 419 Copies of IPR disclosures made to the IETF Secretariat and any 420 assurances of licenses to be made available, or the result of an 421 attempt made to obtain a general license or permission for the use of 422 such proprietary rights by implementers or users of this 423 specification can be obtained from the IETF on-line IPR repository at 424 http://www.ietf.org/ipr. 426 The IETF invites any interested party to bring to its attention any 427 copyrights, patents or patent applications, or other proprietary 428 rights that may cover technology that may be required to implement 429 this standard. Please address the information to the IETF at 430 ietf-ipr@ietf.org.