From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3710.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc3710.txt (limited to 'doc/rfc/rfc3710.txt') diff --git a/doc/rfc/rfc3710.txt b/doc/rfc/rfc3710.txt new file mode 100644 index 0000000..a0c0453 --- /dev/null +++ b/doc/rfc/rfc3710.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group H. Alvestrand +Request for Comments: 3710 Cisco Systems +Category: Informational February 2004 + + + An IESG charter + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This memo provides 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 it + is presently understood. + +1. Introduction + +1.1. The Role of the IESG + + The Internet Engineering Steering Group (IESG) is the group + responsible for the 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. + + + + + + + + + + + + +Alvestrand Informational [Page 1] + +RFC 3710 An IESG Charter February 2004 + + +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 [5]. (The + previous process was documented in RFC 1310 [4]; RFC 1602 has later + been updated by RFC 1871 [7] and obsoleted by RFC 2026 [1].) + + Some of the functions were also defined in RFC 1603 [6], 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 [9]. + + 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 IETF consensus on + what the IESG should do. + + This document is published as an Informational RFC, detailing the + current operations of the IESG. It does not claim to represent + consensus of the IETF that this is the right set of instructions to + the IESG. + +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 (ADs) for the IETF Areas + + o The Internet Architecture Board (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. + + + +Alvestrand Informational [Page 2] + +RFC 3710 An IESG Charter February 2004 + + + 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 + are 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. + + IESG decisions are made by the IETF Chair and the Area Directors. + All IESG members can participate in the IESG's discussions. + +3. Procedural Issues + + While the IESG is generally free to set its own procedures, some + parts of its 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 + + + +Alvestrand Informational [Page 3] + +RFC 3710 An IESG Charter February 2004 + + + 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 + needing to consult the IESG first. + + The IESG may reach decisions by face to face meeting, + teleconferencing, 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 when appropriate. + + 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. + + The chair may also exclude members and liaisons who have a serious + conflict of interest on an issue (although this has never been + enacted). Members can also choose to recuse themselves from + discussion of an issue, or refrain from participating in a particular + ballot, if they feel it is appropriate. + + + + + + + +Alvestrand Informational [Page 4] + +RFC 3710 An IESG Charter February 2004 + + +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 additional + details of IESG actions. + + A Working Group (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 from 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 the charter is ready for + review, but prior to the IESGs final decision on chartering the WG. + The final decision to charter a WG is an IESG decision. + + The Birds of a Feather (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 of creating a working + group. BOFs are also often discussed with the IESG and IAB. + + + + + + + + + +Alvestrand Informational [Page 5] + +RFC 3710 An IESG Charter February 2004 + + +4.2. Working Group Management + + The role of the Area Director in WG management is described in BCP 25 + [2], section 6.7. + + 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 complete, or when + the AD concludes that letting the working group continue its work no + longer contributes to the IETF's progress. + + The decision to terminate a working group is announced, giving the + reason for termination. + + + +Alvestrand Informational [Page 6] + +RFC 3710 An IESG Charter February 2004 + + +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, and are then assigned to a relevant AD. The + IESG is responsible for determining: + + o Whether or not the specification is appropriate for the 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. + + + + + +Alvestrand Informational [Page 7] + +RFC 3710 An IESG Charter February 2004 + + + The IESG may decide that a document submitted for standards-track + publication should instead be published as Experimental or + Informational, or that a document submitted for Proposed standard + should be published as a 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 procedures are 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 + of shepherding 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 for + publication. + + 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 Informational [Page 8] + +RFC 3710 An IESG Charter February 2004 + + +6. The IESG Role in Area Management + + The IETF divides its work into a number of areas, each comprised of + 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 handled 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 most + important to the Internet in that area are indeed being worked on. + + The IESG decides which areas working groups belong to. + +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 Internet Assigned Numbers Authority (IANA) and + RFC-Editor functions is handled by the IAB. + + + + + + + + + + +Alvestrand Informational [Page 9] + +RFC 3710 An IESG Charter February 2004 + + +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 [10]). 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. + +8. Security Considerations + + The security of the Internet depends on standards giving proper + thought to security. Apart from that, there seems to be no + considerations of security relevant to this memo. + +9. Acknowledgements + + This work has been supported, aided and abetted by the whole IESG at + the time of this 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 Informational [Page 10] + +RFC 3710 An IESG Charter February 2004 + + +10. References + +10.1. 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 2727, February 2000. + +10.2. Informative References + + [4] Chapin, L., "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. + + [9] http://www.ietf.org + + [10] Carpenter, B., Ed., "Charter of the Internet Architecture Board + (IAB)", BCP 39, RFC 2850, May 2000. + +11. Author's Address + + Harald Tveit Alvestrand + Cisco Systems + 5245 Arboretum Dr + Los Altos, CA + USA + + EMail: harald@alvestrand.no + + + + + + +Alvestrand Informational [Page 11] + +RFC 3710 An IESG Charter February 2004 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Alvestrand Informational [Page 12] + -- cgit v1.2.3