idnits 2.17.1 draft-carpenter-ietf-chair-tasks-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 399. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 25, 2006) is 6566 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: 'RFC2418' is defined on line 330, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 3005 (Obsoleted by RFC 9245) ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) ** Obsolete normative reference: RFC 4371 (Obsoleted by RFC 8714) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter (ed) 3 Internet-Draft IBM 4 Expires: October 27, 2006 April 25, 2006 6 Tasks of the IETF Chair, IESG Chair, and General Area Director 7 draft-carpenter-ietf-chair-tasks-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 27, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes tasks performed by the IETF Chair, the IESG 41 Chair, and the Area Director of the General Area of the IETF. Its 42 purpose is to inform the community of what these tasks are, and to 43 allow the community to consider whether combining all these roles in 44 one person is optimal. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Tasks of the IETF Chair . . . . . . . . . . . . . . . . . . . 4 50 3. Tasks of the IESG Chair . . . . . . . . . . . . . . . . . . . 5 51 4. Tasks of the General Area Director . . . . . . . . . . . . . . 7 52 5. Time allocation . . . . . . . . . . . . . . . . . . . . . . . 7 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 54 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 55 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 56 9. Change log [RFC Editor: please remove this section] . . . . . 8 57 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 59 10.2. Informative References . . . . . . . . . . . . . . . . . 9 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 Intellectual Property and Copyright Statements . . . . . . . . . . 11 63 1. Introduction 65 By tradition, the same person occupies the jobs of general Chair of 66 the IETF and of IESG Chair, i.e., chair of its steering group. In 67 addition, the IESG has chosen to define a General Area to house IETF 68 activities and Working Groups that do not fit into one of the 69 specific technical Areas. By tradition the same person that acts as 70 IETF Chair and IESG Chair also acts as Area Director of this Area. 72 Specific descriptions of these roles are sparse in IETF process 73 documents. BCP 9 [RFC2026] states: 75 "The Area Directors along with the IETF Chair comprise 76 the Internet Engineering Steering Group (IESG)." 78 BCP 10 [RFC3777] states: 80 "2. No person should serve both on the IAB and as an Area Director, 81 except the IETF Chair whose roles as an IAB member and Area 82 Director of the General Area are set out elsewhere." 84 but makes no other reference to the phrases "IETF Chair" and "General 85 Area" and gives no reference for "elsewhere." BCP 9 makes one 86 passing reference to the "IESG Chair" in its description of the 87 appeals process, and BCP 10 does not use the phrase. Finally, BCP 11 88 [RFC2028] states that 90 "The IESG is composed of the IETF Area Directors and the 91 chair of the IETF, who also serves as the chair of the IESG." 93 The IAB Charter, BCP 39 [RFC2850], identifies the IETF Chair as a 94 voting IAB member. 96 The IESG Charter [RFC3710], which is non-normative, documents that 97 the IETF Chair is a member of the IESG and acts as the General Area 98 Director. It does not explicitly state that the IETF Chair is the 99 IESG Chair, but it does list some duties for the Chair. 101 BCP 45 [RFC3005] gives the IETF Chair a role in managing the main 102 IETF discussion list. 104 BCP 102 [RFC4052] and BCP 103 [RFC4053] assign specific roles to the 105 IETF Chair in special cases of external liaison handling. 107 Finally, BCP 101 states [RFC4071] that the IETF Chair is an ex 108 officio voting member of the IETF Administrative Oversight Committee 109 (IAOC), and therefore implies [RFC4371] that he or she is also a 110 Trustee of the IETF Trust. 112 One motivation for the current document is simply to describe the 113 various tasks which fall to the person fulfilling the three roles of 114 IETF Chair, IESG Chair, and General Area Director. This description 115 may be of value in the identification of candidates for these roles, 116 and to future occupants of these roles. Another motivation is to 117 allow the community to consider whether combining all these roles in 118 one person is optimal. 120 In what follows, tasks have been classified as best as possible among 121 the three roles. 123 2. Tasks of the IETF Chair 124 1. Establish IETF consensus. 125 The Chair initiates and moderates IETF discussions, ascertains 126 IETF opinions, and assesses IETF consensus, on matters that do 127 not fit into any specific Area (including the General Area!). 128 The principal medium for this is the main IETF discussion list 129 [RFC3005], and on occasion an IETF plenary meeting. Incidental 130 to this, the IETF Chair, the IETF Executive Director, or a 131 sergeant-at-arms appointed by the Chair are responsible for 132 dealing with inappropriate postings on the list. 133 2. Act as IAB Member. 134 The IETF Chair is a full member of the IAB [RFC2850] except for 135 matters in conflict with also being a member of the IESG. 136 However, the IETF Chair is not present in the IAB as a 137 representative of the IESG, which has its own liaison. The IETF 138 Chair is expected to play a full technical role in the IAB and 139 does not normally speak there in the IETF Chair role. 140 3. Participate in IAOC. 141 The IETF Chair is an ex officio voting member of the IETF 142 Administrative Oversight Committee (IAOC) [RFC4071] and a Trustee 143 of the IETF Trust [RFC4371]. These are active roles including 144 constant interaction with the IAOC itself and the IETF 145 Administrative Director (IAD), and frequent interaction with the 146 IETF's service providers (IANA, RFC Editor, and Secretariat). 147 Note that the role of supervising the Secretariat described in 148 the the IESG Charter [RFC3710] no longer applies, now being 149 filled by the IAD. 151 Note that currently, the IETF Chair is the only IESG member in 152 the IAOC. In the event of a separation of the IETF and IESG 153 Chair roles, this would need to be reviewed. 154 4. Act as Visible Head of the IETF. 155 Although the IETF has traditionally been a low profile 156 organisation, and explicitly (by T-shirt motto) "rejects Kings 157 and Presidents," the reality is that when dealing with other 158 organisations of all kinds, and when dealing with journalistic 159 media in particular, the role of IETF Chair is automatically and 160 immediately perceived as that of a figurehead. The IETF Chair 161 must be able to deal diplomatically and effectively with this, 162 even if the message will often be that the Chair cannot speak for 163 the IETF on a given matter, because no IETF consensus has yet 164 been reached. 165 1. BCP 102 [RFC4052] defines a specific role for the IETF Chair 166 in the case of technical liaison statements concerning the 167 IETF as a whole. BCP 103 [RFC4053] defines a minor role for 168 the IETF Chair in handling incoming liaison statements. 169 2. The IETF Chair will sometimes need to interact directly with 170 the heads of other Standards Development Organisations. This 171 should be done in close concertation with the IAB Chair, due 172 to the IAB's general responsibility for liaisons [RFC2850]. 173 3. The IETF Chair will be contacted by journalists for general 174 and specific comments, often on controversial issues. On 175 occasion it may be desirable for the Chair to take the 176 initiative (e.g. arrange for a press release), although this 177 is unusual. 178 4. The IETF Chair is expected to contribute to the IETF Journal 179 published by ISOC. 180 5. The IETF Chair is called upon several times a year to make a 181 progress report to the ISOC Board in its role as the IETF's 182 "funding agency." Note that this is completely distinct from 183 the IAB's role as "a source of advice and guidance" [RFC2850] 184 to ISOC. The IAB and the IASA also make reports to ISOC 185 about their areas of competence; the IETF Chair reports on 186 the IETF's progress as a standards body. 187 5. Lightning Rod. 188 The IETF Chair has to act as the lightning rod, hot potato 189 catcher, and help desk of last resort, for members of the IETF 190 community. Often this is simply a matter of dispatching a query 191 to the right person (for example, technical issues to the 192 appropriate Area Director, legal issues to the IETF Counsel and 193 administrative issues to the IAD). Sometimes there is no right 194 person. 196 This role has a positive, pro-active aspect. The IETF Chair 197 should try to have an overall picture of the IETF organization 198 and community, and to "see what's missing" and get someone to do 199 something about it. 201 3. Tasks of the IESG Chair 203 The IESG Chair is responsible for smooth operation of the IESG as a 204 whole and on issues that transcend an individual area in particular. 205 Specific aspects of this role are listed below. 207 1. Moderate IESG discussions. 208 The IESG Chair, like the person chairing any committee, has to 209 moderate and guide its discussions and mediate its decision- 210 taking. In the IESG, decisions to approve documents are normally 211 taken by a highly structured ballot process supported by software 212 tools. However, the Chair has to seek consensus in contentious 213 discussions, and to operate a decision process for cases not 214 handled by the regular ballots. 215 2. First responder. 216 The IESG Chair has to act as "first responder" for incoming items 217 not directed at a specific Area Director (e.g. publication 218 requests, complaints or appeals, or general technical queries and 219 suggestions). In most cases, the item should be assigned to a 220 willing AD; anything else is the Chair's responsibility. 221 3. Progress chaser for daily operations. 222 The IESG Chair at the time of writing has delegated this task to 223 two IESG "whips", but the function is properly that of the Chair. 224 It is to ensure that the day-to-day work of the IESG goes 225 smoothly. 226 1. Tools and metrics are used to identify stalled documents and 227 projects. Then the progress chaser will contact the 228 responsible AD, and determine what action, if any, is needed. 229 If necessary, he or she will bring problem cases to the 230 attention of the whole IESG. 232 With literally hundreds of documents under IESG consideration 233 at any one time, the amount of such progress-chasing work 234 should not be underestimated. 235 2. Additionally, the progress chaser will attempt to gather 236 loose ends for whole IESG, identify chronic problems and gaps 237 in the tools and project list, and identify needs for new 238 procedures and clarifications in existing procedures. 239 4. Represent IESG needs to IASA. 240 When the IESG has established a clear need for improvements in 241 tools or administration, the IESG Chair will convey this need to 242 the IAD or IAOC. On a day to day or weekly basis, the IESG Chair 243 will communicate directly with the Secretariat about short term 244 issues and needs, with the full awareness of the IAD. 245 (Currently, the IAD, the IESG Chair and the Head of Secretariat 246 have a weekly one hour conference call.) 247 5. Represent IESG views to the IETF. 248 When the IESG has established a view on some matter that needs 249 review or consensus of the IETF, the IESG Chair will convey this 250 view to the community. (This is distinct from publishing an IESG 251 decision or statement, which is a Secretariat job.) 253 4. Tasks of the General Area Director 254 1. The General AD has the tasks of any AD for his or her own area - 255 remain attentive to emerging ideas, foster BOFs and WGs as 256 appropriate, manage those WGs, shepherd their drafts and any 257 relevant independent submissions. Although the General Area is 258 in theory for any work not covered elsewhere, it is in practice 259 limited to non-technical topics, i.e. IETF process topics. This 260 does create a curious meta-problem, which is the constant concern 261 about conflict of interest for an Area Director shepherding and 262 advocating work that affects (positively or negatively) his or 263 her own job. 264 2. By convention, the General AD oversees several ad hoc teams (EDU, 265 TOOLS, PROTO) chartered by the IESG. 266 3. The General AD also has the tasks of any AD - reviewing all 267 drafts, WG charters, and any other matters under consideration by 268 the IESG. In a busy fortnight, this can represent 20 or 30 269 documents to review. Recent General ADs have successfully 270 delegated much of the review load to a General Area Review Team, 271 without which most drafts would remain unread in the General 272 Area. 274 Note that if the General AD role was separated from the IESG 275 Chair role, it would have to be decided whether the IESG Chair 276 retained a vote in IESG decisions. If so, the Chair would 277 necessarily also have the task of reviewing all drafts, charters 278 and other matters under consideration. 280 5. Time allocation 282 A detailed analysis of how much time is taken by each of the three 283 roles would require considerable effort. What is clear from recent 284 experience is that the diversity of tasks makes it only too easy to 285 lose any clear sense of relative priorities, and the quantity of 286 small work items means that even important and urgent "big picture" 287 items can readily be overlooked. 289 At a rough estimate, the tasks classified above as "IETF Chair" take 290 50% of the time, the tasks classified as "IESG Chair" take 25%, and 291 those classified as "General AD" take 25%. 293 This is without including the workloads delegated to the IESG Whips 294 and the General Area Review Team respectively. With those workloads, 295 the three tasks would be of roughly equal size, and quite impossible 296 for one person. 298 6. Security Considerations 300 This document has no security implications for the Internet. 302 7. IANA Considerations 304 This document requires no action by the IANA. 306 8. Acknowledgements 308 In drafting this document, previous discussions within the IESG were 309 reviewed. Some words originally written by Harald Alvestrand and 310 Thomas Narten have been used. Useful comments on an early version 311 were made by Harald Alvestrand. 313 This document was produced using the xml2rfc tool[RFC2629]. 315 9. Change log [RFC Editor: please remove this section] 317 draft-carpenter-ietf-chair-tasks-00: original version, 2006-04-25 319 10. References 321 10.1. Normative References 323 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 324 3", BCP 9, RFC 2026, October 1996. 326 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 327 the IETF Standards Process", BCP 11, RFC 2028, 328 October 1996. 330 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 331 Procedures", BCP 25, RFC 2418, September 1998. 333 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 334 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 335 May 2000. 337 [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, 338 RFC 3005, November 2000. 340 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 341 Recall Process: Operation of the Nominating and Recall 342 Committees", BCP 10, RFC 3777, June 2004. 344 [RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes 345 for Management of IETF Liaison Relationships", BCP 102, 346 RFC 4052, April 2005. 348 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 349 Handling Liaison Statements to and from the IETF", 350 BCP 103, RFC 4053, April 2005. 352 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 353 Administrative Support Activity (IASA)", BCP 101, 354 RFC 4071, April 2005. 356 [RFC4371] Carpenter, B. and L. Lynch, "BCP 101 Update for IPR 357 Trust", BCP 101, RFC 4371, January 2006. 359 10.2. Informative References 361 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 362 June 1999. 364 [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, 365 February 2004. 367 Author's Address 369 Brian Carpenter (ed) 370 IBM 371 8 Chemin de Blandonnet 372 1214 Vernier, 373 Switzerland 375 Email: brc@zurich.ibm.com 377 Intellectual Property Statement 379 The IETF takes no position regarding the validity or scope of any 380 Intellectual Property Rights or other rights that might be claimed to 381 pertain to the implementation or use of the technology described in 382 this document or the extent to which any license under such rights 383 might or might not be available; nor does it represent that it has 384 made any independent effort to identify any such rights. Information 385 on the procedures with respect to rights in RFC documents can be 386 found in BCP 78 and BCP 79. 388 Copies of IPR disclosures made to the IETF Secretariat and any 389 assurances of licenses to be made available, or the result of an 390 attempt made to obtain a general license or permission for the use of 391 such proprietary rights by implementers or users of this 392 specification can be obtained from the IETF on-line IPR repository at 393 http://www.ietf.org/ipr. 395 The IETF invites any interested party to bring to its attention any 396 copyrights, patents or patent applications, or other proprietary 397 rights that may cover technology that may be required to implement 398 this standard. Please address the information to the IETF at 399 ietf-ipr@ietf.org. 401 Disclaimer of Validity 403 This document and the information contained herein are provided on an 404 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 405 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 406 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 407 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 408 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 409 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 411 Copyright Statement 413 Copyright (C) The Internet Society (2006). This document is subject 414 to the rights, licenses and restrictions contained in BCP 78, and 415 except as set forth therein, the authors retain all their rights. 417 Acknowledgment 419 Funding for the RFC Editor function is currently provided by the 420 Internet Society.