idnits 2.17.1 draft-klensin-stds-review-panel-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 944. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 951. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 957. ** 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 == Line 525 has weird spacing: '...treated more ...' == Line 537 has weird spacing: '...real or imagi...' == Line 704 has weird spacing: '...issions of in...' == Line 741 has weird spacing: '...o serve out t...' -- 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 8, 2005) is 6867 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) == Unused Reference: 'RFC2119' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC2048' is defined on line 909, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) -- Possible downref: Non-RFC (?) normative reference: ref. 'TrackerStates' -- Obsolete informational reference (is this intentional?): RFC 1310 (Obsoleted by RFC 1602) -- Obsolete informational reference (is this intentional?): RFC 2048 (Obsoleted by RFC 4288, RFC 4289) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3932 (Obsoleted by RFC 5742) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft July 8, 2005 4 Expires: January 9, 2006 6 Procedures for Review and Approval of IETF Standards-Track Documents 7 draft-klensin-stds-review-panel-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 9, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Somewhat over a decade ago, the IETF responded to a series of 41 perceived problems with the then-IAB by restructuring the way in 42 which the IAB and IESG were constituted and assigning all standards- 43 approval and closely-related processes to the IESG. In retrospect, 44 that decision has had serious downsides: among them are the 45 observations that the IESG has become overloaded to the point that 46 the role requires an unreasonable level of investment and that the 47 intertwining of managing WGs and then reviewing and approving their 48 products has led to confusion and the risk, and sometimes the 49 appearance, of inherent conflicts of interest and abuses. This 50 document proposes to re-separate the "steering" and "WG management" 51 functions that were orginally the IESG's responsibility from the 52 "final review and standards approval" roles and respecifies the 53 standards approval process in that context. 55 The general concepts outlined in this document have been discussed 56 informally in the community for some time. This document is provided 57 as a specific proposal to facilitate a focused discussion. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Background and Overview . . . . . . . . . . . . . . . . . 3 63 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3 Impact and Documents Updated . . . . . . . . . . . . . . . 4 65 1.4 Document Review . . . . . . . . . . . . . . . . . . . . . 4 66 2. A New IETF Leadership Body: Internet Standards Review Panel . 5 67 2.1 Responsibilities . . . . . . . . . . . . . . . . . . . . . 5 68 2.2 Membership and Internal Leadership . . . . . . . . . . . . 6 69 2.3 Appointment Model . . . . . . . . . . . . . . . . . . . . 7 70 2.4 Meetings . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. The Role of the IESG . . . . . . . . . . . . . . . . . . . . . 7 72 3.1 Responsibilities . . . . . . . . . . . . . . . . . . . . . 7 73 3.2 Membership and Internal Leadership . . . . . . . . . . . . 8 74 3.3 Appointment Model . . . . . . . . . . . . . . . . . . . . 8 75 4. The IETF Chair Role . . . . . . . . . . . . . . . . . . . . . 9 76 5. The IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Progressing a Document on the Standards Track . . . . . . . . 10 78 6.1 Processing Prior to Last Call . . . . . . . . . . . . . . 10 79 6.1.1 The IETF Working Group Model . . . . . . . . . . . . . 10 80 6.1.2 The Individual Submission Model . . . . . . . . . . . 12 81 6.2 Last Call Processing . . . . . . . . . . . . . . . . . . . 13 82 6.3 Review and Approval . . . . . . . . . . . . . . . . . . . 15 83 7. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 8. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 9. Workload Risk Analysis . . . . . . . . . . . . . . . . . . . . 17 86 10. IASA Considerations . . . . . . . . . . . . . . . . . . . . 18 87 11. Internationalization Considerations . . . . . . . . . . . . 18 88 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 89 13. Security considerations . . . . . . . . . . . . . . . . . . 18 90 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 91 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 15.1 Normative References . . . . . . . . . . . . . . . . . . . 19 93 15.2 Informative References . . . . . . . . . . . . . . . . . . 19 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 95 Intellectual Property and Copyright Statements . . . . . . . . 21 97 1. Introduction 99 1.1 Background and Overview 101 Somewhat over a decade ago, the IETF responded to a series of 102 perceived problems with the then-IAB by restructuring the way in 103 which the IAB and IESG were constituted and assigning all standards- 104 approval and closely-related processes to the IESG [RFC1310], 105 [RFC1396]. In retrospect, that decision has had serious downsides. 106 Both IESG members and the community have observed that the IESG has 107 become overloaded to the point that the role requires an unreasonable 108 level of investment, limiting the possible pool of candidates. In 109 additional, the intertwining of managing WGs and then reviewing and 110 approving their products has led to confusion and the risk, and 111 sometimes the appearance, of inherent conflicts of interest and 112 abuses. Several of these issues, and their implications, were 113 discussed during the "Problem Statement" investigation [RFC3774] and 114 the subsequent discussion of resolution methods [RFC3844], but no 115 significant and effective solutions have been proposed and 116 implemented. 118 This document proposes to re-separate the "steering" and "WG 119 management" functions that were orginally the IESG's responsibility 120 from the "final review and standards approval" role that formally 121 belonged to the IAB, assigning the latter to a new body with a new 122 structure. It also outlines consequential changes, such as 123 redefining and separating the roles of IETF Chair and Chair of the 124 IESG, and specifies different flows for standards-track processing of 125 WG-produced and individual submission documents. 127 In addition to the IETF Chair separation, the net effect of these 128 changes is expected to be 130 o Freeing up the ADs for more intensive oversight of the WGs and, in 131 particular, more active coordination of WG product, including 132 encouraging arrangments for cross-area review while documents are 133 still under development. 134 o Leaving responsibility for evaluation of whether WG standards- 135 track products (and individual standards-track submissions 136 submitted via AD sponsorship) are ready for IETF Last Call in the 137 hands of ADs and the IESG and providing for additional feedback 138 from the IESG into the Last Call process. 139 o Creating a new, alternative, mechanism for moving individual 140 submission standards-track documents directly to IETF Last Call by 141 demonstrating significant community support. 142 o Putting management of IETF Last Calls for Standards Track 143 documents and post-Last-Call evaluation, including final cross- 144 area review, specific topic review ("security considerations", 145 congestion control issues, and similar statements and issues), and 146 determination of appropriateness for standardization, into the 147 hands of a new body that is focused exclusively on the review and 148 approval activity and whose primary responsibilities are to the 149 IETF as a whole, not to WGs and WG management. 150 o Moving final approval responsibility for procedural changes to the 151 IAB, with opportunity for formal input from the IESG as well as 152 the broader community. 154 Making this separation actually strengthens the role of the IESG in 155 managing the IETF process. The potential for, and appearance of, 156 conflicts of interest between effective management of a WG, including 157 making technical contributions and other suggestions to it, and then 158 being the final judge of that WG's work is eliminated, as is the 159 appeals chain as a remedy for an IESG decision to hold a document for 160 further work. Other provisions of this document are likely to 161 further strengthen the steering and managing role as the new 162 arrangements stabilize. 164 1.2 Terminology 166 Document states referred to in this specification as "tracker states" 167 or as "in the tracking system" are defined in [TrackerStates]. For 168 the purposes of this specification, "IETF Standards Track documents" 169 are considered to include technical specifications and applicability 170 statements being processed at any maturity level and BCP documents 171 that specify technical, engineering, or operational best practices. 172 Except as modified or redefined by this specification or applicable 173 updates, document types, status, and maturity levels are as defined 174 in [RFC2026]. 176 1.3 Impact and Documents Updated 178 In making these changes, this document significantly modifies the 179 allocations of responsibilities in [RFC2026], the organizational 180 description in [RFC2028], and the nomcom responsibilities in 181 [RFC3777]. 183 1.4 Document Review 185 [[ Note in Draft: This version of the document contains comments from 186 the author about issues to be resolved or particular choices made in 187 the associated text. Those comments are delimited by doubled left 188 and right square brackets (such as those surrounding this text). 189 Because of the method used to produce them, they will normally appear 190 in the text version of the Internet-Draft with an "anchor" number and 191 designation. ]] 193 [[ Note to the RFC Editor: if this I-D reaches you without this 194 subsection and all other text delimited by [[ ... ]] having been 195 first removed, something is seriously wrong. ]] 197 2. A New IETF Leadership Body: Internet Standards Review Panel 199 This document defines a new IETF body, the Internet Standards Review 200 Panel (ISRP), referred to for convenience as the "panel" or the 201 "Review Panel" below. That body will be responsibility for final 202 processing review of documents for standardization. While it may 203 comment on its reasons for accepting or rejecting a document, it is 204 intended to accept a specification or return it for further work. It 205 has no role in negotiating the content of documents, nor in proposing 206 specific alternatives except as input to the normal IETF process. 208 [[anchor6: That is a fairly hard line and high bar. Some relaxation 209 may be appropriate, but it might put us on a slippery slope and 210 create a good deal of confusion about the boundary between the 211 "review" function of this body and the "management, steering, and 212 document clearing" roles of the IESG.]] 214 2.1 Responsibilities 216 Documents are presented to this body for standards-track review and 217 approval via one of the mechanisms described in Section 6.1. 218 Section 6 covers steps in document processing more generally, 219 including the Last Call and evaluation processes themselves. The 220 panel directs that an IETF Last Call be initiated, reviews the 221 results of the Last Call, commissions special review committees as it 222 deems necessary for particular documents, conducts a final technical 223 oversight review, and approves documents on the IETF Standards Track. 224 It may reject a document for unsuitability at any stage in the 225 process, providing an explanation and returning the document to the 226 group or body that submitted it. Rejection is a serious measure: the 227 panel is expected to be more flexible about clearly early-stage 228 specifications (such as obviously pre-implementation Proposed 229 Standards) but to set a higher bar on more mature and operational 230 practices documents. The panel may, as an alternative to rejection, 231 suggest qualifying text or disclaimers to be included in the 232 document, including identification of known deficiencies in first- 233 stage Standards Track documents, but changes of that nature must be 234 agreed to by the submitters and reviewed via an IETF Last Call (on 235 the changes alone, not the base specification) of not less than two 236 weeks duration. 238 [[anchor8: This is a somewhat tougher set of rules with regard to 239 post-Last-Call document modification than the IESG has been operating 240 under. They appear to be consistent with the tone of the Problem 241 Statement discussion and more recent comments on the IETF mailing 242 list. Note that "changes of that nature" (which will need to be 243 tightened up in any final version), involves changes that 244 substantively impact the specification or its applicability. The 245 specifications of this document do not change procedures for 246 editorial review and corrections by the RFC Editor or the review of 247 those changes by authors subsequent to RFC Editor processing.]] 249 With the exception outlined immediately below, the panel will have no 250 involvement with Experimental or Informational specifications unless 251 they are presented as informative and coordinated parts of a package 252 with one or more standards-track specifications, nor will it have any 253 involvement with IETF Procedural documents (whether identified as 254 "BCP"s or not). Responsibility for those classes of documents is 255 identified below. 257 As suggested elsewhere in this document, the panel is expected to 258 commission reviews and retain oversight of them, rather than being 259 expected to conduct all reviews itself. A clear shortage of 260 competent and willing reviewers for a given specification should be 261 taken as an indication that the specification is not of interest to 262 the IETF community and hence a reason to return the specification 263 with a recommendation that it be considered for publication as 264 Informational (or possibly Experimental) rather than on the standards 265 track. [[anchor9: This is another tough norm that may need to be 266 diluted. But, as a norm, it deserves discussion and consideration.]] 268 2.2 Membership and Internal Leadership 270 The panel will initially consist of ten members, with six chosen to 271 reflect the skill set of the current IETF Areas and four chosen to 272 reflect general, cross-area, expertise. Should the IESG increase or 273 decrease the number of areas, the number of area-specific members of 274 the panel will increase or decrease accordingly. 276 [[anchor11: The membership numbers are a little arbitrary and should 277 be discussed and tuned as needed. The "one per area" number was 278 chosen under the reasoning that, since this group is picking up well 279 under half of the IESG's current responsibilities, and the IESG is 280 functioning with two people per area, one should be sufficient. 281 Somewhat fewer people should be generalists, specifically chosen to 282 have broad, cross-area, understanding of the Internet and the 283 Internet protocol suite. And it seems desirable to keep this body 284 small enough to let it work efficiently]] 286 The panel will select one of its members to act as Chair, using a 287 mechanism of its choosing. The position of Chair may be rotated if 288 the panel concludes that is appropriate and efficient. The Chair is 289 expected to lead meetings of the panel and to provide a general 290 coordination function with support from the IASA. [[anchor12: There 291 are reasonable arguments for having the Chair selected as an 292 additional panel member by the Nomcom and responsible directly to the 293 community rather than to members of the panel. Intutitively, that 294 seems like an opportunity for more bureaucracy with little payoff, 295 but the community needs to discuss this one. There is also a case to 296 be made for selecting the Chair only from the "general expertise" 297 subset of the panel, but I would think we could let the panel sort 298 that out.]] 300 2.3 Appointment Model 302 The panel will be selected by the Nomcom, using the usual methods, 303 and for a two-year term. Given the nature of the review process, the 304 Nomcom should generally favor former WG Chairs and document editors 305 and others with established reputations for a broad view of the 306 technical issues facing the community. The terms of the area- 307 specific members and the general expertise ones should be separately 308 staggered, with roughly half of each group being selected each year. 309 The rules about resignations and replacements in [RFC3777] should 310 generally apply to the panel as well as to the IESG. [[anchor14: 311 Ultimately, 3777 is likely to need a specific update for this, but, 312 for now...]] 314 Members of the Review Panel are subject to the same recall provisions 315 as the IESG, the IAB, and the IETF Chair. 317 2.4 Meetings 319 While an occasional face to face meeting might be convenient, there 320 is no intrinsic requirement that the Review Panel "meet" other than 321 by email and occasional teleconferences. This might create an 322 opportunity for the Nomcom to include, in the selection of ISRP 323 members, IETF participants who are long-term technical contributors 324 to the community but who rarely if ever attend IETF meetings. 326 3. The Role of the IESG 328 3.1 Responsibilities 330 With the exception of shifting the final review phase to the Review 331 Panel, the IESG role continues as it has been. The IESG remains the 332 manager of WGs, the overseer of IETF operations, and the manager of 333 the standards process. The ADs are also the primary gating group for 334 advancement of documents into Last Call and provide the management 335 mechanism for dealing with any documents on which the Review Panel 336 pushes back. It shares with the Review Panel the responsibility for 337 ensuring that cross-area review occurs within the WG process and is 338 responsible for preventing late surprises. As described in existing 339 specifications and current practice, the IESG retains the decision 340 responsibility for reviewing and accepting WG charters (with the 341 advice of the IAB), creating WGs, selecting or approving WG 342 leadership, and for managing and terminating those WG. The various 343 groups now responsible for new participant training, tools, and 344 facilitation of the standards process continue to be responsible to 345 the IESG and the IESG retains the lead responsibility for 346 coordinating meeting scheduling and arrangements with the Secretariat 347 and IASA, evaluating implementation reports and IPR compliance, and 348 so on. 350 As the managers of the IETF standards process, the IESG and the ADs 351 who make it up also retain their roles in determining whether 352 independent submissions to the RFC Editor constitute "end runs" of 353 the IETF process as outlined in [RFC3932] and as the advisor to the 354 IANA on registration matters that require IESG review and approval 355 rather than the more formal approval from the IETF Community that 356 goes with standards-track processing (see [RFC2434]). The IESG also 357 retains the authority to request publication of Informational or 358 Experimental RFCs that describe IETF products and review 359 responsibility for IETF procedural documents (see Section 5). 361 More details on standards processing can be found in Section 6. 363 3.2 Membership and Internal Leadership 365 The IESG membership and appointment structure continues essentially 366 unchanged. Areas are created and dissolved at IESG discretion. The 367 only significant change is that the IESG obtains a Chair separate 368 from the IETF Chair (see Section 4), one whose primary 369 responsibilities are leading or coordinating IESG meetings and 370 representing the IESG to the IASA/IAOC and other bodies. 372 The IETF Chair becomes an ex-officio non-voting member of the IESG, 373 on the same basis as the IAB Chair today. No other changes are made 374 to non-AD memberships and liaisons to the IESG. 376 3.3 Appointment Model 378 The IESG members, other than the IESG Chair, are selected as 379 specified in [RFC3777]; no change is anticipated. 381 The IESG Chair is chosen by the IESG from their own membership, using 382 a method of their choice. At the discretion of the IESG and after 383 consulting with and obtaining the advice of the Nomcom chair, the 384 individual chosen as IESG Chair may be relieved of responsibility for 385 a technical area and the Nomcom asked to fill the vacancy thereby 386 created. [[anchor20: Because IESG members are generally chosen on the 387 basis of expertise in particular areas, this may turn out to be too 388 convoluted and it may be better to have the Nomcom select the IESG 389 Chair. On the other hand, the job of IESG Chair may not be 390 burdensome (and it may be to the advantage of the commmunity to 391 prevent it from becoming burdensome) and there are significant 392 advantages to having an IESG Chair who is chosen by the IESG 393 membership as a leader rather than having the selection made 394 externally.]] 396 4. The IETF Chair Role 398 In order to facilitate a clean appeal process, general IETF 399 leadership, and coordination with the IASA and between the IESG and 400 the ISRP (Review Panel), the role of IETF Chair is separated from the 401 role of chairing the IESG and optionally leading one of its Areas. 402 The IETF Chair continues to be chosen by the Nomcom, as in the past. 403 The IETF Chair also continues as an ex-officio member of the IAOC. 405 [[anchor21: Note in Draft: this section, and the IETF Chair role, is 406 underspecified, somewhat deliberately so. It will probably need more 407 words. One of the reasons there aren't more yet is that this 408 document is discussing the relevant roles in the context of 409 standards-track document processing; the IETF Chair has a number of 410 roles (some very time-consuming) that are unrelated to either 411 standards-track document processing or leading the IESG.]] 413 5. The IAB 415 With two exceptions, the specifications of this document have no 416 impact on the IAB. In particular, the relationships between the IAB 417 and external bodies and between the IAB and the IETF are unchanged. 418 The first of those exceptions involves the changes in the flow of 419 appeals to the IAB, as discussed in Section 7 below. There are no 420 changes in the way the IAB handles appeals that reach it. 422 The second is that, on the same theory that it is undesirable for the 423 IESG to have final approval responsibility for documents whose 424 production they manage, this specification shifts final review and 425 approval responsibility for IETF procedural documents and changes 426 from the IESG to the IAB. Such changes must be proposed to the IESG 427 (either directly or via a WG) as they are under existing rules. The 428 IESG will then review the relevant documents and, having done so, 429 forward them to the IAB. Normally, the IESG will forward the 430 proposed document(s) with a formal opinion as to whether or not they 431 should be adopted and the reasons for that conclusion, but the IESG 432 may forward a document without comment. The IAB will then initiate 433 an IETF Last Call, normally for four weeks, on the document(s), 434 including any IESG comments and recommendations in the Last Call 435 statement to the community. Once the Last Call concludes, the IAB 436 will evaluate the consensus of the community and approve or 437 disapprove the proposal on that basis. 439 [[anchor22: The above may be controversial, but symmetry implies that 440 it should at least be considered. One would hope that the community, 441 and the IAB, would pay careful attention to reasoned IESG comments on 442 any procedural proposals, especially when those comments are based on 443 IESG experience with IETF management. If they do not, we probably 444 have far more serious problems than whether or not a procedural 445 change is approved.]] 447 Unreasonable delay on the part of the IESG in forwarding a procedural 448 proposal to the IAB, or procedural irregularities by the IAB in 449 processing it, may be appealed using the usual mechanisms. 451 6. Progressing a Document on the Standards Track 453 Under the system documented in RFC 2026 and adapted and refined by 454 the IESG, there are two ways to get a document processed onto the 455 standards track. They are submission of a document to the IESG via a 456 WG or an individual submission directly to the IESG. The former goes 457 through the AD responsible for the working group. Those attempting 458 the latter must find an AD who is willing to "sponsor" and then 459 "shepherd" the document; if no AD can be found who is interested, the 460 document essentially dies. The processing paths outlined below 461 preserve those two models, albeit with small variations, and 462 introduce a third one. 464 6.1 Processing Prior to Last Call 466 6.1.1 The IETF Working Group Model 468 This is the traditional model and continues essentially unchanged up 469 to the point of Last Call initiation. When a WG believes that it has 470 completed work on a document, it forwards it, with a publication 471 request, to the responsible AD after whatever level of checking and 472 preparation of ancillary materials the WG concludes is appropriate or 473 the AD insists upon. The AD performs a review. Based on that 474 review, the AD may take one of the actions specified in the next 475 three subsections: 477 6.1.1.1 Immediate Last Call 479 If the AD is satisfied about both the quality of the document and the 480 level of review it has received, he or she may forward it directly to 481 the Review Panel with a Last Call request. If this action is chosen, 482 IESG review occurs in parallel with Last Call and any IESG comments 483 become input to the Review Panel's consideration of Last Call 484 results. 486 6.1.1.2 IESG Review, Then Last Call 488 The AD may conclude that the document should be more extensively 489 reviewed by the IESG prior to an IETF Last Call. If that action is 490 chosen, the IESG may 492 o conclude that a Last Call should be initiated, 493 o specify text for the Last Call announcement that, e.g., calls the 494 community's attention to specific issues that should be examined, 495 o make a recommendation to the Review Panel about specific issues to 496 be considered without specifying specific Last Call text, or 497 o return the document to the WG, as described in the next 498 subsection. 500 6.1.1.3 Return of document to WG 502 The document may be returned to the WG for further consideration or 503 processing. The AD or IESG is expected to supply the WG with a clear 504 enough statement of issues with, and expectations of, the document 505 and the review process that the WG can either make progress on a 506 satisfactory revision to conclude that it should be abandoned. A 507 decision by an AD or the IESG to return a document to the WG is not 508 subject to appeal, see Section 7. 510 6.1.1.4 Internal IESG Processing Conventions 512 The IESG may, from time to time, adopt whatever rules or conventions 513 it finds appropriate to set conditions on the choices of these 514 actions, e.g., on the circumstances under which an AD may initiate an 515 IETF Last Call, or return a document to the WG, without prior IESG 516 review and decisions. It may also determine the conventions by which 517 IESG consensus to take an action is determined, including conditions 518 under which a document may be blocked, and may create guidelines for 519 information to be supplied when a document is returned to a WG. Such 520 rules and conventions must be announced to the community, may, at the 521 IESG's discretion, be Last Called (with the Last Call results 522 evaluated by the IESG), and may be appealed. 524 [[anchor27: Note that, for WG documents, and individual documents 525 that are treated more or less as WG documents (see below), the IESG 526 is permitted to establish procedures essentially identical to those 527 that exist today, including the use of blocking "discuss" positions. 529 The author would encourage the IESG to adopt rules that make the 530 first of these paths (AD to Last Call without IESG review) a rare 531 situation at least until experience is accumulated with the new 532 system. However, these block Last Call initiation, rather than final 533 approval of a standard. By giving the IESG the opportunity to 534 identify specific concerns in the Last Call announcement, the odds of 535 the community paying attention to, and commenting on, those concerns 536 are considerably increased. This document deliberately does not 537 address any real or imaginary concerns about abuse of such 538 procedures on the grounds that such concerns are better dealt with by 539 ongoing dialogue between the community and the IESG rather than by 540 rigid rules.]] 542 6.1.2 The Individual Submission Model 544 Traditionally, non-working-group requests for approval of a 545 standards-track document must go through the IESG and achieve support 546 and sponsorship from at least one AD in order to progress to IETF 547 Last Call. This document specifies a (deliberately difficult) 548 alternative, largely to provide a better solution to the perception 549 of IESG blocking of WG and non-WG documents than the appeal process. 551 6.1.2.1 Alternative 1: AD Approval 553 This is an updated version of the traditional procedure. The 554 submitter finds an AD who is willing to sponsor and shepherd the 555 document through the IESG. The document is then processed exactly as 556 if it were a WG document (see Section 6.1.1, above) except that any 557 return of the document should be to the submitter and specific 558 concerns about it may, at the IESG's discretion, be announced to the 559 IETF list. 561 6.1.2.2 Option 2: Demonstrated Community Support 563 A Last Call may be requested on a document without the requirement 564 for IESG sponsorship by having its proponents demonstrate that there 565 is significant community support for the proposal. Such a request is 566 initiated by a petition submitted to the IETF Chair (see below) 567 asking that the specification be processed for the IETF standards 568 track. The petition must 570 o be endorsed as required for a Recall petition under section 7(1) 571 of [RFC3777] (20 signatures of people eligible for the nomcom), 572 o contain affirmation by every signatory that they have conducted an 573 individual technical review of the document and that they believe 574 it is appropriate for standardization as written 576 o contain certifications by at least ten of the signatories that 577 they were not involved with the development of the document, or 578 technical contributors to it, prior to conducting their technical 579 review, i.e., that they are independent reviewers. 581 When the IETF Chair receives such a petition, he or she will cause a 582 preliminary announcement to be made to the community indicating that 583 a Last Call is being contemplated and that any procedural or work- 584 conflict concerns should be identified to the IESG. The IESG will 585 then be given a fixed-timeout period, not to exceed one month, to 586 comment, to the Review Panel and the community, on possible conflicts 587 between the proposed specification and work going on in the IETF, in 588 a style similar to that contemplated in [RFC3932]. The IESG may 589 raise any other concerns, including technical ones, at this point, or 590 may defer them until the Last Call. Once that report is received, or 591 the time allotted runs out, the IETF Chair will ask the Review Panel 592 to initiate a Last Call as described below, including any IESG 593 procedural, technical, or conflict comments in the Last Call 594 announcement (or referencing those materials from it). 596 While responsibility for managing this process through to submission 597 to the Review Panel for Last Call rests with the IETF Chair, the 598 actual steps, including receipt of petitions and issuing requests to 599 the IESG and Review Panel, may be delegated to the IASA by an 600 appropriate announcement to the community. 602 [[anchor29: This option was included because of concerns that the 603 stylistic tastes of individual IESG members might be blocking (in the 604 sense of preventing any community review at all) work that had wide 605 community support. The binding of the petition threshold to that of 606 the recall procedure in RFC 3777 was a fairly arbitrary choice, made 607 on the assumption that the community had already concluded that 608 threshold was adequate to balance the need for review against the 609 risk of denial of service attacks on the system. Better formulae are 610 certainly possible; in particular, we should have a model by which 611 active IETF participant-contributors who do not come to face to face 612 meetings can endorse one of these Last Call requests. But the 613 explicit idea here is to encourage people to send proposals through 614 the IESG route unless that appears to be blocked for some reason. On 615 the other hand, if it is blocked, our focus should be on engineering 616 and standardization, not procedural quibbling.]] 618 6.2 Last Call Processing 620 When a request is received by the Review Panel to initiate a Last 621 Call, they will cause a Last Call package and announcement to be 622 assembled and published to the IETF Announce list. That package will 623 consist of, at least, abstracts of and references to the document or 624 documents, plus any concerns raised by or specific review requests 625 from, the IESG. For "community support" individual submissions, any 626 statements from the IESG about conflicts will also be included: the 627 ultimate judgment as to whether conflicts should be eliminated or 628 should lead to conflicting standards, and whether or not those 629 standards adequately identify the tradeoff considerations, rests with 630 the community. 632 The Review Panel may include such other information with the Last 633 Call announcement as it considers appropriate. Any of the 634 administrative elements of Last Call preparation and processing may 635 be delegated to the IASA by mutual consent. 637 Note that, while the Review Panel may conduct a preliminary review 638 before sending out the Last Call announcement, and add its 639 preliminary observations, if any, to the Last Call package, all 640 documents submitted to it will be sent out for IETF Last Call and 641 review or other activities by the Review Panel are not permitted to 642 significantly delay that action. 644 [[anchor31: Explanation: this document assumes that technical or 645 editorial iterations on a document should occur before the 646 community's time is taken up with an IETF Last Call, presumably in a 647 Working Group or equivalent setting. Once a document is Last Called, 648 processing is expected to be linear, leading to either acceptance or 649 rejection ("return"), and with minimal iteration loops. The entire 650 Review Panel concept is intended as a final quality check and 651 determination that all issues that should be covered have been 652 covered in an adequate way. As suggested elsewhere, if significant 653 problems are found during or after Last Call, it indicates a failure 654 in the processes that prepared and checked the document and 655 authorized and requested a Last Call on it.]] 657 IETF Last Calls for "community support" submissions will last for 658 four weeks unless the Review Panel concludes that a longer period is 659 needed. Other Last Calls will be as specified in RFC 2026 (two weeks 660 for WG-produced documents, four for others, unless the IESG 661 determines that a longer period is desirable). 663 If the IESG has not already conducted an in-depth review of the 664 document, it is expected to do so during Last Call, with its comments 665 and recommendations submitted to the Review Panel and, optionally, 666 circulated to the community. 668 The Review Panel may grant reasonable extensions to the Last Call 669 period if an extension is requested and believed to be in the best 670 interest of the community. 672 6.3 Review and Approval 674 Once the Last Call is completed, the Review Panel will assess the 675 Last Call comments. Documents should be approved for publication on 676 the standards track if and only if the Review Panel is convinced that 677 they are supported by community consensus, that they are technically 678 adequate to the grade or maturity level for which they are proposed, 679 and that they are editorially sufficient that their meaning and 680 intent is clear, again as appropriate to grade. The Review Panel is 681 expected to solicit or conduct additional reviews as needed to 682 calibrate or supplement Last Call comments. When it has concluded 683 its review, the Review Panel is expected to reach consensus, using a 684 method of its choosing but announced to the community, on whether the 685 document should be published on the standards track. If it concludes 686 that it should be, it will cause Protocol Action notices to be 687 published and the document to be forward to the RFC Editor. If it 688 concludes that it should not, the document(s) are returned to the 689 submitter (the IESG for WG documents or AD-sponsored individual 690 submissions) and the authors otherwise). The returned document will 691 be accompanied comments that describe the reasons the Review Panel 692 was not willing to standardize the specification. Those comments 693 will normally be published to the IETF community and may include a 694 recommendation as to whether or not a revised version of the document 695 should be resubmitted. 697 For "community support" submissions that are returned, rather than 698 standardized, the Review Panel may establish procedures that require 699 a higher level of review and endorsement before revised forms of the 700 documents are resubmitted for Last Call. Such procedures must be 701 announced to the community and may be appealed. [[anchor33: 702 Obviously, this provision is intended to provide a hook for 703 protection against denial of service attacks and even well- 704 intentioned repeated submissions of inappropriate documents. If it 705 also has the effect of encouraging higher quality for first 706 submissions lest a future submission not be considered, so much the 707 better.]] 709 7. Appeals 711 Appeals on actions of the IESG flow to the relevant ADs, then the 712 IESG Chair, then the IETF Chair, then the IESG, and then to the IAB. 713 Appeals on actions of the ISRP (Review Panel) flow to the ISRP Chair, 714 then the IETF Chair, then to the IAB. Appeals to the IAB on matters 715 of approval or rejection of documents are constrained as they are 716 under current procedures: the IAB may instruct the ISRP to reconsider 717 an action, but may not itself reverse an ISRP decision. Appears 718 beyond the IAB are governed by procedures and constraints now in 719 effect. 721 In this process, the IETF Chair is encouraged and expected to mediate 722 between the complaining party and the body to whom the appeal is 723 addressed and attempt to resolve problems without the need for full- 724 scale appeals. 726 Decisions by the IESG or, where appropriate, by an individual AD, to 727 not forward a document to the ISRP for standards-track review and 728 approval may not be appealed. The IETF Chair or, in the case of an 729 individual AD decision, the IESG Chair, may be requested to attempt 730 to mediate the situation but, if that fails, the only recourse 731 available to proponents of the document is the "Community Support" 732 option described in Section 6.1.2.2. 734 8. Transition 736 [[anchor35: Obviously, this is a can of worms and the text that 737 appears below is only one of several options. In the author's 738 opinion, if we are going to do this, we should get on with it rather 739 than devising some gradual transition plan, but that still leaves 740 several options. One could, for example, imagine plans that would 741 permit all current ADs to serve out their terms under current 742 definitions and only when they are reappointed or replaced would 743 their roles transition to the new model.]] 745 If the community believes that this document addresses a sufficiently 746 important set of problems to be worth the changes it suggests, those 747 problems should be solved sooner rather than later. One such fast- 748 track transition model would involve the following steps. 750 1. Nomcom selects initial set of members of the Review Panel, half 751 for a full term and half for a half-term. 752 2. The Review Panel is seated after selection and confirmation. 753 3. Documents not already in the tracking system at "AD Evaluation" 754 or some more advanced state are processed under the old rules 755 unless the IESG, at its discretion, decides to pass formal review 756 off to the Review Panel. Document in "Publication Requested" may 757 be processed through the old rules by agreement between the 758 submitter and the IESG (or, for a WG document, the relevant AD), 759 or may be shifted to the new rules if that is preferable or 760 agreement cannot be swiftly reached. 761 4. New documents (i.e., in "I-D Exists" state or earlier) as of the 762 date the Review Panel is seated will be processed through the new 763 system. 765 Except for very unusual cases, this should result in a complete shift 766 to the new system within several months of the seating of the Review 767 Panel. For the unusual cases, and expecially for documents already 768 in Last Call or later, the IESG can make case-by-case decisions, as 769 it deems appropriate, to accelerate handoff to the Review Panel. 771 Transfer of responsibility for reviewing and approving procedural 772 changes from the old model to the one specified in this document will 773 occur immediately upon approval for this document for any proposals 774 not already in IETF Last Call. 776 9. Workload Risk Analysis 778 [[Note to RFC Editor: this section is to be removed before 779 publication.]] 781 The changes proposed here are proposed because they appear to be the 782 Right Thing to Do in terms of getting better quality standards out of 783 the IETF. By eliminating the final review load from the IESG's task 784 list, it should make the IESG role less burdensome and, by permitting 785 other IESG responsibilities to run in parallel with the conduct and 786 evaluation of Last Calls by another body, should improve overall 787 processing speed while delivering a equal or higher level of overall 788 quality. 790 It is impossible to predict how long it would take to process a 791 standard through the "community support" path of Section 6.1.2.2 792 because no equivalent to that procedure has existed in the IETF, at 793 least within the last decade or so. But, if it turns out to be too 794 heavyweight, the community will either need to tune it or drop it: 795 dropping it or ignoring it would leave us no worse off than with the 796 "find a sponsoring AD or forget it" situation we are in today. 798 However, it introduces an extra half-step into the standards process 799 with the opportunity for IESG review prior to Last Call. I have 800 every confidence that, if the community were to conclude that this 801 proposal is the right way to go, the IESG will get with the spirit of 802 the thing and progress documents quickly and efficiently, taking 803 advantage of their newfound increased time to monitor WG work more 804 aggressively in ways that prevent weak documents from emerging from 805 the system at all. However, to the extent that, e.g., ADs are 806 inappropriately sitting on WG documents rather than letting them go 807 to Last Call today (a claim that was made during the Problem 808 Statement process), this proposal will not help with that issue. 809 While the procedures above intentionally do not bar it, one must 810 assume that neither the IESG nor the broader community would be 811 particularly sympathetic to IETF WGs using the community support 812 option. There are almost certainly other ways by which this proposal 813 could stretch the approval process out; some would at least result in 814 better quality, others would not. 816 10. IASA Considerations 818 While this specification will reduce IESG workload and shift some 819 responsibilities to the Review Panel (ISRP), the mere existence of a 820 third body that has to maintain mailing lists, talk at regular 821 intervals, make decisions and maintain records of them, and so on 822 will inevitably increase the overall IETF administrative workload. 823 In addition, several sections above make provision for the IETF Chair 824 and the Review panel to shift operational responsibility for various 825 tasks, such a receiving and logging documents and assembling Last 826 Call packages, to the IASA. The IAD, IAOC, and the community had 827 best be prepared for this shift in responsibilities and the 828 additional resources that might be required. 830 The specification also increases the IAOC membership by one, adding 831 the IESG Chair position to the IETF Chair one. It does not 832 contemplate representation of the ISRP itself on the ISRP. 834 [[anchor38: And besides, I couldn't resist writing the first "IASA 835 Considerations" section into an I-D. I can only hope that it does 836 not turn into a requirement .]] 838 11. Internationalization Considerations 840 This document specifies IETF procedures and does not interact with 841 internationalization. 843 12. IANA Considerations 845 This document specifies internal procedures for IETF operation and 846 hence does not involve any actions for the IANA. However, by making 847 shifts in the review and approval procedures for standards-track 848 documents, it inevitably makes some changes to the specific paths 849 over which IANA receives directions. 851 [[anchor41: If this document gets traction, a future version will 852 need to be much more specific about the above.]] 854 13. Security considerations 856 This document specifies IETF procedures. It should have no direct 857 impact on Internet security although, if it is successful, it should 858 improve the quality of security review and the balance between 859 security considerations and other issues in IETF standards-track 860 documents. 862 14. Acknowledgements 864 This document is an attempt to draw a number of more or less similar 865 ideas about again having separate standards document approval and 866 steering and management functions for the IETF together into a 867 proposal specific enough that a discussion, not just speculation and 868 general nodding, can become possible. The author can remember 869 picking up pieces of the ideas suggested here from many conversations 870 over the last four or five years, sometimes as suggestions from 871 others and sometimes as reactions that ended up being completely 872 opposite to those suggestions. A list of those who contributed ideas 873 would therefore include people who might be horrified of what their 874 ideas have evolved into. Nonetheless, all of those ideas are 875 gratefully acknowledged while the author must take the blame for the 876 synthesis. 878 15. References 880 15.1 Normative References 882 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 883 3", BCP 9, RFC 2026, October 1996. 885 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 886 the IETF Standards Process", BCP 11, RFC 2028, 887 October 1996. 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels'", RFC 2119, March 1997. 892 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 893 Recall Process: Operation of the Nominating and Recall 894 Committees", BCP 10, RFC 3777, June 2004. 896 [TrackerStates] 897 Internet Engineering Steering Group (IESG), "Main States", 898 https: //datatracker.ietf.org/public/states_table.cgi, 899 July 2005. 901 15.2 Informative References 903 [RFC1310] Chapin, A., "The Internet Standards Process", RFC 1310, 904 March 1992. 906 [RFC1396] Crocker, S., "The Process for Organization of Internet 907 Standards Working Group (POISED)", RFC 1396, January 1993. 909 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 910 Internet Mail Extensions (MIME) Part Four: Registration 911 Procedures", BCP 13, RFC 2048, November 1996. 913 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 914 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 915 October 1998. 917 [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. 919 [RFC3844] Davies, E. and J. Hofmann, "IETF Problem Resolution 920 Process", RFC 3844, August 2004. 922 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 923 Procedures", BCP 92, RFC 3932, October 2004. 925 Author's Address 927 John C Klensin 928 1770 Massachusetts Ave, #322 929 Cambridge, MA 02140 930 USA 932 Phone: +1 617 491 5735 933 Email: john-ietf@jck.com 935 Intellectual Property Statement 937 The IETF takes no position regarding the validity or scope of any 938 Intellectual Property Rights or other rights that might be claimed to 939 pertain to the implementation or use of the technology described in 940 this document or the extent to which any license under such rights 941 might or might not be available; nor does it represent that it has 942 made any independent effort to identify any such rights. Information 943 on the procedures with respect to rights in RFC documents can be 944 found in BCP 78 and BCP 79. 946 Copies of IPR disclosures made to the IETF Secretariat and any 947 assurances of licenses to be made available, or the result of an 948 attempt made to obtain a general license or permission for the use of 949 such proprietary rights by implementers or users of this 950 specification can be obtained from the IETF on-line IPR repository at 951 http://www.ietf.org/ipr. 953 The IETF invites any interested party to bring to its attention any 954 copyrights, patents or patent applications, or other proprietary 955 rights that may cover technology that may be required to implement 956 this standard. Please address the information to the IETF at 957 ietf-ipr@ietf.org. 959 Disclaimer of Validity 961 This document and the information contained herein are provided on an 962 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 963 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 964 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 965 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 966 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 967 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 969 Copyright Statement 971 Copyright (C) The Internet Society (2005). This document is subject 972 to the rights, licenses and restrictions contained in BCP 78, and 973 except as set forth therein, the authors retain all their rights. 975 Acknowledgment 977 Funding for the RFC Editor function is currently provided by the 978 Internet Society.