idnits 2.17.00 (12 Aug 2021) /tmp/idnits52188/draft-housley-iesg-rfc3932bis-06.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 408. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. 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.) ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC3932, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3710, but the abstract doesn't seem to directly say this. It does mention RFC3710 though, so this could be OK. -- The draft header indicates that this document updates RFC2026, but the abstract doesn't seem to directly say this. It does mention RFC2026 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Unrecognized Status in 'Category: Best Current Practice (if approved)', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) (Using the creation date from RFC2026, updated by this document, for RFC5378 checks: 1995-09-12) -- 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 (18 November 2008) is 4931 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3' on line 195 ** Obsolete normative reference: RFC 4844 (ref. 'N1') (Obsoleted by RFC 8729) == Outdated reference: draft-iab-streams-headers-boilerplates has been published as RFC 5741 ** Downref: Normative reference to an Informational draft: draft-iab-streams-headers-boilerplates (ref. 'N3') -- Obsolete informational reference (is this intentional?): RFC 3932 (ref. 'I1') (Obsoleted by RFC 5742) == Outdated reference: draft-irtf-rfcs has been published as RFC 5743 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT H. Alvestrand 3 Obsoletes: 3932 (if approved) Google 4 Updates: 3710, 2026 (if approved) R. Housley 5 Category: Best Current Practice (if approved) Vigil Security 6 Exipres: 18 May 2009 18 November 2008 8 IESG Procedures for Handling of Independent and IRTF Stream Submissions 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-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/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document describes the procedures used by the IESG for handling 36 documents submitted for RFC publication on the Independent and IRTF 37 streams. 39 This document updates procedures described in RFC 2026 and RFC 3710. 41 {{{ RFC Editor: Please change "RFC XXXX" to the number assigned to 42 this document prior to publication. }}} 44 1. Introduction and History 46 RFC 4844 [N1] defines four RFC streams. When a document is submitted 47 for publication, the review that it receives depends on the stream in 49 RFC3932bis Update of RFC 3932 November 2008 51 which it will be published. The four streams defined in RFC 4844 52 are: 53 - The IETF stream 54 - The IAB stream 55 - The IRTF stream 56 - The Independent Submission stream 58 The IETF is responsible for maintaining the Internet Standards 59 Process, which includes the requirements for developing, reviewing 60 and approving Standards Track and BCP RFCs. These RFCs, and any 61 other IETF-generated Informational or Experimental documents, are 62 reviewed by appropriate IETF bodies and published as part of the IETF 63 Stream. 65 Documents published in streams other than the IETF Stream may not 66 receive any review by the IETF for such things as security, 67 congestion control, or inappropriate interaction with deployed 68 protocols. Generally, there is no attempt for IETF consensus or IESG 69 approval. Therefore, the IETF disclaims, for any of the non-IETF 70 Stream documents, any knowledge of the fitness of those RFCs for any 71 purpose. 73 This memo is only concerned with the IESG processing of the last two 74 categories, which comprise the Independent Submission Stream and the 75 IRTF Document Stream, respectively [N1]. 77 Following the approval of RFC 2026 [N2] and prior to the publication 78 of RFC 3932 [I1], the IESG reviewed all Independent Submission Stream 79 documents before publication. This review was often a full-scale 80 review of technical content, with the Area Director (ADs) attempting 81 to clear points with the authors, stimulate revisions of the 82 documents, encourage the authors to contact appropriate working 83 groups (WGs) and so on. This was a considerable drain on the 84 resources of the IESG, and since this was not the highest priority 85 task of the IESG members, it often resulted in significant delays. 87 In March 2004, the IESG decided to make a major change in this review 88 model, with the IESG taking responsibility only for checking for 89 conflicts between the work of the IETF and the documents submitted. 90 Soliciting technical review is deemed to be the responsibility of the 91 RFC Editor. If an individual AD chooses to review the technical 92 content of the document and finds issues, that AD will communicate 93 these issues to the RFC Editor, and they will be treated the same way 94 as comments on the documents from other sources. 96 Prior to 2006, documents from the IRTF were treated as either IAB 97 submissions or individual submissions via the RFC Editor. However, 98 the Internet Research Steering Group (IRSG) has established a review 100 RFC3932bis Update of RFC 3932 November 2008 102 process for the publication of RFCs on the IRTF Document Stream [I2]. 103 Once these procedures are fully adopted, the IESG will continue to be 104 responsible only for checking for conflicts between the work of the 105 IETF and the documents submitted, but results of the check will be 106 reported to the IRTF. These results may be copied to the RFC Editor 107 as a courtesy. 109 This document describes only the review process done by the IESG when 110 the RFC Editor or the IRTF requests that review. There are many 111 other interactions between document editors and the IESG for 112 instance, an AD may suggest that an author submit a document as input 113 for work within the IETF rather than to the RFC Editor as part of the 114 Independent Submission Stream, or the IESG may suggest that a 115 document submitted to the IETF is better suited for submission to the 116 RFC Editor as part of Independent Submission Stream but these 117 interactions are not described in this memo. 119 1.1. Changes since RFC 3932 121 RFC 3932 provided procedures for the review of Independent Submission 122 Stream submissions. With the definition of procedures by the IRSG 123 for the IRTF Document Stream, it has become clear that similar 124 procedures apply to the review by the IESG of IRTF Document Stream 125 documents. 127 The IAB and the RFC Editor have made updates to the formatting of the 128 title page for all RFCs [N3]. With these changes, the upper left 129 hand corner of the title page indicates the stream that produced the 130 RFC. This label eliminates the need for a mandatory IESG note on all 131 Independent Submission and IRTF Stream documents. 133 2. Background Material 135 The review of independent submissions by the IESG was prescribed by 136 RFC 2026 [N2] section 4.2.3. The procedure described in this 137 document is compatible with that description. 139 The procedures developed by the IRTF for documents created by the 140 Research Groups also include review by the IESG [I2]. 142 The IESG Charter, RFC 3710 [I5], section 5.2.2 describes the review 143 process that was employed in Spring 2003 (even though the RFC was not 144 published until 2004); with the publication of RFC 3932 [I1], the 145 procedure described in RFC 3710 was no longer relevant to documents 146 submitted via the RFC Editor. The publication of this document 147 further updates RFC 3710, section 5.2.2 so that it covers the IRTF 148 stream and the Individual Submission Stream. 150 RFC3932bis Update of RFC 3932 November 2008 152 3. Detailed Description of IESG Review 154 The RFC Editor reviews Independent Stream submissions for suitability 155 for publications as RFC. As described in RFC 4846 [I3], the RFC 156 Editor asks the IESG to review the documents for conflicts with the 157 IETF standards process or work done in the IETF community. 159 Similarly, documents intended for publication as part of the IRTF 160 Stream are sent to the IESG for review for conflicts with the IETF 161 standards process or work done in the IETF community [I2]. 163 The IESG review of these Independent Stream and IRTF Stream documents 164 reach one of the following five types of conclusions. 166 1. The IESG has concluded that there is no conflict between this 167 document and IETF work. 169 2. The IESG has concluded that this work is related to IETF work done 170 in WG , but this relationship does not prevent publishing. 172 3. The IESG has concluded that publication could potentially disrupt 173 the IETF work done in WG and recommends not publishing the 174 document at this time. 176 4. The IESG has concluded that this document violates IETF procedures 177 for and should therefore not be published without IETF review 178 and IESG approval. 180 5. The IESG has concluded that this document extends an IETF protocol 181 in a way that requires IETF review and should therefore not be 182 published without IETF review and IESG approval. 184 Generally, the RFC headers and boilerplate clearly describe the 185 relationship of the document to the IETF standards process [N3]. In 186 exceptional cases, when the relationship of the document to the IETF 187 standards process might be unclear, the IESG response may be 188 accompanied by a clarifying IESG note and a request that the RFC 189 Editor include the IESG note in the document if the document is 190 published. 192 The last two responses are included respectively, for the case where 193 a document attempts to take actions (such as registering a new URI 194 scheme) that require IETF Review, Standards Action, or IESG Approval 195 (as these terms are defined in RFC 5226 [3]), and for the case where 196 an IETF protocol is proposed to be changed or extended in an 197 unanticipated way that may be detrimental to the normal usage of the 198 protocol, but where the protocol documents do not explicitly say that 199 this type of extension requires IETF review. 201 RFC3932bis Update of RFC 3932 November 2008 203 If a document requires IETF review, the IESG will offer the author 204 the opportunity to ask for publication as an AD-sponsored individual 205 document, which is subject to full IETF review, including possible 206 assignment to a WG or rejection. Redirection to the full IESG review 207 path is not a guarantee that the IESG will accept the work item, or 208 even that the IESG will give it any particular priority; it is a 209 guarantee that the IESG will consider the document. 211 The IESG will normally complete review within four weeks after 212 notification by the RFC Editor or IRTF. In the case of a possible 213 conflict, the IESG may contact a WG or a WG chair for an outside 214 opinion of whether publishing the document is harmful to the work of 215 that WG and, in the case of a possible conflict with an IANA 216 registration procedure, the IANA expert for that registry. 218 If the IESG does not find any conflict between an independent 219 submission and IETF work, then the RFC Editor is responsible for 220 judging the technical merits for that submission, including 221 considerations of possible harm to the Internet. If the IESG does 222 not find any conflict between an IRTF submission and IETF work, then 223 the IRSG is responsible for judging the technical merits for that 224 submission, including considerations of possible harm to the 225 Internet. 227 The RFC Editor, in agreement with the IAB, shall manage mechanisms 228 for appropriate technical review of independent submissions. 229 Likewise, the IRSG, in agreement with the IAB, shall manage 230 mechanisms for appropriate technical review of IRTF submissions. 232 4. Examples of Cases Where Publication Is Harmful 234 This section gives a couple of examples where delaying or preventing 235 publication of a document might be appropriate due to conflict with 236 IETF work. It forms part of the background material, not a part of 237 the procedure. 239 Rejected Alternative Bypass: 241 As a WG is working on a solution to a problem, a participant 242 decides to ask for RFC publication, as part of the Independent 243 Stream, of a solution that the WG has rejected. Publication of 244 the document will give the publishing party an RFC number before 245 the WG is finished. It seems better to have the WG product 246 published first, and have the non-adopted document published 247 later, with a clear disclaimer note saying that "the IETF 248 technology for this function is X". 250 Example: Photuris (RFC 2522), which was published after 252 RFC3932bis Update of RFC 3932 November 2008 254 IKE (RFC 2409). 256 Note: in general, the IESG has no problem with rejected 257 alternatives being made available to the community; such 258 publications can be a valuable contribution to the technical 259 literature. However, it is necessary to avoid confusion with the 260 alternatives adopted by the WG. 262 Inappropriate Reuse of "free" Bits: 264 In 2003, a proposal for an experimental RFC was published that 265 wanted to reuse the high bits of the "fragment offset" part of the 266 IP header for another purpose. No IANA consideration says how 267 these bits can be repurposed, but the standard defines a specific 268 meaning for them. The IESG concluded that implementations of this 269 experiment risked causing hard-to-debug interoperability problems 270 and recommended not publishing the document in the RFC series. 271 The RFC Editor accepted the recommendation. 273 The RFC series is one of many available publication channels; this 274 document takes no position on the question of which documents are 275 appropriate for publication in the RFC Series. That is a matter for 276 discussion in the Internet community. 278 5. IAB Statement 280 In its capacity as the body that approves the general policy followed 281 by the RFC Editor (see RFC 2850 [I4]), the IAB has reviewed this 282 proposal and supports it as an operational change that is in line 283 with the respective roles of the IESG, IRTF, and RFC Editor. The IAB 284 continues to monitor discussions within the IETF about potential 285 adjustments to the IETF document publication processes and recognizes 286 that the process described in this document, as well as other general 287 IETF publication processes, may need to be adjusted to align with any 288 changes that result from such discussions. 290 6. Security Considerations 292 The process change described in this memo has no direct bearing on 293 the security of the Internet. 295 7. Acknowledgements 297 RFC 3932 was a product of the IESG in October 2004, and it was 298 reviewed in the IETF, by the RFC Editor, and by the IAB. Special 299 thanks for the development of RFC 3932 go to John Klensin, Keith 300 Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul 301 Hoffman, Brian Carpenter, and all other IETF community participants 303 RFC3932bis Update of RFC 3932 November 2008 305 who provided valuable feedback. 307 This update to RFC 3932 was the product of the IESG in July and 308 August of 2008, and it was reviewed in the IETF, by the RFC Editor, 309 by the IRSG, and by the IAB. Special thanks for this development of 310 this update go to (in alphabetical order) Jari Arkko, Ran Atkinson, 311 Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, 312 and Olaf Kolkman. 314 8. References 316 8.1. Normative Reference 318 [N1] Internet Architecture Board and L. Daigle, Ed., "The RFC Series 319 and RFC Editor", RFC 4844, July 2007. 321 [N2] Bradner, S., "The Internet Standards Process -- Revision 3", 322 BCP 9, RFC 2026, October 1996. 324 [N3] Internet-Draft: draft-iab-streams-headers-boilerplates, work in 325 progress. 327 8.2. Informative References 329 [I1] Alvestrand, H., "The IESG and RFC Editor Documents: 330 Procedures", RFC 3932, October 2004. 332 [I2] Internet-Draft: draft-irtf-rfcs, work in progress. 334 [I3] Klensin, J., and D. Thaler, "Independent Submissions to the RFC 335 Editor", RFC 4846, July 2007. 337 [I4] Internet Architecture Board and B. Carpenter, Ed., "Charter of 338 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 339 2000. 341 [I5] Alvestrand, H., "An IESG charter", RFC 3710, February 2004. 343 Authors' Address 345 Harald Alvestrand 346 EMail: harald@alvestrand.no 348 Russell Housley 349 Email: housley@vigilsec.com 351 RFC3932bis Update of RFC 3932 November 2008 353 Copyright and IPR Statements 355 Copyright (C) The IETF Trust (2008). 357 This document is subject to the rights, licenses and restrictions 358 contained in BCP 78, and except as set forth therein, the authors 359 retain all their rights. 361 This document and translations of it may be copied and furnished to 362 others, and derivative works that comment on or otherwise explain it 363 or assist in its implementation may be prepared, copied, published 364 and distributed, in whole or in part, without restriction of any 365 kind, provided that the above copyright notice and this paragraph are 366 included on all such copies and derivative works. However, this 367 document itself may not be modified in any way, such as by removing 368 the copyright notice or references to the Internet Society or other 369 Internet organizations, except as needed for the purpose of 370 developing Internet standards in which case the procedures for 371 copyrights defined in the Internet Standards process must be 372 followed, or as required to translate it into languages other than 373 English. 375 The limited permissions granted above are perpetual and will not be 376 revoked by the Internet Society or its successors or assigns. 378 This document and the information contained herein are provided on an 379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 381 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 382 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 383 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 386 The IETF takes no position regarding the validity or scope of any 387 Intellectual Property Rights or other rights that might be claimed to 388 pertain to the implementation or use of the technology described in 389 this document or the extent to which any license under such rights 390 might or might not be available; nor does it represent that it has 391 made any independent effort to identify any such rights. Information 392 on the procedures with respect to rights in RFC documents can be 393 found in BCP 78 and BCP 79. 395 Copies of IPR disclosures made to the IETF Secretariat and any 396 assurances of licenses to be made available, or the result of an 397 attempt made to obtain a general license or permission for the use of 398 such proprietary rights by implementers or users of this 399 specification can be obtained from the IETF on-line IPR repository at 400 http://www.ietf.org/ipr. 402 RFC3932bis Update of RFC 3932 November 2008 404 The IETF invites any interested party to bring to its attention any 405 copyrights, patents or patent applications, or other proprietary 406 rights that may cover technology that may be required to implement 407 this standard. Please address the information to the IETF at 408 ietf-ipr@ietf.org.