An IESG charter
draft-iesg-charter-03
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3710.
|
|
---|---|---|---|
Author | Harald T. Alvestrand | ||
Last updated | 2013-03-02 (Latest revision 2003-06-04) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Informational | ||
Formats | |||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 3710 (Informational) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Steven M. Bellovin | ||
Send notices to | <fred@cisco.com> |
draft-iesg-charter-03
Network Working Group H. Alvestrand Internet-Draft Cisco Systems Expires: September 30, 2003 April 2003 An IESG charter draft-iesg-charter-03 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 September 30, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo gives a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as presently understood. Discussion of this memo is encouraged on the POISED mailing list <poised@lists.tislabs.com> STATUS NOTE (to be removed from RFC): This document is intended for publication as an Informational document, detailing the instructions to the IESG that the IESG thinks it has been operating under. It does not claim to represent consensus Alvestrand Expires September 30, 2003 [Page 1] Internet-Draft An IESG charter April 2003 of the IETF that this is the right set of instructions to the IESG. At this time (spring 2003), the structure of the IETF is undergoing reevaluation, and the result is likely to include changes to the IESG's role; spending time to get IETF consensus that this document represents the IETF consensus on what the IESG should do, which a BCP publication would indicate, seems like a less than useful exercise. Alvestrand Expires September 30, 2003 [Page 2] Internet-Draft An IESG charter April 2003 1. Introduction 1.1 The role of the IESG The Internet Engineering Steering Group (IESG) is the group responsible for direct operation of the IETF and for ensuring the quality of work produced by the IETF. The IESG charters and terminates working groups, selects their chairs, monitors their progress and coordinates efforts between them. The IESG performs technical review and approval of working group documents and candidates for the IETF standards track, and reviews other candidates for publication in the RFC series. It also administers IETF logistics, including operation of the Internet-Draft document series and the IETF meeting event. 1.2 Historic note The role of the IESG in the IETF management structure has been largely constant since 1993, after the significant changes introduced by the "POISED" process, and documented in RFC 1602. (The previous process was documented in RFC 1310; RFC 1602 has later been updated by RFC 1871 and obsoleted by RFC 2026). Some of the functions were also defined in RFC 1603, Working Group Guidelines, which was later obsoleted by RFC 2418 [2]. As the community has grown, and the IESG has gathered experience, the ways in which the IESG has approached its tasks have varied considerably, but the tasks have remained relatively constant. This document describes the tasks assigned to the IESG. It does not attempt to describe in detail the procedures the IESG uses to accomplish these tasks; that is done elsewhere - consult the IESG's Web pages on the IETF Website for more information. At this time (spring 2003), the structure of the IETF is undergoing reevaluation, and the result is likely to include changes to the IESG's role. Therefore, this document was written as a "documentation of existing practice" rather than as the IETF consensus on what the IESG should do. It is published as an Informational document, detailing the instructions to the IESG that the IESG thinks it has been operating under. It does not claim to represent consensus of the IETF that this is the right set of instructions to the IESG. Alvestrand Expires September 30, 2003 [Page 3] Internet-Draft An IESG charter April 2003 2. The composition of the IESG The IESG has the following members: o The IETF Chair, who also functions as the General Area Director when this area is active o The Area Directors for the IETF Areas o The IAB Chair and the IETF Executive Director, as ex-officio members of the IESG. The IETF Chair and the Area Directors are selected by the IETF NomCom according to the procedures of BCP 10 [3] (Nomcom procedures). The IETF Executive Director is the person charged with running the IETF Secretariat. The IESG also has liaisons, who are members of the IESG mailing list and may attend all IESG meetings. The Liaison positions exist to facilitate the work of the IETF by expediting communication with other entities involved in the IETF process; which positions to have is decided by the IESG. The liaisons are selected as appropriate by the bodies they represent. At the time of this writing, the liaisons present represent the following bodies: The RFC Editor The IANA The IAB In addition, members of the IETF Secretariat are subscribed to the mailing list and present in the IESG meetings as needed in order to serve as a support function. Decisions of the IESG are made by the IETF Chair and the Area Directors. All IESG members can participate in the IESG's discussions. Alvestrand Expires September 30, 2003 [Page 4] Internet-Draft An IESG charter April 2003 3. Procedural issues While the IESG is generally free to set its own procedures, some parts of the procedures are properly part of its charter. These are given here. 3.1 Decision making The IESG attempts to reach all decisions unanimously. If unanimity cannot be achieved, the chair may conduct informal polls to determine consensus. There is no general rule on how the IESG takes votes; if this had ever been needed, it is likely that the same rule as for the IAB would be used (decisions may be taken if at least two thirds of the members concur and there are no more than two dissents). For the purpose of judging consensus, only the IETF Chair and the Area Directors are counted. The IESG may decide that other procedures for reaching a decision are appropriate under specific conditions. Such other procedures may include: o Assertions of IETF consensus, such as when evaluating a standards action. Here, in addition to the technical quality of the specification, the IESG has to evaluate the community opinion about the specification's subject matter; this has to happen with due notice and opportunity for community feedback. o IESG actions in areas where the IESG has the authority to take action. This does not need special rules. o AD actions taken with the advice and consent of the IESG; the IESG is expected to be kept informed, and gives comment, but the authority to act is delegated to the AD. o AD action; cases where an AD can take independent action without the need to consult the IESG first. The IESG may reach decisions by face to face meeting, teleconference, Internet communication, or any combination of the above. 3.2 Openness and confidentiality The IESG publishes a record of decisions from its meetings on the Internet, and conducts an open meeting at every IETF meeting. It publishes more detailed documentation of decisions as RFCs, Internet Drafts or messages to the IETF-announce mailing list, with copies kept on the IETF website where appropriate. Alvestrand Expires September 30, 2003 [Page 5] Internet-Draft An IESG charter April 2003 The IESG also has private group discussions, using any means of its choice, including email. Records of those discussions are not required to be made public. This is believed to be vital in permitting a frank exchange of viewpoints and worries, allowing people to speak out freely on topics known to be controversial, and permitting people to change their minds based on presented arguments. Decisions and their justification are a matter of public record. However, discussion of personnel matters and possibly legal and financial matters may sometimes be required to be kept confidential, and the chair may, with the consent of the full members, exclude liaison and ex officio members whose presence is seen as inappropriate for the particular discussion from such discussions. The chair may also exclude members and liaisons who have a serious conflict of interest on an issue (although this has never been done so far). Members can also choose to recuse themselves from discussion of an issue, or refrain from casting a vote on an issue, if they feel that is appropriate. Alvestrand Expires September 30, 2003 [Page 6] Internet-Draft An IESG charter April 2003 4. The IESG role in working group management The IESG is in charge of managing the working group process. While the process of managing a working group is assigned to the working group chairs, the IESG is in charge of those processes that are beyond the scope of the working group chair's role. Most of these functions are delegated by the IESG to a single Area Director - the "responsible Area Director" for the group. 4.1 Working group creation The formation of working groups is described in BCP 25 [2] section 2; this document does not repeat the text there, but gives some more details of IESG actions. A WG may be requested by members of the IETF community, who address the request to an AD that the requesters feel is the appropriate AD for the task, or the formation can be initiated by an AD. The IESG may assign the prospective working group to another AD and/or Area if the IESG thinks that is best. The AD is responsible for ensuring that a working group being chartered fulfills the criteria for WG formation given in BCP 25. The charter is the result of a negotiation between the AD and the community of interest, with review and advice by the rest of the IESG and the IAB. The AD, with the advice of the IESG, is also responsible for selecting chairs for the working group which the AD thinks will be up to the task. All charters for proposed working groups are announced to the community at large when the IESG thinks that the charter is ready for review, but before the IESG makes a final decision on chartering the WG. The final decision to charter a WG is an IESG decision. The BOF procedure described in BCP 25 [2] section 2.4 also requires approval from the relevant AD (the one who got the request or the AD that the IESG thinks is the right AD to manage the task). A BOF is not required to start a working group, and a BOF may be held without the purpose being to create a working group. BOFs are also often discussed with the IESG and IAB. 4.2 Working group management The role of the Area Director in WG management is described in BCP 25 [2] section 6.7. Alvestrand Expires September 30, 2003 [Page 7] Internet-Draft An IESG charter April 2003 The role of managing a WG is divided between the WG Chair(s) and the AD. A WG chair has to manage the working group "from the inside", dealing with individuals, drafts, proposals, meetings and email lists, and has full power and responsibility to do that. An AD manages a WG "from the outside", dealing with charters, chairs, cross-WG and cross-area relationships and so on. The AD is responsible for making sure the working groups stay focused on the charter tasks, make forward progress, are coordinated with the rest of the area, and are coordinated with the rest of the IETF. The ADs help each other with maintaining cross-area coordination. In a well functioning working group, main responsibility for these things rests with the chairs; the AD will normally be able to concentrate on supporting the working group chairs' work. When a WG finds that it is essential that work gets done which is not on its charter, the AD, consulting with the rest of the IESG as required, is responsible for figuring out whether to add it to their charter, add it to another group's charter, task someone outside the WG to work on it, or initiate creation of another WG. Substantive changes to the body of a WG's charter require the same type of process as chartering - see BCP 25 [2] section 5. The Area Director is also responsible for picking and, when necessary, replacing working group chairs. This is done in consultation with the IESG, but the decision is made by the responsible AD. 4.3 Working group termination Terminating a WG is a decision of the responsible AD. A working group may be shut down when its work is completed, or when the AD concludes that letting the working group continue its work does not contribute to the IETF's forward progress. The decision to terminate a working group is announced, giving the reason for termination. Alvestrand Expires September 30, 2003 [Page 8] Internet-Draft An IESG charter April 2003 5. The IESG role in document review The IESG is expected to ensure that the documents are of a sufficient quality for release as RFCs, that they describe their subject matter well, and that there are no outstanding engineering issues that should be addressed before publication. The degree of review will vary with the intended status and perceived importance of the documents. When there are problems or solutions that occur frequently, the IESG may publish documents describing the problems and how to avoid them, such as "IANA considerations" (BCP 26 [8]), or publish web pages with commonly used guidelines. Rules - stuff that the community is expected to follow - are decided by IETF consensus processing and commonly published as BCP RFCs. Guidance to the community that is of a more ephemeral and less normative nature is decided by the IESG and published on the IESG's Web pages. 5.1 Working group documents This role is described in BCP 25 [2] section 7.5 and 8, and BCP 9 [1] section 6. The IESG role is one of review and approval. 5.2 Non-working group documents 5.2.1 Standards-track documents This role, which applies to Proposed, Draft, Standard and BCP processing, is described in BCP 9 [1] section 6. Such documents are submitted to the IESG, which will assign them to a relevant AD. The IESG is responsible for determining: o Whether or not the specification is appropriate for standards track o Whether or not the specification needs review by one or more existing WGs o Whether or not the quality of the specification is adequate The IESG will either approve or disapprove of the publication of the document on the standards track; no document can be published on the standards track without IESG approval. The IESG may decide that a document submitted for standards-track Alvestrand Expires September 30, 2003 [Page 9] Internet-Draft An IESG charter April 2003 publication should instead be published as Experimental or Informational, or that a document submitted for Proposed standard should be published as BCP, or vice versa. 5.2.2 Informational and Experimental documents These documents are normally submitted to the RFC Editor in accordance with the procedures of BCP 9 [1] section 4.2.3 and BCP 25 [2] section 8. The IESG is asked to review all documents submitted in this fashion for conflicts with the IETF standards process or work done in the IETF community; this is a modification of the BCP 9 [1] procedure, and documented in BCP 25 [2] section 8. The IESG may recommend that the document be published as-is, that it be reviewed by a working group, that the document be published with an IESG note indicating issues such as conflict with the IETF standards process, or may recommend that the document not be published. If the document is referred to a WG, the WG can recommend that the document be adopted as a WG document, that it be published (possibly with comments), or that the IESG recommend to the RFC Editor that it not be published. The responsible AD for the WG is responsible for getting a response from the WG in a timely manner. An AD, in consultation with the author, may choose to put an individual's document directly before the IESG, without waiting for the document to be submitted through the RFC Editor. This document will then be processed in the same fashion as an Informational or Experimental document from a working group. 5.3 IESG review procedures The IESG review procedure is defined by the IESG. The IESG is responsible for conducting the process in a timely manner with appropriate communication. For all documents, the IESG assigns a specific AD the responsibility for the document; that AD will normally review the document, and possibly ask for revisions to it to address obvious problems, before asking the entire IESG to consider it. The IESG has web pages as part of the IETF web (www.ietf.org); current details of procedures, as well as the means of finding the responsible AD for any document, are published there. Alvestrand Expires September 30, 2003 [Page 10] Internet-Draft An IESG charter April 2003 6. The IESG role in area management The IETF divides its work into a number of areas, each comprising working groups that relate to that area's focus. (BCP 25 [2] section 1). The area structure is defined by the IESG, and the IESG can add areas, redefine areas, merge areas, change the number of ADs assigned to an area, or close down areas. Changes to the area structure affect the IETF in many ways; decisions to change the area structure are taken in consultation with the community. When changing the area structure, the IESG can decide which members are responsible for new and changed areas, including making one sitting AD responsible for multiple areas, but the IESG can only add new members through the nomcom process. The primary task of area management is done by one or two Area Directors per area. An AD may be advised by one or more directorates, which are created, selected, chaired and if necessary disbanded by the AD (BCP 25 [2] section 1). Directorates may be specific to an area, specific to a technology, or chartered in some other fashion. The ADs for an area are jointly responsible for making sure the WGs in the area are well coordinated, that there is coverage for the technologies needed in the area, and that the challenges that are most important to the Internet in that area are indeed being worked on. The IESG decides which areas working groups belong to. Alvestrand Expires September 30, 2003 [Page 11] Internet-Draft An IESG charter April 2003 7. Other IESG roles 7.1 Staff supervision The IETF Chair has primary responsibility for supervising the work of the IETF Secretariat, with the advice and consent of the IESG, the IAB Chair and the ISOC president. The supervision of the IANA and RFC-Editor functions is handled by the IAB. 7.2 Process management The IESG is responsible for making sure the IETF process is functional in all aspects. This includes taking responsibility for initiating consideration of updates to the process when required, as well as addressing obvious miscarriages of process even when they do not fall into the categories described above. 7.3 External relations The responsibility for handling external relations rests with the IAB, as described in the IAB Charter (RFC 2850). However, when technical cooperation is required, it is essential that the work be coordinated with the relevant ADs. This often means that ADs will function in a liaison role with other organizations, but the IAB may decide that the same function may also be done by others when it decides that this is more appropriate. 7.4 Appeals actions The formal appeals procedure is described in BCP 9 [1] section 6.5. Most decisions by a working group chair can be appealed to the AD, and decisions by an individual AD can be appealed to the IESG. Decisions of the IESG can be appealed to the IAB; for this reason, the IAB chair and the liaison from the IAB recuse themselves from discussion of appeals to the IESG. Alvestrand Expires September 30, 2003 [Page 12] Internet-Draft An IESG charter April 2003 8. Security considerations The security of the Internet depends on standards giving proper thought to security. Apart from that, there seem to be no considerations of security relevant to this memo. Alvestrand Expires September 30, 2003 [Page 13] Internet-Draft An IESG charter April 2003 9. Acknowledgements This work has been supported, aided and abetted by the whole IESG of the time of writing, and has benefited from many other comments. Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen, Robert Elz, Keith Moore, Pete Resnick, Dave Crocker, Vint Cerf, Steve Coya and all others who provided comments on various versions of this document! Alvestrand Expires September 30, 2003 [Page 14] Internet-Draft An IESG charter April 2003 Normative references [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [3] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 2282, February 1998. Alvestrand Expires September 30, 2003 [Page 15] Internet-Draft An IESG charter April 2003 Informative references [4] Chapin, A., "The Internet Standards Process", RFC 1310, March 1992. [5] Huitema, C. and P. Gross, "The Internet Standards Process -- Revision 2", RFC 1602, March 1994. [6] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and Procedures", RFC 1603, March 1994. [7] Postel, J., "Addendum to RFC 1602 -- Variance Procedure", BCP 2, RFC 1871, November 1995. [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Author's Address Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 Trondheim 7043 NO EMail: harald@alvestrand.no Alvestrand Expires September 30, 2003 [Page 16] Internet-Draft An IESG charter April 2003 Appendix A. Change log This section should be deleted when publishing as an RFC Changes from -02 to -03 (apart from minor wording changes): o Added discussion of Informational status to history note (1.2) o Changed history to mention the Kobe/POISED change in procedure (1.2) o Changed the composition of the IESG to mention members separately from liaisons (2) o Removed most of the description of the ExecDirector(2, 7.1) o Changed ballot procedure to be a parenthetical remark, to make clear it's not running code (3.1) o Clarified exclusion paragraph (3.2) o Clarified split of responsibilities between AD and WG chair (4.2) o Clarified (or made clearer that it doesn't have very rigid rules) AD-shepherded info/experimental individual documents (5.2.2) o Added responsibility for timeliness to IESG review (with no promise that it is DONE in a timely fashion.....) (5.3) Alvestrand Expires September 30, 2003 [Page 17] Internet-Draft An IESG charter April 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 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 assignees. 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 Alvestrand Expires September 30, 2003 [Page 18] Internet-Draft An IESG charter April 2003 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 September 30, 2003 [Page 19]