idnits 2.17.00 (12 Aug 2021) /tmp/idnits9549/draft-iesg-charter-00.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 (December 6, 2002) is 7105 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 242, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 245, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 248, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 251, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 254, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 257, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 260, 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: June 6, 2003 December 6, 2002 6 An IESG charter 7 draft-iesg-charter-00 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 June 6, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). 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 1. Introduction 44 The role of the IESG in the IETF management structure has been 45 largely constant since 1992, when the structure of the Internet 46 standards process was defined by RFC 1310 (which was later updated by 47 RFC 1602, RFC 1871 and RFC 2026). 49 Some of the functions were also defined in RFC 1603 (which was later 50 updated by RFC 2418). 52 As the community has grown, and the IESG has gathered experience, the 53 way in which the IESG approaches its tasks has varied considerably, 54 but the tasks have remained relatively constant. 56 This document describes the tasks assigned to the IESG. 58 2. The composition of the IESG 60 The IESG has the following members: 62 o The IETF Chair, who is also the General AD 64 o The Area Directors for the IETF Areas 66 o Liaisons 68 The Chair and the Area Directors are selected by the IETF NomCom 69 according to the procedures of RFC 2282 (Nomcom procedures). The 70 Liaisons are selected as appropriate by the liaising bodies. At the 71 time of this writing, the liaisons present are: 73 The RFC Editor 75 The IANA 77 The IAB 79 In addition, members of the IETF Secretariat are subscribed to the 80 mailing list and present in the IESG meetings as needed in order to 81 serve as a support function. 83 3. The IESG role in working group management 85 3.1 Working group creation 87 The formation of working groups is described in RFC 2418 section 2. 88 Each area director is responsible for ensuring that a working group 89 being chartered is relevant, has achievable goals and constitutes an 90 acceptable risk, has sufficient interest and so on. The charter is 91 the result of a negotiation between the AD and the prospective 92 chairs, with review by the IAB and approval by the IESG. Normally, 93 there will be communication with the community of interest for the 94 working group too. 96 The AD is also responsible for selecting chairs for the working group 97 that he thinks will be up to the task. 99 The BOF procedure described in RFC 2418 section 2.4 also requires 100 approval from the relevant AD. A BOF is not required to start a 101 working group, and a BOF may be held without the purpose being to 102 create a working group. BOFs are also often discussed with the IESG 103 and IAB. 105 If an AD determines that it is needed, he can take the initiative to 106 create a working group. 108 3.2 Working group management 110 The role of the Area Director in WG management is described in RFC 111 2418 section 6.7. The AD is responsible for making sure the working 112 groups stay focused on the charter tasks, make forward progress, are 113 coordinated with the rest of the area, and (with the IESG) 114 coordinated with the rest of the IETF. 116 In a well functioning working group, main responsibility for these 117 things rests with the chairs; the AD will normally be able to 118 concentrate on supporting the working group chairs' work. 120 When a WG finds that it is essential that work gets done which is not 121 on its charter, the AD is responsible for figuring out whether to add 122 it to their charter, add it to another group's charter, task someone 123 outside the WG to work on it, or initiate creation of another WG. 125 The Area Director is also responsible for picking and, when 126 necessary, replacing working group chairs. This is usually done in 127 consultation with the IESG. 129 4. The IESG role in document review 131 4.1 Working group documents 133 This role is described in RFC 2418 section 7.5, and RFC 2026 section 134 6. The IESG role is one of review and approval. 136 4.2 Non-working group documents 138 4.2.1 Standards-track 140 This role is described in RFC 2026 section 6. Such documents are 141 submitted to the IESG, which will assign them to a relevant area 142 director. The IESG is responsible for determining: 144 o Whether or not the specification is appropriate for standards 145 track 147 o Whether or not the specification needs review by one or more 148 existing WGs 150 o Whether or not the quality of the specification is adequate 152 4.2.2 Informational and Experimental 154 These documents are usually submitted to the RFC Editor in accordance 155 with the procedures of RFC 2026 section 4.2.3 and RFC 2418 section 8. 156 The IESG is asked to review all documents submitted in this fashion 157 for conflicts with the IETF standards process or work done in the 158 IETF community; this is a modification of the RFC 2026 procedure, and 159 documented in RFC 2418 section 8. 161 4.3 IESG review procedures 163 The IESG review procedure is defined by the IESG. 165 At the time of this writing, the procedure consists of: 167 o An initial review by the responsible AD, assisted by whatever 168 reviewers the AD wants to bring to bear 170 o Once the responsible AD is satisfied that the document is worth 171 sponsoring, a review by the entire IESG 173 o If the IESG has questions or comments, the responsible AD takes 174 the token to resolve these with the authors or WG responsible 175 before taking the (possibly revised) document back to the IESG for 176 re-review. 178 The IESG has web pages as part of the IETF web (www.ietf.org); 179 current details of procedures should be published there. 181 5. The IESG role in area management 183 The IETF divides its work into a number of areas, each comprising 184 working groups that relate to that area's focus. (RFC 2418 section 185 1). The area structure is defined by the IESG, and may be changed by 186 the IESG. The IESG decides which areas groups belong to. When 187 reassigning areas, the IESG can move responsibility for areas between 188 IESG members, but the IESG can only add new members through the 189 nomcom process. 191 The primary task of area management is done by one or two area 192 directors per area. An area director may be advised by one or more 193 directorates, which is selected and chaired by the area director (RFC 194 2418 section 1). Directorates may be specific to an area, specific 195 to a technology, or chartered in some other fashion. 197 The ADs for an area are responsible for making sure the WGs in the 198 area are well coordinated, that there is coverage for the 199 technologies needed in the area, and that the challenges that are 200 most important to the Internet in that area are indeed being worked 201 on. 203 To that end, they may charter working groups, suggest modifications 204 to working group charters, encourage people to work on specific work 205 items within or outside working groups, or even shut down working 206 groups that are not performing an useful function. 208 6. Other IESG roles 210 6.1 Staff supervision 212 The IESG is the main body responsible for supporting the IETF Chair 213 in supervising the work of the IETF Secretariat. 215 The supervision of the IANA and the RFC Editor is handled by the IAB. 217 6.2 Process management 219 The IESG is responsible for making sure the IETF process is 220 functional in all aspects. This includes taking responsibility for 221 initiating consideration of updates of the process when required, as 222 well as addressing obvious miscarriages of process even when it does 223 not fall into the categories described above. 225 6.3 External relations 227 The main responsibility for handling external relations rests with 228 the IAB. However, when technical cooperation is required, it is 229 essential that the work be coordinated with the relevant ADs. This 230 often means that ADs will function in a liaison role with other 231 organizations, but the same function may also be done by others when 232 that seems more appropriate. 234 7. Security considerations 236 The security of the Internet depends on standards giving proper 237 thought to security. Apart from that, there seem to be no 238 considerations of security relevant to this memo. 240 References 242 [1] Chapin, A., "The Internet Standards Process", RFC 1310, March 243 1992. 245 [2] Huitema, C. and P. Gross, "The Internet Standards Process -- 246 Revision 2", RFC 1602, March 1994. 248 [3] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and 249 Procedures", RFC 1603, March 1994. 251 [4] Postel, J., "Addendum to RFC 1602 -- Variance Procedure", BCP 2, 252 RFC 1871, November 1995. 254 [5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 255 9, RFC 2026, October 1996. 257 [6] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 258 25, RFC 2418, September 1998. 260 [7] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall 261 Process: Operation of the Nominating and Recall Committees", BCP 262 10, RFC 2282, February 1998. 264 Author's Address 266 Harald Tveit Alvestrand 267 Cisco Systems 268 Weidemanns vei 27 269 Trondheim 7043 270 NO 272 EMail: harald@alvestrand.no 274 Full Copyright Statement 276 Copyright (C) The Internet Society (2002). All Rights Reserved. 278 This document and translations of it may be copied and furnished to 279 others, and derivative works that comment on or otherwise explain it 280 or assist in its implementation may be prepared, copied, published 281 and distributed, in whole or in part, without restriction of any 282 kind, provided that the above copyright notice and this paragraph are 283 included on all such copies and derivative works. However, this 284 document itself may not be modified in any way, such as by removing 285 the copyright notice or references to the Internet Society or other 286 Internet organizations, except as needed for the purpose of 287 developing Internet standards in which case the procedures for 288 copyrights defined in the Internet Standards process must be 289 followed, or as required to translate it into languages other than 290 English. 292 The limited permissions granted above are perpetual and will not be 293 revoked by the Internet Society or its successors or assigns. 295 This document and the information contained herein is provided on an 296 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 297 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 298 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 299 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 300 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 302 Acknowledgement 304 Funding for the RFC Editor function is currently provided by the 305 Internet Society.