One document matched: draft-carpenter-solution-sirs-00.txt
Network Working Group B. Carpenter
Internet Draft IBM
draft-carpenter-solution-sirs-00.txt D. Crocker
Expires: <11-03> Brandenburg
May 2003
Careful Additional Review of Documents (CARD)
by Senior IETF Reviewers (SIRS)
(draft-carpenter-solution-sirs-00.txt)
COPYRIGHT NOTICE
If published as an RFC this document will become
Copyright (C) The Internet Society (2003). All Rights
Reserved.
ABSTRACT
IETF specifications do not receive formal review until
they are submitted to the IESG. Hence, significant
problems with a specification often are not detected
until considerable effort has been wasted and changes
to fix the problems are difficult to add. The procedure
described in this document is intended to solve, or
palliate, a number of related problems that have been
observed in the IETF process. The basic model is to
create a team of Senior IETF Reviewers (SIRS), and have
all documents receive a certain number of reviews by
SIRs, prior to being submitted for publication. Review
at a very early stage is strongly encouraged.
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of
RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be
accessed at
http://www.ietf.org/shadow.html.
TABLE OF CONTENTS
1. Introduction
2. SIRs
2.1. The Body of Senior Internet Reviewers
2.2. Obtaining SIR Participation
3. Carding
3.1. Reviewing in Public
3.2. Form of a Review
3.3. Iterative Carding
4. Security considerations
5. Acknowledgements
6. Informative References
7. Authors' Addresses
8. Intellectual Property
9. Full Copyright Statement
Introduction
IETF specifications do not receive formal review until
they are submitted to the IESG. Hence, significant
problems with a specification often are not detected
until considerable effort has been wasted and changes
to fix the problems are difficult to add. We can
speculate that this problem explains a large part of
the long tail in the distribution of IESG document
approval times, as well as a perception that the IESG
has too much authority.
The procedure described in this document is intended to
solve, or palliate, a number of related problems that
have been observed in the IETF process [PROBLEM]:
* overload of the IESG (leading to delay)
* perception that authority and influence
in the IETF are concentrated in too few
hands
* submission of documents to the IESG that
still have significant problems (leading
to delay)
* failure to detect fundamental problems
and Internet- wide issues at an early
stage
Particularly because of the last point, it is
impossible to resolve all these problems simply by
giving additional responsibility to working groups
themselves. An additional procedure is needed.
The procedure specified here calls for a team of 'sirs'
to 'card'. The term 'card' is used for textiles and
pubs. The former usage removes detritus from textiles
and prepares it for weaving. The latter vets
participants at the door. The term also is an acronym
for 'Careful Additional Review of Documents.'
The carding procedure initially makes no change to the
formal process of IETF document development, review,
approval, and publication. It is an additional
procedure intended to tackle the problems listed above.
If successful, it can be transformed into a formal
process in due course.
The basic model is that the IETF will create a team of
Senior IETF Reviewers (SIRs, who need be neither male
nor knighted) chosen in a way designed to create trust,
and that all documents must receive a certain number of
reviews by SIRs, prior to being submitted to the IESG
or the RFC Editor for publication. Furthermore, review
at a very early stage is strongly encouraged.
The model is intended to be compatible with, and
complementary to, existing mechanisms such as the
various Directorates within the IETF and the MIB Doctor
system.
The remainder of this document described how the team
of SIRs is created and refreshed, how the review
process works, and how it is used by document authors
and working groups to achieve their objectives.
2. SIRS
2.1. The Body of Senior Internet Reviewers
2.1.1. Initial Set of SIRs
With approximately 200 RFCs published per year, and
with most of them having existed in multiple Internet
Drafts, a large team of SIRs is needed.
A target of 100 people is suggested.
The goal is to identify a team of people with adequate
experience contributing to IETF technical work, who are
likely to be trusted as a group to be both technically
expert and unbiased.
The initial team is defined by objective criteria, to
avoid any bias in their selection. It will consist of:
* all current IAB members
* all former IAB and IESG members, and former
WG Chairs, who the Secretariat can contact
and who are willing to serve
* all current MIB Doctors
* all members of existing IETF Directorates
* all authors of at least three RFCs, who the
Secretariat can contact and who are willing
to serve
* (other suggestions???)
(Current IESG Area Directors are excluded from the
pool.)
2.1.2. Addition and Removal of SIRs
The team of SIRs is augmented each year [[schedule
TBD]] by a public nomination process and a voting
procedure (TBD) among the existing SIRs.
SIRs who do not produce at least [[five ??]] reviews in
a given year will be retired from the team. In
extremis, SIR status may be removed by a simple
majority vote of the team of SIRs.
2.2. Obtaining SIR Participation
For Working Group documents, Working Groups solicit the
assistance of SIRs. That is, the general IETF
community controls who is authorized as a SIR, but WGs
control which specific SIRs provides the formal review
that is needed for a given document.
A primary goal of this proposal is to ensure that
Working Groups benefit from broad experience in the
design of Internet technology. Hence it is entirely
reasonable that some SIRs reviewing a given document
should be subject matter experts. However the full set
of input from SIRs is substantially more useful when it
includes SIRs from other areas. In particular, cross-
area review makes it more likely that architectural and
operational impacts outside of the subject matter will
be detected. It is therefore strongly recommended that
WGs seek a diverse set of SIRs to participate in
evaluations, able to cover most if not all IETF Areas
between them.
Each WG will make its own decision about how its SIRs
are selected (e.g. chosen by the WG Chairs, chosen by
the document authors concerned, etc.)
For individual submissions, the document author(s) will
solicit SIR reviews, according to the same principles
applied to Working Group documents.
There is no fixed number of SIR reviews required prior
to submission to the IESG or the RFC Editor. However,
it is likely that drafts with at least three positive
reviews from SIRs in different areas will experience
much shorter IESG review cycles than drafts with fewer
positive reviews. Other common sense rules will apply;
for example a MIB that has not been reviewed by a MIB
Doctor is unlikely to be published.
In all likelihood, Drafts without reviews will get
worse IESG response time than today, whereas Drafts
with reviews will be processed much more rapidly,
especially as the IESG's confidence in the SIR
procedure increases.
3. CARDING
3.1. Reviewing in Public
The current list of SIRs will be available on the IETF
web site. All reviews will be published on the web
site, with adequate tooling (similar to or linked to
the ID Tracker) so that every review can be readily
found. In fact, a WG or document author in need of
reviews should be able to request them through the web
site.
3.2. Form of a Review
Each review must start with a summary statement chosen
from or adapted from the following list:
* This draft is ready for publication as a
[type] RFC.
* This draft is on the right track but has
open issues, described in the review.
* This draft has serious issues, described
in the review, and needs to be rethought.
* This draft has very fundamental issues,
described in the review, and further work
is not recommended.
The length of a review will vary greatly according to
circumstances, and it is acceptable for purely
editorial comments to be sent privately. All
substantive comments must be included in the public
review.
SIRs should review for all kinds of problems, from
basic architectural or security issues, Internet-wide
impact, technical nits, problems of form and format
(such as IANA Considerations or incorrect references),
and editorial issues. As a draft progresses from its
initial, "-00" version towards one that is ready for
submission, successive SIR reviews should progress from
the general architectural level to the editorial level.
The intention is that before a draft is submitted by a
WG to the IESG, or by an individual to the RFC Editor,
it has already benefited from a level of review
equivalent to that traditionally applied by the IESG.
3.3. Iterative Carding
The carding of textiles is an iterative process, and so
is the carding of documents by SIRs. It is not required
that every version of an Internet Draft should be
submitted for SIR review. However, it is advisable to
request reviews at the very beginning (to check for
fundamental issues), as major technical issues are
resolved, and again just before the document is
submitted for IESG approval. Thus three SIR review
cycles per document may be considered the minimum.
Both Working Groups and individual submitters should
realise that carding should start early (to detect and
hopefully fix fundamental problems) and be repeated as
often as needed (to avoid submitting inadequate
documents to the IESG). By these means, it should be
possible to avoid most cases where a document spends a
long time in IESG review or, worse, is fundamentally
unacceptable to the IESG.
4. SECURITY CONSIDERATIONS
This document does not directly impact the operational
security of the Internet.
5. ACKNOWLEDGEMENTS
Your name could go here!
Valuable comments and ideas have come from many
sources, especially an earlier draft by Ted Hardie and
many members of the IETF 'problem' working group.
6. INFORMATIVE REFERENCES
[PROBLEM] IETF Problem Statement, E. Davies (ed.),
draft-ietf-problem-issue-statement-
00.txt, work in progress.
7. AUTHORS' ADDRESSES
Brian E. Carpenter
IBM Zurich Research Laboratory
Saeumerstrasse 4
8803 Rueschlikon
Switzerland
Email: brian@hursley.ibm.com
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
Tel: +1.408.246.8253
dcrocker@brandenburg.com
8. INTELLECTUAL PROPERTY
PLACEHOLDER for full IETF IPR Statement if needed.
9. FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2003). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment
on or otherwise explain it or assist in its
implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and
derivative works. However, this document itself may
not be modified in any way, such as by removing the
copyright notice or references to the Internet Society
or other Internet organizations, except as needed for
the purpose of developing Internet standards in which
case the procedures for copyrights defined in the
Internet Standards process must be followed, or as
required to translate it into languages other than
English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
| PAFTECH AB 2003-2026 | 2026-04-24 06:46:57 |