idnits 2.17.1 draft-iesg-rfced-documents-03.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.5 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 357. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 373), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 15, 2004) is 7225 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) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '2') (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Alvestrand 2 Internet-Draft July 15, 2004 3 Expires: January 13, 2005 5 The IESG and RFC Editor documents: Procedures 6 draft-iesg-rfced-documents-03.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3667. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 13, 2005. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document describes the IESG's procedures for handling documents 39 submitted for RFC publication via the RFC Editor, subsequent to the 40 changes proposed by the IESG at the Seoul IETF, March 2004. 42 This document updates procedures described in RFC 2026 and RFC 3710. 44 1. Introduction and history 46 There are a number of different methods by which an RFC is published, 47 some of which include review in the Internet Engineering Task Force 48 (IETF), and some of which include approval by the Internet 49 Engineering Steering Group (IESG): 50 o IETF Working Group (WG) to Standards Track: Includes WG consensus, 51 review in the IETF, IETF Last Call and IESG approval 52 o IETF Working Group to Experimental/Informational: Includes WG 53 consensus, review in the IETF and IESG approval 54 o AD Sponsored to Standards Track: Includes review in the IETF, IETF 55 Last Call and IESG approval 56 o AD Sponsored Individual to Experimental/Informational: Includes 57 some form of review in the IETF and IESG approval 58 o Documents for which special rules exist 59 o RFC Editor documents to Experimental/Informational 60 This memo is concerned with the IESG processing of the last category 61 only. 63 Special rules apply to some documents, including documents from the 64 Internet Architecture Board (IAB), April 1st RFCs, and republication 65 of documents from other standards development organizations. The IESG 66 and the RFC Editor keep a running dialogue, in consultation with the 67 IAB, on these other documents and classification of them, but they 68 are outside the scope of this memo. 70 For the last few years, the IESG has reviewed all RFC Editor 71 documents (documents submitted by individuals to the RFC Editor for 72 RFC publication) before publication. In 2003, this review was often a 73 full scale review of technical content, with the ADs attempting to 74 clear points with the authors, stimulate revisions of the documents, 75 encourage the authors to contact appropriate working groups and so 76 on. This was a considerable drain on the resources of the IESG, and 77 since this is not the highest priority task the IESG members do, it 78 often resulted in significant delays. 80 In March 2004, the IESG decided to make a major change in this review 81 model. The new review model will have the IESG take responsibility 82 ONLY for checking for conflicts between the work of the IETF and the 83 documents submitted; soliciting technical review is deemed to be the 84 responsibility of the RFC Editor. If an individual IESG member 85 chooses to review the technical content of the document, and finds 86 issues, that member will communicate these issues to the RFC Editor, 87 where they will be treated the same way as comments on the documents 88 from other sources. 90 Note: This document describes only the review process done by the 91 IESG when the RFC Editor requests that review. There are many other 92 interactions between document editors and the IESG - for instance, an 93 AD may suggest that an author submit a document as input for work 94 within the IETF rather than to the RFC Editor, or the IESG may 95 suggest that a document submitted to the IETF is better suited for 96 submission to the RFC Editor - but these interactions are not 97 described in this memo. 99 2. Background material 101 The review of independent submissions by the IESG was prescribed by 102 RFC 2026 [1] section 4.2.3. The procedure described in this document 103 is compatible with that description. 105 RFC 3710 [4] section 5.2.2 describes the spring 2003 review process 106 (even though the RFC was published in 2004); with the publication of 107 this document, the procedure described in RFC 3710 is no longer 108 relevant to documents submitted via the RFC Editor. 110 3. Detailed description of IESG review 112 The RFC Editor reviews submissions for suitability for publications 113 as RFC. Once the RFC Editor thinks a document may be suited for RFC 114 publication, the RFC Editor asks the IESG to review the documents for 115 conflicts with the IETF standards process or work done in the IETF 116 community. 118 The review is initiated by a note from the RFC Editor specifying the 119 draft name, the RFC Editor's belief about the document's present 120 suitability for publication, and (if possible) the list of people who 121 have reviewed the document for the RFC Editor. 123 The IESG may return five different responses, any of which may be 124 accompanied by an IESG note to be put on the document if the RFC 125 Editor wishes to publish. 127 1. The IESG has not found any conflict between this document and 128 IETF work. 129 2. The IESG thinks that this work is related to IETF work done in WG 130 , but this does not prevent publishing. 131 3. The IESG thinks that publication is harmful to the IETF work done 132 in WG , and recommends not publishing the document at this 133 time. 134 4. The IESG thinks that this document violates IETF procedures for 135 , and should therefore not be published without IETF review 136 and IESG approval. 137 5. The IESG thinks that this document extends an IETF protocol in a 138 way that requires IETF review, and should therefore not be 139 published without IETF review and IESG approval. 141 The last two cases are included for the case where a document 142 attempts to do things (such as registering a new URI scheme) that 143 require IETF consensus or IESG approval (as these terms are defined 144 in RFC 2434 [2]), and the case where an IETF protocol is proposed to 145 be changed or extended in an unanticipated way that may be harmful to 146 the normal usage of the protocol, but where the protocol documents do 147 not explicitly say that this type of extension requires IETF review. 149 In the case of a document requiring IETF review, the IESG will offer 150 the author the opportunity to ask for publication as an AD-sponsored 151 individual document, which is subject to full IESG review including 152 possible assignment to a WG or rejection. Redirection to the full 153 IESG review path is not a guarantee that the IESG will accept the 154 work item, or even that the IESG will give it any particular 155 priority; it is a guarantee that the IESG will consider the document. 157 The IESG will normally have review done within 4 weeks from the RFC 158 Editor's notification. In the case of a possible conflict, the IESG 159 may contact a WG or a WG chair for an outside opinion of whether 160 publishing the document is harmful to the work of the WG, and in the 161 case of a possible conflict with an IANA registration procedure, the 162 IESG may contact the IANA expert for that registry. 164 Note that if the IESG has not found any conflict between a submission 165 and IETF work, then judging its technical merits, including 166 considerations of possible harm to the Internet, will become the 167 responsbility of the RFC Editor. The IESG assumes that the RFC 168 Editor, in agreement with the IAB, will manage mechanisms for 169 additional technical review. 171 4. Standard IESG note 173 One of the following IESG notes will be sent to the RFC Editor for 174 all documents with a request for placement either in or immediately 175 following the "Status of this Memo" section of the finished RFC, 176 unless the IESG decides otherwise: 177 1. For documents that specify a protocol or other technology, and 178 that have been considered in the IETF at one time: 180 The content of this RFC was at one time considered by the IETF, 181 and therefore it may resemble a current IETF work in progress or 182 a published IETF work. This RFC is not a candidate for any level 183 of Internet Standard. The IETF disclaims any knowledge of the 184 fitness of this RFC for any purpose, and in particular notes that 185 the decision to publish is not based on IETF review for such 186 things as security, congestion control or inappropriate 187 interaction with deployed protocols. The RFC Editor has chosen 188 to publish this document at its discretion. Readers of this RFC 189 should exercise caution in evaluating its value for 190 implementation and deployment. See RFC XXXX for more information. 191 2. For documents that specify a protocol or similar technology, and 192 are independent of the IETF process: 194 This RFC is not a candidate for any level of Internet Standard. 195 The IETF disclaims any knowledge of the fitness of this RFC for 196 any purpose, and in particular notes that the decision to publish 197 is not based on IETF review for such things as security, 198 congestion control or inappropriate interaction with deployed 199 protocols. The RFC Editor has chosen to publish this document at 200 its discretion. Readers of this document should exercise caution 201 in evaluating its value for implementation and deployment. See 202 RFC XXXX for more information. 203 3. For documents that do not specify a protocol or similar 204 technology: 206 This RFC is not a candidate for any level of Internet Standard. 207 The IETF disclaims any knowledge of the fitness of this RFC for 208 any purpose, and notes that the decision to publish is not based 209 on IETF review apart from IESG review for conflict with IETF 210 work. The RFC Editor has chosen to publish this document at its 211 discretion. See RFC XXXX for more information. 212 NOTE TO RFC EDITOR: Please replace "RFC XXXX" with the actual RFC 213 number of this document when published, and delete this sentence. 215 5. Examples of cases where publication is harmful 217 This section gives a couple of examples where it might be appropriate 218 to delay or prevent publishing of a document due to conflict with 219 IETF work. It forms part of the background material, not a part of 220 the procedure. 222 Rejected Alternative Bypass: A WG is working on a solution to a 223 problem, and a participant decides to ask for publication of a 224 solution that the WG has rejected. Publication of the document will 225 give the publishing party an RFC number to refer to before the WG is 226 finished. It seems better to have the WG product published first, and 227 have the non-adopted document published later, with a clear 228 disclaimer note saying that "the IETF technology for this function is 229 X". Example: Photuris (RFC 2522), which was published after IKE (RFC 230 2409). 232 Inappropriate Reuse of "free" Bits: In 2003, a proposal for an 233 experimental RFC was published that wanted to reuse the high bits of 234 the "fragment offset" part of the IP header for another purpose. 235 There is no IANA consideration saying how these bits can be 236 repurposed - but the standard defines a specific meaning for them. 237 The IESG concluded that implementations of this experiment risked 238 causing hard-to-debug interoperability problems, and recommended not 239 publishing the document in the RFC series. The RFC Editor accepted 240 the recommendation. 242 Note: in general, the IESG has no problem with rejected alternatives 243 being made available to the community; such publications can be a 244 valuable contribution to the technical literature. However, it is 245 necessary to avoid confusion with the alternatives the working group 246 did adopt. 248 The RFC series is one of many available publication channels; this 249 document takes no position on the question of which documents the RFC 250 series is appropriate for - this is a matter for discussion in the 251 IETF community. 253 6. IAB statement 255 In its capacity as the body that approves the general policy followed 256 by the RFC Editor (see RFC2850 [3]), the IAB has reviewed this 257 proposal and supports it as an operational change that is in line 258 with the respective roles of the IESG and RFC Editor. The IAB 259 continues to monitor the range of organized discussions within the 260 IETF about potential adjustments to the IETF document publication 261 processes (e.g., NEWTRK working group), and recognizes that the 262 process described in this document, as well as other general IETF 263 publication processes, and others may need to be adjusted in the 264 light of the outcome of those discussions. 266 7. Security Considerations 268 The process change described in this memo has no direct bearing on 269 the security of the Internet. 271 8. Acknowledgements 273 This document is a product of the IESG, and all its members deserve 274 thanks for their contributions to it. 276 This document has been reviewed in the IETF, by the RFC Editor and 277 the IAB; the IAB produced the text of section 6. Special thanks go to 278 John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt 279 Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter and all other 280 IETF community members who provided valuable feedback on the 281 document. 283 Normative references 285 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 286 9, RFC 2026, October 1996. 288 Informative references 290 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 291 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 293 [3] Internet Architecture Board and B. Carpenter, "Charter of the 294 Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000. 296 [4] Alvestrand, H., "An IESG charter", RFC 3710, February 2004. 298 Author's Address 300 Harald Alvestrand 302 EMail: harald@alvestrand.no 304 Appendix A. Changes from version -01 to -02 306 This section should be removed by the RFC Editor. 308 These changes were made to address comments raised during Last Call: 309 o Added more description of "special rules" to intro, and made it 310 clearer that this memo doesn't describe those 311 o Added para at beginning of section 2 indicating that this document 312 does not describe all IESG-author interactions 313 o Modified description of RFC Editor's work process at start of 314 section 3 315 o Changed "IETF review" to "IETF review and IESG approval" in bullet 316 4 and 5 of section 3 317 o Clarified relative roles of RFC Editor and IESG at end of section 318 3 319 o Used formulation of "decision to publish is not based on IETF 320 review" rather than "has not had IETF review" in standard IESG 321 notes 322 o Added section 6 with an IAB statement 323 o Added this section 325 Appendix B. Changes from version -02 to -03 327 This section should be removed by the RFC Editor. 329 Added mention of 3710 and 2026 to the abstract 331 Spelled out "IAB". Removed use of "SDO". 333 Removed one example (Publish While Waiting) 335 Intellectual Property Statement 337 The IETF takes no position regarding the validity or scope of any 338 Intellectual Property Rights or other rights that might be claimed to 339 pertain to the implementation or use of the technology described in 340 this document or the extent to which any license under such rights 341 might or might not be available; nor does it represent that it has 342 made any independent effort to identify any such rights. Information 343 on the IETF's procedures with respect to rights in IETF Documents can 344 be found in BCP 78 and BCP 79. 346 Copies of IPR disclosures made to the IETF Secretariat and any 347 assurances of licenses to be made available, or the result of an 348 attempt made to obtain a general license or permission for the use of 349 such proprietary rights by implementers or users of this 350 specification can be obtained from the IETF on-line IPR repository at 351 http://www.ietf.org/ipr. 353 The IETF invites any interested party to bring to its attention any 354 copyrights, patents or patent applications, or other proprietary 355 rights that may cover technology that may be required to implement 356 this standard. Please address the information to the IETF at 357 ietf-ipr@ietf.org. 359 Disclaimer of Validity 361 This document and the information contained herein are provided on an 362 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 363 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 364 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 365 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 366 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 367 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Copyright Statement 371 Copyright (C) The Internet Society (2004). This document is subject 372 to the rights, licenses and restrictions contained in BCP 78, and 373 except as set forth therein, the authors retain all their rights. 375 Acknowledgment 377 Funding for the RFC Editor function is currently provided by the 378 Internet Society.