Network Working Group S. Bradner
Internet-Draft Harvard U.
July 2003
Ideas for changes to the IETF document approval process
<draft-bradner-ietf-proc-ideas-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC 2026.
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
Abstract
The problem working group has shown that a number of IETF
participants feel that the current process by which the IETF approves
documents for publication as RFCs needs to be changed. There does
not seem to be consensus on specific reasons that change is needed
but there seems to be consensus that change is needed. This document
is designed to provide some ideas on different ways that the current
processes could be revised. My intent is to spur discussion on
possibilities, not to say (at this time) what my preference is.
Copyright (C) The Internet Society (2003)
1. Introduction
While no consensus has yet developed on the root causes of the
concerns that some people have about the current IETF processes,
there appears to be general consensus that some change is be needed.
This document provides ideas about revisions to our current processes
that I offer for consideration.
Bradner [Page 1]
Internet-Draft Process Changes June 2003
This document provides some possible ways that the IETF document
approval process might be modified to alleviate some of the problems
that were identified during the discussions in the problem working
group. With this document I'm also suggesting that others with ideas
publish their own IDs. (It's better than just posting to a mailing
list because it's easier to find in the future.)
I have attempted to make each of these possible document approval
procedures as terse as I could while still making the intent clear.
In other words, the different ideas are not intended to be fully
fleshed out. If anyone thinks any of them make any sense we can work
on filling in the details.
There is no reason for anyone to think that any of these ideas are
magic in any way. They are intended to cause discussion. I will not
say which of these, if any, I think is best. Nor is there any reason
to not mix and match among these ideas and ideas from others. But,
that said, I have tried to make each of them something I could live
with if somehow it came to pass.
The descriptions and details of these ideas have not been carefully
worked out because my main purpose in publishing this document is to
spur discussion not to push for the adoption of any particular idea.
So please discuss the ideas themselves and please do not nitpick the
details. There will be plenty of time to do that for any ideas, in
this document or in documents that others publish, that the community
thinks are worth looking at.
2. Scope of this document
This document only focuses on the process that the IETF uses to
approve documents produced by IETF working groups. It does not
attempt to address the process by which the IESG provides advice to
the RFC Editor about submissions directly to the RFC Editor, about
how working groups are created, how chairs are selected, how
consensus is determined or any of a number of other issues that were
exposed during the problem discussion.
This document also does not address independent (non-working group)
submissions for standards track. Whatever revised process, if any,
that gets adopted will have to be refined to include reviews of such
documents.
3. Assumptions
This list is limited in one way. It is my strong belief that a key
feature of the IETF is the multi-disciplinary technical review done
by the IESG. This is a feature that differentiates the IETF from
almost all other standards development organizations, I believe it is
a very important part of what has made the IETF technology as
Bradner [Page 2]
Internet-Draft Process Changes June 2003
important as it is in the world today. Thus, I did not include any
processes that did not include this review.
These ideas also assume that the approval body (IESG or IAB) does not
make changes to documents on their own. Any changes must be done
with the involvement and consent of the working group chairs and
document editors (and, if they are more than editorial, by the
working group). This includes such changes as those currently
included in the messages telling the RFC Editor that the IESG has
approved a document for publication. This is the way things
currently are supposed to work so this is not a change. The reason
to even mention this at all is to be sure that no one thinks that the
IESG or IAB should be empowered to change the text on submissions on
their own.
4. Unaddressed
Many of the issues that came up during the problem discussion relate,
in some way or another, to the approval of documents in the IETF I
have not directly addressed them in this document. A few of them are
listed here for reference.
a/ Ensuring transparency of the decision process by ensuring that all
communications between the decision makers and anyone about a
document as well as all communication between decision makers
about the document are put into the tracker, including all last
call comments. This includes ballot comments by decision makers.
b/ Offload decision makers by requiring the WG chair(s) to include a
document write-up when requesting publication of an ID as a RFC.
The AD could help create the write-up but the chair is responsible
to ensure that the write-up gets done.
c/ The legitimacy of the decision makers using non-technical issues
to reject working group documents. Examples include dislike of the
architectural approach even thought there are no known technical
issues with the proposal, a desire to have a single protocol so as
to not confuse the marketplace, and a philosophical dislike of
specific technology areas such as NATs or firewalls.
d/ Finding additional issues with a document after it has been
through the approval process more than once.
e/ Imposing requirements on a technology during the review stage that
were not part of the requirements that drove the working group
work.
5. Process ideas
Bradner [Page 3]
Internet-Draft Process Changes June 2003
Here are some ideas of changed ways to perform the approval process.
They are numbered and named only for reference, not to indicate
priority but, in general, the degree of change from the current
process is greater for the higher numbered ideas than for the lower
numbered ideas.
1/ Pre-IESG Independent Technical Review:
Summary: Add a mandatory independent technical review before the
IESG will even look at a document.
Details: This idea adds a requirement for an independent technical
assessment by one or more parties who have not been directly
involved in the working group before the IESG would consider
reviewing a document.
Comments: See draft-carpenter-solution-sirs-01.txt for one
suggestion on how to implement such reviews. One comment on
the mailing list about the general idea was that it might tend
to institutionalize the "old boys club."
Impact on IETF process documents: No changes would be required in
RFC 2026 [RFC2026] or RFC 2418 [RFC2418] to implement this
idea.
2/ Change the IESG rejection threshold
Summary: Currently a document can be returned by the IEST if a
single AD has an issue with a document. This idea raises the
bar to require that at least 3 ADs agree to return the
document.
Details: Under this idea it would require that 3 or more ADs would
have to record their support to return a document for a
particular problem before that document could be returned for
that problem. If there are not that many ADs that agree that
the particular issue is important enough to return a document
then the issue probably not all that important. The minimum of
three ADs was chosen because it would require support from ADs
from more than one area. A document that fails to meet the
requirements for the ID nits or Instructions to RFC Authors
would be returned automatically (i.e. no requirement for any
particular number of ADs since it is assumed that all ADs agree
to those requirements.)
Comments: This change might not change how many docs get returned
all that much because, in most cases, the concerns of a
particular AD make sense to enough other ADs that the threshold
Bradner [Page 4]
Internet-Draft Process Changes June 2003
would be easily reached. But there have been a number of
specific cases where this change would have kept a document
from being returned.
Note that having 3 ADs, each finding a different issue, but
none of those issues getting other ADs to agree to them would
not get returned. Since all of the AD comments would be
available through the tracker the WG/document authors could
address any concerns they agreed with even if the document is
not formally returned. If a working group agreed with some or
all of the IESG comments and wanted to revise the document they
could withdraw the request for publication and resubmit it to
the IESG after revision.
See draft-huston-ietf-pact-00.txt for a somewhat different idea
for modifying the internal IESG voting.
Impact on IETF process documents: No changes would be required in
RFC 2026 or RFC 2418 to implement this idea.
3/ IESG override of WG Consensus following WG reconsideration
Summary: Change the threshold for the IESG returning a document to
a working group in the specific case where the document has
previously been reviewed and returned to a working group by the
IESG.
Details: This idea applies to the case where a working group gets
a document returned by the IESG for a reason other than failure
to meet the ID Nits or Instructions to RFC Authors. If, after
at least 30 days of discussion, the working group consensus
disagrees with the IESG about the particular issue that caused
the IESG to return the document, the working group can submit
the document to the IESG again. In this case it would take a
2/3 majority of the IESG to again return the document to the
working group.
Comments: I think it should be quite hard for the IESG to
override a working group consensus in the case that a working
group has considered IESG comments and rejected them. While I
think it is very important that the IESG perform technical
reviews of proposals I also feel that it should be hard, but
not impossible, for the IESG to impose its view on a working
group if the working group has carefully considered the IESG
view and rejected it. There have not been many cases in my
experience where this idea would have come into play but it
might be a useful escape mechanism in some specific cases. It
also might be that there have not been such cases because the
Bradner [Page 5]
Internet-Draft Process Changes June 2003
current process does not allow any such escape mechanism.
Some people have commented to me that this idea should not be
needed because they feel that working group consensus should be
able override an IESG return in all cases. I do not personally
agree with that view.
Impact on IETF process documents: No changes would be required in
RFC 2026 or RFC 2418 to implement this idea.
4/ Designated Reviewers
Summary: Offload the IESG by having each IESG member designate a
reviewer for each IETF document that comes before the IESG and
relying on the review provided by the reviewer during IESG
discussions.
Details: When a document comes before the IESG (after the review
by AD responsible for the working group) each IESG member
designates a reviewer for the document. The IESG member could
designate themselves. The reviewer would then review the
document and submit a report. The IESG member would then be
required to use that review during the IESG discussion on the
document instead of doing a separate review. The review would
be of the general form of the reviews for an academic paper -
yes, yes if changed, or no. The designated reviewers should be
included in all discussions about a specific document.
Comments: This idea offloads the IESG members by letting them use
non- IESG reviewers and, by requiring the IESG member to rely
on the review, makes the effort the reviewer put in useful. It
also provides a mechanism to train new people for roles in the
IETF leadership. I'm not sure if the reviewer's names should
always be public (some people might be reluctant to be seen to
criticize a colleague but anonymity could produce conspiracy
theories)
Impact on IETF process documents: No changes would be required in
RFC 2026 or RFC 2418 to implement this idea.
5/ Involve the Working Group chairs and document editors in the IESG
deliberation
Summary: Make the working group chairs and the document editors a
full part of the IESG email and teleconference discussions
about a document.
Details: Make the working group chairs and the document editors a
full part of the IESG discussions about a document, maybe by
Bradner [Page 6]
Internet-Draft Process Changes June 2003
creating a temporary mailing list for each document that the
chairs, editors and IESG are subscribed to. Also include the
chairs and editors on the IESG call where the document is
discussed.
Comments: This idea adds transparency to the process and provides
for an opportunity for a high-bandwidth exchange of information
during the review process. This could significantly reduce the
back and forth communications that are often required to be
sure the chairs and editors understand the issues the IESG are
concerned with. It might be pragmatic to limit the number of
chairs and editors that attend the teleconference to one of
each even if all of the chairs and editors would be included in
the email discussion.
This would likely lengthen the teleconference discussions on
particular documents but might reduce the IESG time devoted to
a document over the long run by reducing the number of times a
document gets discussed by the IESG. It also might force a
more structured teleconference schedule because the editors and
chairs would have to know when their document was to be
discussed in order to know when they could join. This would
force a predefined agenda with specific timeslots. It also
could require separate IESG teleconferences where documents are
not discussed.
Impact on IETF process documents: No changes would be required in
RFC 2026 or RFC 2418 to implement this idea.
6/ Reestablish the IAB as the IETF document decision body
Summary: This idea reestablishes pre-Kobe structure with IAB as
the body in the IETF that performs the technical evaluation of
working group documents with one specific difference.
Details: The IESG would continue to perform the area and working
group management tasks. When a working group was ready to
publish a document they would send a notice to the IESG, as is
done now. The IESG would review the document only to determine
that the document passed the ID nits and Instructions to RFC
Authors requirements. The IESG would also verify, normally by
the assertion of the relevant area director, that the proper
consensus process had been followed in the working group. The
IESG would then forward the publication request to the IAB.
The IAB would appoint a 2 or 3 member subcommittee of IAB
members and the working group Technical Advisor (TA) to do the
technical review and report back to the IAB as a whole. The
Bradner [Page 7]
Internet-Draft Process Changes June 2003
IAB as a whole, along with the TA, makes the final decision.
The report of the subcommittee would be public. The TA would
also be present on the teleconference where the IAB discussed
the document and be a full part of the discussion.
Working groups would be formed as they currently are except
that all working groups would have technical advisors that
would be appointed by the IAB. The TA would provide periodic
public reports on the working group to the IAB.
Comments: One of the issues with the pre-Kobe IAB process was
that the IAB was not always all that well aware of what was
going on in the working groups or what particular deliberations
had taken place in a working group leading up to the consensus
on the document that they were reviewing. Having the TA
appointed by the IAB, having the TA report periodically to the
IAB and having the TA be part of the IAB review process would
hopefully ensure that the IAB would know more about what had
happened in the working group. The TA would be expected to be
operate as a second designated AD when it came to technical
questions in front of the working group but would differ to the
AD on working group process issues and determinations of the
relevance of particular topics to the working group charter.
It might take time to implement this idea because the current
IAB members were not recruited with an expectation of having to
do this much work. Thus, it might have to wait until a new
generation of IAB members were selected.
I have received some comments that this idea would not actually
solve any of the fundamental issues. I am not sure but wanted
to include this idea for completeness and because some
reviewers expressed support for the idea.
Impact on IETF process documents: Changes would be required in
RFC 2026 to implement this idea. Changes might not be required
in RFC 2418 since the role of a working group TA was not
defined in that document.
7/ Restructure IETF Areas and include IAB in decision process
Summary: Same as #6 except that a subcommittee of 4 ADs from a
restructured IESG would be responsible for a review of
engineering quality and technical reasonableness before
forwarding a recommendation to the IAB.
Details: Restructure the IETF to only have 3 areas: Operations,
Security and General. The Operations and Security Areas would
Bradner [Page 8]
Internet-Draft Process Changes June 2003
each have two ADs. The General Area would have 9 (or more) ADs
(including the IETF Chair). Working groups other than ones
very specific to Operations or Security would be managed by two
ADs assigned from the General Area. Narrowly focused
Operations- and Security-related working groups would be
managed by the Operations or Security ADs. When a working
group forwarded a request to publish a document to the IESG a
subcommittee of 4 ADs would be selected to review the document.
The subcommittee, and not the whole IESG, would evaluate the
engineering quality of the document before deciding if it was
ready to be passed on to the IAB. The IAB would, with the
working group technical advisor, make the final publication
decision as described in #6.
Comments: This idea is based partially on an idea I had a number
of years ago (which was shot down by the IESG at the time) and
partially on some suggestions (I did not use them all) that
Avri Doria made.
In practice the decision on which area particular working group
gets formed in has been somewhat arbitrary. Many working
groups could have been just as easily based in a different
area. So it might make sense to have a single area with a
bunch of ADs. Working groups would then be assigned to two ADs
based on the AD's knowledge, interests and time availability.
But security and operations are special. All IETF technology
must be secure and be able to be operated. Thus it might be
reasonable to keep a security area and a operations area to
house working groups which are purely security or operations in
nature and to house sets of security and operations advisors
(which would have some form of official status to help make the
roles more attractive). Each working group would have an
assigned security advisor and an assigned operations advisor.
The number of ADs in the general area could be increased or
decreased based on the number of active working groups.
Another possibility is to have more than one IETF chair, with
one designated the working chair, with non-congruent terms to
help manage a larger group of ADs.
When a working group forwards a request to publish a document
to the IESG a subcommittee is formed to evaluate the document.
The subcommittee would consist of the two ADs that were
assigned to the working group and two other ADs chosen based on
their knowledge, interests and time availability. (The
security and operations advisors could also be on the
subcommittee.) The subcommittee would be responsible for
evaluating the document and interacting with the working group
Bradner [Page 9]
Internet-Draft Process Changes June 2003
if they felt it was not ready for publication. when the
subcommittee feels the document is ready it forwards a
recommendation to the IAB which does the final review.
The aim here is twofold (and this maybe too messy). First, a
reorganization of the IESG to better match working groups with
ADs and, second, using a subcommittee, rather than the IESG as
a whole, to evaluate the document. Using a subcommittee should
offload the IESG because not all ADs would have to evaluate
each document. Other ADs that have comments on the document
can react to the IETF last-call or send their comments to the
IAB.
Avri also suggests that the terms of IESG members and of the
IETF Chair could be lengthened to 3 years with a limit of 2
successive terms after which there would have to be a break of
at least one year.
6. Acknowledgements
This document was reviewed by a number of people, all of whom
provided useful comments but most of whom disagreed with parts of it.
Some of the reviewers contributed their own ideas. I am not listing
the reviewers here, not because I want to hide them (they can speak
up on their own if they want to) but because I do not want to imply
that they agree with what I have written. In any case the ideas
should stand or fall on their own merit. They should not be judged
by who has submitted them or who has participated in their
development.
7. Security Considerations
This document relates to IETF process, not any particular technology,
thus it raises no particular security concerns.
8. Informative References
[RFC2026] Bradner, S. Ed., "The Internet Standards Process --
Revision 3," October 1996, RFC 2026
[RFC2418] Bradner, S. Ed., "IETF Working Group Guidelines and
Procedures," September 1998, RFC 2418
9. Authors Address
Scott Bradner
Harvard University
29 Oxford St.
Bradner [Page 10]
Internet-Draft Process Changes June 2003
Cambridge MA, 02138
sob@harvard.edu +1 617 495 3864
10. Full copyright statement:
Copyright (C) The Internet Society (2003). Except as set forth
below, authors retain all their rights.
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
rights in submissions 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 CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS (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.
Bradner [Page 11]