| < draft-iesg-charter-02.txt | draft-iesg-charter-03.txt > | |||
|---|---|---|---|---|
| Network Working Group H. Alvestrand | Network Working Group H. Alvestrand | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Expires: October 8, 2003 April 9, 2003 | Expires: September 30, 2003 April 2003 | |||
| An IESG charter | An IESG charter | |||
| draft-iesg-charter-02 | draft-iesg-charter-03 | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
| all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that other | |||
| other groups may also distribute working documents as Internet- | groups may also distribute working documents as Internet-Drafts. | |||
| Drafts. | ||||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at http:// | The list of current Internet-Drafts can be accessed at http:// | |||
| www.ietf.org/ietf/1id-abstracts.txt. | www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on October 8, 2003. | This Internet-Draft will expire on September 30, 2003. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2003). All Rights Reserved. | Copyright (C) The Internet Society (2003). All Rights Reserved. | |||
| Abstract | Abstract | |||
| This memo gives a charter for the Internet Engineering Steering Group | This memo gives a charter for the Internet Engineering Steering Group | |||
| (IESG), a management function of the Internet Engineering Task Force | (IESG), a management function of the Internet Engineering Task Force | |||
| (IETF). | (IETF). | |||
| It is meant to document the charter of the IESG as presently | It is meant to document the charter of the IESG as presently | |||
| understood. | understood. | |||
| Discussion of this memo is encouraged on the POISED mailing list | Discussion of this memo is encouraged on the POISED mailing list | |||
| <poised@lists.tislabs.com> | <poised@lists.tislabs.com> | |||
| STATUS NOTE (to be removed from RFC): | STATUS NOTE (to be removed from RFC): | |||
| This document is intended for publication as an Informational | This document is intended for publication as an Informational | |||
| document, detailing the instructions to the IESG that the IESG thinks | document, detailing the instructions to the IESG that the IESG thinks | |||
| it has been operating under. It does not claim to represent | it has been operating under. It does not claim to represent consensus | |||
| consensus of the IETF that this is the right set of instructions to | of the IETF that this is the right set of instructions to the IESG. | |||
| the IESG. At this time (spring 2003), the structure of the IETF is | At this time (spring 2003), the structure of the IETF is undergoing | |||
| undergoing reevaluation, and the result is likely to include changes | reevaluation, and the result is likely to include changes to the | |||
| to the IESG's role; spending time to get IETF consensus that this | IESG's role; spending time to get IETF consensus that this document | |||
| document represents the IETF consensus on what the IESG should do, | represents the IETF consensus on what the IESG should do, which a BCP | |||
| which a BCP publication would indicate, seems like a less than useful | publication would indicate, seems like a less than useful exercise. | |||
| exercise. | ||||
| 1. Introduction | 1. Introduction | |||
| 1.1 The role of the IESG | 1.1 The role of the IESG | |||
| The Internet Engineering Steering Group (IESG) is the group that | The Internet Engineering Steering Group (IESG) is the group | |||
| exists to perform the overarching operational and technical | responsible for direct operation of the IETF and for ensuring the | |||
| management functions of the Internet Engineeering Task Force (IETF). | quality of work produced by the IETF. | |||
| As part of this function, the IESG is tasked with making the | The IESG charters and terminates working groups, selects their | |||
| management decisions about working groups in the IETF, and with the | chairs, monitors their progress and coordinates efforts between them. | |||
| final review and approval of documents produced by Working Groups and | The IESG performs technical review and approval of working group | |||
| documents published as IETF standards-track documents, and review of | documents and candidates for the IETF standards track, and reviews | |||
| other candidates for RFC publication. | 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 | 1.2 Historic note | |||
| The role of the IESG in the IETF management structure has been | The role of the IESG in the IETF management structure has been | |||
| largely constant since 1992, when the structure of the Internet | largely constant since 1993, after the significant changes introduced | |||
| standards process was defined by RFC 1310 (which was later updated by | by the "POISED" process, and documented in RFC 1602. (The previous | |||
| RFC 1602, RFC 1871 and RFC 2026). | 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 | Some of the functions were also defined in RFC 1603, Working Group | |||
| Guidelines, which was later updated by RFC 2418 [2]. | Guidelines, which was later obsoleted by RFC 2418 [2]. | |||
| As the community has grown, and the IESG has gathered experience, the | As the community has grown, and the IESG has gathered experience, the | |||
| ways in which the IESG has approeched its tasks have varied | ways in which the IESG has approached its tasks have varied | |||
| considerably, but the tasks have remained relatively constant. | considerably, but the tasks have remained relatively constant. | |||
| This document describes the tasks assigned to the IESG. It does not | This document describes the tasks assigned to the IESG. It does not | |||
| attempt to describe the procedures the IESG uses to accomplish these | attempt to describe in detail the procedures the IESG uses to | |||
| tasks; that is done elsewhere - consult the IESG's Web pages on the | accomplish these tasks; that is done elsewhere - consult the IESG's | |||
| IETF Website for more information. | 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. | ||||
| 2. The composition of the IESG | 2. The composition of the IESG | |||
| The IESG has the following members: | The IESG has the following members: | |||
| o The IETF Chair, who may also function as an Area Director when | o The IETF Chair, who also functions as the General Area Director | |||
| appropriate | when this area is active | |||
| o The Area Directors for the IETF Areas | o The Area Directors for the IETF Areas | |||
| o The IAB Chair and the IETF Executive Director, as ex-officio | o The IAB Chair and the IETF Executive Director, as ex-officio | |||
| members of the IESG. | members of the IESG. | |||
| o Liaisons | ||||
| The IETF Chair and the Area Directors are selected by the IETF NomCom | The IETF Chair and the Area Directors are selected by the IETF NomCom | |||
| according to the procedures of BCP 10 [3] (Nomcom procedures). | according to the procedures of BCP 10 [3] (Nomcom procedures). | |||
| The IETF Executive Director is appointed by the IETF Chair, and is | The IETF Executive Director is the person charged with running the | |||
| charged with running the IETF Secretariat; traditionally, this | IETF Secretariat. | |||
| position has been held by a person employed full-time by the | ||||
| organization performing the secretariat function. | ||||
| The Liaison positions exist to facilitate the work of the IETF by | The IESG also has liaisons, who are members of the IESG mailing list | |||
| expediting communication with other entities involved in the IETF | and may attend all IESG meetings. The Liaison positions exist to | |||
| process; which positions to have is decided by the IESG. | 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 | The liaisons are selected as appropriate by the bodies they | |||
| represent. At the time of this writing, the liaisons present | represent. At the time of this writing, the liaisons present | |||
| represent the following bodies: | represent the following bodies: | |||
| The RFC Editor | The RFC Editor | |||
| The IANA | The IANA | |||
| The IAB | The IAB | |||
| In addition, members of the IETF Secretariat are subscribed to the | In addition, members of the IETF Secretariat are subscribed to the | |||
| mailing list and present in the IESG meetings as needed in order to | mailing list and present in the IESG meetings as needed in order to | |||
| serve as a support function. | serve as a support function. | |||
| Decisions of the IESG are made by the IETF Chair and the Area | Decisions of the IESG are made by the IETF Chair and the Area | |||
| Directors. All IESG members can participate in the IESG's | Directors. All IESG members can participate in the IESG's | |||
| discussions. | discussions. | |||
| 3. Procedural issues | 3. Procedural issues | |||
| While the IESG is generally free to set its own procedures, some | While the IESG is generally free to set its own procedures, some | |||
| parts of the procedures are properly part of its charter. These are | parts of the procedures are properly part of its charter. These are | |||
| given here. | given here. | |||
| 3.1 Decision making | 3.1 Decision making | |||
| The IESG attempts to reach all decisions unanimously. If unanimity | The IESG attempts to reach all decisions unanimously. If unanimity | |||
| cannot be achieved, the chair may conduct informal polls to determine | cannot be achieved, the chair may conduct informal polls to determine | |||
| consensus. The IESG may make decisions and take action if at least | consensus. There is no general rule on how the IESG takes votes; if | |||
| two thirds of the members concur and there are no more than two | this had ever been needed, it is likely that the same rule as for the | |||
| dissents. | 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 | For the purpose of judging consensus, only the IETF Chair and the | |||
| Area Directors are counted. | Area Directors are counted. | |||
| The IESG may decide that other procedures for reaching a decision are | The IESG may decide that other procedures for reaching a decision are | |||
| apporpriate under specific conditions. Such other procedures may | appropriate under specific conditions. Such other procedures may | |||
| include: | include: | |||
| o Assertions of IETF consensus, such as when evaluating a standards | o Assertions of IETF consensus, such as when evaluating a standards | |||
| action. Here, in addition to the technical quality of the | action. Here, in addition to the technical quality of the | |||
| specification, the IESG has to evaluate the community opinion | specification, the IESG has to evaluate the community opinion | |||
| about the specification's subject matter; this has to happen with | about the specification's subject matter; this has to happen with | |||
| due notice and opportunity for community feedback. | due notice and opportunity for community feedback. | |||
| o IESG actions in areas where the IESG has the authority to take | o IESG actions in areas where the IESG has the authority to take | |||
| action. This does not need special rules. | action. This does not need special rules. | |||
| o AD actions taken with the advice and consent of the IESG; the IESG | 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 | is expected to be kept informed, and gives comment, but the | |||
| authority to act is delegated to the AD. | authority to act is delegated to the AD. | |||
| o AD action; cases where an AD can take independent action without | o AD action; cases where an AD can take independent action without | |||
| the need to consult the IESG first. | the need to consult the IESG first. | |||
| The IESG may reach decisions by face to face meeting, teleconference, | The IESG may reach decisions by face to face meeting, teleconference, | |||
| Internet communication, or any combination of the above. | Internet communication, or any combination of the above. | |||
| 3.2 Openness and confidentiality | 3.2 Openness and confidentiality | |||
| The IESG publishes the record of decisions from all its meetings on | The IESG publishes a record of decisions from its meetings on the | |||
| the Internet, and conducts an open meeting at every IETF meeting. It | Internet, and conducts an open meeting at every IETF meeting. It | |||
| publishes all its final decisions as RFCs, Internet Drafts or | publishes more detailed documentation of decisions as RFCs, Internet | |||
| messages to the IETF-announce mailing list, with copies kept on the | Drafts or messages to the IETF-announce mailing list, with copies | |||
| IETF website where appropriate. | kept on the IETF website where appropriate. | |||
| The IESG also discusses its business privately as a group, using any | The IESG also has private group discussions, using any means of its | |||
| means of its choice, including email. Records of those discussions | choice, including email. Records of those discussions are not | |||
| are not required to be made public. This is believed to be vital in | required to be made public. This is believed to be vital in | |||
| permitting a frank exchange of viewpoints and worries, allowing | permitting a frank exchange of viewpoints and worries, allowing | |||
| people to speak out freely on topics known to be controversial, and | people to speak out freely on topics known to be controversial, and | |||
| permitting people to change their minds based on presented arguments. | permitting people to change their minds based on presented arguments. | |||
| Decisions and their justification are a matter of public record. | Decisions and their justification are a matter of public record. | |||
| However, discussion of personnel matters and possibly legal and | However, discussion of personnel matters and possibly legal and | |||
| financial matters may sometimes be required to be kept confidential, | financial matters may sometimes be required to be kept confidential, | |||
| and the chair may, with the consent of the full members, exclude | and the chair may, with the consent of the full members, exclude | |||
| liaison and ex officio members whose presence is seen as | liaison and ex officio members whose presence is seen as | |||
| inappropriate for the particular discussion from such discussions. | inappropriate for the particular discussion from such discussions. | |||
| The chair may also apply exclusion to full members who have a serious | The chair may also exclude members and liaisons who have a serious | |||
| conflict of interest on an issue. Members can also choose to recuse | conflict of interest on an issue (although this has never been done | |||
| themselves from discussion of an issue, or refrain from casting a | so far). Members can also choose to recuse themselves from discussion | |||
| vote on an issue, if they feel that is appropriate. | of an issue, or refrain from casting a vote on an issue, if they feel | |||
| that is appropriate. | ||||
| 4. The IESG role in working group management | 4. The IESG role in working group management | |||
| The IESG is in charge of managing the working group process. While | The IESG is in charge of managing the working group process. While | |||
| the process of running a working group is delegated to the working | the process of managing a working group is assigned to the working | |||
| group chairs, the IESG is in charge of those processes that are | 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 | 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 | functions are delegated by the IESG to a single Area Director - the | |||
| "responsible Area Director" for the group. | "responsible Area Director" for the group. | |||
| 4.1 Working group creation | 4.1 Working group creation | |||
| The formation of working groups is described in BCP 25 [2] section | 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 | 2; this document does not repeat the text there, but gives some more | |||
| details of IESG actions. | details of IESG actions. | |||
| A WG may be requested by members of the IETF community, who addresse | 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 | 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 | for the task, or the formation can be initiated by an AD. The IESG | |||
| may assign the prospective working group to another AD if the IESG | may assign the prospective working group to another AD and/or Area if | |||
| thinks that is best. | the IESG thinks that is best. | |||
| The AD is responsible for ensuring that a working group being | The AD is responsible for ensuring that a working group being | |||
| chartered fulfils the criteria for WG formation given in BCP 25. The | chartered fulfills the criteria for WG formation given in BCP 25. The | |||
| charter is the result of a negotiation between the AD and 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 | community of interest, with review and advice by the rest of the IESG | |||
| and the IAB. | and the IAB. | |||
| The AD is also responsible for selecting chairs for the working group | The AD, with the advice of the IESG, is also responsible for | |||
| which the AD thinks will be up to the task. | 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 | All charters for proposed working groups are announced to the | |||
| community at large when the IESG thinks that the charter is ready for | 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 | review, but before the IESG makes a final decision on chartering the | |||
| WG. The final decision to charter a WG is an IESG decision. | 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 | 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 | 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 | 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 | 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 | the purpose being to create a working group. BOFs are also often | |||
| discussed with the IESG and IAB. | discussed with the IESG and IAB. | |||
| 4.2 Working group management | 4.2 Working group management | |||
| The role of the Area Director in WG management is described in BCP 25 | The role of the Area Director in WG management is described in BCP 25 | |||
| [2] section 6.7. The AD is responsible for making sure the working | [2] section 6.7. | |||
| groups stay focused on the charter tasks, make forward progress, are | ||||
| coordinated with the rest of the area, and are coordinated with the | The role of managing a WG is divided between the WG Chair(s) and the | |||
| rest of the IETF. The ADs help each other with maintaining cross- | AD. | |||
| area coordination. | ||||
| 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 | In a well functioning working group, main responsibility for these | |||
| things rests with the chairs; the AD will normally be able to | things rests with the chairs; the AD will normally be able to | |||
| concentrate on supporting the working group chairs' work. | concentrate on supporting the working group chairs' work. | |||
| When a WG finds that it is essential that work gets done which is not | 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 | 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 | required, is responsible for figuring out whether to add it to their | |||
| charter, add it to another group's charter, task someone outside the | charter, add it to another group's charter, task someone outside the | |||
| WG to work on it, or initiate creation of another WG. | WG to work on it, or initiate creation of another WG. | |||
| Substantive changes to the body of a WG's charter require the | Substantive changes to the body of a WG's charter require the same | |||
| approval of the IESG. | type of process as chartering - see BCP 25 [2] section 5. | |||
| The Area Director is also responsible for picking and, when | The Area Director is also responsible for picking and, when | |||
| necessary, replacing working group chairs. This is done in | necessary, replacing working group chairs. This is done in | |||
| consultation with the IESG, but the decision is made by the | consultation with the IESG, but the decision is made by the | |||
| responsible AD. | responsible AD. | |||
| 4.3 Working group termination | 4.3 Working group termination | |||
| Terminating a WG is a decision of the responsible AD. | Terminating a WG is a decision of the responsible AD. | |||
| A working group may be shut down when its work is completed, or when | 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 | the AD concludes that letting the working group continue its work | |||
| does not contribute to the IETF's forward progress. | does not contribute to the IETF's forward progress. | |||
| The decision to terminate a working group must be announced, and the | The decision to terminate a working group is announced, giving the | |||
| reasons should be clearly given. | reason for termination. | |||
| 5. The IESG role in document review | 5. The IESG role in document review | |||
| The IESG is expected to ensure that the documents are of a sufficient | The IESG is expected to ensure that the documents are of a sufficient | |||
| quality for release as RFCs, that they describe their subject matter | quality for release as RFCs, that they describe their subject matter | |||
| well, and that there are no outstanding engineering issues that | well, and that there are no outstanding engineering issues that | |||
| should be addressed before publication. The degree of review will | should be addressed before publication. The degree of review will | |||
| vary with the intended status and perceived importance of the | vary with the intended status and perceived importance of the | |||
| documents. | documents. | |||
| When there are problems or solutions that occur frequently, the IESG | When there are problems or solutions that occur frequently, the IESG | |||
| may publish documents describing the problems and how to avoid them, | may publish documents describing the problems and how to avoid them, | |||
| such as "IANA considerations" (BCP 26 [8]), or publish web pages with | such as "IANA considerations" (BCP 26 [8]), or publish web pages with | |||
| commonly used guidelines. | commonly used guidelines. | |||
| Rules - stuff that the community is expected to follow - are decided | Rules - stuff that the community is expected to follow - are decided | |||
| by IETF consensus processing and commonly published as BCP RFCs. | by IETF consensus processing and commonly published as BCP RFCs. | |||
| Guidance to the community that is of a more ephemeral and less | 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 | normative nature is decided by the IESG and published on the IESG's | |||
| Web pages. | Web pages. | |||
| 5.1 Working group documents | 5.1 Working group documents | |||
| This role is described in BCP 25 [2] section 7.5 and 8, and BCP 9 [1] | 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. | section 6. The IESG role is one of review and approval. | |||
| 5.2 Non-working group documents | 5.2 Non-working group documents | |||
| 5.2.1 Standards-track documents | 5.2.1 Standards-track documents | |||
| This role is described in BCP 9 [1] section 6. Such documents are | This role, which applies to Proposed, Draft, Standard and BCP | |||
| submitted to the IESG, which will assign them to a relevant AD. The | 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: | IESG is responsible for determining: | |||
| o Whether or not the specification is appropriate for standards | o Whether or not the specification is appropriate for standards | |||
| track | track | |||
| o Whether or not the specification needs review by one or more | o Whether or not the specification needs review by one or more | |||
| existing WGs | existing WGs | |||
| o Whether or not the quality of the specification is adequate | o Whether or not the quality of the specification is adequate | |||
| skipping to change at page 10, line 11 ¶ | skipping to change at page 10, line 12 ¶ | |||
| The IESG may decide that a document submitted for standards-track | The IESG may decide that a document submitted for standards-track | |||
| publication should instead be published as Experimental or | publication should instead be published as Experimental or | |||
| Informational, or that a document submitted for Proposed standard | Informational, or that a document submitted for Proposed standard | |||
| should be published as BCP, or vice versa. | should be published as BCP, or vice versa. | |||
| 5.2.2 Informational and Experimental documents | 5.2.2 Informational and Experimental documents | |||
| These documents are normally submitted to the RFC Editor in | 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 | 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 | [2] section 8. The IESG is asked to review all documents submitted in | |||
| in this fashion for conflicts with the IETF standards process or work | 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] | done in the IETF community; this is a modification of the BCP 9 [1] | |||
| procedure, and documented in BCP 25 [2] section 8. | procedure, and documented in BCP 25 [2] section 8. | |||
| The IESG may recommend that the document be published as-is, that it | 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 | be reviewed by a working group, that the document be published with | |||
| an IESG note indicating issues such as conflict with the IETF | an IESG note indicating issues such as conflict with the IETF | |||
| standards process, or may recommend that the document not be | standards process, or may recommend that the document not be | |||
| published. | published. | |||
| If the document is referred to a WG, the WG can recommend that the | 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 | 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 | 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 | not be published. The responsible AD for the WG is responsible for | |||
| getting a response from the WG in a timely manner. | getting a response from the WG in a timely manner. | |||
| NOTE IN DRAFT: The following text tries to capture the occasional | An AD, in consultation with the author, may choose to put an | |||
| practice of processing individual documents through the IESG without | individual's document directly before the IESG, without waiting for | |||
| first going through the RFC Editor. It is not clear that the | the document to be submitted through the RFC Editor. This document | |||
| description is accurate, so this may change. The IESG is discussing. | will then be processed in the same fashion as an Informational or | |||
| Experimental document from a working group. | ||||
| When an AD decides that an Informational or Experimental document is | ||||
| of particular importance to the community, the AD may also choose to | ||||
| put it directly before the IESG. 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 | 5.3 IESG review procedures | |||
| The IESG review procedure is defined by the IESG. | 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 all documents, the IESG assigns a specific AD the responsibility | |||
| for the document; that AD will normally review the document, and | for the document; that AD will normally review the document, and | |||
| possibly ask for revisions to it to address obvious problems, before | possibly ask for revisions to it to address obvious problems, before | |||
| asking the entire IESG to consider it. | asking the entire IESG to consider it. | |||
| The IESG has web pages as part of the IETF web (www.ietf.org); | 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 | current details of procedures, as well as the means of finding the | |||
| responsible AD for any document, are published there. | responsible AD for any document, are published there. | |||
| 6. The IESG role in area management | 6. The IESG role in area management | |||
| The IETF divides its work into a number of areas, each comprising | 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 | 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 | 1). The area structure is defined by the IESG, and the IESG can add | |||
| areas, redefine areas, merge areas or close down areas. | 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 | Changes to the area structure affect the IETF in many ways; decisions | |||
| to change the area structure are taken in consultation with the | to change the area structure are taken in consultation with the | |||
| community | community. | |||
| When changing the area structure, the IESG can decide which ADs are | When changing the area structure, the IESG can decide which members | |||
| responsible for new and changed areas, including making one sitting | are responsible for new and changed areas, including making one | |||
| AD responsible for multiple areas, but the IESG can only add new | sitting AD responsible for multiple areas, but the IESG can only add | |||
| members through the nomcom process. | new members through the nomcom process. | |||
| The primary task of area management is done by one or two Area | 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 | Directors per area. An AD may be advised by one or more directorates, | |||
| directorates, which are selected and chaired by the AD (BCP 25 [2] | which are created, selected, chaired and if necessary disbanded by | |||
| section 1). Directorates may be specific to an area, specific to a | the AD (BCP 25 [2] section 1). Directorates may be specific to an | |||
| technology, or chartered in some other fashion. | area, specific to a technology, or chartered in some other fashion. | |||
| The ADs for an area are jointly responsible for making sure the WGs | 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 | in the area are well coordinated, that there is coverage for the | |||
| technologies needed in the area, and that the challenges that are | technologies needed in the area, and that the challenges that are | |||
| most important to the Internet in that area are indeed being worked | most important to the Internet in that area are indeed being worked | |||
| on. | on. | |||
| The IESG decides which areas working groups belong to. | The IESG decides which areas working groups belong to. | |||
| 7. Other IESG roles | 7. Other IESG roles | |||
| 7.1 Staff supervision | 7.1 Staff supervision | |||
| The IETF Chair has primary responsibility for supervising the work of | The IETF Chair has primary responsibility for supervising the work of | |||
| the IETF Executive Director and the IETF Secretariat, with the advice | the IETF Secretariat, with the advice and consent of the IESG, the | |||
| and consent of the IESG, the IAB Chair and the ISOC president. | IAB Chair and the ISOC president. | |||
| The supervision of the IANA and RFC-Editor functions is handled by | The supervision of the IANA and RFC-Editor functions is handled by | |||
| the IAB. | the IAB. | |||
| 7.2 Process management | 7.2 Process management | |||
| The IESG is responsible for making sure the IETF process is | The IESG is responsible for making sure the IETF process is | |||
| functional in all aspects. This includes taking responsibility for | functional in all aspects. This includes taking responsibility for | |||
| initiating consideration of updates to the process when required, as | initiating consideration of updates to the process when required, as | |||
| well as addressing obvious miscarriages of process even when they do | well as addressing obvious miscarriages of process even when they do | |||
| not fall into the categories described above. | not fall into the categories described above. | |||
| 7.3 External relations | 7.3 External relations | |||
| The responsibility for handling external relations rests with the | The responsibility for handling external relations rests with the | |||
| IAB, as described in the IAB Charter (RFC 2850). However, when | IAB, as described in the IAB Charter (RFC 2850). However, when | |||
| technical cooperation is required, it is essential that the work be | technical cooperation is required, it is essential that the work be | |||
| coordinated with the relevant ADs. This often means that ADs will | coordinated with the relevant ADs. This often means that ADs will | |||
| function in a liaison role with other organizations, but the IAB may | 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 | decide that the same function may also be done by others when it | |||
| decides that this is more appropriate. | decides that this is more appropriate. | |||
| 7.4 Appeals actions | 7.4 Appeals actions | |||
| The formal appeals procedure is described in BCP 9 [1] section 6.5. | 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, | 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. | and decisions by an individual AD can be appealed to the IESG. | |||
| Decisions of the IESG can be appealed to the IAB. | 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 | 8. Security considerations | |||
| The security of the Internet depends on standards giving proper | The security of the Internet depends on standards giving proper | |||
| thought to security. Apart from that, there seem to be no | thought to security. Apart from that, there seem to be no | |||
| considerations of security relevant to this memo. | considerations of security relevant to this memo. | |||
| 9. Acknowledgements | 9. Acknowledgements | |||
| This work has been supported, aided and abetted by the whole IESG of | This work has been supported, aided and abetted by the whole IESG of | |||
| the time of writing, and has benefitted from many other comments. | the time of writing, and has benefited from many other comments. | |||
| Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret | Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret | |||
| Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen and all others | Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen, Robert Elz, | |||
| who provided comments on various versions of this document! | Keith Moore, Pete Resnick, Dave Crocker, Vint Cerf, Steve Coya and | |||
| all others who provided comments on various versions of this | ||||
| document! | ||||
| Normative references | Normative references | |||
| [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP | [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP | |||
| 9, RFC 2026, October 1996. | 9, RFC 2026, October 1996. | |||
| [2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP | [2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP | |||
| 25, RFC 2418, September 1998. | 25, RFC 2418, September 1998. | |||
| [3] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall | [3] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall | |||
| skipping to change at page 17, line 5 ¶ | skipping to change at page 17, line 5 ¶ | |||
| Author's Address | Author's Address | |||
| Harald Tveit Alvestrand | Harald Tveit Alvestrand | |||
| Cisco Systems | Cisco Systems | |||
| Weidemanns vei 27 | Weidemanns vei 27 | |||
| Trondheim 7043 | Trondheim 7043 | |||
| NO | NO | |||
| EMail: harald@alvestrand.no | EMail: harald@alvestrand.no | |||
| 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) | ||||
| 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 | Full Copyright Statement | |||
| Copyright (C) The Internet Society (2003). All Rights Reserved. | Copyright (C) The Internet Society (2003). All Rights Reserved. | |||
| This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
| others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
| or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
| and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
| kind, provided that the above copyright notice and this paragraph are | kind, provided that the above copyright notice and this paragraph are | |||
| included on all such copies and derivative works. However, this | included on all such copies and derivative works. However, this | |||
| document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||
| the copyright notice or references to the Internet Society or other | the copyright notice or references to the Internet Society or other | |||
| Internet organizations, except as needed for the purpose of | Internet organizations, except as needed for the purpose of | |||
| developing Internet standards in which case the procedures for | developing Internet standards in which case the procedures for | |||
| copyrights defined in the Internet Standards process must be | copyrights defined in the Internet Standards process must be | |||
| followed, or as required to translate it into languages other than | followed, or as required to translate it into languages other than | |||
| English. | English. | |||
| The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||
| revoked by the Internet Society or its successors or assigns. | revoked by the Internet Society or its successors or assignees. | |||
| This document and the information contained herein is provided on an | This document and the information contained herein is provided on an | |||
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |||
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |||
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |||
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| Acknowledgement | Acknowledgement | |||
| End of changes. 65 change blocks. | ||||
| 132 lines changed or deleted | 209 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||