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- 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]