Internet DRAFT - draft-klensin-stds-review-panel
draft-klensin-stds-review-panel
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 <sigh>.]]
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]
