idnits 2.17.1 draft-carpenter-icar-sirs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Missing revision: the document name given in the document, 'draft-carpenter-icar-sirs-1', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-carpenter-icar-sirs-1', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-carpenter-icar-sirs-1', but the file name used is 'draft-carpenter-icar-sirs-01' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 435 lines 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 18 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([------], [PROBLEM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 2004) is 7318 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) == Missing Reference: 'TBD' is mentioned on line 192, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-problem-issue-statement-00 Summary: 10 errors (**), 1 flaw (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet Draft IBM 4 draft-carpenter-icar-sirs-1.txt D. Crocker 5 Expires: <09-04> Brandenburg 6 March 2004 8 Careful Additional Review of Documents (CARD) 9 by Senior IETF Reviewers (SIRS) 11 (draft-carpenter-icar-sirs-00.txt) 13 COPYRIGHT NOTICE 15 If published as an RFC this document will become 16 Copyright (C) The Internet Society (2003). All Rights 17 Reserved. 19 ABSTRACT 21 IETF specifications do not receive formal review until 22 they are submitted to the IESG. Hence, significant 23 problems with a specification often are not detected 24 until considerable effort has been wasted and changes 25 to fix the problems are difficult to add. The procedure 26 described in this document is intended to solve, or 27 palliate, a number of related problems that have been 28 observed in the IETF process. The basic model is to 29 create a team of Senior IETF Reviewers (SIRS), and have 30 all documents receive a certain number of reviews by 31 SIRs, prior to being submitted for publication. Review 32 at a very early stage is strongly encouraged. 34 STATUS OF THIS MEMO 36 This document is an Internet-Draft and is in full 37 conformance with all provisions of Section 10 of 38 RFC2026. 40 Internet-Drafts are working documents of the Internet 41 Engineering Task Force (IETF), its areas, and its 42 working groups. Note that other groups may also 43 distribute working documents as Internet Drafts. 45 Internet-Drafts are draft documents valid for a maximum 46 of six months and may be updated, replaced, or 47 obsoleted by other documents at any time. It is 48 inappropriate to use Internet- Drafts as reference 49 material or to cite them other than as "work in 50 progress." 52 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/1id-abstracts.html 56 The list of Internet-Draft Shadow Directories can be 57 accessed at 59 http://www.ietf.org/shadow.html. 61 TABLE OF CONTENTS 63 1. Introduction 64 2. SIRs 65 2.1. The Body of Senior Internet Reviewers 66 2.2. Obtaining SIR Participation 67 3. Carding 68 3.1. Reviewing in Public 69 3.2. Form of a Review 70 3.3. Iterative Carding 71 4. Security considerations 72 5. Acknowledgements 73 6. Informative References 74 7. Authors' Addresses 75 8. Intellectual Property 76 9. Full Copyright Statement 78 EDITORS' NOTES 80 The acronym "SIR" is retained in this draft simply for reasons of 81 continuity. However, feedback during an experimental period has shown 82 that the community would prefer an acronym without the connotations of 83 the English word "sir." 85 The mechanism proposed in Section 2.1 for selecting the panel of 86 reviewers led to considerable debate during the experimental period. It 87 has not been fundamentally modified in this draft, but the authors 88 recognize that the community may prefer a very different mechanism. 90 Change marks are included, as [[---...---]], to indicate sections of 91 text that differ from the -00 version of this draft. Segments that are 92 marked, but have no included text indicate that text was removed. 94 DISCUSSION VENUE 96 Discussion of this proposal is intended to place on the ICAR mailing 97 list 99 INTRODUCTION 101 IETF specifications do not receive formal review until 102 they are submitted to the IESG. Hence, significant 103 problems with a specification often are not detected 104 until considerable effort has been wasted and changes 105 to fix the problems are difficult to add. 106 [[--- 107 ---]] 109 The procedure described in this document is intended to 110 solve, or palliate, a number of related problems that 111 have been observed in the IETF process [PROBLEM]: 113 [[--- 114 ---]] 115 * submission of documents to the IESG that 116 still have significant problems (leading 117 to delay) 119 * failure to detect fundamental problems 120 and Internet- wide issues at an early 121 stage 123 Particularly because of the second point, it is 124 impossible to resolve these problems simply by 125 giving additional responsibility to working groups 126 themselves. An additional procedure is needed. 128 The procedure specified here calls for a team of 'sirs' 129 to 'card'. The term 'card' is used for textiles and 130 pubs. The former usage removes detritus from textiles 131 and prepares it for weaving. The latter vets 132 participants at the door. The term also is an acronym 133 for 'Careful Additional Review of Documents.' 135 [[--- 136 The carding procedure makes no change to the formal process of IETF 137 document development, review, approval, and publication. It is an 138 additional procedure intended to tackle the problems listed above. 140 The basic model is to create a team of Senior IETF Reviewers (SIRs, who 141 need be neither male nor knighted) chosen in a way designed to create 142 trust, and that all documents receive reviews by SIRs, as appropriate 143 during document development. Review at a very early stage is strongly 144 encouraged. 145 ---]] 147 The model is intended to be compatible with, and 148 complementary to, existing mechanisms such as the 149 various Directorates within the IETF and the MIB Doctor 150 system. 152 The remainder of this document described how the team 153 of SIRs is created and refreshed, how the review 154 process works, and how it is used by document authors 155 and working groups to achieve their objectives. 157 2. SIRS 159 2.1. The Body of Senior Internet Reviewers 161 2.1.1. Initial Set of SIRs 163 ---]] 164 [[--- 165 The initial team is defined by objective criteria, to 166 avoid any bias in their selection. It will consist of: 168 * all current IAB members 170 * all former IAB and IESG members, and former 171 WG Chairs, who the Secretariat can contact 172 and who are willing to serve 174 * all current MIB Doctors 176 * all members of existing IETF Directorates 178 * all authors of at least three RFCs, who the 179 Secretariat can contact and who are willing 180 to serve 182 * (other suggestions???) 184 (Current IESG Area Directors are excluded from the 185 pool.) 187 2.1.2. Addition and Removal of SIRs 189 [[--- 190 The team of SIRs is augmented as needed -- at least once a year year 191 [schedule TBD] by a public nomination process and a voting procedure 192 [TBD] among the existing SIRs. 194 SIRs who do not produce at least five reviews in a given year will be 195 retired from the team. In extremis, SIR status may be removed by a 196 simple majority vote of the team of SIRs. 197 ---]] 199 2.2. Obtaining SIR Participation 201 For Working Group documents, Working Groups solicit the 202 assistance of SIRs. That is, the general IETF 203 community controls who is authorized as a SIR, but WGs 204 control which specific SIRs provides the formal review 205 that is needed for a given document. 207 A primary goal of this proposal is to ensure that 208 Working Groups benefit from broad experience in the 209 design of Internet technology. Hence it is entirely 210 reasonable that some SIRs reviewing a given document 211 should be subject matter experts. However the full set 212 of input from SIRs is substantially more useful when it 213 includes SIRs from other areas. In particular, cross- 214 area review makes it more likely that architectural and 215 operational impacts outside of the subject matter will 216 be detected. It is therefore strongly recommended that 217 WGs seek a diverse set of SIRs to participate in 218 evaluations, able to cover most if not all IETF Areas 219 between them. 221 Each WG will make its own decision about how its SIRs 222 are selected (e.g. chosen by the WG Chairs, chosen by 223 the document authors concerned, etc.) 225 For individual submissions, the document author(s) will 226 solicit SIR reviews, according to the same principles 227 applied to Working Group documents. 229 There is no fixed number of SIR reviews required prior 230 to submission to the IESG or the RFC Editor. However, 231 it is likely that drafts with at least three positive 232 reviews from SIRs in different areas will experience 233 much shorter IESG review cycles than drafts with fewer 234 positive reviews. Other common sense rules will apply; 235 for example a MIB that has not been reviewed by a MIB 236 Doctor is unlikely to be published. 238 In all likelihood, Drafts without reviews will get 239 worse IESG response time than today, whereas Drafts 240 with reviews will be processed much more rapidly, 241 especially as the IESG's confidence in the SIR 242 procedure increases. 244 3. CARDING 246 3.1. Reviewing in Public 248 The current list of SIRs will be available on the IETF web site. 250 [[--- 251 Reviews are posted in two places. One is for public discussion, such as 252 in the relevant working group mailing list. These should be posted in 253 segments, to nvite focused threads of discussion. The second venue is as 254 a complete copy in an IETF Reviews web page. 256 A WG or document author in need of reviews should be able to request 257 them through the web site. 258 ---]] 260 3.2. Form of a Review 262 [[--- 263 [A more extensive and formalized template for reviews needs to be formulated, 264 to give reviewers guidance about offering comments on such things as 265 efficiency, operations impact, deployment/adoption issues, etc. /d] 266 ---]] 268 Each review must start with a summary statement chosen 269 from or adapted from the following list: 271 * This draft is ready for publication as a 272 [type] RFC. 274 * This draft is on the right track but has 275 open issues, described in the review. 277 * This draft has serious issues, described 278 in the review, and needs to be rethought. 280 * This draft has very fundamental issues, 281 described in the review, and further work 282 is not recommended. 284 The length of a review will vary greatly according to 285 circumstances, and it is acceptable for purely 286 editorial comments to be sent privately. All 287 substantive comments must be included in the public 288 review. 290 SIRs should review for all kinds of problems, from 291 basic architectural or security issues, Internet-wide 292 impact, technical nits, problems of form and format 293 (such as IANA Considerations or incorrect references), 294 and editorial issues. As a draft progresses from its 295 initial, "-00" version towards one that is ready for 296 submission, successive SIR reviews should progress from 297 the general architectural level to the editorial level. 299 The intention is that before a draft is submitted by a 300 WG to the IESG, or by an individual to the RFC Editor, 301 it has already benefited from a level of review 302 equivalent to that traditionally applied by the IESG. 304 3.3. Iterative Carding 306 The carding of textiles is an iterative process, and so 307 is the carding of documents by SIRs. It is not required 308 that every version of an Internet Draft should be 309 submitted for SIR review. However, it is advisable to 310 request reviews at the very beginning (to check for 311 fundamental issues), as major technical issues are 312 resolved, and again just before the document is 313 submitted for IESG approval. Thus three SIR review 314 cycles per document may be considered the minimum. 316 Both Working Groups and individual submitters should 317 realise that carding should start early (to detect and 318 hopefully fix fundamental problems) and be repeated as 319 often as needed (to avoid submitting inadequate 320 documents to the IESG). By these means, it should be 321 possible to avoid most cases where a document spends a 322 long time in IESG review or, worse, is fundamentally 323 unacceptable to the IESG. 325 4. SECURITY CONSIDERATIONS 327 This document does not directly impact the operational 328 security of the Internet. 330 5. ACKNOWLEDGEMENTS 332 Your name could go here! 334 Valuable comments and ideas have come from many 335 sources, especially an earlier draft by Ted Hardie and 336 many members of the IETF 'problem' working group. 338 6. INFORMATIVE REFERENCES 340 [PROBLEM] IETF Problem Statement, E. Davies (ed.), 341 draft-ietf-problem-issue-statement- 342 00.txt, work in progress. 344 7. AUTHORS' ADDRESSES 345 Brian E. Carpenter 346 IBM Zurich Research Laboratory 347 Saeumerstrasse 4 348 8803 Rueschlikon 349 Switzerland 351 Email: brian@hursley.ibm.com 353 Dave Crocker 354 Brandenburg InternetWorking 355 675 Spruce Drive 356 Sunnyvale, CA 94086 USA 358 Tel: +1.408.246.8253 359 dcrocker@brandenburg.com 361 8. INTELLECTUAL PROPERTY 363 PLACEHOLDER for full IETF IPR Statement if needed. 365 9. FULL COPYRIGHT STATEMENT 367 Copyright (C) The Internet Society (2003). All Rights 368 Reserved. 370 This document and translations of it may be copied and 371 furnished to others, and derivative works that comment 372 on or otherwise explain it or assist in its 373 implementation may be prepared, copied, published and 374 distributed, in whole or in part, without restriction 375 of any kind, provided that the above copyright notice 376 and this paragraph are included on all such copies and 377 derivative works. However, this document itself may 378 not be modified in any way, such as by removing the 379 copyright notice or references to the Internet Society 380 or other Internet organizations, except as needed for 381 the purpose of developing Internet standards in which 382 case the procedures for copyrights defined in the 383 Internet Standards process must be followed, or as 384 required to translate it into languages other than 385 English. 387 The limited permissions granted above are perpetual and 388 will not be revoked by the Internet Society or its 389 successors or assigns. 391 This document and the information contained herein is 392 provided on an "AS IS" basis and THE INTERNET SOCIETY 393 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 394 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 395 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 396 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 397 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 398 PARTICULAR PURPOSE.