idnits 2.17.1 draft-iesg-charter-03.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 2003) is 7679 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 503, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 506, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 509, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 512, 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: September 30, 2003 April 2003 6 An IESG charter 7 draft-iesg-charter-03 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 other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on September 30, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This memo gives a charter for the Internet Engineering Steering Group 38 (IESG), a management function of the Internet Engineering Task Force 39 (IETF). 40 It is meant to document the charter of the IESG as presently 41 understood. 43 Discussion of this memo is encouraged on the POISED mailing list 44 46 STATUS NOTE (to be removed from RFC): 47 This document is intended for publication as an Informational 48 document, detailing the instructions to the IESG that the IESG thinks 49 it has been operating under. It does not claim to represent consensus 50 of the IETF that this is the right set of instructions to the IESG. 51 At this time (spring 2003), the structure of the IETF is undergoing 52 reevaluation, and the result is likely to include changes to the 53 IESG's role; spending time to get IETF consensus that this document 54 represents the IETF consensus on what the IESG should do, which a BCP 55 publication would indicate, seems like a less than useful exercise. 57 1. Introduction 59 1.1 The role of the IESG 61 The Internet Engineering Steering Group (IESG) is the group 62 responsible for direct operation of the IETF and for ensuring the 63 quality of work produced by the IETF. 65 The IESG charters and terminates working groups, selects their 66 chairs, monitors their progress and coordinates efforts between them. 67 The IESG performs technical review and approval of working group 68 documents and candidates for the IETF standards track, and reviews 69 other candidates for publication in the RFC series. It also 70 administers IETF logistics, including operation of the Internet-Draft 71 document series and the IETF meeting event. 73 1.2 Historic note 75 The role of the IESG in the IETF management structure has been 76 largely constant since 1993, after the significant changes introduced 77 by the "POISED" process, and documented in RFC 1602. (The previous 78 process was documented in RFC 1310; RFC 1602 has later been updated 79 by RFC 1871 and obsoleted by RFC 2026). 81 Some of the functions were also defined in RFC 1603, Working Group 82 Guidelines, which was later obsoleted by RFC 2418 [2]. 84 As the community has grown, and the IESG has gathered experience, the 85 ways in which the IESG has approached 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 in detail the procedures the IESG uses to 90 accomplish these tasks; that is done elsewhere - consult the IESG's 91 Web pages on the IETF Website for more information. 93 At this time (spring 2003), the structure of the IETF is undergoing 94 reevaluation, and the result is likely to include changes to the 95 IESG's role. Therefore, this document was written as a "documentation 96 of existing practice" rather than as the IETF consensus on what the 97 IESG should do. 98 It is published as an Informational document, detailing the 99 instructions to the IESG that the IESG thinks it has been operating 100 under. It does not claim to represent consensus of the IETF that this 101 is the right set of instructions to the IESG. 103 2. The composition of the IESG 105 The IESG has the following members: 107 o The IETF Chair, who also functions as the General Area Director 108 when this area is active 110 o The Area Directors for the IETF Areas 112 o The IAB Chair and the IETF Executive Director, as ex-officio 113 members of the IESG. 115 The IETF Chair and the Area Directors are selected by the IETF NomCom 116 according to the procedures of BCP 10 [3] (Nomcom procedures). 118 The IETF Executive Director is the person charged with running the 119 IETF Secretariat. 121 The IESG also has liaisons, who are members of the IESG mailing list 122 and may attend all IESG meetings. The Liaison positions exist to 123 facilitate the work of the IETF by expediting communication with 124 other entities involved in the IETF process; which positions to have 125 is decided by the IESG. 127 The liaisons are selected as appropriate by the bodies they 128 represent. At the time of this writing, the liaisons present 129 represent the following bodies: 131 The RFC Editor 133 The IANA 135 The IAB 137 In addition, members of the IETF Secretariat are subscribed to the 138 mailing list and present in the IESG meetings as needed in order to 139 serve as a support function. 141 Decisions of the IESG are made by the IETF Chair and the Area 142 Directors. All IESG members can participate in the IESG's 143 discussions. 145 3. Procedural issues 147 While the IESG is generally free to set its own procedures, some 148 parts of the procedures are properly part of its charter. These are 149 given here. 151 3.1 Decision making 153 The IESG attempts to reach all decisions unanimously. If unanimity 154 cannot be achieved, the chair may conduct informal polls to determine 155 consensus. There is no general rule on how the IESG takes votes; if 156 this had ever been needed, it is likely that the same rule as for the 157 IAB would be used (decisions may be taken if at least two thirds of 158 the members concur and there are no more than two dissents). 160 For the purpose of judging consensus, only the IETF Chair and the 161 Area Directors are counted. 163 The IESG may decide that other procedures for reaching a decision are 164 appropriate under specific conditions. Such other procedures may 165 include: 167 o Assertions of IETF consensus, such as when evaluating a standards 168 action. Here, in addition to the technical quality of the 169 specification, the IESG has to evaluate the community opinion 170 about the specification's subject matter; this has to happen with 171 due notice and opportunity for community feedback. 173 o IESG actions in areas where the IESG has the authority to take 174 action. This does not need special rules. 176 o AD actions taken with the advice and consent of the IESG; the IESG 177 is expected to be kept informed, and gives comment, but the 178 authority to act is delegated to the AD. 180 o AD action; cases where an AD can take independent action without 181 the need to consult the IESG first. 183 The IESG may reach decisions by face to face meeting, teleconference, 184 Internet communication, or any combination of the above. 186 3.2 Openness and confidentiality 188 The IESG publishes a record of decisions from its meetings on the 189 Internet, and conducts an open meeting at every IETF meeting. It 190 publishes more detailed documentation of decisions as RFCs, Internet 191 Drafts or messages to the IETF-announce mailing list, with copies 192 kept on the IETF website where appropriate. 194 The IESG also has private group discussions, using any means of its 195 choice, including email. Records of those discussions are not 196 required to be made public. This is believed to be vital in 197 permitting a frank exchange of viewpoints and worries, allowing 198 people to speak out freely on topics known to be controversial, and 199 permitting people to change their minds based on presented arguments. 200 Decisions and their justification are a matter of public record. 202 However, discussion of personnel matters and possibly legal and 203 financial matters may sometimes be required to be kept confidential, 204 and the chair may, with the consent of the full members, exclude 205 liaison and ex officio members whose presence is seen as 206 inappropriate for the particular discussion from such discussions. 208 The chair may also exclude members and liaisons who have a serious 209 conflict of interest on an issue (although this has never been done 210 so far). Members can also choose to recuse themselves from discussion 211 of an issue, or refrain from casting a vote on an issue, if they feel 212 that is appropriate. 214 4. The IESG role in working group management 216 The IESG is in charge of managing the working group process. While 217 the process of managing a working group is assigned to the working 218 group chairs, the IESG is in charge of those processes that are 219 beyond the scope of the working group chair's role. Most of these 220 functions are delegated by the IESG to a single Area Director - the 221 "responsible Area Director" for the group. 223 4.1 Working group creation 225 The formation of working groups is described in BCP 25 [2] section 226 2; this document does not repeat the text there, but gives some more 227 details of IESG actions. 229 A WG may be requested by members of the IETF community, who address 230 the request to an AD that the requesters feel is the appropriate AD 231 for the task, or the formation can be initiated by an AD. The IESG 232 may assign the prospective working group to another AD and/or Area if 233 the IESG thinks that is best. 235 The AD is responsible for ensuring that a working group being 236 chartered fulfills the criteria for WG formation given in BCP 25. The 237 charter is the result of a negotiation between the AD and the 238 community of interest, with review and advice by the rest of the IESG 239 and the IAB. 241 The AD, with the advice of the IESG, is also responsible for 242 selecting chairs for the working group which the AD thinks will be up 243 to the task. 245 All charters for proposed working groups are announced to the 246 community at large when the IESG thinks that the charter is ready for 247 review, but before the IESG makes a final decision on chartering the 248 WG. The final decision to charter a WG is an IESG decision. 250 The BOF procedure described in BCP 25 [2] section 2.4 also requires 251 approval from the relevant AD (the one who got the request or the AD 252 that the IESG thinks is the right AD to manage the task). A BOF is 253 not required to start a working group, and a BOF may be held without 254 the purpose being to create a working group. BOFs are also often 255 discussed with the IESG and IAB. 257 4.2 Working group management 259 The role of the Area Director in WG management is described in BCP 25 260 [2] section 6.7. 262 The role of managing a WG is divided between the WG Chair(s) and the 263 AD. 265 A WG chair has to manage the working group "from the inside", dealing 266 with individuals, drafts, proposals, meetings and email lists, and 267 has full power and responsibility to do that. 269 An AD manages a WG "from the outside", dealing with charters, chairs, 270 cross-WG and cross-area relationships and so on. 272 The AD is responsible for making sure the working groups stay focused 273 on the charter tasks, make forward progress, are coordinated with the 274 rest of the area, and are coordinated with the rest of the IETF. The 275 ADs help each other with maintaining cross-area coordination. 277 In a well functioning working group, main responsibility for these 278 things rests with the chairs; the AD will normally be able to 279 concentrate on supporting the working group chairs' work. 281 When a WG finds that it is essential that work gets done which is not 282 on its charter, the AD, consulting with the rest of the IESG as 283 required, is responsible for figuring out whether to add it to their 284 charter, add it to another group's charter, task someone outside the 285 WG to work on it, or initiate creation of another WG. 287 Substantive changes to the body of a WG's charter require the same 288 type of process as chartering - see BCP 25 [2] section 5. 290 The Area Director is also responsible for picking and, when 291 necessary, replacing working group chairs. This is done in 292 consultation with the IESG, but the decision is made by the 293 responsible AD. 295 4.3 Working group termination 297 Terminating a WG is a decision of the responsible AD. 299 A working group may be shut down when its work is completed, or when 300 the AD concludes that letting the working group continue its work 301 does not contribute to the IETF's forward progress. 303 The decision to terminate a working group is announced, giving the 304 reason for termination. 306 5. The IESG role in document review 308 The IESG is expected to ensure that the documents are of a sufficient 309 quality for release as RFCs, that they describe their subject matter 310 well, and that there are no outstanding engineering issues that 311 should be addressed before publication. The degree of review will 312 vary with the intended status and perceived importance of the 313 documents. 315 When there are problems or solutions that occur frequently, the IESG 316 may publish documents describing the problems and how to avoid them, 317 such as "IANA considerations" (BCP 26 [8]), or publish web pages with 318 commonly used guidelines. 320 Rules - stuff that the community is expected to follow - are decided 321 by IETF consensus processing and commonly published as BCP RFCs. 323 Guidance to the community that is of a more ephemeral and less 324 normative nature is decided by the IESG and published on the IESG's 325 Web pages. 327 5.1 Working group documents 329 This role is described in BCP 25 [2] section 7.5 and 8, and BCP 9 [1] 330 section 6. The IESG role is one of review and approval. 332 5.2 Non-working group documents 334 5.2.1 Standards-track documents 336 This role, which applies to Proposed, Draft, Standard and BCP 337 processing, is described in BCP 9 [1] section 6. Such documents are 338 submitted to the IESG, which will assign them to a relevant AD. The 339 IESG is responsible for determining: 341 o Whether or not the specification is appropriate for standards 342 track 344 o Whether or not the specification needs review by one or more 345 existing WGs 347 o Whether or not the quality of the specification is adequate 349 The IESG will either approve or disapprove of the publication of the 350 document on the standards track; no document can be published on the 351 standards track without IESG approval. 353 The IESG may decide that a document submitted for standards-track 354 publication should instead be published as Experimental or 355 Informational, or that a document submitted for Proposed standard 356 should be published as BCP, or vice versa. 358 5.2.2 Informational and Experimental documents 360 These documents are normally submitted to the RFC Editor in 361 accordance with the procedures of BCP 9 [1] section 4.2.3 and BCP 25 362 [2] section 8. The IESG is asked to review all documents submitted in 363 this fashion for conflicts with the IETF standards process or work 364 done in the IETF community; this is a modification of the BCP 9 [1] 365 procedure, and documented in BCP 25 [2] section 8. 367 The IESG may recommend that the document be published as-is, that it 368 be reviewed by a working group, that the document be published with 369 an IESG note indicating issues such as conflict with the IETF 370 standards process, or may recommend that the document not be 371 published. 373 If the document is referred to a WG, the WG can recommend that the 374 document be adopted as a WG document, that it be published (possibly 375 with comments), or that the IESG recommend to the RFC Editor that it 376 not be published. The responsible AD for the WG is responsible for 377 getting a response from the WG in a timely manner. 379 An AD, in consultation with the author, may choose to put an 380 individual's document directly before the IESG, without waiting for 381 the document to be submitted through the RFC Editor. This document 382 will then be processed in the same fashion as an Informational or 383 Experimental document from a working group. 385 5.3 IESG review procedures 387 The IESG review procedure is defined by the IESG. 389 The IESG is responsible for conducting the process in a timely manner 390 with appropriate communication. 392 For all documents, the IESG assigns a specific AD the responsibility 393 for the document; that AD will normally review the document, and 394 possibly ask for revisions to it to address obvious problems, before 395 asking the entire IESG to consider it. 397 The IESG has web pages as part of the IETF web (www.ietf.org); 398 current details of procedures, as well as the means of finding the 399 responsible AD for any document, are published there. 401 6. The IESG role in area management 403 The IETF divides its work into a number of areas, each comprising 404 working groups that relate to that area's focus. (BCP 25 [2] section 405 1). The area structure is defined by the IESG, and the IESG can add 406 areas, redefine areas, merge areas, change the number of ADs assigned 407 to an area, or close down areas. 409 Changes to the area structure affect the IETF in many ways; decisions 410 to change the area structure are taken in consultation with the 411 community. 413 When changing the area structure, the IESG can decide which members 414 are responsible for new and changed areas, including making one 415 sitting AD responsible for multiple areas, but the IESG can only add 416 new members through the nomcom process. 418 The primary task of area management is done by one or two Area 419 Directors per area. An AD may be advised by one or more directorates, 420 which are created, selected, chaired and if necessary disbanded by 421 the AD (BCP 25 [2] section 1). Directorates may be specific to an 422 area, specific to a technology, or chartered in some other fashion. 424 The ADs for an area are jointly responsible for making sure the WGs 425 in the area are well coordinated, that there is coverage for the 426 technologies needed in the area, and that the challenges that are 427 most important to the Internet in that area are indeed being worked 428 on. 430 The IESG decides which areas working groups belong to. 432 7. Other IESG roles 434 7.1 Staff supervision 436 The IETF Chair has primary responsibility for supervising the work of 437 the IETF Secretariat, with the advice and consent of the IESG, the 438 IAB Chair and the ISOC president. 440 The supervision of the IANA and RFC-Editor functions is handled by 441 the IAB. 443 7.2 Process management 445 The IESG is responsible for making sure the IETF process is 446 functional in all aspects. This includes taking responsibility for 447 initiating consideration of updates to the process when required, as 448 well as addressing obvious miscarriages of process even when they do 449 not fall into the categories described above. 451 7.3 External relations 453 The responsibility for handling external relations rests with the 454 IAB, as described in the IAB Charter (RFC 2850). However, when 455 technical cooperation is required, it is essential that the work be 456 coordinated with the relevant ADs. This often means that ADs will 457 function in a liaison role with other organizations, but the IAB may 458 decide that the same function may also be done by others when it 459 decides that this is more appropriate. 461 7.4 Appeals actions 463 The formal appeals procedure is described in BCP 9 [1] section 6.5. 465 Most decisions by a working group chair can be appealed to the AD, 466 and decisions by an individual AD can be appealed to the IESG. 468 Decisions of the IESG can be appealed to the IAB; for this reason, 469 the IAB chair and the liaison from the IAB recuse themselves from 470 discussion of appeals to the IESG. 472 8. Security considerations 474 The security of the Internet depends on standards giving proper 475 thought to security. Apart from that, there seem to be no 476 considerations of security relevant to this memo. 478 9. Acknowledgements 480 This work has been supported, aided and abetted by the whole IESG of 481 the time of writing, and has benefited from many other comments. 483 Thanks to David Putzolu, Pekka Savola, John Klensin, Margaret 484 Wasserman, Brian Carpenter, Fred Baker, Jonne Soininen, Robert Elz, 485 Keith Moore, Pete Resnick, Dave Crocker, Vint Cerf, Steve Coya and 486 all others who provided comments on various versions of this 487 document! 489 Normative references 491 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 492 9, RFC 2026, October 1996. 494 [2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 495 25, RFC 2418, September 1998. 497 [3] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall 498 Process: Operation of the Nominating and Recall Committees", BCP 499 10, RFC 2282, February 1998. 501 Informative references 503 [4] Chapin, A., "The Internet Standards Process", RFC 1310, March 504 1992. 506 [5] Huitema, C. and P. Gross, "The Internet Standards Process -- 507 Revision 2", RFC 1602, March 1994. 509 [6] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and 510 Procedures", RFC 1603, March 1994. 512 [7] Postel, J., "Addendum to RFC 1602 -- Variance Procedure", BCP 2, 513 RFC 1871, November 1995. 515 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 516 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 518 Author's Address 520 Harald Tveit Alvestrand 521 Cisco Systems 522 Weidemanns vei 27 523 Trondheim 7043 524 NO 526 EMail: harald@alvestrand.no 528 Appendix A. Change log 530 This section should be deleted when publishing as an RFC 532 Changes from -02 to -03 (apart from minor wording changes): 534 o Added discussion of Informational status to history note (1.2) 536 o Changed history to mention the Kobe/POISED change in procedure 537 (1.2) 539 o Changed the composition of the IESG to mention members separately 540 from liaisons (2) 542 o Removed most of the description of the ExecDirector(2, 7.1) 544 o Changed ballot procedure to be a parenthetical remark, to make 545 clear it's not running code (3.1) 547 o Clarified exclusion paragraph (3.2) 549 o Clarified split of responsibilities between AD and WG chair (4.2) 551 o Clarified (or made clearer that it doesn't have very rigid rules) 552 AD-shepherded info/experimental individual documents (5.2.2) 554 o Added responsibility for timeliness to IESG review (with no 555 promise that it is DONE in a timely fashion.....) (5.3) 557 Intellectual Property Statement 559 The IETF takes no position regarding the validity or scope of any 560 intellectual property or other rights that might be claimed to 561 pertain to the implementation or use of the technology described in 562 this document or the extent to which any license under such rights 563 might or might not be available; neither does it represent that it 564 has made any effort to identify any such rights. Information on the 565 IETF's procedures with respect to rights in standards-track and 566 standards-related documentation can be found in BCP-11. Copies of 567 claims of rights made available for publication and any assurances of 568 licenses to be made available, or the result of an attempt made to 569 obtain a general license or permission for the use of such 570 proprietary rights by implementors or users of this specification can 571 be obtained from the IETF Secretariat. 573 The IETF invites any interested party to bring to its attention any 574 copyrights, patents or patent applications, or other proprietary 575 rights which may cover technology that may be required to practice 576 this standard. Please address the information to the IETF Executive 577 Director. 579 Full Copyright Statement 581 Copyright (C) The Internet Society (2003). All Rights Reserved. 583 This document and translations of it may be copied and furnished to 584 others, and derivative works that comment on or otherwise explain it 585 or assist in its implementation may be prepared, copied, published 586 and distributed, in whole or in part, without restriction of any 587 kind, provided that the above copyright notice and this paragraph are 588 included on all such copies and derivative works. However, this 589 document itself may not be modified in any way, such as by removing 590 the copyright notice or references to the Internet Society or other 591 Internet organizations, except as needed for the purpose of 592 developing Internet standards in which case the procedures for 593 copyrights defined in the Internet Standards process must be 594 followed, or as required to translate it into languages other than 595 English. 597 The limited permissions granted above are perpetual and will not be 598 revoked by the Internet Society or its successors or assignees. 600 This document and the information contained herein is provided on an 601 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 602 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 603 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 604 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 605 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 607 Acknowledgement 609 Funding for the RFC Editor function is currently provided by the 610 Internet Society.