idnits 2.17.1 draft-iesg-discuss-criteria-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 408. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 6, 2006) is 6654 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) ** Downref: Normative reference to an Informational RFC: RFC 1958 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3424 (ref. '3') == Outdated reference: A later version (-09) exists of draft-ietf-proto-wgchair-doc-shepherding-05 ** Downref: Normative reference to an Informational draft: draft-ietf-proto-wgchair-doc-shepherding (ref. '4') Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar 4 Expires: August 10, 2006 A. Mankin 5 Lucent 6 M. Wasserman 7 ThingMagic 8 February 6, 2006 10 DISCUSS Criteria in IESG Review 11 draft-iesg-discuss-criteria-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 10, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document describes the role of the 'DISCUSS' position in the 45 IESG review process. It gives some guidance on when a DISCUSS should 46 and should not be issued. It also discusses procedures for DISCUSS 47 resolution. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Document Classes Reviewed by the IESG . . . . . . . . . . . . 3 53 3. Protocol Action Criteria . . . . . . . . . . . . . . . . . . . 4 54 3.1. DISCUSS Criteria . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. DISCUSS Non-Criteria . . . . . . . . . . . . . . . . . . . 5 56 3.3. Saying No to A Document . . . . . . . . . . . . . . . . . 6 57 4. DISCUSS Resolution . . . . . . . . . . . . . . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . . . . 11 66 1. Introduction 68 The Internet Engineering Steering Group (IESG) is responsible for the 69 final review of IETF documents. Members of the IESG have the option, 70 when they review a document, of stating a 'DISCUSS' position. The 71 DISCUSS identifies one or more issues that must be discussed in 72 relation to the document before the document can become an RFC. As 73 such, 'DISCUSS' is a blocking position; the document cannot proceed 74 until any issues are resolved to the satisfaction of the Area 75 Director who issued the DISCUSS. For cases where the reasoning for 76 an unresolved DISCUSS does not reflect the consensus of the IESG, 77 override procedures can be invoked to unblock documents. 79 The criteria set forward in this document are intended to serve two 80 purposes: to educate and to improve consistency. When new members 81 join the IESG, it might not be immediately clear when it is 82 appropriate to issue a DISCUSS and when a non-blocking comment should 83 be preferred. Even among the standing IESG (at the time this 84 document was written), it is clear that different Area Directors use 85 different criteria for issuing a DISCUSS. While this is not innately 86 problematic, greater consistency in evaluating the severity of an 87 issue would reduce unnecessary document delays and blockages. 89 This document approaches IESG review of Proposed Standard documents 90 as a review of "last resort". Most such documents reviewed by the 91 IESG are produced and reviewed in the context of IETF working groups. 92 In those cases, the IESG cannot overrule working group consensus 93 without good reason; informed community consensus should prevail. 95 While this document serves as commentary on the way the IESG applies 96 the IETF process rules, it is not intended to change any of the 97 underlying principles, including RFC2026 [1]. These criteria are not 98 intended to constrain the IESG from issuing DISCUSSes on documents 99 that are genuinely problematic, but rather to set reasonable 100 expectation among the IESG and the community about the propriety of 101 and justification for blocking IETF documents. The IESG would 102 welcome comments on this document, which is expected to end up as an 103 informational web page. Comments can be sent to iesg@ietf.org. 105 2. Document Classes Reviewed by the IESG 107 The IESG reviews several classes of document, and applies different 108 criteria to each of these document types. The exemplary questions 109 that follow appear on each IESG agenda to remind the Area Directors 110 of the appropriate level of review for these classes: 112 Protocol Actions "Is this document a reasonable basis on which to 113 build the salient part of the Internet infrastructure? If not, 114 what changes would make it so?" 115 Document Actions (WG) "Is this document a reasonable contribution to 116 the area of Internet engineering which it covers? If not, what 117 changes would make it so?" 118 Document Actions (Individual) "Is this document a reasonable 119 contribution to the area of Internet engineering which it covers? 120 If not, what changes would make it so?" 121 Document Actions (from RFC-Editor) "Does this document represent an 122 end run around the IETF's working groups or its procedures? Does 123 this document present an incompatible change to IETF technologies 124 as if it were compatible?" 126 Of these document classes, the fundamental distinction between 127 "Protocol Actions" and "Document Actions" involves the relation of 128 these documents to the IETF Standards Track. Only Standards Track 129 and Best Common Practice documents are considered for "Protocol 130 Action"; Informational and Experimental documents are considered for 131 "Document Action". 133 Protocol Actions are naturally subject to greater scrutiny than 134 Document Actions; Area Directors are not even required to state a 135 position on a Document Action (the default being "No Objection"). 136 Accordingly, the exact criteria used to evaluate Protocol Actions 137 would benefit from greater scrutiny. The remainder of this document 138 focuses on the use of DISCUSS for standards-trakc and BCP documents. 140 3. Protocol Action Criteria 142 3.1. DISCUSS Criteria 144 The following are legitimate reasons that an Area Director might 145 state a DISCUSS position on a Protocol Action. This cannot be an 146 exhaustive list, but this set should be taken as exemplary of the 147 common causes for DISCUSSes seen by the IESG in the past. 148 o The specification is impossible to implement due to technical or 149 clarity issues. 150 o The protocol has technical flaws that will prevent it from working 151 properly, or the description is unclear in such a way that the 152 reader cannot understand it without ambiguity. 153 o It is unlikely that multiple implementations of the specification 154 would interoperate, usually due to vagueness or incomplete 155 specification. 156 o Widespread deployment would be damaging to the Internet or an 157 enterprise network for reasons of congestion control, scalability, 158 or the like. 160 o The specification would create serious security holes, or the 161 described protocol has self-defeating security vulnerabilities 162 (e.g. a protocol that cannot fulfill its purpose without security 163 properties it does not provide). 164 o It would present serious operational issues in widespread 165 deployment, by for example neglecting network management or 166 configuration entirely. 167 o Failure to conform with IAB architecture (e.g., RFC1958 [2], or 168 UNSAF [3]) in the absence of any satisfactory text explaining this 169 architectural decision. 170 o The specification was not properly vetted against the I-D 171 Checklist. Symptoms include broken ABNF or XML, missing Security 172 Considerations, and so on. 173 o The draft omits a normative reference necessary for its 174 implementation, or cites such a reference merely informatively 175 rather than normatively. 176 o The document does not meet criteria for advancement in its 177 designated standards track, for example because it is a document 178 going to Full Standard that contains 'down references' to RFCs at 179 a lower position in the standards track, or a Standards Track 180 document that contains only informational guidance. 181 o IETF process related to document advancement was not carried out; 182 e.g., there are unresolved and substantive Last Call comments 183 which the document does not address, the document is outside the 184 scope of the charter of the WG which requested its publication, 185 and so on. 186 o The IETF as a whole does not have consensus on the technical 187 approach or document. There are cases where individual working 188 groups or areas have forged rough consensus around a technical 189 approach which does not garner IETF consensus. An AD may DISCUSS 190 a document where she or he believes this to be the case. While 191 the Area Director should describe the technical area where 192 consensus is flawed, the focus of the DISCUSS and its resolution 193 should be on how to forge a cross-IETF consensus. 195 3.2. DISCUSS Non-Criteria 197 None of the following are criteria for which the IESG should DISCUSS 198 a document; though they might reasonably form the basis of a non- 199 blocking comment on a document. 200 o Disagreement with informed WG decisions that do not exhibit 201 problems outlined in Section 3.1. In other words, disagreement in 202 preferences among technically sound approaches. 203 o Reiteration of the issues that have been raised and discussed as 204 part of WG or IETF Last Call, unless the AD believes they have not 205 been properly addressed. 207 o Pedantic corrections to non-normative text. Oftentimes, poor 208 phrasing or misunderstandings in descriptive text are corrected 209 during IESG review. However, if these corrections are not 210 essential to the implementation of the specification, these should 211 not be blocking comments. 212 o Stylistic issues of any kind. The IESG are welcome to copy-edit 213 as a non-blocking comment, but this should not obstruct document 214 processing. 215 o The motivation for a particular feature of a protocol is not clear 216 enough. At the IESG review stage, protocols should not be blocked 217 because they provide capabilities beyond what seems necessary to 218 acquit their responsibilities. 219 o There are additional, purely informational references that might 220 be added to the document, such as pointers to academic papers or 221 new work. Although the cross-area perspective of the IESG invites 222 connections and comparison between disparate work in the IETF, 223 IESG review is not the appropriate time to append external sources 224 to the document. 225 o The document fails to cite a particular non-normative reference. 226 This is an appropriate non-blocking comment, but not a blocking 227 comment. 228 o Unfiltered external party reviews. While an AD is welcome to 229 consult with external parties, the AD is expected to evaluate, to 230 understand and to concur with issues raised by external parties. 231 Blindly cut-and-pasting an external party review into a DISCUSS is 232 inappropriate if the AD is unable to defend or substantiate the 233 issues raised in the review. 234 o New issues with unchanged text in documents previously reviewed by 235 the AD in question. Review is potentially an endless process; the 236 same eyes looking at the same document several times over the 237 course of years might uncover completely different issues every 238 time. 239 o "IOU" DISCUSS. Stating "I think there's something wrong here, and 240 I'll tell you what it is later" is not appropriate for a DISCUSS; 241 in that case, the AD should state the position DEFER (or, if the 242 document has already been DEFERed once, "No Objection"). 244 3.3. Saying No to A Document 246 In some cases an AD may believe that a document has fundamental flaws 247 that cannot be fixed. Normally in such cases the AD will write up a 248 description of these flaws and enter an "Abstain" position on the 249 ballot. Such a position does not support publication of the document 250 but also does not block the rest of the IESG from approving the 251 document. Normally, entering an Abstain position is a sufficient 252 mechanism for an AD to voice his or her objections. 254 However, there may be cases where an AD believes that the mechanisms 255 described in a document may cause significant damage to the Internet 256 and/or that the mechanisms described in a document are sufficiently 257 incompatible with the Internet architecture that a document must not 258 be published, despite the fact that the document is within scope for 259 the WG and represents WG consensus. This situation should be 260 extremely rare, and an AD should not take this position lightly, but 261 this does represent an important cross-area "back-stop" function of 262 the IESG. 264 In this situation, the AD will enter a "DISCUSS" position on the 265 ballot and explain his or her position as clearly as possible in the 266 tracker. The AD should also be willing to explain his or her 267 position to the other ADs and to the WG. 269 It is possible in such a situation that the WG will understand the 270 AD's objections and choose to withdraw the document, perhaps to 271 consider alternatives, and the situation will be resolved. 273 Another possibility is that the WG will disagree with the AD, and 274 will continue to request publication of the document. In those cases 275 the responsible AD should work with both the WG and the AD holding 276 the DISCUSS to see of a mutually agreeable path can be found. 278 4. DISCUSS Resolution 280 The traditional method of DISCUSS resolution is the initiation of a 281 discussion about the issues in question. This discussion may include 282 only the IESG, particularly if the DISCUSS is resolved quickly during 283 or following the IESG agenda when the document is presented. Usually 284 the discussion extends to document editors and working group chairs, 285 and entire working groups, as necessary. Increasingly, one of the 286 working group chairs may coordinate the resolution of the DISCUSS 287 (see [4]). 289 As the conclusion of this discussion, revisions to the document may 290 or may not be required. If revisions are required, it is customary 291 for the Area Director to clear their DISCUSS only when the revision 292 containing the necessary emendations has been published in the 293 Internet-Drafts repository. 295 While in many cases, DISCUSSes are resolved expeditiously, there are 296 common cases where a DISCUSS can take weeks or months to resolve, 297 given that revisions are frequently required, and such revisions need 298 to be checked by the AD that issued the DISCUSS. Accordingly, 299 DISCUSSes should be used sparingly. 301 If a DISCUSS cannot be resolved by the working group, and the AD 302 continues to hold his or her DISCUSS, the IESG has an alternative 303 balloting procedure that can be used to override a single discuss 304 position. In the alternative procedure, all ADs are required to 305 enter a "yes" or "no" position on the document. A document will be 306 published if two-thirds of the IESG state a position of "yes", and no 307 more than two ADs state a "no" position. Two-thirds of the IESG is 308 formally defined as two-thirds of the sitting ADs (current 9), except 309 for those who are recused from voting on the document in question, 310 rounded up to the next whole number. If three or more ADs hold a 311 "no" position on a document using the alternative balloting 312 procedure, or if a document fails to gather the required number of 313 "yes" positions, the document will be returned to the WG with a "no" 314 answer, which is one of the options described in RFC 2026. 316 When an AD is replaced for any reason, the successor should promptly 317 evaluate DISCUSS ballots left by his or her predecessor, and either 318 re-assert them, if they still meet the criteria of Section 3.1, or 319 register "No Objection" if they do not. The successor AD is 320 responsible for handling such DISCUSS ballots just as if they were 321 his or her own. 323 The criteria provided in this document are intended to help the IESG 324 to restrict the usage of a DISCUSS to cases where it is necessary. 326 5. IANA Considerations 328 This document contains no considerations for the IANA. 330 6. Security Considerations 332 This is a procedural document without security implications. 333 However, the ability of the IESG to review the security properties of 334 the submitted protocol specifications, point out and help resolve 335 security flaws in them is vital for Internet security. 337 7. References 339 7.1. Normative References 341 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 342 RFC 2026, October 1996. 344 [2] Carpenter, B., "Architectural Principles of the Internet", 345 RFC 1958, June 1996. 347 [3] Daigle, L., "IAB Considerations for UNilateral Self-Address 348 Fixing (UNSAF) Across Network Address Translation", RFC 3424, 349 November 2002. 351 [4] Falk, A., Levkowetz, H., and D. Meyer, "The PROTO Process: 352 Working Group Chair Document Shepherding", 353 draft-ietf-proto-wgchair-doc-shepherding-05 (work in progress), 354 March 2005. 356 7.2. Informative References 357 Authors' Addresses 359 Jon Peterson 360 NeuStar, Inc. 361 1800 Sutter St 362 Suite 570 363 Concord, CA 94520 364 USA 366 Phone: +1 925/363-8720 367 Email: jon.peterson@neustar.biz 368 URI: http://www.neustar.biz/ 370 Allison Mankin 371 Lucent Bell Labs 373 Email: mankin@psg.com 375 Margaret Wasserman 376 ThingMagic 377 One Broadway 378 14th Floor 379 Cambridge, MA 02142 380 USA 382 Phone: +1 617 758 4177 383 Email: margaret@thingmagic.com 384 URI: http://www.thingmagic.com/ 386 Intellectual Property Statement 388 The IETF takes no position regarding the validity or scope of any 389 Intellectual Property Rights or other rights that might be claimed to 390 pertain to the implementation or use of the technology described in 391 this document or the extent to which any license under such rights 392 might or might not be available; nor does it represent that it has 393 made any independent effort to identify any such rights. Information 394 on the procedures with respect to rights in RFC documents can be 395 found in BCP 78 and BCP 79. 397 Copies of IPR disclosures made to the IETF Secretariat and any 398 assurances of licenses to be made available, or the result of an 399 attempt made to obtain a general license or permission for the use of 400 such proprietary rights by implementers or users of this 401 specification can be obtained from the IETF on-line IPR repository at 402 http://www.ietf.org/ipr. 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. 410 Disclaimer of Validity 412 This document and the information contained herein are provided on an 413 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 414 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 415 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 416 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 417 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 418 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 420 Copyright Statement 422 Copyright (C) The Internet Society (2006). This document is subject 423 to the rights, licenses and restrictions contained in BCP 78, and 424 except as set forth therein, the authors retain all their rights. 426 Acknowledgment 428 Funding for the RFC Editor function is currently provided by the 429 Internet Society.