idnits 2.17.00 (12 Aug 2021) /tmp/idnits9010/draft-iesg-charter-02.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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.) 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 (April 9, 2003) is 6981 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: '4' is defined on line 477, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 480, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 483, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 486, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2282 (ref. '3') (Obsoleted by RFC 2727) -- Obsolete informational reference (is this intentional?): RFC 1310 (ref. '4') (Obsoleted by RFC 1602) -- Obsolete informational reference (is this intentional?): RFC 1602 (ref. '5') (Obsoleted by RFC 2026) -- Obsolete informational reference (is this intentional?): RFC 1603 (ref. '6') (Obsoleted by RFC 2418) -- Obsolete informational reference (is this intentional?): RFC 1871 (ref. '7') (Obsoleted by RFC 2026) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '8') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 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: October 8, 2003 April 9, 2003 6 An IESG charter 7 draft-iesg-charter-02 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 October 8, 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. 45 Discussion of this memo is encouraged on the POISED mailing list 46 48 STATUS NOTE (to be removed from RFC): 49 This document is intended for publication as an Informational 50 document, detailing the instructions to the IESG that the IESG thinks 51 it has been operating under. It does not claim to represent 52 consensus of the IETF that this is the right set of instructions to 53 the IESG. At this time (spring 2003), the structure of the IETF is 54 undergoing reevaluation, and the result is likely to include changes 55 to the IESG's role; spending time to get IETF consensus that this 56 document represents the IETF consensus on what the IESG should do, 57 which a BCP publication would indicate, seems like a less than useful 58 exercise. 60 1. Introduction 62 1.1 The role of the IESG 64 The Internet Engineering Steering Group (IESG) is the group that 65 exists to perform the overarching operational and technical 66 management functions of the Internet Engineeering Task Force (IETF). 68 As part of this function, the IESG is tasked with making the 69 management decisions about working groups in the IETF, and with the 70 final review and approval of documents produced by Working Groups and 71 documents published as IETF standards-track documents, and review of 72 other candidates for RFC publication. 74 1.2 Historic note 76 The role of the IESG in the IETF management structure has been 77 largely constant since 1992, when the structure of the Internet 78 standards process was defined by RFC 1310 (which was later updated by 79 RFC 1602, RFC 1871 and RFC 2026). 81 Some of the functions were also defined in RFC 1603, Working Group 82 Guidelines, which was later updated by RFC 2418 [2]. 84 As the community has grown, and the IESG has gathered experience, the 85 ways in which the IESG has approeched its tasks have varied 86 considerably, but the tasks have remained relatively constant. 88 This document describes the tasks assigned to the IESG. It does not 89 attempt to describe the procedures the IESG uses to accomplish these 90 tasks; that is done elsewhere - consult the IESG's Web pages on the 91 IETF Website for more information. 93 2. The composition of the IESG 95 The IESG has the following members: 97 o The IETF Chair, who may also function as an Area Director when 98 appropriate 100 o The Area Directors for the IETF Areas 102 o The IAB Chair and the IETF Executive Director, as ex-officio 103 members of the IESG. 105 o Liaisons 107 The IETF Chair and the Area Directors are selected by the IETF NomCom 108 according to the procedures of BCP 10 [3] (Nomcom procedures). 110 The IETF Executive Director is appointed by the IETF Chair, and is 111 charged with running the IETF Secretariat; traditionally, this 112 position has been held by a person employed full-time by the 113 organization performing the secretariat function. 115 The Liaison positions exist to facilitate the work of the IETF by 116 expediting communication with other entities involved in the IETF 117 process; which positions to have is decided by the IESG. 119 The liaisons are selected as appropriate by the bodies they 120 represent. At the time of this writing, the liaisons present 121 represent the following bodies: 123 The RFC Editor 125 The IANA 127 The IAB 129 In addition, members of the IETF Secretariat are subscribed to the 130 mailing list and present in the IESG meetings as needed in order to 131 serve as a support function. 133 Decisions of the IESG are made by the IETF Chair and the Area 134 Directors. All IESG members can participate in the IESG's 135 discussions. 137 3. Procedural issues 139 While the IESG is generally free to set its own procedures, some 140 parts of the procedures are properly part of its charter. These are 141 given here. 143 3.1 Decision making 145 The IESG attempts to reach all decisions unanimously. If unanimity 146 cannot be achieved, the chair may conduct informal polls to determine 147 consensus. The IESG may make decisions and take action if at least 148 two thirds of the members concur and there are no more than two 149 dissents. 151 For the purpose of judging consensus, only the IETF Chair and the 152 Area Directors are counted. 154 The IESG may decide that other procedures for reaching a decision are 155 apporpriate under specific conditions. Such other procedures may 156 include: 158 o Assertions of IETF consensus, such as when evaluating a standards 159 action. Here, in addition to the technical quality of the 160 specification, the IESG has to evaluate the community opinion 161 about the specification's subject matter; this has to happen with 162 due notice and opportunity for community feedback. 164 o IESG actions in areas where the IESG has the authority to take 165 action. This does not need special rules. 167 o AD actions taken with the advice and consent of the IESG; the IESG 168 is expected to be kept informed, and gives comment, but the 169 authority to act is delegated to the AD. 171 o AD action; cases where an AD can take independent action without 172 the need to consult the IESG first. 174 The IESG may reach decisions by face to face meeting, teleconference, 175 Internet communication, or any combination of the above. 177 3.2 Openness and confidentiality 179 The IESG publishes the record of decisions from all its meetings on 180 the Internet, and conducts an open meeting at every IETF meeting. It 181 publishes all its final decisions as RFCs, Internet Drafts or 182 messages to the IETF-announce mailing list, with copies kept on the 183 IETF website where appropriate. 185 The IESG also discusses its business privately as a group, using any 186 means of its choice, including email. Records of those discussions 187 are not required to be made public. This is believed to be vital in 188 permitting a frank exchange of viewpoints and worries, allowing 189 people to speak out freely on topics known to be controversial, and 190 permitting people to change their minds based on presented arguments. 191 Decisions and their justification are a matter of public record. 193 However, discussion of personnel matters and possibly legal and 194 financial matters may sometimes be required to be kept confidential, 195 and the chair may, with the consent of the full members, exclude 196 liaison and ex officio members whose presence is seen as 197 inappropriate for the particular discussion from such discussions. 199 The chair may also apply exclusion to full members who have a serious 200 conflict of interest on an issue. Members can also choose to recuse 201 themselves from discussion of an issue, or refrain from casting a 202 vote on an issue, if they feel that is appropriate. 204 4. The IESG role in working group management 206 The IESG is in charge of managing the working group process. While 207 the process of running a working group is delegated to the working 208 group chairs, the IESG is in charge of those processes that are 209 beyond the scope of the working group chair's role. Most of these 210 functions are delegated by the IESG to a single Area Director - the 211 "responsible Area Director" for the group. 213 4.1 Working group creation 215 The formation of working groups is described in BCP 25 [2] section 216 2; this document does not repeat the text there, but gives some more 217 details of IESG actions. 219 A WG may be requested by members of the IETF community, who addresse 220 the request to an AD that the requesters feel is the appropriate AD 221 for the task, or the formation can be initiated by an AD. The IESG 222 may assign the prospective working group to another AD if the IESG 223 thinks that is best. 225 The AD is responsible for ensuring that a working group being 226 chartered fulfils the criteria for WG formation given in BCP 25. The 227 charter is the result of a negotiation between the AD and the 228 community of interest, with review and advice by the rest of the IESG 229 and the IAB. 231 The AD is also responsible for selecting chairs for the working group 232 which the AD thinks will be up to the task. 234 All charters for proposed working groups are announced to the 235 community at large when the IESG thinks that the charter is ready for 236 review, but before the IESG makes a final decision on chartering the 237 WG. The final decision to charter a WG is an IESG decision. 239 The BOF procedure described in BCP 25 [2] section 2.4 also requires 240 approval from the relevant AD (the one who got the request or the AD 241 that the IESG thinks is the right AD to manage the task). A BOF is 242 not required to start a working group, and a BOF may be held without 243 the purpose being to create a working group. BOFs are also often 244 discussed with the IESG and IAB. 246 4.2 Working group management 248 The role of the Area Director in WG management is described in BCP 25 249 [2] section 6.7. The AD is responsible for making sure the working 250 groups stay focused on the charter tasks, make forward progress, are 251 coordinated with the rest of the area, and are coordinated with the 252 rest of the IETF. The ADs help each other with maintaining cross- 253 area coordination. 255 In a well functioning working group, main responsibility for these 256 things rests with the chairs; the AD will normally be able to 257 concentrate on supporting the working group chairs' work. 259 When a WG finds that it is essential that work gets done which is not 260 on its charter, the AD, consulting with the rest of the IESG as 261 required, is responsible for figuring out whether to add it to their 262 charter, add it to another group's charter, task someone outside the 263 WG to work on it, or initiate creation of another WG. 265 Substantive changes to the body of a WG's charter require the 266 approval of the IESG. 268 The Area Director is also responsible for picking and, when 269 necessary, replacing working group chairs. This is done in 270 consultation with the IESG, but the decision is made by the 271 responsible AD. 273 4.3 Working group termination 275 Terminating a WG is a decision of the responsible AD. 277 A working group may be shut down when its work is completed, or when 278 the AD concludes that letting the working group continue its work 279 does not contribute to the IETF's forward progress. 281 The decision to terminate a working group must be announced, and the 282 reasons should be clearly given. 284 5. The IESG role in document review 286 The IESG is expected to ensure that the documents are of a sufficient 287 quality for release as RFCs, that they describe their subject matter 288 well, and that there are no outstanding engineering issues that 289 should be addressed before publication. The degree of review will 290 vary with the intended status and perceived importance of the 291 documents. 293 When there are problems or solutions that occur frequently, the IESG 294 may publish documents describing the problems and how to avoid them, 295 such as "IANA considerations" (BCP 26 [8]), or publish web pages with 296 commonly used guidelines. 298 Rules - stuff that the community is expected to follow - are decided 299 by IETF consensus processing and commonly published as BCP RFCs. 301 Guidance to the community that is of a more ephemeral and less 302 normative nature is decided by the IESG and published on the IESG's 303 Web pages. 305 5.1 Working group documents 307 This role is described in BCP 25 [2] section 7.5 and 8, and BCP 9 [1] 308 section 6. The IESG role is one of review and approval. 310 5.2 Non-working group documents 312 5.2.1 Standards-track documents 314 This role is described in BCP 9 [1] section 6. Such documents are 315 submitted to the IESG, which will assign them to a relevant AD. The 316 IESG is responsible for determining: 318 o Whether or not the specification is appropriate for standards 319 track 321 o Whether or not the specification needs review by one or more 322 existing WGs 324 o Whether or not the quality of the specification is adequate 326 The IESG will either approve or disapprove of the publication of the 327 document on the standards track; no document can be published on the 328 standards track without IESG approval. 330 The IESG may decide that a document submitted for standards-track 331 publication should instead be published as Experimental or 332 Informational, or that a document submitted for Proposed standard 333 should be published as BCP, or vice versa. 335 5.2.2 Informational and Experimental documents 337 These documents are normally submitted to the RFC Editor in 338 accordance with the procedures of BCP 9 [1] section 4.2.3 and BCP 25 339 [2] section 8. The IESG is asked to review all documents submitted 340 in this fashion for conflicts with the IETF standards process or work 341 done in the IETF community; this is a modification of the BCP 9 [1] 342 procedure, and documented in BCP 25 [2] section 8. 344 The IESG may recommend that the document be published as-is, that it 345 be reviewed by a working group, that the document be published with 346 an IESG note indicating issues such as conflict with the IETF 347 standards process, or may recommend that the document not be 348 published. 350 If the document is referred to a WG, the WG can recommend that the 351 document be adopted as a WG document, that it be published (possibly 352 with comments), or that the IESG recommend to the RFC Editor that it 353 not be published. The responsible AD for the WG is responsible for 354 getting a response from the WG in a timely manner. 356 NOTE IN DRAFT: The following text tries to capture the occasional 357 practice of processing individual documents through the IESG without 358 first going through the RFC Editor. It is not clear that the 359 description is accurate, so this may change. The IESG is discussing. 361 When an AD decides that an Informational or Experimental document is 362 of particular importance to the community, the AD may also choose to 363 put it directly before the IESG. This document will then be 364 processed in the same fashion as an Informational or Experimental 365 document from a working group. 367 5.3 IESG review procedures 369 The IESG review procedure is defined by the IESG. 371 For all documents, the IESG assigns a specific AD the responsibility 372 for the document; that AD will normally review the document, and 373 possibly ask for revisions to it to address obvious problems, before 374 asking the entire IESG to consider it. 376 The IESG has web pages as part of the IETF web (www.ietf.org); 377 current details of procedures, as well as the means of finding the 378 responsible AD for any document, are published there. 380 6. The IESG role in area management 382 The IETF divides its work into a number of areas, each comprising 383 working groups that relate to that area's focus. (BCP 25 [2] section 384 1). The area structure is defined by the IESG, and the IESG can add 385 areas, redefine areas, merge areas or close down areas. 387 Changes to the area structure affect the IETF in many ways; decisions 388 to change the area structure are taken in consultation with the 389 community 391 When changing the area structure, the IESG can decide which ADs are 392 responsible for new and changed areas, including making one sitting 393 AD responsible for multiple areas, but the IESG can only add new 394 members through the nomcom process. 396 The primary task of area management is done by one or two Area 397 Directors per area. An AD may be advised by one or more 398 directorates, which are selected and chaired by the AD (BCP 25 [2] 399 section 1). Directorates may be specific to an area, specific to a 400 technology, or chartered in some other fashion. 402 The ADs for an area are jointly responsible for making sure the WGs 403 in the area are well coordinated, that there is coverage for the 404 technologies needed in the area, and that the challenges that are 405 most important to the Internet in that area are indeed being worked 406 on. 408 The IESG decides which areas working groups belong to. 410 7. Other IESG roles 412 7.1 Staff supervision 414 The IETF Chair has primary responsibility for supervising the work of 415 the IETF Executive Director and the IETF Secretariat, with the advice 416 and consent of the IESG, the IAB Chair and the ISOC president. 418 The supervision of the IANA and RFC-Editor functions is handled by 419 the IAB. 421 7.2 Process management 423 The IESG is responsible for making sure the IETF process is 424 functional in all aspects. This includes taking responsibility for 425 initiating consideration of updates to the process when required, as 426 well as addressing obvious miscarriages of process even when they do 427 not fall into the categories described above. 429 7.3 External relations 431 The responsibility for handling external relations rests with the 432 IAB, as described in the IAB Charter (RFC 2850). However, when 433 technical cooperation is required, it is essential that the work be 434 coordinated with the relevant ADs. This often means that ADs will 435 function in a liaison role with other organizations, but the IAB may 436 decide that the same function may also be done by others when it 437 decides that this is more appropriate. 439 7.4 Appeals actions 441 The formal appeals procedure is described in BCP 9 [1] section 6.5. 443 Most decisions by a working group chair can be appealed to the AD, 444 and decisions by an individual AD can be appealed to the IESG. 446 Decisions of the IESG can be appealed to the IAB. 448 8. Security considerations 450 The security of the Internet depends on standards giving proper 451 thought to security. Apart from that, there seem to be no 452 considerations of security relevant to this memo. 454 9. Acknowledgements 456 This work has been supported, aided and abetted by the whole IESG of 457 the time of writing, and has benefitted from many other comments. 459 Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret 460 Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen and all others 461 who provided comments on various versions of this document! 463 Normative references 465 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 466 9, RFC 2026, October 1996. 468 [2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 469 25, RFC 2418, September 1998. 471 [3] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall 472 Process: Operation of the Nominating and Recall Committees", BCP 473 10, RFC 2282, February 1998. 475 Informative references 477 [4] Chapin, A., "The Internet Standards Process", RFC 1310, March 478 1992. 480 [5] Huitema, C. and P. Gross, "The Internet Standards Process -- 481 Revision 2", RFC 1602, March 1994. 483 [6] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and 484 Procedures", RFC 1603, March 1994. 486 [7] Postel, J., "Addendum to RFC 1602 -- Variance Procedure", BCP 2, 487 RFC 1871, November 1995. 489 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 490 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 492 Author's Address 494 Harald Tveit Alvestrand 495 Cisco Systems 496 Weidemanns vei 27 497 Trondheim 7043 498 NO 500 EMail: harald@alvestrand.no 502 Full Copyright Statement 504 Copyright (C) The Internet Society (2003). All Rights Reserved. 506 This document and translations of it may be copied and furnished to 507 others, and derivative works that comment on or otherwise explain it 508 or assist in its implementation may be prepared, copied, published 509 and distributed, in whole or in part, without restriction of any 510 kind, provided that the above copyright notice and this paragraph are 511 included on all such copies and derivative works. However, this 512 document itself may not be modified in any way, such as by removing 513 the copyright notice or references to the Internet Society or other 514 Internet organizations, except as needed for the purpose of 515 developing Internet standards in which case the procedures for 516 copyrights defined in the Internet Standards process must be 517 followed, or as required to translate it into languages other than 518 English. 520 The limited permissions granted above are perpetual and will not be 521 revoked by the Internet Society or its successors or assigns. 523 This document and the information contained herein is provided on an 524 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 525 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 526 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 527 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 528 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Acknowledgement 532 Funding for the RFC Editor function is currently provided by the 533 Internet Society.