1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
|
<pre>Internet Engineering Task Force (IETF) S. Dawkins
Request for Comments: 7475 Huawei
BCP: 9 March 2015
Updates: <a href="./rfc2026">2026</a>, <a href="./rfc2418">2418</a>
Category: Best Current Practice
ISSN: 2070-1721
<span class="h1">Increasing the Number of Area Directors in an IETF Area</span>
Abstract
This document removes a limit on the number of Area Directors who
manage an Area in the definition of "IETF Area". This document
updates <a href="./rfc2026">RFC 2026</a> (<a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>) and <a href="./rfc2418">RFC 2418</a> (<a href="./bcp25">BCP 25</a>).
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It has been approved for publication by the Internet
Engineering Steering Group (IESG). Further information on BCPs is
available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7475">http://www.rfc-editor.org/info/rfc7475</a>.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Dawkins Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7475">RFC 7475</a> More Area Directors in an Area March 2015</span>
Table of Contents
<a href="#section-1">1</a>. Introduction and Scope . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3">3</a>. Normative Text Change . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5.1">5.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5.2">5.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction and Scope</span>
This document updates <a href="./rfc2026">RFC 2026</a> ([<a href="./rfc2026" title=""The Internet Standards Process -- Revision 3"">RFC2026</a>], <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>) to remove a limit
on the number of Area Directors who manage an Area in the definition
of "IETF Area". This document also updates <a href="./rfc2418">RFC 2418</a> ([<a href="./rfc2418" title=""IETF Working Group Guidelines and Procedures"">RFC2418</a>], <a href="https://www.rfc-editor.org/bcp/bcp25">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp25">25</a>) to reflect this updated definition.
The change described in this document is intended to allow the IESG
additional flexibility in organizing the IETF's work. It does not
make any changes to the role of an Area and does not argue that
assigning more than two Area Directors to an Area is an optimal
solution in the long run. In particular, this change is not intended
to increase the size of the IESG significantly. If several Areas
will require more than two Area Directors, the IESG should consider
investigating alternative ways of organizing the IETF's work.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Discussion</span>
In recent discussions, the IESG has explored splitting and combining
Areas. One proposal resulted in a single Area that would be managed
by three Area Directors.
An Area managed by three Area Directors conflicts with this
definition in <a href="#section-14">Section 14</a>, "DEFINITIONS OF TERMS" of <a href="./rfc2026">RFC 2026</a>
([<a href="./rfc2026" title=""The Internet Standards Process -- Revision 3"">RFC2026</a>]):
IETF Area - A management division within the IETF. An Area
consists of Working Groups related to a general topic such as
routing. An Area is managed by one or two Area Directors.
A similar statement appears in <a href="#section-1">Section 1</a>, "Introduction" of <a href="./rfc2418">RFC 2418</a>
([<a href="./rfc2418" title=""IETF Working Group Guidelines and Procedures"">RFC2418</a>]):
Each IETF area is managed by one or two Area Directors (ADs).
<span class="grey">Dawkins Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7475">RFC 7475</a> More Area Directors in an Area March 2015</span>
While it's true that recent IESGs have had two Area Directors in each
Area except for the General Area, the number of Area Directors in
each Area has varied since the publication of <a href="./rfc1396">RFC 1396</a> ([<a href="./rfc1396" title=""The Process for Organization of Internet Standards Working Group (POISED)"">RFC1396</a>]).
(For reference, see <<a href="http://www.ietf.org/iesg/past-members.html">http://www.ietf.org/iesg/past-members.html</a>>.)
This variation was due to a number of factors, including workload and
personal preferences, and happened as a natural part of the IESG
organizing itself to do the work the IESG is chartered to do.
At one point, the IESG placed three Area Directors in a single Area
(Scott Bradner, Deirdre Kostick, and Michael O'Dell, in the
Operational & Management Requirements Area, between IETF 36 and IETF
37 in 1996).
The last time the IESG increased the number of Area Directors in an
Area was when they requested that the Nominating Committee provide a
second Area Director in the Routing Area in 1999. Although the
number of Area Directors in an Area hasn't changed since then, the
IESG continues to be responsible for specifying the positions that
the Nominating Committee fills each year.
It is consistent with the IESG's role in creating and dismantling
entire Areas to allow the IESG flexibility in assigning enough Area
Directors who have been selected by the Nominating Committee to
effectively manage the working groups within an Area.
Note the requirement in <a href="./rfc7437">RFC 7437</a> ([<a href="./rfc7437" title=""IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees"">RFC7437</a>], <a href="https://www.rfc-editor.org/bcp/bcp10">BCP 10</a>) that the
Nominating Committee review (approximately) half the positions for
the IESG each year is unchanged. The Nominating Committee may assign
an appropriate term duration for each position to ensure the ideal
application of this rule in the future, and this is also unchanged.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Normative Text Change</span>
For this text (OLD) in <a href="#section-14">Section 14</a>, "DEFINITIONS OF TERMS" of <a href="./rfc2026">RFC 2026</a>
([<a href="./rfc2026" title=""The Internet Standards Process -- Revision 3"">RFC2026</a>]):
IETF Area - A management division within the IETF. An Area
consists of Working Groups related to a general topic such as
routing. An Area is managed by one or two Area Directors.
Replace with this text (NEW):
IETF Area - A management division within the IETF. An Area
consists of Working Groups related to a general topic such as
routing. An Area is managed by one or more Area Directors.
<span class="grey">Dawkins Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7475">RFC 7475</a> More Area Directors in an Area March 2015</span>
For this text (OLD) in <a href="#section-1">Section 1</a>, "Introduction" of <a href="./rfc2418">RFC 2418</a>
([<a href="./rfc2418" title=""IETF Working Group Guidelines and Procedures"">RFC2418</a>]):
Each IETF area is managed by one or two Area Directors (ADs).
Replace with this text (NEW):
Each IETF area is managed by one or more Area Directors (ADs).
Informational RFCs such as <a href="./rfc3710">RFC 3710</a> ([<a href="./rfc3710" title=""An IESG charter"">RFC3710</a>]) and informal
descriptions of IETF organizational structure that also describe IETF
Areas as being managed by one or two Area Directors should be
considered updated by this normative specification.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document updates an IETF process BCP and has no direct Internet
security implications.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Normative References</span>
[<a id="ref-RFC2026">RFC2026</a>] Bradner, S., "The Internet Standards Process -- Revision
3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996,
<<a href="http://www.rfc-editor.org/info/rfc2026">http://www.rfc-editor.org/info/rfc2026</a>>.
[<a id="ref-RFC2418">RFC2418</a>] Bradner, S., "IETF Working Group Guidelines and
Procedures", <a href="https://www.rfc-editor.org/bcp/bcp25">BCP 25</a>, <a href="./rfc2418">RFC 2418</a>, September 1998,
<<a href="http://www.rfc-editor.org/info/rfc2418">http://www.rfc-editor.org/info/rfc2418</a>>.
[<a id="ref-RFC7437">RFC7437</a>] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection,
Confirmation, and Recall Process: Operation of the
Nominating and Recall Committees", <a href="https://www.rfc-editor.org/bcp/bcp10">BCP 10</a>, <a href="./rfc7437">RFC 7437</a>,
January 2015, <<a href="http://www.rfc-editor.org/info/rfc7437">http://www.rfc-editor.org/info/rfc7437</a>>.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-RFC1396">RFC1396</a>] Crocker, S., "The Process for Organization of Internet
Standards Working Group (POISED)", <a href="./rfc1396">RFC 1396</a>, January 1993,
<<a href="http://www.rfc-editor.org/info/rfc1396">http://www.rfc-editor.org/info/rfc1396</a>>.
[<a id="ref-RFC3710">RFC3710</a>] Alvestrand, H., "An IESG charter", <a href="./rfc3710">RFC 3710</a>, February
2004, <<a href="http://www.rfc-editor.org/info/rfc3710">http://www.rfc-editor.org/info/rfc3710</a>>.
<span class="grey">Dawkins Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7475">RFC 7475</a> More Area Directors in an Area March 2015</span>
Acknowledgements
Thanks to Barry Leiba and Jari Arkko for applying the giggle test to
version -00 of this document, and to Adrian Farrel, Alexey Melnikov,
Brian Carpenter, Christer Holmberg, David Crocker, David Harrington,
Donald Eastlake, Kathleen Moriarty, Murray Kucherawy, Susan Hares,
Stephan Farrell, and Stewart Bryant for providing review comments.
Thanks to Fred Baker, Michael St. Johns, and Scott Bradner for
providing a better understanding of the history of how the IESG ended
up with two Area Directors in most Areas and even, at one point,
three Area Directors in one Area.
Author's Address
Spencer Dawkins
Huawei Technologies
EMail: spencerdawkins.ietf@gmail.com
Dawkins Best Current Practice [Page 5]
</pre>
|
