[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        S. Bradner
Internet-Draft                                               Harvard U.

                                                              July 2003

        Ideas for changes to the IETF document approval process


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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

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

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

   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

      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

      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

      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

      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

      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

      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

         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

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

Bradner                                                        [Page 11]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/