Network Working Group J. Klensin Internet-Draft July 8, 2005 Expires: January 9, 2006 Procedures for Review and Approval of IETF Standards-Track Documents draft-klensin-stds-review-panel-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 9, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Somewhat over a decade ago, the IETF responded to a series of perceived problems with the then-IAB by restructuring the way in which the IAB and IESG were constituted and assigning all standards- approval and closely-related processes to the IESG. In retrospect, that decision has had serious downsides: among them are the observations that the IESG has become overloaded to the point that the role requires an unreasonable level of investment and that the intertwining of managing WGs and then reviewing and approving their products has led to confusion and the risk, and sometimes the Klensin Expires January 9, 2006 [Page 1] Internet-Draft IETF Standards Review July 2005 appearance, of inherent conflicts of interest and abuses. This document proposes to re-separate the "steering" and "WG management" functions that were orginally the IESG's responsibility from the "final review and standards approval" roles and respecifies the standards approval process in that context. The general concepts outlined in this document have been discussed informally in the community for some time. This document is provided as a specific proposal to facilitate a focused discussion. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Background and Overview . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Impact and Documents Updated . . . . . . . . . . . . . . . 4 1.4 Document Review . . . . . . . . . . . . . . . . . . . . . 4 2. A New IETF Leadership Body: Internet Standards Review Panel . 5 2.1 Responsibilities . . . . . . . . . . . . . . . . . . . . . 5 2.2 Membership and Internal Leadership . . . . . . . . . . . . 6 2.3 Appointment Model . . . . . . . . . . . . . . . . . . . . 7 2.4 Meetings . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. The Role of the IESG . . . . . . . . . . . . . . . . . . . . . 7 3.1 Responsibilities . . . . . . . . . . . . . . . . . . . . . 7 3.2 Membership and Internal Leadership . . . . . . . . . . . . 8 3.3 Appointment Model . . . . . . . . . . . . . . . . . . . . 8 4. The IETF Chair Role . . . . . . . . . . . . . . . . . . . . . 9 5. The IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Progressing a Document on the Standards Track . . . . . . . . 10 6.1 Processing Prior to Last Call . . . . . . . . . . . . . . 10 6.1.1 The IETF Working Group Model . . . . . . . . . . . . . 10 6.1.2 The Individual Submission Model . . . . . . . . . . . 12 6.2 Last Call Processing . . . . . . . . . . . . . . . . . . . 13 6.3 Review and Approval . . . . . . . . . . . . . . . . . . . 15 7. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Workload Risk Analysis . . . . . . . . . . . . . . . . . . . . 17 10. IASA Considerations . . . . . . . . . . . . . . . . . . . . 18 11. Internationalization Considerations . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 13. Security considerations . . . . . . . . . . . . . . . . . . 18 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 15.1 Normative References . . . . . . . . . . . . . . . . . . . 19 15.2 Informative References . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 21 Klensin Expires January 9, 2006 [Page 2] Internet-Draft IETF Standards Review July 2005 1. Introduction 1.1 Background and Overview Somewhat over a decade ago, the IETF responded to a series of perceived problems with the then-IAB by restructuring the way in which the IAB and IESG were constituted and assigning all standards- approval and closely-related processes to the IESG [RFC1310], [RFC1396]. In retrospect, that decision has had serious downsides. Both IESG members and the community have observed that the IESG has become overloaded to the point that the role requires an unreasonable level of investment, limiting the possible pool of candidates. In additional, the intertwining of managing WGs and then reviewing and approving their products has led to confusion and the risk, and sometimes the appearance, of inherent conflicts of interest and abuses. Several of these issues, and their implications, were discussed during the "Problem Statement" investigation [RFC3774] and the subsequent discussion of resolution methods [RFC3844], but no significant and effective solutions have been proposed and implemented. This document proposes to re-separate the "steering" and "WG management" functions that were orginally the IESG's responsibility from the "final review and standards approval" role that formally belonged to the IAB, assigning the latter to a new body with a new structure. It also outlines consequential changes, such as redefining and separating the roles of IETF Chair and Chair of the IESG, and specifies different flows for standards-track processing of WG-produced and individual submission documents. In addition to the IETF Chair separation, the net effect of these changes is expected to be o Freeing up the ADs for more intensive oversight of the WGs and, in particular, more active coordination of WG product, including encouraging arrangments for cross-area review while documents are still under development. o Leaving responsibility for evaluation of whether WG standards- track products (and individual standards-track submissions submitted via AD sponsorship) are ready for IETF Last Call in the hands of ADs and the IESG and providing for additional feedback from the IESG into the Last Call process. o Creating a new, alternative, mechanism for moving individual submission standards-track documents directly to IETF Last Call by demonstrating significant community support. o Putting management of IETF Last Calls for Standards Track documents and post-Last-Call evaluation, including final cross- area review, specific topic review ("security considerations", Klensin Expires January 9, 2006 [Page 3] Internet-Draft IETF Standards Review July 2005 congestion control issues, and similar statements and issues), and determination of appropriateness for standardization, into the hands of a new body that is focused exclusively on the review and approval activity and whose primary responsibilities are to the IETF as a whole, not to WGs and WG management. o Moving final approval responsibility for procedural changes to the IAB, with opportunity for formal input from the IESG as well as the broader community. Making this separation actually strengthens the role of the IESG in managing the IETF process. The potential for, and appearance of, conflicts of interest between effective management of a WG, including making technical contributions and other suggestions to it, and then being the final judge of that WG's work is eliminated, as is the appeals chain as a remedy for an IESG decision to hold a document for further work. Other provisions of this document are likely to further strengthen the steering and managing role as the new arrangements stabilize. 1.2 Terminology Document states referred to in this specification as "tracker states" or as "in the tracking system" are defined in [TrackerStates]. For the purposes of this specification, "IETF Standards Track documents" are considered to include technical specifications and applicability statements being processed at any maturity level and BCP documents that specify technical, engineering, or operational best practices. Except as modified or redefined by this specification or applicable updates, document types, status, and maturity levels are as defined in [RFC2026]. 1.3 Impact and Documents Updated In making these changes, this document significantly modifies the allocations of responsibilities in [RFC2026], the organizational description in [RFC2028], and the nomcom responsibilities in [RFC3777]. 1.4 Document Review [[ Note in Draft: This version of the document contains comments from the author about issues to be resolved or particular choices made in the associated text. Those comments are delimited by doubled left and right square brackets (such as those surrounding this text). Because of the method used to produce them, they will normally appear in the text version of the Internet-Draft with an "anchor" number and designation. ]] Klensin Expires January 9, 2006 [Page 4] Internet-Draft IETF Standards Review July 2005 [[ Note to the RFC Editor: if this I-D reaches you without this subsection and all other text delimited by [[ ... ]] having been first removed, something is seriously wrong. ]] 2. A New IETF Leadership Body: Internet Standards Review Panel This document defines a new IETF body, the Internet Standards Review Panel (ISRP), referred to for convenience as the "panel" or the "Review Panel" below. That body will be responsibility for final processing review of documents for standardization. While it may comment on its reasons for accepting or rejecting a document, it is intended to accept a specification or return it for further work. It has no role in negotiating the content of documents, nor in proposing specific alternatives except as input to the normal IETF process. [[anchor6: That is a fairly hard line and high bar. Some relaxation may be appropriate, but it might put us on a slippery slope and create a good deal of confusion about the boundary between the "review" function of this body and the "management, steering, and document clearing" roles of the IESG.]] 2.1 Responsibilities Documents are presented to this body for standards-track review and approval via one of the mechanisms described in Section 6.1. Section 6 covers steps in document processing more generally, including the Last Call and evaluation processes themselves. The panel directs that an IETF Last Call be initiated, reviews the results of the Last Call, commissions special review committees as it deems necessary for particular documents, conducts a final technical oversight review, and approves documents on the IETF Standards Track. It may reject a document for unsuitability at any stage in the process, providing an explanation and returning the document to the group or body that submitted it. Rejection is a serious measure: the panel is expected to be more flexible about clearly early-stage specifications (such as obviously pre-implementation Proposed Standards) but to set a higher bar on more mature and operational practices documents. The panel may, as an alternative to rejection, suggest qualifying text or disclaimers to be included in the document, including identification of known deficiencies in first- stage Standards Track documents, but changes of that nature must be agreed to by the submitters and reviewed via an IETF Last Call (on the changes alone, not the base specification) of not less than two weeks duration. [[anchor8: This is a somewhat tougher set of rules with regard to post-Last-Call document modification than the IESG has been operating under. They appear to be consistent with the tone of the Problem Klensin Expires January 9, 2006 [Page 5] Internet-Draft IETF Standards Review July 2005 Statement discussion and more recent comments on the IETF mailing list. Note that "changes of that nature" (which will need to be tightened up in any final version), involves changes that substantively impact the specification or its applicability. The specifications of this document do not change procedures for editorial review and corrections by the RFC Editor or the review of those changes by authors subsequent to RFC Editor processing.]] With the exception outlined immediately below, the panel will have no involvement with Experimental or Informational specifications unless they are presented as informative and coordinated parts of a package with one or more standards-track specifications, nor will it have any involvement with IETF Procedural documents (whether identified as "BCP"s or not). Responsibility for those classes of documents is identified below. As suggested elsewhere in this document, the panel is expected to commission reviews and retain oversight of them, rather than being expected to conduct all reviews itself. A clear shortage of competent and willing reviewers for a given specification should be taken as an indication that the specification is not of interest to the IETF community and hence a reason to return the specification with a recommendation that it be considered for publication as Informational (or possibly Experimental) rather than on the standards track. [[anchor9: This is another tough norm that may need to be diluted. But, as a norm, it deserves discussion and consideration.]] 2.2 Membership and Internal Leadership The panel will initially consist of ten members, with six chosen to reflect the skill set of the current IETF Areas and four chosen to reflect general, cross-area, expertise. Should the IESG increase or decrease the number of areas, the number of area-specific members of the panel will increase or decrease accordingly. [[anchor11: The membership numbers are a little arbitrary and should be discussed and tuned as needed. The "one per area" number was chosen under the reasoning that, since this group is picking up well under half of the IESG's current responsibilities, and the IESG is functioning with two people per area, one should be sufficient. Somewhat fewer people should be generalists, specifically chosen to have broad, cross-area, understanding of the Internet and the Internet protocol suite. And it seems desirable to keep this body small enough to let it work efficiently]] The panel will select one of its members to act as Chair, using a mechanism of its choosing. The position of Chair may be rotated if the panel concludes that is appropriate and efficient. The Chair is Klensin Expires January 9, 2006 [Page 6] Internet-Draft IETF Standards Review July 2005 expected to lead meetings of the panel and to provide a general coordination function with support from the IASA. [[anchor12: There are reasonable arguments for having the Chair selected as an additional panel member by the Nomcom and responsible directly to the community rather than to members of the panel. Intutitively, that seems like an opportunity for more bureaucracy with little payoff, but the community needs to discuss this one. There is also a case to be made for selecting the Chair only from the "general expertise" subset of the panel, but I would think we could let the panel sort that out.]] 2.3 Appointment Model The panel will be selected by the Nomcom, using the usual methods, and for a two-year term. Given the nature of the review process, the Nomcom should generally favor former WG Chairs and document editors and others with established reputations for a broad view of the technical issues facing the community. The terms of the area- specific members and the general expertise ones should be separately staggered, with roughly half of each group being selected each year. The rules about resignations and replacements in [RFC3777] should generally apply to the panel as well as to the IESG. [[anchor14: Ultimately, 3777 is likely to need a specific update for this, but, for now...]] Members of the Review Panel are subject to the same recall provisions as the IESG, the IAB, and the IETF Chair. 2.4 Meetings While an occasional face to face meeting might be convenient, there is no intrinsic requirement that the Review Panel "meet" other than by email and occasional teleconferences. This might create an opportunity for the Nomcom to include, in the selection of ISRP members, IETF participants who are long-term technical contributors to the community but who rarely if ever attend IETF meetings. 3. The Role of the IESG 3.1 Responsibilities With the exception of shifting the final review phase to the Review Panel, the IESG role continues as it has been. The IESG remains the manager of WGs, the overseer of IETF operations, and the manager of the standards process. The ADs are also the primary gating group for advancement of documents into Last Call and provide the management mechanism for dealing with any documents on which the Review Panel pushes back. It shares with the Review Panel the responsibility for Klensin Expires January 9, 2006 [Page 7] Internet-Draft IETF Standards Review July 2005 ensuring that cross-area review occurs within the WG process and is responsible for preventing late surprises. As described in existing specifications and current practice, the IESG retains the decision responsibility for reviewing and accepting WG charters (with the advice of the IAB), creating WGs, selecting or approving WG leadership, and for managing and terminating those WG. The various groups now responsible for new participant training, tools, and facilitation of the standards process continue to be responsible to the IESG and the IESG retains the lead responsibility for coordinating meeting scheduling and arrangements with the Secretariat and IASA, evaluating implementation reports and IPR compliance, and so on. As the managers of the IETF standards process, the IESG and the ADs who make it up also retain their roles in determining whether independent submissions to the RFC Editor constitute "end runs" of the IETF process as outlined in [RFC3932] and as the advisor to the IANA on registration matters that require IESG review and approval rather than the more formal approval from the IETF Community that goes with standards-track processing (see [RFC2434]). The IESG also retains the authority to request publication of Informational or Experimental RFCs that describe IETF products and review responsibility for IETF procedural documents (see Section 5). More details on standards processing can be found in Section 6. 3.2 Membership and Internal Leadership The IESG membership and appointment structure continues essentially unchanged. Areas are created and dissolved at IESG discretion. The only significant change is that the IESG obtains a Chair separate from the IETF Chair (see Section 4), one whose primary responsibilities are leading or coordinating IESG meetings and representing the IESG to the IASA/IAOC and other bodies. The IETF Chair becomes an ex-officio non-voting member of the IESG, on the same basis as the IAB Chair today. No other changes are made to non-AD memberships and liaisons to the IESG. 3.3 Appointment Model The IESG members, other than the IESG Chair, are selected as specified in [RFC3777]; no change is anticipated. The IESG Chair is chosen by the IESG from their own membership, using a method of their choice. At the discretion of the IESG and after consulting with and obtaining the advice of the Nomcom chair, the individual chosen as IESG Chair may be relieved of responsibility for Klensin Expires January 9, 2006 [Page 8] Internet-Draft IETF Standards Review July 2005 a technical area and the Nomcom asked to fill the vacancy thereby created. [[anchor20: Because IESG members are generally chosen on the basis of expertise in particular areas, this may turn out to be too convoluted and it may be better to have the Nomcom select the IESG Chair. On the other hand, the job of IESG Chair may not be burdensome (and it may be to the advantage of the commmunity to prevent it from becoming burdensome) and there are significant advantages to having an IESG Chair who is chosen by the IESG membership as a leader rather than having the selection made externally.]] 4. The IETF Chair Role In order to facilitate a clean appeal process, general IETF leadership, and coordination with the IASA and between the IESG and the ISRP (Review Panel), the role of IETF Chair is separated from the role of chairing the IESG and optionally leading one of its Areas. The IETF Chair continues to be chosen by the Nomcom, as in the past. The IETF Chair also continues as an ex-officio member of the IAOC. [[anchor21: Note in Draft: this section, and the IETF Chair role, is underspecified, somewhat deliberately so. It will probably need more words. One of the reasons there aren't more yet is that this document is discussing the relevant roles in the context of standards-track document processing; the IETF Chair has a number of roles (some very time-consuming) that are unrelated to either standards-track document processing or leading the IESG.]] 5. The IAB With two exceptions, the specifications of this document have no impact on the IAB. In particular, the relationships between the IAB and external bodies and between the IAB and the IETF are unchanged. The first of those exceptions involves the changes in the flow of appeals to the IAB, as discussed in Section 7 below. There are no changes in the way the IAB handles appeals that reach it. The second is that, on the same theory that it is undesirable for the IESG to have final approval responsibility for documents whose production they manage, this specification shifts final review and approval responsibility for IETF procedural documents and changes from the IESG to the IAB. Such changes must be proposed to the IESG (either directly or via a WG) as they are under existing rules. The IESG will then review the relevant documents and, having done so, forward them to the IAB. Normally, the IESG will forward the proposed document(s) with a formal opinion as to whether or not they should be adopted and the reasons for that conclusion, but the IESG may forward a document without comment. The IAB will then initiate Klensin Expires January 9, 2006 [Page 9] Internet-Draft IETF Standards Review July 2005 an IETF Last Call, normally for four weeks, on the document(s), including any IESG comments and recommendations in the Last Call statement to the community. Once the Last Call concludes, the IAB will evaluate the consensus of the community and approve or disapprove the proposal on that basis. [[anchor22: The above may be controversial, but symmetry implies that it should at least be considered. One would hope that the community, and the IAB, would pay careful attention to reasoned IESG comments on any procedural proposals, especially when those comments are based on IESG experience with IETF management. If they do not, we probably have far more serious problems than whether or not a procedural change is approved.]] Unreasonable delay on the part of the IESG in forwarding a procedural proposal to the IAB, or procedural irregularities by the IAB in processing it, may be appealed using the usual mechanisms. 6. Progressing a Document on the Standards Track Under the system documented in RFC 2026 and adapted and refined by the IESG, there are two ways to get a document processed onto the standards track. They are submission of a document to the IESG via a WG or an individual submission directly to the IESG. The former goes through the AD responsible for the working group. Those attempting the latter must find an AD who is willing to "sponsor" and then "shepherd" the document; if no AD can be found who is interested, the document essentially dies. The processing paths outlined below preserve those two models, albeit with small variations, and introduce a third one. 6.1 Processing Prior to Last Call 6.1.1 The IETF Working Group Model This is the traditional model and continues essentially unchanged up to the point of Last Call initiation. When a WG believes that it has completed work on a document, it forwards it, with a publication request, to the responsible AD after whatever level of checking and preparation of ancillary materials the WG concludes is appropriate or the AD insists upon. The AD performs a review. Based on that review, the AD may take one of the actions specified in the next three subsections: 6.1.1.1 Immediate Last Call If the AD is satisfied about both the quality of the document and the level of review it has received, he or she may forward it directly to Klensin Expires January 9, 2006 [Page 10] Internet-Draft IETF Standards Review July 2005 the Review Panel with a Last Call request. If this action is chosen, IESG review occurs in parallel with Last Call and any IESG comments become input to the Review Panel's consideration of Last Call results. 6.1.1.2 IESG Review, Then Last Call The AD may conclude that the document should be more extensively reviewed by the IESG prior to an IETF Last Call. If that action is chosen, the IESG may o conclude that a Last Call should be initiated, o specify text for the Last Call announcement that, e.g., calls the community's attention to specific issues that should be examined, o make a recommendation to the Review Panel about specific issues to be considered without specifying specific Last Call text, or o return the document to the WG, as described in the next subsection. 6.1.1.3 Return of document to WG The document may be returned to the WG for further consideration or processing. The AD or IESG is expected to supply the WG with a clear enough statement of issues with, and expectations of, the document and the review process that the WG can either make progress on a satisfactory revision to conclude that it should be abandoned. A decision by an AD or the IESG to return a document to the WG is not subject to appeal, see Section 7. 6.1.1.4 Internal IESG Processing Conventions The IESG may, from time to time, adopt whatever rules or conventions it finds appropriate to set conditions on the choices of these actions, e.g., on the circumstances under which an AD may initiate an IETF Last Call, or return a document to the WG, without prior IESG review and decisions. It may also determine the conventions by which IESG consensus to take an action is determined, including conditions under which a document may be blocked, and may create guidelines for information to be supplied when a document is returned to a WG. Such rules and conventions must be announced to the community, may, at the IESG's discretion, be Last Called (with the Last Call results evaluated by the IESG), and may be appealed. [[anchor27: Note that, for WG documents, and individual documents that are treated more or less as WG documents (see below), the IESG is permitted to establish procedures essentially identical to those that exist today, including the use of blocking "discuss" positions. Klensin Expires January 9, 2006 [Page 11] Internet-Draft IETF Standards Review July 2005 The author would encourage the IESG to adopt rules that make the first of these paths (AD to Last Call without IESG review) a rare situation at least until experience is accumulated with the new system. However, these block Last Call initiation, rather than final approval of a standard. By giving the IESG the opportunity to identify specific concerns in the Last Call announcement, the odds of the community paying attention to, and commenting on, those concerns are considerably increased. This document deliberately does not address any real or imaginary concerns about abuse of such procedures on the grounds that such concerns are better dealt with by ongoing dialogue between the community and the IESG rather than by rigid rules.]] 6.1.2 The Individual Submission Model Traditionally, non-working-group requests for approval of a standards-track document must go through the IESG and achieve support and sponsorship from at least one AD in order to progress to IETF Last Call. This document specifies a (deliberately difficult) alternative, largely to provide a better solution to the perception of IESG blocking of WG and non-WG documents than the appeal process. 6.1.2.1 Alternative 1: AD Approval This is an updated version of the traditional procedure. The submitter finds an AD who is willing to sponsor and shepherd the document through the IESG. The document is then processed exactly as if it were a WG document (see Section 6.1.1, above) except that any return of the document should be to the submitter and specific concerns about it may, at the IESG's discretion, be announced to the IETF list. 6.1.2.2 Option 2: Demonstrated Community Support A Last Call may be requested on a document without the requirement for IESG sponsorship by having its proponents demonstrate that there is significant community support for the proposal. Such a request is initiated by a petition submitted to the IETF Chair (see below) asking that the specification be processed for the IETF standards track. The petition must o be endorsed as required for a Recall petition under section 7(1) of [RFC3777] (20 signatures of people eligible for the nomcom), o contain affirmation by every signatory that they have conducted an individual technical review of the document and that they believe it is appropriate for standardization as written Klensin Expires January 9, 2006 [Page 12] Internet-Draft IETF Standards Review July 2005 o contain certifications by at least ten of the signatories that they were not involved with the development of the document, or technical contributors to it, prior to conducting their technical review, i.e., that they are independent reviewers. When the IETF Chair receives such a petition, he or she will cause a preliminary announcement to be made to the community indicating that a Last Call is being contemplated and that any procedural or work- conflict concerns should be identified to the IESG. The IESG will then be given a fixed-timeout period, not to exceed one month, to comment, to the Review Panel and the community, on possible conflicts between the proposed specification and work going on in the IETF, in a style similar to that contemplated in [RFC3932]. The IESG may raise any other concerns, including technical ones, at this point, or may defer them until the Last Call. Once that report is received, or the time allotted runs out, the IETF Chair will ask the Review Panel to initiate a Last Call as described below, including any IESG procedural, technical, or conflict comments in the Last Call announcement (or referencing those materials from it). While responsibility for managing this process through to submission to the Review Panel for Last Call rests with the IETF Chair, the actual steps, including receipt of petitions and issuing requests to the IESG and Review Panel, may be delegated to the IASA by an appropriate announcement to the community. [[anchor29: This option was included because of concerns that the stylistic tastes of individual IESG members might be blocking (in the sense of preventing any community review at all) work that had wide community support. The binding of the petition threshold to that of the recall procedure in RFC 3777 was a fairly arbitrary choice, made on the assumption that the community had already concluded that threshold was adequate to balance the need for review against the risk of denial of service attacks on the system. Better formulae are certainly possible; in particular, we should have a model by which active IETF participant-contributors who do not come to face to face meetings can endorse one of these Last Call requests. But the explicit idea here is to encourage people to send proposals through the IESG route unless that appears to be blocked for some reason. On the other hand, if it is blocked, our focus should be on engineering and standardization, not procedural quibbling.]] 6.2 Last Call Processing When a request is received by the Review Panel to initiate a Last Call, they will cause a Last Call package and announcement to be assembled and published to the IETF Announce list. That package will consist of, at least, abstracts of and references to the document or Klensin Expires January 9, 2006 [Page 13] Internet-Draft IETF Standards Review July 2005 documents, plus any concerns raised by or specific review requests from, the IESG. For "community support" individual submissions, any statements from the IESG about conflicts will also be included: the ultimate judgment as to whether conflicts should be eliminated or should lead to conflicting standards, and whether or not those standards adequately identify the tradeoff considerations, rests with the community. The Review Panel may include such other information with the Last Call announcement as it considers appropriate. Any of the administrative elements of Last Call preparation and processing may be delegated to the IASA by mutual consent. Note that, while the Review Panel may conduct a preliminary review before sending out the Last Call announcement, and add its preliminary observations, if any, to the Last Call package, all documents submitted to it will be sent out for IETF Last Call and review or other activities by the Review Panel are not permitted to significantly delay that action. [[anchor31: Explanation: this document assumes that technical or editorial iterations on a document should occur before the community's time is taken up with an IETF Last Call, presumably in a Working Group or equivalent setting. Once a document is Last Called, processing is expected to be linear, leading to either acceptance or rejection ("return"), and with minimal iteration loops. The entire Review Panel concept is intended as a final quality check and determination that all issues that should be covered have been covered in an adequate way. As suggested elsewhere, if significant problems are found during or after Last Call, it indicates a failure in the processes that prepared and checked the document and authorized and requested a Last Call on it.]] IETF Last Calls for "community support" submissions will last for four weeks unless the Review Panel concludes that a longer period is needed. Other Last Calls will be as specified in RFC 2026 (two weeks for WG-produced documents, four for others, unless the IESG determines that a longer period is desirable). If the IESG has not already conducted an in-depth review of the document, it is expected to do so during Last Call, with its comments and recommendations submitted to the Review Panel and, optionally, circulated to the community. The Review Panel may grant reasonable extensions to the Last Call period if an extension is requested and believed to be in the best interest of the community. Klensin Expires January 9, 2006 [Page 14] Internet-Draft IETF Standards Review July 2005 6.3 Review and Approval Once the Last Call is completed, the Review Panel will assess the Last Call comments. Documents should be approved for publication on the standards track if and only if the Review Panel is convinced that they are supported by community consensus, that they are technically adequate to the grade or maturity level for which they are proposed, and that they are editorially sufficient that their meaning and intent is clear, again as appropriate to grade. The Review Panel is expected to solicit or conduct additional reviews as needed to calibrate or supplement Last Call comments. When it has concluded its review, the Review Panel is expected to reach consensus, using a method of its choosing but announced to the community, on whether the document should be published on the standards track. If it concludes that it should be, it will cause Protocol Action notices to be published and the document to be forward to the RFC Editor. If it concludes that it should not, the document(s) are returned to the submitter (the IESG for WG documents or AD-sponsored individual submissions) and the authors otherwise). The returned document will be accompanied comments that describe the reasons the Review Panel was not willing to standardize the specification. Those comments will normally be published to the IETF community and may include a recommendation as to whether or not a revised version of the document should be resubmitted. For "community support" submissions that are returned, rather than standardized, the Review Panel may establish procedures that require a higher level of review and endorsement before revised forms of the documents are resubmitted for Last Call. Such procedures must be announced to the community and may be appealed. [[anchor33: Obviously, this provision is intended to provide a hook for protection against denial of service attacks and even well- intentioned repeated submissions of inappropriate documents. If it also has the effect of encouraging higher quality for first submissions lest a future submission not be considered, so much the better.]] 7. Appeals Appeals on actions of the IESG flow to the relevant ADs, then the IESG Chair, then the IETF Chair, then the IESG, and then to the IAB. Appeals on actions of the ISRP (Review Panel) flow to the ISRP Chair, then the IETF Chair, then to the IAB. Appeals to the IAB on matters of approval or rejection of documents are constrained as they are under current procedures: the IAB may instruct the ISRP to reconsider an action, but may not itself reverse an ISRP decision. Appears beyond the IAB are governed by procedures and constraints now in effect. Klensin Expires January 9, 2006 [Page 15] Internet-Draft IETF Standards Review July 2005 In this process, the IETF Chair is encouraged and expected to mediate between the complaining party and the body to whom the appeal is addressed and attempt to resolve problems without the need for full- scale appeals. Decisions by the IESG or, where appropriate, by an individual AD, to not forward a document to the ISRP for standards-track review and approval may not be appealed. The IETF Chair or, in the case of an individual AD decision, the IESG Chair, may be requested to attempt to mediate the situation but, if that fails, the only recourse available to proponents of the document is the "Community Support" option described in Section 6.1.2.2. 8. Transition [[anchor35: Obviously, this is a can of worms and the text that appears below is only one of several options. In the author's opinion, if we are going to do this, we should get on with it rather than devising some gradual transition plan, but that still leaves several options. One could, for example, imagine plans that would permit all current ADs to serve out their terms under current definitions and only when they are reappointed or replaced would their roles transition to the new model.]] If the community believes that this document addresses a sufficiently important set of problems to be worth the changes it suggests, those problems should be solved sooner rather than later. One such fast- track transition model would involve the following steps. 1. Nomcom selects initial set of members of the Review Panel, half for a full term and half for a half-term. 2. The Review Panel is seated after selection and confirmation. 3. Documents not already in the tracking system at "AD Evaluation" or some more advanced state are processed under the old rules unless the IESG, at its discretion, decides to pass formal review off to the Review Panel. Document in "Publication Requested" may be processed through the old rules by agreement between the submitter and the IESG (or, for a WG document, the relevant AD), or may be shifted to the new rules if that is preferable or agreement cannot be swiftly reached. 4. New documents (i.e., in "I-D Exists" state or earlier) as of the date the Review Panel is seated will be processed through the new system. Except for very unusual cases, this should result in a complete shift to the new system within several months of the seating of the Review Panel. For the unusual cases, and expecially for documents already in Last Call or later, the IESG can make case-by-case decisions, as Klensin Expires January 9, 2006 [Page 16] Internet-Draft IETF Standards Review July 2005 it deems appropriate, to accelerate handoff to the Review Panel. Transfer of responsibility for reviewing and approving procedural changes from the old model to the one specified in this document will occur immediately upon approval for this document for any proposals not already in IETF Last Call. 9. Workload Risk Analysis [[Note to RFC Editor: this section is to be removed before publication.]] The changes proposed here are proposed because they appear to be the Right Thing to Do in terms of getting better quality standards out of the IETF. By eliminating the final review load from the IESG's task list, it should make the IESG role less burdensome and, by permitting other IESG responsibilities to run in parallel with the conduct and evaluation of Last Calls by another body, should improve overall processing speed while delivering a equal or higher level of overall quality. It is impossible to predict how long it would take to process a standard through the "community support" path of Section 6.1.2.2 because no equivalent to that procedure has existed in the IETF, at least within the last decade or so. But, if it turns out to be too heavyweight, the community will either need to tune it or drop it: dropping it or ignoring it would leave us no worse off than with the "find a sponsoring AD or forget it" situation we are in today. However, it introduces an extra half-step into the standards process with the opportunity for IESG review prior to Last Call. I have every confidence that, if the community were to conclude that this proposal is the right way to go, the IESG will get with the spirit of the thing and progress documents quickly and efficiently, taking advantage of their newfound increased time to monitor WG work more aggressively in ways that prevent weak documents from emerging from the system at all. However, to the extent that, e.g., ADs are inappropriately sitting on WG documents rather than letting them go to Last Call today (a claim that was made during the Problem Statement process), this proposal will not help with that issue. While the procedures above intentionally do not bar it, one must assume that neither the IESG nor the broader community would be particularly sympathetic to IETF WGs using the community support option. There are almost certainly other ways by which this proposal could stretch the approval process out; some would at least result in better quality, others would not. Klensin Expires January 9, 2006 [Page 17] Internet-Draft IETF Standards Review July 2005 10. IASA Considerations While this specification will reduce IESG workload and shift some responsibilities to the Review Panel (ISRP), the mere existence of a third body that has to maintain mailing lists, talk at regular intervals, make decisions and maintain records of them, and so on will inevitably increase the overall IETF administrative workload. In addition, several sections above make provision for the IETF Chair and the Review panel to shift operational responsibility for various tasks, such a receiving and logging documents and assembling Last Call packages, to the IASA. The IAD, IAOC, and the community had best be prepared for this shift in responsibilities and the additional resources that might be required. The specification also increases the IAOC membership by one, adding the IESG Chair position to the IETF Chair one. It does not contemplate representation of the ISRP itself on the ISRP. [[anchor38: And besides, I couldn't resist writing the first "IASA Considerations" section into an I-D. I can only hope that it does not turn into a requirement .]] 11. Internationalization Considerations This document specifies IETF procedures and does not interact with internationalization. 12. IANA Considerations This document specifies internal procedures for IETF operation and hence does not involve any actions for the IANA. However, by making shifts in the review and approval procedures for standards-track documents, it inevitably makes some changes to the specific paths over which IANA receives directions. [[anchor41: If this document gets traction, a future version will need to be much more specific about the above.]] 13. Security considerations This document specifies IETF procedures. It should have no direct impact on Internet security although, if it is successful, it should improve the quality of security review and the balance between security considerations and other issues in IETF standards-track documents. Klensin Expires January 9, 2006 [Page 18] Internet-Draft IETF Standards Review July 2005 14. Acknowledgements This document is an attempt to draw a number of more or less similar ideas about again having separate standards document approval and steering and management functions for the IETF together into a proposal specific enough that a discussion, not just speculation and general nodding, can become possible. The author can remember picking up pieces of the ideas suggested here from many conversations over the last four or five years, sometimes as suggestions from others and sometimes as reactions that ended up being completely opposite to those suggestions. A list of those who contributed ideas would therefore include people who might be horrified of what their ideas have evolved into. Nonetheless, all of those ideas are gratefully acknowledged while the author must take the blame for the synthesis. 15. References 15.1 Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels'", RFC 2119, March 1997. [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004. [TrackerStates] Internet Engineering Steering Group (IESG), "Main States", https: //datatracker.ietf.org/public/states_table.cgi, July 2005. 15.2 Informative References [RFC1310] Chapin, A., "The Internet Standards Process", RFC 1310, March 1992. [RFC1396] Crocker, S., "The Process for Organization of Internet Standards Working Group (POISED)", RFC 1396, January 1993. [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Klensin Expires January 9, 2006 [Page 19] Internet-Draft IETF Standards Review July 2005 Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. [RFC3844] Davies, E. and J. Hofmann, "IETF Problem Resolution Process", RFC 3844, August 2004. [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john-ietf@jck.com Klensin Expires January 9, 2006 [Page 20] Internet-Draft IETF Standards Review July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Klensin Expires January 9, 2006 [Page 21]