idnits 2.17.00 (12 Aug 2021) /tmp/idnits9840/draft-iesg-charter-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 6, 2003) is 7074 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 303, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 306, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 309, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 312, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 315, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 318, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 321, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1310 (ref. '1') (Obsoleted by RFC 1602) ** Obsolete normative reference: RFC 1602 (ref. '2') (Obsoleted by RFC 2026) ** Obsolete normative reference: RFC 1603 (ref. '3') (Obsoleted by RFC 2418) ** Obsolete normative reference: RFC 1871 (ref. '4') (Obsoleted by RFC 2026) ** Obsolete normative reference: RFC 2282 (ref. '7') (Obsoleted by RFC 2727) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft Cisco Systems 4 Expires: July 7, 2003 January 6, 2003 6 An IESG charter 7 draft-iesg-charter-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on July 7, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This memo gives a charter for the Internet Engineering Steering Group 39 (IESG), a management function of the Internet Engineering Task Force 40 (IETF). 42 It is meant to document the charter of the IESG as presently 43 understood (Jan 2003). 45 Discussion of this memo is encouraged on the POISED mailing list 46 48 1. Introduction 50 1.1 The role of the IESG 52 The Internet Engineering Steering Group (IESG) is the operational and 53 technical management function of the Internet Engineeering Task Force 54 (IETF). 56 It is tasked with making the management decisions about working 57 groups in the IETF, and with the final review and approval of 58 documents published as IETF standards-track documents. 60 1.2 Historic note 62 The role of the IESG in the IETF management structure has been 63 largely constant since 1992, when the structure of the Internet 64 standards process was defined by RFC 1310 (which was later updated by 65 RFC 1602, RFC 1871 and RFC 2026). 67 Some of the functions were also defined in RFC 1603 (which was later 68 updated by RFC 2418). 70 As the community has grown, and the IESG has gathered experience, the 71 way in which the IESG approaches its tasks has varied considerably, 72 but the tasks have remained relatively constant. 74 This document describes the tasks assigned to the IESG. It does not 75 attempt to describe the procedures the IESG uses to accomplish these 76 tasks; that is done in other memos. 78 2. The composition of the IESG 80 The IESG has the following members: 82 o The IETF Chair, who is also the General AD 84 o The Area Directors for the IETF Areas 86 o The IAB Chair and the IETF Executive Director, as ex-officio 87 members of the IESG. 89 o Liaisons 91 The Chair and the Area Directors are selected by the IETF NomCom 92 according to the procedures of RFC 2282 (Nomcom procedures). 94 The RFC Editor 96 The IANA 98 The IAB 100 In addition, members of the IETF Secretariat are subscribed to the 101 mailing list and present in the IESG meetings as needed in order to 102 serve as a support function. 104 Decisions of the IESG are made by the IETF Chair and the Area 105 Directors. 107 3. The IESG role in working group management 109 3.1 Working group creation 111 The formation of working groups is described in RFC 2418 section 2. 113 The normal case is that a working group is requested by members of 114 the IETF community. 116 Each area director is responsible for ensuring that a working group 117 being chartered is relevant, has achievable goals and constitutes an 118 acceptable risk, has sufficient interest and so on. The charter is 119 the result of a negotiation between the AD and the prospective 120 chairs, with review by the IAB and approval by the IESG. Normally, 121 there will be communication with the community of interest for the 122 working group too. 124 The AD is also responsible for selecting chairs for the working group 125 that he thinks will be up to the task. 127 All charters for proposed working groups are announced to the 128 community at large before the IESG makes a decision. 130 The BOF procedure described in RFC 2418 section 2.4 also requires 131 approval from the relevant AD. A BOF is not required to start a 132 working group, and a BOF may be held without the purpose being to 133 create a working group. BOFs are also often discussed with the IESG 134 and IAB. 136 If an AD determines that it is needed, the AD can initiate the 137 formation of a working group. 139 3.2 Working group management 141 The role of the Area Director in WG management is described in RFC 142 2418 section 6.7. The AD is responsible for making sure the working 143 groups stay focused on the charter tasks, make forward progress, are 144 coordinated with the rest of the area, and (with the IESG) 145 coordinated with the rest of the IETF. 147 In a well functioning working group, main responsibility for these 148 things rests with the chairs; the AD will normally be able to 149 concentrate on supporting the working group chairs' work. 151 When a WG finds that it is essential that work gets done which is not 152 on its charter, the AD, consulting with the rest of the IESG as 153 required, is responsible for figuring out whether to add it to their 154 charter, add it to another group's charter, task someone outside the 155 WG to work on it, or initiate creation of another WG. 157 The Area Director is also responsible for picking and, when 158 necessary, replacing working group chairs. This is usually done in 159 consultation with the IESG. 161 4. The IESG role in document review 163 4.1 Working group documents 165 This role is described in RFC 2418 section 7.5, and RFC 2026 section 166 6. The IESG role is one of review and approval. 168 4.2 Non-working group documents 170 4.2.1 Standards-track 172 This role is described in RFC 2026 section 6. Such documents are 173 submitted to the IESG, which will assign them to a relevant area 174 director. The IESG is responsible for determining: 176 o Whether or not the specification is appropriate for standards 177 track 179 o Whether or not the specification needs review by one or more 180 existing WGs 182 o Whether or not the quality of the specification is adequate 184 The IESG may recommend that a document submitted for standards-track 185 publication instead be published as Experimental or Informational. 187 4.2.2 Informational and Experimental 189 These documents are usually submitted to the RFC Editor in accordance 190 with the procedures of RFC 2026 section 4.2.3 and RFC 2418 section 8. 191 The IESG is asked to review all documents submitted in this fashion 192 for conflicts with the IETF standards process or work done in the 193 IETF community; this is a modification of the RFC 2026 procedure, and 194 documented in RFC 2418 section 8. 196 The IESG may recommend that the document be reviewed by a working 197 group, that the document be published with an IESG note indicating 198 issues such as conflict with the IETF standards process, or may 199 recommend that the document not be published. 201 4.3 IESG review procedures 203 The IESG review procedure is defined by the IESG. 205 The IESG has web pages as part of the IETF web (www.ietf.org); 206 current details of procedures should be published there. 208 5. The IESG role in area management 210 The IETF divides its work into a number of areas, each comprising 211 working groups that relate to that area's focus. (RFC 2418 section 212 1). The area structure is defined by the IESG, and may be changed by 213 the IESG. The IESG decides which areas groups belong to. When 214 reassigning areas, the IESG can move responsibility for areas between 215 IESG members, but the IESG can only add new members through the 216 nomcom process. 218 The primary task of area management is done by one or two area 219 directors per area. An area director may be advised by one or more 220 directorates, which is selected and chaired by the area director (RFC 221 2418 section 1). Directorates may be specific to an area, specific 222 to a technology, or chartered in some other fashion. 224 The ADs for an area are responsible for making sure the WGs in the 225 area are well coordinated, that there is coverage for the 226 technologies needed in the area, and that the challenges that are 227 most important to the Internet in that area are indeed being worked 228 on. 230 To that end, they may charter working groups, suggest modifications 231 to working group charters, encourage people to work on specific work 232 items within or outside working groups, or even shut down working 233 groups that are not performing an useful function. 235 6. Other IESG roles 237 6.1 Staff supervision 239 The IESG is the main body responsible for supporting the IETF Chair 240 in supervising the work of the IETF Secretariat. 242 The supervision of the IANA and the RFC Editor is handled by the IAB. 244 6.2 Process management 246 The IESG is responsible for making sure the IETF process is 247 functional in all aspects. This includes taking responsibility for 248 initiating consideration of updates of the process when required, as 249 well as addressing obvious miscarriages of process even when it does 250 not fall into the categories described above. 252 6.3 External relations 254 The main responsibility for handling external relations rests with 255 the IAB, as described in the IAB Charter (RFC 2850). However, when 256 technical cooperation is required, it is essential that the work be 257 coordinated with the relevant ADs. This often means that ADs will 258 function in a liaison role with other organizations, but the same 259 function may also be done by others when that seems more appropriate. 261 7. Procedural issues 263 While the IESG is generally free to set its own procedures, some 264 parts of the procedures are properly part of its charter. These are 265 given here. 267 7.1 Decision taking 269 The IESG attempts to reach all decisions unanimously. If unanimity 270 cannot be achieved, the chair may conduct informal polls to determine 271 consensus. The IESG may make decisions and take action if at least 272 seven members concur and there are no more than two dissents. 274 For the purpose of judging consensus, only the IETF Chair and the 275 Area Directors are counted. 277 (NOTE: This rule is new, and has not been tried. Its inclusion here 278 is only done to get around the "how do we decide about a challenge to 279 the rules" problem.) 281 The IESG may reach decisions by face to face meeting, teleconference, 282 Internet communication, or any combination of the above. 284 7.2 Openness and confidentiality 286 The IESG publishes minutes of all its meetings on the Internet, and 287 conducts an open meeting at every IETF meeting. It publishes all its 288 findings as RFCs, Internet Drafts or messages to the IETF-announce 289 mailing list. However, discussion of personnel matters and possibly 290 legal and financial matters may sometimes be required to be kept 291 confidential, and the chair may, with the consent of the full 292 members, exclude liaison and ex officio members from such 293 discussions. 295 8. Security considerations 297 The security of the Internet depends on standards giving proper 298 thought to security. Apart from that, there seem to be no 299 considerations of security relevant to this memo. 301 References 303 [1] Chapin, A., "The Internet Standards Process", RFC 1310, March 304 1992. 306 [2] Huitema, C. and P. Gross, "The Internet Standards Process -- 307 Revision 2", RFC 1602, March 1994. 309 [3] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and 310 Procedures", RFC 1603, March 1994. 312 [4] Postel, J., "Addendum to RFC 1602 -- Variance Procedure", BCP 2, 313 RFC 1871, November 1995. 315 [5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 316 9, RFC 2026, October 1996. 318 [6] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 319 25, RFC 2418, September 1998. 321 [7] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall 322 Process: Operation of the Nominating and Recall Committees", BCP 323 10, RFC 2282, February 1998. 325 Author's Address 327 Harald Tveit Alvestrand 328 Cisco Systems 329 Weidemanns vei 27 330 Trondheim 7043 331 NO 333 EMail: harald@alvestrand.no 335 Full Copyright Statement 337 Copyright (C) The Internet Society (2003). All Rights Reserved. 339 This document and translations of it may be copied and furnished to 340 others, and derivative works that comment on or otherwise explain it 341 or assist in its implementation may be prepared, copied, published 342 and distributed, in whole or in part, without restriction of any 343 kind, provided that the above copyright notice and this paragraph are 344 included on all such copies and derivative works. However, this 345 document itself may not be modified in any way, such as by removing 346 the copyright notice or references to the Internet Society or other 347 Internet organizations, except as needed for the purpose of 348 developing Internet standards in which case the procedures for 349 copyrights defined in the Internet Standards process must be 350 followed, or as required to translate it into languages other than 351 English. 353 The limited permissions granted above are perpetual and will not be 354 revoked by the Internet Society or its successors or assigns. 356 This document and the information contained herein is provided on an 357 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 358 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 359 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 360 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 361 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 363 Acknowledgement 365 Funding for the RFC Editor function is currently provided by the 366 Internet Society.