idnits 2.17.1 draft-housley-iesg-rfc3932bis-12.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 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 and authors 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 (16 November 2009) is 5247 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 220 ** Obsolete normative reference: RFC 4844 (ref. 'N1') (Obsoleted by RFC 8729) ** 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) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 Expires: 16 May 2009 16 November 2009 8 IESG Procedures for Handling of Independent and IRTF Stream Submissions 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 RFC3932bis Update of RFC 3932 November 2009 44 Abstract 46 This document describes the procedures used by the IESG for handling 47 documents submitted for RFC publication on the Independent Submission 48 and IRTF streams. 50 This document updates procedures described in RFC 2026 and RFC 3710. 52 1. Introduction and History 54 RFC 4844 [N1] defines four RFC streams. When a document is submitted 55 for publication, the review that it receives depends on the stream in 56 which it will be published. The four streams defined in RFC 4844 57 are: 58 - The IETF stream 59 - The IAB stream 60 - The IRTF stream 61 - The Independent Submission stream 63 The IETF is responsible for maintaining the Internet Standards 64 Process, which includes the requirements for developing, reviewing 65 and approving Standards Track and BCP RFCs. These RFCs, and any 66 other IETF-generated Informational or Experimental documents, are 67 reviewed by appropriate IETF bodies [N2] and published as part of the 68 IETF Stream. 70 Documents published in streams other than the IETF Stream might not 71 receive any review by the IETF for such things as security, 72 congestion control, or inappropriate interaction with deployed 73 protocols. Generally, there is no attempt for IETF consensus or IESG 74 approval. Therefore, the IETF disclaims, for any of the non-IETF 75 Stream documents, any knowledge of the fitness of those RFCs for any 76 purpose. 78 IESG processing described in this document is concerned only with the 79 last two categories, which comprise the Independent Submission Stream 80 and the IRTF Stream, respectively [N1]. 82 Following the approval of RFC 2026 [N2] and prior to the publication 83 of RFC 3932 [I1], the IESG reviewed all Independent Submission Stream 84 documents before publication. This review was often a full-scale 85 review of technical content, with the Area Director (ADs) attempting 86 to clear points with the authors, stimulate revisions of the 87 documents, encourage the authors to contact appropriate working 88 groups (WGs) and so on. This was a considerable drain on the 89 resources of the IESG, and since this was not the highest priority 90 task of the IESG members, it often resulted in significant delays. 92 RFC3932bis Update of RFC 3932 November 2009 94 In March 2004, the IESG decided to make a major change in this review 95 model, with the IESG taking responsibility only for checking for 96 conflicts between the work of the IETF and the documents submitted. 97 Soliciting technical review is deemed to be the responsibility of the 98 RFC Editor. If an individual AD chooses to review the technical 99 content of the document and finds issues, that AD will communicate 100 these issues to the RFC Editor, and they will be treated the same way 101 as comments on the documents from other sources. 103 Prior to 2006, documents from the IRTF were treated as either IAB 104 submissions or individual submissions via the RFC Editor. However, 105 the Internet Research Steering Group (IRSG) has established a review 106 process for the publication of RFCs on the IRTF Stream [I2]. Once 107 these procedures are fully adopted, the IESG will be responsible only 108 for checking for conflicts between the work of the IETF and the 109 documents submitted, but results of the check will be reported to the 110 IRTF. These results may be copied to the RFC Editor as a courtesy. 112 This document describes only the review process done by the IESG when 113 the RFC Editor or the IRTF requests that review. The RFC Editor will 114 request the review of Independent Submission Stream documents, and 115 the IRTF will request review of IRTF Stream documents. There are 116 many other interactions between document editors and the IESG for 117 instance, an AD may suggest that an author submit a document as input 118 for work within the IETF rather than to the RFC Editor as part of the 119 Independent Submission Stream, or the IESG may suggest that a 120 document submitted to the IETF is better suited for submission to the 121 RFC Editor as part of Independent Submission Stream but these 122 interactions are not described in this memo. 124 For the convenience of the reader, this document includes description 125 of some actions taken by the RFC Editor, the IAB, and the IRSG. The 126 inclusion of these actions is not normative. Rather, these actions 127 are included to describe the overall process surrounding the 128 normative IESG procedures described in this document. No RFC Editor, 129 IAB, or IRSG procedures are set by this document. 131 1.1. Changes since RFC 3932 133 RFC 3932 provided procedures for the review of Independent Submission 134 Stream submissions. With the definition of procedures by the IRSG 135 for the IRTF Stream, it has become clear that similar procedures 136 apply to the review by the IESG of IRTF Stream documents. 138 The IAB and the RFC Editor have made updates to the formatting of the 139 title page for all RFCs [N3]. With these changes, the upper left 140 hand corner of the title page indicates the stream that produced the 141 RFC. This label replaces some of the information that was previously 143 RFC3932bis Update of RFC 3932 November 2009 145 provided in mandatory IESG notes on non-IETF-stream documents. 147 The IESG may request the inclusion of an IESG note in an Independent 148 Submission or IRTF Stream document to explain the specific 149 relationship, if any, to IETF work. In case there is a dispute about 150 the content of the IESG note, this document provides a dispute 151 resolution process. 153 2. Background Material 155 The review of independent submissions by the IESG was prescribed by 156 RFC 2026 [N2] section 4.2.3. The procedure described in this 157 document is compatible with that description. 159 The procedures developed by the IRTF for documents created by the 160 Research Groups also include review by the IESG [I2]. 162 The IESG Charter, RFC 3710 [I5], section 5.2.2 describes the review 163 process that was employed in Spring 2003 (even though the RFC was not 164 published until 2004); with the publication of RFC 3932 [I1], the 165 procedure described in RFC 3710 was no longer relevant to documents 166 submitted via the RFC Editor. The publication of this document 167 further updates section 5.2.2 of RFC 3710, now covering both the IRTF 168 Stream and the Independent Submission Stream. 170 3. Detailed Description of IESG Review 172 The RFC Editor reviews Independent Submission Stream submissions for 173 suitability for publication as RFCs. As described in RFC 4846 [I3], 174 the RFC Editor asks the IESG to review the documents for conflicts 175 with the IETF standards process or work done in the IETF community. 177 Similarly, documents intended for publication as part of the IRTF 178 Stream are sent to the IESG for review for conflicts with the IETF 179 standards process or work done in the IETF community [I2]. 181 The IESG review of these Independent Submission Stream and IRTF 182 Stream documents reach one of the following five types of conclusion, 183 any of which may be accompanied by a request to include an IESG note 184 if the document is published. 186 1. The IESG has concluded that there is no conflict between this 187 document and IETF work. 189 2. The IESG has concluded that this work is related to IETF work done 190 in WG , but this relationship does not prevent publishing. 192 3. The IESG has concluded that publication could potentially disrupt 194 RFC3932bis Update of RFC 3932 November 2009 196 the IETF work done in WG and recommends not publishing the 197 document at this time. 199 4. The IESG has concluded that this document violates IETF procedures 200 for and should therefore not be published without IETF review 201 and IESG approval. 203 5. The IESG has concluded that this document extends an IETF protocol 204 in a way that requires IETF review and should therefore not be 205 published without IETF review and IESG approval. 207 The RFC headers and boilerplate is intended to describe the 208 relationship of the document to the IETF standards process [N3]. In 209 exceptional cases, when the relationship of the document to the IETF 210 standards process might be unclear, the IESG may request the 211 inclusion of an IESG note to clarify the relationship of the document 212 to the IETF standards process. Such a note is likely to include 213 pointers to related IETF RFCs. The dispute resolution process in 214 Section 4 is provided to handle situation where the IRSG or RFC 215 Editor is concerned with the content of the requested IESG note. 217 The last two responses are included respectively, for the case where 218 a document attempts to take actions (such as registering a new URI 219 scheme) that require IETF Review, Standards Action, or IESG Approval 220 (as these terms are defined in RFC 5226 [3]), and for the case where 221 an IETF protocol is proposed to be changed or extended in a way not 222 anticipated by the original authors that may be detrimental to the 223 normal usage of the protocol, but where the protocol documents do not 224 explicitly say that this type of extension requires IETF review. 226 If a document requires IETF review, the IESG will offer the author 227 the opportunity to ask for publication as an AD-sponsored individual 228 document, which is subject to full IETF review, including possible 229 assignment to a WG or rejection. Redirection to the full IESG review 230 path is not a guarantee that the IESG will accept the work item, or 231 even that the IESG will give it any particular priority; it is a 232 guarantee that the IESG will consider the document. 234 The IESG will normally complete review within four weeks after 235 notification by the RFC Editor or IRTF. In the case of a possible 236 conflict, the IESG may contact a WG or a WG Chair for an outside 237 opinion of whether publishing the document is harmful to the work of 238 that WG and, in the case of a possible conflict with an IANA 239 registration procedure, the IANA expert for that registry. 241 If the IESG does not find any conflict between an independent 242 submission and IETF work, then the RFC Editor is responsible for 243 judging the technical merits for that submission, including 245 RFC3932bis Update of RFC 3932 November 2009 247 considerations of possible harm to the Internet. If the IESG does 248 not find any conflict between an IRTF submission and IETF work, then 249 the IRSG is responsible for judging the technical merits for that 250 submission, including considerations of possible harm to the 251 Internet. 253 The RFC Editor, in agreement with the IAB, shall manage mechanisms 254 for appropriate technical review of independent submissions. 255 Likewise, the IRSG, in agreement with the IAB, shall manage 256 mechanisms for appropriate technical review of IRTF submissions. 258 4. Dispute Resolution 260 Experience has shown that the IESG and the RFC Editor have worked 261 well together regarding publication recommendations and IESG notes. 262 Where questions have arisen, they have been quickly resolved when all 263 parties become aware of the concerns. However, should a dispute ever 264 arise, a third party can assist with resolution. Therefore, this 265 dispute procedure has an informal dialogue phase followed by an 266 arbitration phase if the matter remains unresolved. 268 If IESG requests the inclusion of an IESG note and the IRSG or the 269 RFC Editor intends to publish the document without the requested IESG 270 note, then they must provide a clear and concise description of the 271 concerns to the IESG before proceeding. A proposal for alternate 272 IESG note text from the IRSG or the RFC Editor is highly encouraged. 274 If the IESG does not want the document to be published without the 275 requested IESG note, then the IESG must initiate an informal 276 dialogue. The dialogue should not take more than six weeks. This 277 period of time allows the IESG to conduct an IETF Last Call 278 concerning the content of the requested IESG note (and not on the 279 document as a whole) to determine community consensus if desired. At 280 the end of the dialogue, the IESG can reaffirm the original IESG 281 note, provide an alternate IESG note, or withdraw the note 282 altogether. If an IESG note is requested, the IRSG or the RFC Editor 283 must state whether they intend to include it. 285 If dialogue fails to resolve IRSG or RFC Editor concerns with the 286 content of a requested IESG note and they intend to publish the 287 document as an RFC without the requested IESG note, then the IESG can 288 formally ask the IAB to provide arbitration. The IAB is not 289 obligated to perform arbitration and may decline the request. If the 290 IAB declines, the RFC Editor decides whether the IESG note is 291 included. If the IAB accepts, the IAB review will occur according to 292 procedures of the IAB's own choosing. The IAB can direct the 293 inclusion of the IESG note, direct the withdrawal of the IESG note, 294 or leave the final decision to the RFC Editor. Unlike the IAB 296 RFC3932bis Update of RFC 3932 November 2009 298 reviews specified in RFC 4846 [I3], if the IAB directs the inclusion 299 or withdrawal the IESG note, the IAB decision is binding, not 300 advisory. 302 5. Examples of Cases Where Publication Is Harmful 304 This section gives a couple of examples where delaying or preventing 305 publication of a document might be appropriate due to conflict with 306 IETF work. It forms part of the background material, not a part of 307 the procedure. 309 Rejected Alternative Bypass: 311 As a WG is working on a solution to a problem, a participant 312 decides to ask for Independent Submission Stream publication of a 313 solution that the WG has rejected. Publication of the document 314 will give the publishing party an RFC number before the WG is 315 finished. It seems better to have the WG product published first, 316 and have the non-adopted document published later, with a clear 317 disclaimer note saying that "the IETF technology for this function 318 is X". 320 Example: Photuris (RFC 2522), which was published after 321 IKE (RFC 2409). 323 Note: in general, the IESG has no problem with rejected 324 alternatives being made available to the community; such 325 publications can be a valuable contribution to the technical 326 literature. However, it is necessary to avoid confusion with the 327 alternatives adopted by the WG. 329 Inappropriate Reuse of "free" Bits: 331 In 2003, a proposal for an experimental RFC was published that 332 wanted to reuse the high bits of the "fragment offset" part of the 333 IP header for another purpose. No IANA consideration says how 334 these bits can be repurposed, but the standard defines a specific 335 meaning for them. The IESG concluded that implementations of this 336 experiment risked causing hard-to-debug interoperability problems 337 and recommended not publishing the document in the RFC series. 338 The RFC Editor accepted the recommendation. 340 The RFC series is one of many available publication channels; this 341 document takes no position on the question of which documents are 342 appropriate for publication in the RFC Series. That is a matter for 343 discussion in the Internet community. 345 RFC3932bis Update of RFC 3932 November 2009 347 6. IAB Statement 349 In its capacity as the body that approves the general policy followed 350 by the RFC Editor (see RFC 2850 [I4]), the IAB has reviewed this 351 proposal and supports it as an operational change that is in line 352 with the respective roles of the IESG, IRTF, and RFC Editor. The IAB 353 continues to monitor discussions within the IETF about potential 354 adjustments to the IETF document publication processes and recognizes 355 that the process described in this document, as well as other general 356 IETF publication processes, may need to be adjusted to align with any 357 changes that result from such discussions. 359 7. Security Considerations 361 The process change described in this memo has no direct bearing on 362 the security of the Internet. 364 8. Acknowledgements 366 RFC 3932 was a product of the IESG in October 2004, and it was 367 reviewed in the IETF, by the RFC Editor, and by the IAB. Special 368 thanks for the development of RFC 3932 go to John Klensin, Keith 369 Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul 370 Hoffman, Brian Carpenter, and all other IETF community participants 371 who provided valuable feedback. 373 This update to RFC 3932 was the product of the IESG in July and 374 August of 2008, and it was reviewed in the IETF, by the RFC Editor, 375 by the IRSG, and by the IAB. Special thanks for the development of 376 this update go to (in alphabetical order) Jari Arkko, Ran Atkinson, 377 Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, 378 Olaf Kolkman, and Andy Malis. 380 9. References 382 9.1. Normative Reference 384 [N1] Internet Architecture Board and L. Daigle, Ed., "The RFC Series 385 and RFC Editor", RFC 4844, July 2007. 387 [N2] Bradner, S., "The Internet Standards Process -- Revision 3", 388 BCP 9, RFC 2026, October 1996. 390 [N3] Internet-Draft: draft-iab-streams-headers-boilerplates, work in 391 progress. 393 RFC3932bis Update of RFC 3932 November 2009 395 9.2. Informative References 397 [I1] Alvestrand, H., "The IESG and RFC Editor Documents: 398 Procedures", RFC 3932, October 2004. 400 [I2] Internet-Draft: draft-irtf-rfcs, work in progress. 402 [I3] Klensin, J., and D. Thaler, "Independent Submissions to the RFC 403 Editor", RFC 4846, July 2007. 405 [I4] Internet Architecture Board and B. Carpenter, Ed., "Charter of 406 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 407 2000. 409 [I5] Alvestrand, H., "An IESG charter", RFC 3710, February 2004. 411 Authors' Address 413 Harald Alvestrand 414 EMail: harald@alvestrand.no 416 Russell Housley 417 Email: housley@vigilsec.com