Network Working Group H. Alvestrand Internet-Draft Cisco Systems Expires: July 7, 2003 January 6, 2003 An IESG charter draft-iesg-procedures-00 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/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 July 7, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo describes the current operating procedures of the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). This memo is not intended to become an RFC, but provides information to the Internet community, for which the internet-drafts mechanism is a convenient distribution veichle Discussion of this memo is encouraged on the POISED mailing list Alvestrand Expires July 7, 2003 [Page 1] Internet-Draft An IESG charter January 2003 1. Introduction This document gives some details of IESG procedure. It is intended as a dynamically changeable document, and is intended to give visibility to the current process, not to serve as a template for what the process "ought" to be. 1.1 Notational conventions The term "standards-track documents" is used to cover internet-drafts that are being evaluated by the IESG for publication as Proposed Standard, Draft Standard, Standard or Best Current Practice (BCP). Not all documents evaluated for the standards track are published as such. The term "responsible AD" is used to indicate the Area Director that is in charge of shepherding a document. For working group documents, this will normally be the AD in charge of the working group; for non- WG documents, it will be the AD that is in charge of the IETF activity most closely associated with the subject matter of the document. At times, such as when the AD that would normally be selected is a document author, or is adamantly opposed to the document, another AD will take on that role. All person roles described in this document may at times be filled by persons of both sexes. The English language does not admit a short, gender-neutral pronoun describing a person whose sex is not determined by context. In the interest of political incorrectness, this document will randomly refer to people as "he" or "she", without regard to consistency or appropriateness. Alvestrand Expires July 7, 2003 [Page 2] Internet-Draft An IESG charter January 2003 2. IESG communications The IESG is in constant session through its mailing list - iesg@ietf.org. The IESG has a teleconference every second Thursday for 2 1/2 hours, which is the place where decisions get reviewed and initial IESG consensus is gauged. Alvestrand Expires July 7, 2003 [Page 3] Internet-Draft An IESG charter January 2003 3. IESG decision making The IESG attempts to make all its decisions by consensus. The normal behaviour expected of an AD is that he/she searches for consensus, raises objections if he has them, listens to the arguments for and against her objections, and makes an informed decision about whether to go along with the consensus of the group, attempt to go further in discussing the problem, or recusing himself from the action because she has insoluble problems with the issue at hand. The details of the search for consensus will differ according to the form of action to be taken; see below. Alvestrand Expires July 7, 2003 [Page 4] Internet-Draft An IESG charter January 2003 4. IESG document review procedures The IESG review procedure is defined by the IESG, within the limits given by the rules (RFC 2026), the WG procedures (RFC xxx) and the IESG Charter. The procedure consists of: o An initial review by the responsible AD, assisted by whatever reviewers the AD wants to bring to bear. This may include an IETF Last Call, and must include such a call for standards-track documents. o Once the responsible AD is satisfied that the document is worth sponsoring, a review by the entire IESG o If the IESG has questions or comments, the responsible AD takes the token to resolve these with the authors or WG responsible before taking the (possibly revised) document back to the IESG for re-review. The procedure of IESG evaluation is different for standards-track documents and non-standards-track documents. 4.1 IESG review of standards-track documents For this class of document, each AD is requested to state an opinion. The responsible AD MUST register a "yes" vote to the document in order to get it on the agenda. At least 2/3 of the ADs that are not recusing themselves must register either "Yes" or "No Objection" in order for the document to go out. If an AD has an objection to the document (called a DISCUSS opinion), this is discussed on the mailing list, and on a telechat. If the IESG comes to consensus that the objection is worth sustaining, the responsible AD is tasked with resolving the matter with the working group or author. This may involve an explanation of the group's choices, clarification of text in the document, or a reevaluation of the choices made. Normally, the AD contacts the WG chairs or document authors to discuss the issue. The IESG tries to get a "token holder" AD for the objection; the chosen holder is not necessarily the one who raised the objection, but one who the IESG trusts to detect whether the problem is solved or not. When there are multiple, significantly different objections, there are often multiple token holders. Alvestrand Expires July 7, 2003 [Page 5] Internet-Draft An IESG charter January 2003 When a document is updated, the responsible AD will notify the token holding AD, and he will review the document; it can then either be approved instantly (if the responsible AD and token-holding AD agree that there are no further problems), or it can be put on the agenda for a new telechat. The IESG tries to get all objections to a document in a single pass; however, this does not always succeed, and at times, resolving some issues can cause other problems to surface. When the working group or author takes so long to revise a document that ADs have been replaced before the document comes back for re-review, the new eyes will often see new problems with the document. 4.2 IESG review of WG non-standards-track RFCs For this class of document, there is no requirement that all ADs give an opinion on the document. The call is instead "does anyone have any objection to this going forward"; if there is none, the document is approved. An objection to a document is handled much like that for standards- track documents; the shepherding AD takes the issue to the author or WG for discussion and clarification. 4.3 IESG review of non-WG, non-standards-track documents These documents are referred to the IESG by the RFC Editor. The IESG review is supposed to uncover: o Whether the document should be reviewed by a currently active IETF working group o Whether the document is an attempt to end-run the IETF standards process o Whether the document is misrepresenting the IETF community view or otherwise is actively harmful to the IETF community As with all documents, a shepherding AD is assigned, and she is responsible for reading the document and deciding whether more review outside the IESG is required before going forward. In some cases, such as when a document describes IANA considerations that require "IETF consensus", the AD may ask for an IETF-wide Last Call on the document, in order to notify the community that the document is being processed. The basic question of whether the document is worth publishing is Alvestrand Expires July 7, 2003 [Page 6] Internet-Draft An IESG charter January 2003 left to the RFC Editor; the IESG will only recommend for or against publication. In some cases, the IESG will ask for a change in the title of a document (for instance to insert the name of the protocol's owner into the title of a document describing a proprietary protocol), or ask for an "IESG Note" clarifying some issue (often the relationship of the document to the IETF process) on the front page of the document. 4.4 IESG review considerations The level of review performed by the IESG varies according to the IESG's evaluation of the importance and quality of the document and the process that produced it. An uncontroversial or unimportant document from a well-behaved working group is likely to get a light reading once the responsible AD signs off on it; ADs are likely to assume that it is OK, and only check quickly that they don't see anything obviously broken in their particular area of expertise (such as missing security sections or other nits). Documents that are regarded as important, or have been controversial, are likely to receive more review; the IESG wishes to reassure itself that the controversial issues are indeed settled, and not just papered over; in the process, the ADs are likely to find more "trivial" problems than they would otherwise do, too. Alvestrand Expires July 7, 2003 [Page 7] Internet-Draft An IESG charter January 2003 5. IESG working group management 5.1 Working group creation A working group proposal is always worked out between a responsible AD and the working group proposers. When the responsible AD thinks that a working group charter is a good idea, she may send an informal note to the IESG and IAB mailing list to get initial feedback; this is often called the "laugh test". When the AD thinks that the working group description is ready for wider review, the AD sends it to the IESG secretary in order to place it on a telechat agenda; the IESG secretary will then send the document to the IESG and IAB mailing lists for initial review, with copy to the proposed WG chairs. If no IESG member objects to the charter, the IESG secretary then sends the proposed charter to the IETF-announce list and to the new- work list (which is a list maintained for cooperation between standards bodies). The purpose of this posting is to make sure IETF members and other SDOs are notified of the impending WG creation, and have a chance to raise objections if they want to. The charter is placed on the next telechat agenda 2 weeks later, and if no IESG member objects at that time, the charter of the new working group is approved. 5.2 Working group modification When a working group charter is changed, the procedure depends on the type of change. o Changes to milestone dates are handled by the chairs notifying the IESG secretariat (at ietf-action@ietf.org) and the AD, and the AD approving them. o Changes to milestone text are handled by the chairs and the AD working out new text, the chairs sending the updates to the IESG secretary, and the AD approving them. o Adding, removing and replacing chairs is handled by the AD, who notifies the IESG secretary, who updates the charter. o Changes to the body of a charter requires IESG approval. When updating the body of a charter, the new charter is sent to the IESG secretary, who places it on the IESG telechat agenda; if no IESG Alvestrand Expires July 7, 2003 [Page 8] Internet-Draft An IESG charter January 2003 member objects, the charter is approved. The IESG has the option of sending the revised charter to ietf-announce and new-work for public review, and will always do so if substantial new work items are added to the task list of the WG. When the changed charter is approved, the updated charter is always sent to ietf-announce. 5.3 Working group termination A working group is terminated when the responsible AD decides that the working group needs to be terminated. This may have multiple causes: o The working group is finished with its work, and its RFCs are published (success) o The AD concludes that letting the working group continue its work does not contribute to the IETF's forward progress (failure) A failed working group may be considered failed because the work is being done by other groups in the IETF, because the solutions being worked on are no longer considered relevant to the IETF, or because the group is, in the opinion of the AD, not making forward progress on achieving its goals. In both cases, the working group may have internet-drafts assigned to it that are not published as RFCs; these are then formally reclassified as individual submissions, and the next update of these documents is required to be named draft-, not draft-ietf- . The closing of a WG has no effect on the status of documents that have already been approved by the IESG for publication. Alvestrand Expires July 7, 2003 [Page 9] Internet-Draft An IESG charter January 2003 6. IESG BOF procedures Each AD decides which BOFs are appropriate in his area. It is regarded as courteous, but not required, to pass the BOF description to the IESG and IAB lists for feedback (and detection of AD-shopping or end-runs) before approving the BOF. Important things to consider when approving a BOF where the desired outcome is formation of a WG include: Whether or not there is a clearly defined problem statement Whether or not there is a likely successful outcome Whether or not there is sufficient community interest The first two points are most easily answered by having (personal) internet-drafts published before the BOF describing the work to be done, or proposed solutions to it; the last point is most easily demonstrated by having an active, open mailing list for the issue at hand. Alvestrand Expires July 7, 2003 [Page 10] Internet-Draft An IESG charter January 2003 7. IESG appeals procedure The formal appeals procedure is described in RFC 2026 section 6.5. An appeal to the IESG is initiated by email to the IETF Chair, copied to the IESG secretary. If the appeal is not clear about whether or not it is an appeal, what is being appealed, or what the proposed remedies are, there may be a dialogue between the chair and the appealing person(s) to clarify the appeal. The IESG will then ask the responsible AD to give her opinion of the matter, as evidenced by the previous required step of discussing the matter with the responsible AD. The IESG will then discuss the matter in a telechat without the IAB liaison or the IAB chair being present (in order to keep the separation from the responsible body for a possible appeal), and will usually assign to some AD (not the responsible AD) the task of writing a draft response. When the proposed response text is ready, the IESG will discuss it by email (using a special mailing list that contains only the IESG members), and in a new telechat where the IAB has been asked to leave. When the IESG agrees upon the text, it is sent to the appealant and to the ietf-announce list, as well as being archived on the IESG's public web pages. Author's Address Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 Trondheim 7043 NO EMail: harald@alvestrand.no Alvestrand Expires July 7, 2003 [Page 11] Internet-Draft An IESG charter January 2003 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Alvestrand Expires July 7, 2003 [Page 12]