idnits 2.17.00 (12 Aug 2021) /tmp/idnits49459/draft-iab-streams-headers-boilerplates-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 draft header indicates that this document updates RFC4844, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4844, updated by this document, for RFC5378 checks: 2006-05-23) -- 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 (March 2, 2009) is 4827 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5378' is defined on line 497, but no explicit reference was found in the text == Outdated reference: draft-housley-iesg-rfc3932bis has been published as RFC 5742 -- Obsolete informational reference (is this intentional?): RFC 3 (Obsoleted by RFC 10) -- Obsolete informational reference (is this intentional?): RFC 1150 (Obsoleted by RFC 6360) -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) -- 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) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 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 O. Kolkman, Ed. 4 Updates: 4844, 2223 5 (if approved) Internet Architecture Board 6 Intended status: Informational (IAB) 7 Expires: September 3, 2009 March 2, 2009 9 On RFC Streams, Headers, and Boilerplates 10 draft-iab-streams-headers-boilerplates-07 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 3, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 RFC documents contain a number of fixed elements such as the title 49 page header, standard boilerplates and copyright/IPR statements. 50 This document describes them and introduces some updates to reflect 51 current usage and requirements of RFC publication. In particular, 52 this updated structure is intended to communicate clearly the source 53 of RFC creation and review. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. RFC Streams and Internet Standards . . . . . . . . . . . . . . 3 59 3. RFC Structural Elements . . . . . . . . . . . . . . . . . . . 4 60 3.1. The title page header . . . . . . . . . . . . . . . . . . 4 61 3.2. The Status of this Memo . . . . . . . . . . . . . . . . . 6 62 3.2.1. Paragraph 1 . . . . . . . . . . . . . . . . . . . . . 6 63 3.2.2. Paragraph 2 . . . . . . . . . . . . . . . . . . . . . 6 64 3.2.3. Paragraph 3 . . . . . . . . . . . . . . . . . . . . . 8 65 3.2.4. Noteworthy . . . . . . . . . . . . . . . . . . . . . . 8 66 3.3. Additional Notes . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. Other structural information in RFCs . . . . . . . . . . . 9 68 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 69 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 9 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Appendix A. Some Example 'Status of this Memo' boilerplates . . . 12 75 A.1. IETF Standards Track . . . . . . . . . . . . . . . . . . . 12 76 A.2. IETF Experimental, with Consensus Call . . . . . . . . . . 12 77 A.3. IETF Experimental, No Consensus Call . . . . . . . . . . . 13 78 A.4. IAB Informational . . . . . . . . . . . . . . . . . . . . 13 79 A.5. IRTF Experimental . . . . . . . . . . . . . . . . . . . . 14 80 Appendix B. IAB members at time of approval . . . . . . . . . . . 15 81 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 15 82 Appendix D. Document Editing Details . . . . . . . . . . . . . . 15 83 D.1. version 00->01 . . . . . . . . . . . . . . . . . . . . . . 15 84 D.2. version 01->02 . . . . . . . . . . . . . . . . . . . . . . 16 85 D.3. version 02->03 . . . . . . . . . . . . . . . . . . . . . . 16 86 D.4. version 03->04 . . . . . . . . . . . . . . . . . . . . . . 16 87 D.5. version 04->05 . . . . . . . . . . . . . . . . . . . . . . 16 88 D.6. version 05->06 . . . . . . . . . . . . . . . . . . . . . . 17 89 D.7. version 06->07 . . . . . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 Previously RFCs (e.g. [RFC4844]) contained a number of elements that 95 were there for historical, practical, and legal reasons. They also 96 contained boilerplate material to clearly indicate the status of the 97 document and possibly contained "Notes" to indicate how the document 98 interacts with IETF Standards-Track documents. 100 As the RFC Series has evolved over the years, there has been 101 increasing concern over appropriate labelling of the publications to 102 make clear the status of each RFC and the status of the work it 103 describes. Chiefly, there is a requirement that RFCs published as 104 part of the IETF's review process not be easily confused with RFCs 105 that may have had a very different review and approval process. 106 Various adjustments have been made over the years, including evolving 107 text of "Notes" included in the published RFC. 109 With the definition of the different RFC streams [RFC4844], it is 110 appropriate to formalize the definition of the various pieces of 111 standard RFC boilerplate and introduce some adjustments to ensure 112 better clarity of expression of document status, aligned with the 113 review and approval processes defined for each stream. 115 This memo identifies and describes the common elements of RFC 116 boilerplate structure, and provides a comprehensive approach to 117 updating and using those elements to communicate, with clarity, RFC 118 document and content status. Most of the historical structure 119 information is collected from [RFC2223]. 121 The changes introduced by this memo should be implemented as soon as 122 practically possible after the document has been approved for 123 publication. 125 2. RFC Streams and Internet Standards 127 Users of RFCs should be aware that while all Internet Standards- 128 related documents are published as RFCs, not all RFCs are Internet 129 Standards-related documents. 131 The IETF is responsible for maintaining the Internet Standards 132 Process, which includes the requirements for developing, reviewing 133 and approving Standards Track and BCP RFCs. These, and any other 134 standards-related documents (Informational or Experimental) are 135 reviewed by appropriate IETF bodies and published as part of the IETF 136 Stream. 138 Documents published in streams other than the IETF Stream are not 139 generally reviewed by the IETF for such things as security, 140 congestion control, or inappropriate interaction with deployed 141 protocols. They have also not been subject to approval by the 142 Internet Engineering Steering Group (IESG), including an IETF-wide 143 last call. Therefore, the IETF disclaims, for any of the non-IETF 144 Stream documents, any knowledge of the fitness of those RFCs for any 145 purpose. 147 Refer to [RFC2026], [I-D.housley-iesg-rfc3932bis], and [RFC4844] and 148 their successors for current details of the IETF process and RFC 149 streams. 151 3. RFC Structural Elements 153 3.1. The title page header 155 An RFC title page header can be described as follows: 157 ------------------------------------------------------------------------ 158 159 Request for Comments: [] 160 [ ] [more author info as appropriate] 161 [:] 162 Category: 163 165 ------------------------------------------------------------------------ 167 For example, a sample earlier RFC header is as follows: 169 ------------------------------------------------------------------------ 170 Network Working Group T. Dierks 171 Request for Comments: 4346 Independent 172 Obsoletes: 2246 E. Rescorla 173 Category: Standards Track RTFM, Inc. 174 April 2006 176 ------------------------------------------------------------------------ 178 The right column contains author name and affiliation information as 179 well as the RFC publication month. Conventions and restrictions for 180 these elements are described in RFC style norms and some individual 181 stream definitions. 183 This section is primarily concerned with the information in the left 184 column: 186 This describes the area where the work originates. 187 Historically, all RFCs were labeled Network Working Group. 188 "Network Working Group" refers to the original version of today's 189 IETF when people from the original set of ARPANET sites and 190 whomever else was interested -- the meetings were open -- got 191 together to discuss, design and document proposed protocols 192 [RFC0003]. Here, we obsolete the term "Network Working Group" in 193 order to indicate the originating stream. 195 The is the name of the RFC stream, as defined in 196 [RFC4844] and its successors. At the time of this publication, 197 the streams, and therefore the possible entries are: 199 * Internet Engineering Task Force 201 * Internet Architecture Board 203 * Internet Research Task Force 205 * Independent 207 Request for Comments: This indicates the RFC number, 208 assigned by the RFC Editor upon publication of the document. This 209 element is unchanged. 211 Some document categories are also 212 labeled as a subseries of RFCs. These elements appear as 213 appropriate for such categories, indicating the subseries and the 214 documents number within that series. Currently, there are 215 subseries for BCPs [RFC2026], STDs [RFC1311], and FYIs [RFC1150]. 216 These subseries numbers may appear in several RFCs. For example, 217 when a new RFC obsoletes or updates an old one, the same subseries 218 number is used. Also, several RFCs may be assigned the same 219 subseries number: a single STD, for example, may be composed of 220 several RFCs, each of which will bear the same STD number. This 221 element is unchanged. 223 [:] Some relations between RFCs in the 224 series are explicitly noted in the RFC header. For example, a new 225 RFC may update one or more earlier RFCs. Currently two 226 relationships are defined: "Updates", and "Obsoletes" [RFC2223]. 227 Variants like "Obsoleted by" are also used (e.g in [RFC5143]). 228 Other types of relations may be defined elsewhere. 230 Category: This indicates the initial RFC document 231 category of the publication. These are defined in [RFC2026]. 232 Currently, this is always one of: Standards Track, Best Current 233 Practice, Experimental, Informational, or Historic. This element 234 is unchanged. 236 3.2. The Status of this Memo 238 The "Status of This Memo" describes the category of the RFC, 239 including the distribution statement. This text is included 240 irrespective of the source stream of the RFC. 242 From now on, the "Status of This Memo" will start with a single 243 sentence describing the status. It will also include a statement 244 describing the stream-specific review of the material (which is 245 stream-dependent). This is an important component of status, insofar 246 as it clarifies the breadth and depth of review, and gives the reader 247 an understanding of how to consider its content. 249 3.2.1. Paragraph 1 251 The first paragraph of the Status of this Memo section contains a 252 single sentence, clearly standing out. It depends on the category of 253 the document. 255 For 'Standards Track' documents: "This is an Internet Standards 256 Track document." 258 For 'Best Current Practices' documents: "This memo documents an 259 Internet Best Current Practice." 261 For other categories "This document is not an Internet Standards 262 Track specification; ." 264 For Informational, Experimental, Historic and future categories of 265 RFCs, the RFC editor will maintain an appropriate text for . Initial values are: 268 Informational: "it is published for informational purposes." 270 Historic: "it is published for the historical record." 272 Experimental: "it is published for examination, experimental 273 implementation, and evaluation." 275 3.2.2. Paragraph 2 277 The second paragraph of the "Status of This Memo" will now include a 278 paragraph describing the type of review and exposure the document has 279 received. This is defined on a per-stream basis, although there is a 280 specific structure defined here to ensure there is clarity about 281 review processes and document types. From now on, these paragraphs 282 will be defined as part of RFC stream definitions. Initial text, for 283 current streams, is provided below. 285 The paragraph may include some text that is specific to the initial 286 document category, as follows: when a document is Experimental or 287 Historic the second paragraph opens with: 289 Experimental: "This document defines an Experimental Protocol for 290 the Internet community." 292 Historic: "This document defines a Historic Document for the 293 Internet community." 295 The text that follows is stream dependent -- these are initial values 296 and may be updated by stream definition document updates. 298 IETF Stream: "This document is a product of the Internet Engineering 299 Task Force (IETF)." 301 If there has been an IETF consensus call per IETF process, an 302 additional sentence should be added: "It represents the consensus 303 of the IETF community. It has received public review and has been 304 approved for publication by the Internet Engineering Steering 305 Group (IESG)." If there has not been such a consensus call then 306 this simply reads: "It has been approved for publication by the 307 Internet Engineering Steering Group (IESG)." 309 IAB Stream: "This document is a product of the Internet Architecture 310 Board (IAB), and represents information that the IAB has deemed 311 valuable to provide for permanent record." 313 IRTF Stream: "This document is a product of the Internet Research 314 Task Force (IRTF). The IRTF publishes the results of Internet- 315 related research and development activities. These results might 316 not be suitable for deployment." 318 In addition a sentence indicating the consensus base within the 319 IRTF may be added: "This RFC represents the consensus of the 320 Research Group of the Internet Research Task Force 321 (IRTF)." or alternatively "This RFC represents the individual 322 opinion(s) of one or more members of the Research 323 Group of the Internet Research Task Force (IRTF)". 325 Independent Stream: "This is a contribution to the RFC Series, 326 independently of any other RFC stream. The RFC Editor has chosen 327 to publish this document at its discretion and makes no statement 328 about its value for implementation or deployment. 330 For non-IETF stream documents a reference to Section 2 of this RFC is 331 added with the following sentence: "Documents approved for 332 publication by the [stream approver -- currently, one of: "IAB", 333 "IRSG", or "RFC Editor"] are not a candidate for any level of 334 Internet Standard; see Section 2 of RFC XXXX." 336 For IETF stream documents a similar reference is added: "Further 337 information on [BCPs or Internet Standards] is available in Section 2 338 of RFC XXXX." for BCP and Standard Track documents; "Not all 339 documents approved by the IESG are candidate for any level of 340 Internet Standards; see Section 2 of RFC XXXX." for all other 341 categories. 343 3.2.3. Paragraph 3 345 The boilerplate ends with a reference to where further relevant 346 information can be found. As boilerplate, this text should not be 347 document-specific, although the material to which it refers may lead 348 to document-specific information. The exact wording is subject to 349 change (at the RFC Editor's discretion), but current text is: 351 "Information about the current status of this document, any errata, 352 and how to provide feedback on it may be obtained at 353 http://www.rfc-editor.org/status/.html" 355 where is one of: "ietf", "iab", "irtf", "independent". 357 3.2.4. Noteworthy 359 Note that the texts in paragraph 1 and 2 of the boilerplate indicate 360 the initial status of a document. During their lifetime documents 361 can change status to e.g. Historic. This cannot be reflected in the 362 document itself and will need be reflected in the information refered 363 to in Section 3.4. 365 3.3. Additional Notes 367 Exceptionally, a review and publication process may prescribe 368 additional notes that will appear as labelled notes after the "Status 369 of This Memo". 371 While this has been a common feature of recent RFCs, it is the goal 372 of this document to make the overall RFC structure adequately clear 373 to remove the need for such notes, or at least make their usage truly 374 exceptional. 376 3.4. Other structural information in RFCs 378 RFCs contain other structural informational elements. The RFC Editor 379 is responsible for the positioning and layout of these structural 380 element. Note also that new elements may be introduced or obsoleted 381 using a process consistent with [RFC4844]. These additions may or 382 may not require documentation in an RFC. 384 Currently the following structural information is available or is 385 being considered for inclusion in RFCs: 387 Copyright Notice A copyright notice with a reference to BCP78 388 [BCP78] and an Intellectual Property statement referring to BCP78 389 and BCP79 [BCP79]. The content of these statements are defined by 390 those BCPs. 392 ISSN The International Standard Serial Number [ISO3297]: ISSN 2070- 393 1721. The ISSN uniquely identifies the RFC series as title 394 regardless of language or country in which it is published. The 395 ISSN itself has no significance other than the unique 396 identification of a serial publication. 398 Updates to the RFC A reference identifying where more information 399 about the document can be found. This may include information 400 whether the RFC has been updated or obsoleted, the RFC's origin, a 401 listing of possible errata, information about how to provide 402 feedback and suggestion, and information on how to submit errata 403 as described in [I-D.rfc-editor-errata-process]. 405 4. Security considerations 407 This document tries to clarify the descriptions of the status of an 408 RFC. Misunderstanding the status of a memo could cause 409 interoperability problems, hence security and stability problems. 411 5. IANA considerations 413 None. 415 6. RFC Editor Considerations 417 The RFC Editor is responsible for maintaining the consistency of the 418 RFC series. To that end the RFC Editor maintains a style manual 419 [RFC-style]. In this memo we mention a few explicit structural 420 elements that the RFC editor needs to maintain. The conventions for 421 the content and use of all current and future elements are to be 422 documented in the style manual. 424 Adding a reference to the stream in the header of RFCs is only one 425 method for clarifying from which stream an RFC originated. The RFC 426 editor is encouraged to add such indication in e.g. indices and 427 interfaces. 429 [The rest of this section contains specific instructions towards 430 editing this document and can be removed before publication] 432 The documents has two sections, including this one that need to be 433 removed before publication as an RFC. This one and Appendix D. 435 This memo introduces a number of modifications that will have to be 436 implemented in various tools, such as the xml2rfc tool, the nit 437 tracker and the rfc-erratum portal. 439 The number "XXXX" is to be replaced with RFC number of this memo. 441 References [RFC-style], [BCP78] and [BCP79] have been constructed. 442 Please bring these in line with RFC Editorial conventions. 444 In section Section 3.4: For the final publication, it should be 445 warranted that the ISSN is *not* split by a line break, for clarity. 447 7. References 449 7.1. Normative References 451 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 452 3", BCP 9, RFC 2026, October 1996. 454 [I-D.housley-iesg-rfc3932bis] 455 Alvestrand, H. and R. Housley, "IESG Procedures for 456 Handling of Independent and IRTF Stream Submissions", 457 draft-housley-iesg-rfc3932bis-06 (work in progress), 458 November 2008. 460 7.2. Informative References 462 [ISO3297] Technical Committee ISO/TC 46, Information and 463 documentation, Subcommittee SC 9, Identification and 464 description. , "Information and documentation - 465 International standard serial number (ISSN)" , 09 2007 . 467 [RFC0003] Crocker, S. , "Documentation conventions" , RFC 3 , 468 April 1969 . 470 [RFC1311] Postel, J. , "Introduction to the STD Notes" , RFC 1311 471 , March 1992 . 473 [RFC1150] Malkin, G. and J. Reynolds , "FYI on FYI: Introduction 474 to the FYI Notes" , RFC 1150 , March 1990 . 476 [RFC2223] Postel, J. and J. Reynolds , "Instructions to RFC 477 Authors" , RFC 2223 , October 1997 . 479 [RFC2629] Rose, M. , "Writing I-Ds and RFCs using XML" , RFC 2629 480 , June 1999 . 482 [RFC3979] Bradner, S. , "Intellectual Property Rights in IETF 483 Technology" , BCP 79 , RFC 3979 , March 2005 . 485 [RFC4844] Daigle, L. and Internet Architecture Board , "The RFC 486 Series and RFC Editor" , RFC 4844 , July 2007 . 488 [RFC4749] Sollaud, A. , "RTP Payload Format for the G.729.1 Audio 489 Codec" , RFC 4749 , October 2006 . 491 [RFC5143] Malis, A. , Brayley, J. , Shirron, J. , Martini, L. , 492 and S. Vogelsang , "Synchronous Optical Network/ 493 Synchronous Digital Hierarchy (SONET/SDH) Circuit 494 Emulation Service over MPLS (CEM) Encapsulation" , 495 RFC 5143 , February 2008 . 497 [RFC5378] Bradner, S. and J. Contreras , "Rights Contributors 498 Provide to the IETF Trust" , BCP 78 , RFC 5378 , 499 November 2008 . 501 [I-D.rfc-editor-errata-process] 502 Ginoza, S. , Hagens, A. , and R. Braden , "RFC Editor 503 Proposal for Handling RFC Errata" , 504 draft-rfc-editor-errata-process-02 (work in progress) , 505 May 2008 . 507 [BCP78] Bradner, S., Ed. and J. Contreras, Ed. , "Rights 508 Contributors Provide to the IETF Trust" , BCP 78 , 509 November 2008 . 511 At the moment of publication:[RFC5378] 513 [BCP79] Bradner, S., Ed. and T. Narten, Ed., "Intellectual 514 Property Rights in IETF Technology", BCP 79, April 2007. 516 At the moment of publication:[RFC3979]and[RFC4749] 518 [RFC-style] 519 RFC Editor, "RFC Style Guide", 520 . 522 Appendix A. Some Example 'Status of this Memo' boilerplates 524 A.1. IETF Standards Track 526 The boilerplate for a Standards Track document that (by definition) 527 has been subject to an IETF consensus call. 529 ------------------------------------------------------------------------ 530 Status of this Memo 532 This is an Internet Standards Track document. 534 This document is a product of the Internet Engineering Task Force 535 (IETF). It represents a consensus of the IETF community. It has 536 received public review and has been approved for publication by 537 the Internet Engineering Steering Group. Further information on 538 the Internet Standards Track is available in Section 2 of RFC 539 XXXX." 541 Information about the current status of this document, any 542 errata, and how to provide feedback on it may be obtained at 543 http://www.rfc-editor.org/status/ietf.html 545 ------------------------------------------------------------------------ 547 A.2. IETF Experimental, with Consensus Call 549 The boilerplate for an Experimental document that has been subject to 550 an IETF consensus call. 552 ------------------------------------------------------------------------ 553 Status of this Memo 555 This document is not an Internet Standards Track specification; it 556 has been published for Experimental purposes. 558 This document defines an Experimental Protocol for the Internet 559 community. Discussion and suggestions for improvement are 560 requested. This document is a product of the Internet Engineering 561 Task Force (IETF). It represents a consensus of the IETF 562 community. It has received public review and has been approved 563 for publication by the Internet Engineering Steering Group 564 (IESG). Not all documents approved by the IESG are candidate for 565 any level of Internet Standards see Section 2 of RFC XXXX. 567 Information about the current status of this document, any 568 errata, and how to provide feedback on it may be obtained at 569 http://www.rfc-editor.org/status/ietf.html 570 ------------------------------------------------------------------------ 572 A.3. IETF Experimental, No Consensus Call 574 The boilerplate for an Experimental document that not has been 575 subject to an IETF consensus call. 577 ------------------------------------------------------------------------ 578 Status of this Memo 580 This document is not an Internet Standards Track specification; it 581 has been published for Experimental purposes. 583 This document defines an Experimental Protocol for the Internet 584 community. This document is a product of the Internet Engineering 585 Task Force (IETF). It has been approved for publication by the 586 Internet Engineering Steering Group. Not all documents approved 587 by the IESG are candidate for any level of Internet Standards see 588 Section 2 of RFC XXXX. 590 Information about the current status of this document, any 591 errata, and how to provide feedback on it may be obtained at 592 http://www.rfc-editor.org/status/ietf.html 593 ------------------------------------------------------------------------ 595 A.4. IAB Informational 597 The boilerplate for an Informational IAB document 599 ------------------------------------------------------------------------ 600 Status of this Memo 602 This document is not an Internet Standards Track specification; it 603 has been published for Informational purposes. 605 This document is a product of the Internet Architecture Board 606 (IAB), and represents information that the IAB has deemed valuable 607 to provide for permanent record. Documents approved for 608 publication by the IAB are not a candidate for any level of 609 Internet Standard; see Section 2 of RFC XXXX." 611 Information about the current status of this document, any 612 errata, and how to provide feedback on it may be obtained at 613 http://www.rfc-editor.org/status/iab.html 614 ------------------------------------------------------------------------ 616 A.5. IRTF Experimental 618 The boilerplate for an Experimental document that has been produced 619 by the IRTF and for which there was no RG consensus. This variation 620 is the most verbose boilerplate in the current set. 622 ------------------------------------------------------------------------ 623 Status of this Memo 625 This document is not an Internet Standards Track specification; it 626 has been published for Experimental purposes. 628 This document defines an Experimental Protocol for the Internet 629 community. This document is a product of the Internet Research 630 Task Force (IRTF). The IRTF publishes the results of Internet- 631 related research and development activities. These results might 632 not be suitable for deployment. This RFC represents the individual 633 opinion(s) of one or more members of the BLAFOO Research Group of 634 the Internet Research Task Force (IRTF). Documents approved for 635 publication by the IRTF are not a candidate for any level of 636 Internet Standard; see Section 2 of RFC XXXX." 638 Information about the current status of this document, any 639 errata, and how to provide feedback on it may be obtained at 640 http://www.rfc-editor.org/status/irtf.html 641 ------------------------------------------------------------------------ 642 Appendix B. IAB members at time of approval 644 The IAB members at the time this memo was approved were (in 645 alphabetical order): Loa Andersson, Gonzalo Camarillo, Stuart 646 Cheshire, Russ Housley, Olaf Kolkman, Gregory Lebovitz, Barry Leiba, 647 Kurtis Lindqvist, Andrew Malis, Danny McPherson, David Oran, Dave 648 Thaler, and Lixia Zhang. In addition, the IAB included two ex- 649 officio members: Dow Street, who was serving as the IAB Executive 650 Director, and Aaron Falk, who was serving as the IRTF Chair. 652 Appendix C. Acknowledgements 654 Thanks to Bob Braden, Brian Carpenter, Steve Crocker, Sandy Ginoza, 655 and John Klensin who provided background information and inspiration. 657 Various people have made suggestions that improved the document. 658 Among them are: Lars Eggert, Alfred Hoenes, and Joe Touch. 660 This document was produced using the xml2rfc tool [RFC2629]. 662 Appendix D. Document Editing Details 664 [To Be Removed before publication] 666 $Id: headers-boilerplates.xml 74 2009-03-02 12:42:05Z olaf $ 668 D.1. version 00->01 670 Fixed the header so it appropriately shows that the document updates 671 RFC 4844, 2223. And added a link to 3932-bis that should appear in 672 tandem with this publication. 674 Introduced the "Other structural information in RFCs" section and 675 moved the ISSN number from the front matter to this section. The 676 "Other structural information in RFCs" intends to give very rough 677 guidance providing the RFC editor with sufficient freedom to move 678 pieces around and edit them to please the eye and mind. 680 Modified the last sentence 3rd paragraph of the Status of this memo 681 section for the IRTF Stream in accordance to a suggestion by Aaron 682 Falk; Indicating that review happened by the IRSG and not indicating 683 that review did not happen by the IESG. 685 Introduced the square brackets around the in the 686 header. To highlight this is an optional element. 688 The definition of the "Clarifies" relation has been taken out. There 689 are arguments that introducing the relation needs a bit more thought 690 and is better done by a separate document. 692 Provided the RFC Editor with responsibility to maintain several text 693 pieces. 695 In Section 3.2 some modifications were applied to the text. 697 The contains the full name of the stream. 699 RFC2223 and 4844 moved to the informative reference section. 700 Although I am not sure if those are not normative. Guidance!!! 702 D.2. version 01->02 704 Fixed some editorial nits and missing references. 706 Clarified that the status and category are initial. 708 Added boilerplate text for documents that are initially published as 709 Historic. 711 Added members of IAB, and removed those members from acknowledgements 713 Added References to BCP78 and BCP79. The exact formatting of those 714 references may need to be done by the RFC editor. 716 Added text to recognize occurrences of variations of "Obsolete" and 717 "Update" 719 D.3. version 02->03 721 Stray language in the "IAB members at time of approval" section 722 removed. 724 D.4. version 03->04 726 Addressed the minor nit from Brian Carpenter. 728 Reference to style guide stet to styleguide.html 730 D.5. version 04->05 732 References updated to reflect BCP78 being updated 734 Submitted under new boilerplate 735 Rewording of boilerplate material based on rfc-interest discussion 736 starting with http://mailman.rfc-editor.org/pipermail/rfc-interest/ 737 2008-December/001078.html 739 Added examples in Appendix A 741 D.6. version 05->06 743 Nits corrected 745 Fixede Boilerplate for IETF stream document without IETF consensus. 747 Corruption of examples due to XML bug corrected 749 D.7. version 06->07 751 Nits corrected 753 Fixed inconsistency: Request for feedback only appeared in the 754 Experimental category, moved this to the "Update to this memo 755 section" 757 Changed the content of the 3rd paragraph of document status to be a 758 static (per stream) pointer to finding more information about the 759 document status, errata, and providing feedback. This was to address 760 the concern of having dynamic (per-document) text in the boilerplate, 761 if this "updates" section was document specific. 763 Authors' Addresses 765 Leslie Daigle (editor) 767 Email: daigle@isoc.org, leslie@thinkingcat.com 769 Olaf M. Kolkman (editor) 771 Email: olaf@nlnetlabs.nl 773 Internet Architecture Board 775 Email: iab@iab.org