idnits 2.17.1 draft-dawkins-iesg-one-or-more-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2418, but the abstract doesn't seem to directly say this. It does mention RFC2418 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2026, updated by this document, for RFC5378 checks: 1995-09-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2015) is 3391 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7437 (Obsoleted by RFC 8713) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IESG S. Dawkins 3 Internet-Draft Huawei 4 Updates: 2026,2418 (if approved) January 13, 2015 5 Intended status: Best Current Practice 6 Expires: July 17, 2015 8 Increasing the Number of Area Directors in an IETF Area 9 draft-dawkins-iesg-one-or-more-05.txt 11 Abstract 13 This document removes a limit on the number of Area Directors who 14 manage an Area in the definition of "IETF Area". This document 15 updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 17, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 52 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Normative Text Change . . . . . . . . . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 7.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction and Scope 64 This document updates RFC 2026 ([RFC2026], BCP 9) to remove a limit 65 on the number of Area Directors who manage an Area in the definition 66 of "IETF Area". This document also updates RFC 2418 ([RFC2418], BCP 67 25) to reflect this updated definition. 69 The change described in this document is intended to allow the IESG 70 additional flexibility in organizing the IETF's work. It does not 71 make any changes to the role of an Area, and does not argue that 72 assigning more than two Area Directors to an Area is an optimal 73 solution in the long run. In particular, this change is not intended 74 to increase the size of the IESG significantly. If several Areas 75 will require more than two Area Directors, the IESG should consider 76 investigating alternative ways of organizing the IETF's work. 78 2. Discussion 80 In recent discussions, the IESG has explored splitting and combining 81 Areas. One proposal resulted in a single Area that would be managed 82 by three Area Directors. 84 An Area managed by three Area Directors conflicts with this 85 definition in Section 14, "DEFINITIONS OF TERMS" of RFC 2026 86 ([RFC2026]): 88 IETF Area - A management division within the IETF. An Area 89 consists of Working Groups related to a general topic such as 90 routing. An Area is managed by one or two Area Directors. 92 A similar statement appears in Section 1, "Introduction" of RFC 2418 93 ([RFC2418]): 95 Each IETF area is managed by one or two Area Directors (ADs). 97 While it's true that recent IESGs have had two Area Directors in each 98 Area except for the General Area, the number of Area Directors in 99 each Area has varied since RFC 1396 ([RFC1396]) (for reference, see 100 http://www.ietf.org/iesg/past-members.html). 102 This variation was due to a number of factors, including workload and 103 personal preferences, and happened as a natural part of the IESG 104 organizing itself to do the work the IESG is chartered to do. 106 At one point, the IESG placed three Area Directors in a single Area 107 (Scott Bradner, Deirdre Kostick, and Michael O'Dell, in the 108 Operational & Management Requirements Area, between IETF 36 and IETF 109 37 in 1996). 111 The last time the IESG increased the number of Area Directors in an 112 Area was when they requested that the Nominating Committee provide a 113 second Area Director in the Routing Area in 1999. Although the 114 number of Area Directors in an Area hasn't changed since then, the 115 IESG continues to be responsible for specifying the positions that 116 Nomcom would fill each year. 118 It is consistent with the IESG's role in creating and dismantling 119 entire Areas to allow the IESG flexibility in assigning enough Area 120 Directors who have been selected by the Nominating Committee to 121 effectively manage the working groups within an Area. 123 Note the requirement in RFC 7437 ([RFC7437], BCP 10) that the 124 Nominating Committee review (approximately) half the positions for 125 the IESG each year is unchanged. The Nomcom may assign an 126 appropriate term duration for each position to ensure the ideal 127 application of this rule in the future, and this is also unchanged. 129 3. Normative Text Change 131 For this text (OLD) in Section 14, "DEFINITIONS OF TERMS" of RFC 2026 132 ([RFC2026]): 134 IETF Area - A management division within the IETF. An Area 135 consists of Working Groups related to a general topic such as 136 routing. An Area is managed by one or two Area Directors. 138 Replace with this text (NEW): 140 IETF Area - A management division within the IETF. An Area 141 consists of Working Groups related to a general topic such as 142 routing. An Area is managed by one or more Area Directors. 144 For this text (OLD) in Section 1, "Introduction" of RFC 2418 145 ([RFC2418]): 147 Each IETF area is managed by one or two Area Directors (ADs). 149 Replace with this text (NEW): 151 Each IETF area is managed by one or more Area Directors (ADs). 153 Informational RFCs such as RFC 3710 ([RFC3710]) and informal 154 descriptions of IETF organizational structure which also describe 155 IETF Areas as being managed by one or two Area Directors should be 156 considered updated by this normative specification. 158 4. Security Considerations 160 This document updates an IETF process BCP and has no direct Internet 161 security implications. 163 5. IANA Considerations 165 This document makes no requests of IANA, and the RFC Editor can 166 safely remove this section during publication. 168 6. Acknowledgements 170 Thanks to Barry Leiba and Jari Arkko for applying the giggle test to 171 version -00 of this document, and to Adrian Farrel, Alexey Melnikov, 172 Brian Carpenter, Christer Holmberg, David Crocker, David Harrington, 173 Donald Eastlake, Kathleen Moriarty, Murray Kucherawy, Susan Hares, 174 Stephan Farrell, and Stuart Bryant for providing review comments. 176 Thanks to Fred Baker, Michael St. Johns, and Scott Bradner for 177 providing a better understanding of the history of how the IESG ended 178 up with two Area Directors in most Areas and even, at one point, 179 three Area Directors in one Area. 181 7. References 183 7.1. Normative References 185 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 186 3", BCP 9, RFC 2026, October 1996. 188 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 189 Procedures", BCP 25, RFC 2418, September 1998. 191 [RFC7437] Kucherawy, M., "IAB, IESG, and IAOC Selection, 192 Confirmation, and Recall Process: Operation of the 193 Nominating and Recall Committees", BCP 10, RFC 7437, 194 January 2015. 196 7.2. Informative References 198 [RFC1396] Crocker, S., "The Process for Organization of Internet 199 Standards Working Group (POISED)", RFC 1396, January 1993. 201 [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February 202 2004. 204 Author's Address 206 Spencer Dawkins 207 Huawei Technologies 209 Email: spencerdawkins.ietf@gmail.com