summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8318.txt
blob: a74300de725bd8a586f2e05fa7ad8a174f061618 (plain) (blame)
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
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
Internet Engineering Task Force (IETF)                        S. Dawkins
Request for Comments: 8318                                Wonder Hamster
BCP: 10                                                     January 2018
Updates: 7437
Category: Best Current Practice
ISSN: 2070-1721


    IAB, IESG, and IAOC Selection, Confirmation, and Recall Process:
               IAOC Advisor for the Nominating Committee

Abstract

   This specification formalizes an ad hoc practice used to provide
   advice to the IETF Nominating Committee (NomCom) about the operations
   of the IETF Administrative Oversight Committee (IAOC).

   This document updates RFC 7437.

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 represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8318.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) 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.




Dawkins                   Best Current Practice                 [Page 1]
^L
RFC 8318                 IAOC Advisor for NomCom            January 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Background on 'IAOC Liaisons' to Nominating Committees  . . .   3
   3.  BCP Text Changes  . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Change to Section 4.3 of RFC 7437, 'Structure'  . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Discussion Points  . . . . . . . . . . . . . . . . .   6
     A.1.  Why Is This Role an Advisor?  . . . . . . . . . . . . . .   6
     A.2.  Why Is This Role Not a Liaison? . . . . . . . . . . . . .   7
     A.3.  Why Is This Role Not Required to Be a Sitting IAOC
           Member? . . . . . . . . . . . . . . . . . . . . . . . . .   8
     A.4.  Why Does the Nominating Committee Request an IAOC
           Advisor?  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

































Dawkins                   Best Current Practice                 [Page 2]
^L
RFC 8318                 IAOC Advisor for NomCom            January 2018


1.  Introduction

   This specification formalizes an ad hoc practice used to provide
   advice to the IETF Nominating Committee (NomCom) about the operations
   of the IAOC (described in [RFC4071]).

   This document updates [RFC7437].

   Proposed future changes to BCP 10 should be discussed on the public
   IETF NomCom discussion mailing list, at
   <https://www.ietf.org/mailman/listinfo/ietf-nomcom>.

2.  Background on 'IAOC Liaisons' to Nominating Committees

   When RFC 7437 [RFC7437] was approved, it explicitly charged the
   nominating committee with selecting and reviewing certain members of
   the IAOC.  However, [RFC7437] did not provide for the IAOC to send a
   liaison to the nominating committee.

   This was not thought to be an obstacle because [RFC7437] allowed any
   committee member to propose a liaison from the IAOC:

      Any committee member may propose the addition of a liaison from
      other unrepresented organizations to participate in some or all of
      the deliberations of the committee.  The addition must be approved
      by the committee according to its established voting mechanism.
      Liaisons participate as representatives of their respective
      organizations.

   Beginning in 2010, the IAOC provided a liaison to each nominating
   committee.  In 2016, the IAOC did not provide a liaison because the
   nominating committee was not appointing an IAOC member.  The previous
   nominating committee had filled a mid-term vacancy (using the process
   described in Section 3.5. of [RFC7437]) by appointing an IAOC member
   for a term longer than two years.  In 2017, the NomCom was selecting
   an IAOC member, but the opportunity to request a liaison from the
   IAOC was overlooked, because this practice wasn't part of the
   documented process in [RFC7437].

   This specification adds the previously ad hoc role to [RFC7437] so
   that future nominating committees will be less likely to overlook it.

   Although past ad hoc practice has characterized this role as a
   "liaison", this specification labels the role as an "advisor".  The
   rationale for this change in nomenclature is provided in
   Appendix A.1.





Dawkins                   Best Current Practice                 [Page 3]
^L
RFC 8318                 IAOC Advisor for NomCom            January 2018


3.  BCP Text Changes

   This section provides the updated BCP text for [RFC7437].

   For each OLD text selection, NEW text is provided that replaces the
   OLD text in [RFC7437].

3.1.  Change to Section 4.3 of RFC 7437, 'Structure'

   OLD

      Any committee member may propose the addition of an advisor to
      participate in some or all of the deliberations of the committee.
      The addition must be approved by the committee according to its
      established voting mechanism.  Advisors participate as
      individuals.

   NEW

      Any committee member may propose the addition of an advisor to
      participate in some or all of the deliberations of the committee.
      The addition must be approved by the committee according to its
      established voting mechanism.  Advisors participate as
      individuals.

      Committee members are encouraged to propose the addition of an
      advisor who is knowledgeable about the operations of the IAOC,
      whether or not that nominating committee is reviewing an IAOC
      position.  The nominating committee may choose to ask the IAOC to
      suggest an advisor who is knowledgeable about IAOC operations but
      may select any advisor they vote to approve.

4.  Security Considerations

   This document updates an IETF process BCP and has no direct Internet
   security implications.

5.  IANA Considerations

   This document has no IANA actions.











Dawkins                   Best Current Practice                 [Page 4]
^L
RFC 8318                 IAOC Advisor for NomCom            January 2018


6.  Normative References

   [RFC4071]  Austein, R., Ed. and B. Wijnen, Ed., "Structure of the
              IETF Administrative Support Activity (IASA)", BCP 101,
              RFC 4071, DOI 10.17487/RFC4071, April 2005,
              <https://www.rfc-editor.org/info/rfc4071>.

   [RFC7437]  Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection,
              Confirmation, and Recall Process: Operation of the
              Nominating and Recall Committees", BCP 10, RFC 7437,
              DOI 10.17487/RFC7437, January 2015,
              <https://www.rfc-editor.org/info/rfc7437>.







































Dawkins                   Best Current Practice                 [Page 5]
^L
RFC 8318                 IAOC Advisor for NomCom            January 2018


Appendix A.  Discussion Points

   This section preserves discussions and explanations that came up
   during document discussions.  Ordinarily, this section might be
   deleted during the evaluation process, but some questions came up
   repeatedly, so the editor has included them for anyone who also
   shares those questions.

A.1.  Why Is This Role an Advisor?

   The editor of this document briefly considered proposing a new and
   IAOC-specific role to [RFC7437] but considered such a proposal to be
   complex.  Anticipating every corner case in IETF process BCPs is
   challenging and prone to error, and as this specification was being
   written, the IETF Chair was sponsoring a design team reviewing all
   aspects of the IETF Administrative Support Activity (IASA).
   Therefore, the structure and membership of the IAOC itself could
   change in the near future.  Instead, the specification describes how
   the nominating committee requests advisors and builds on mature text
   that has survived many nominating committee cycles.

   After choosing to reuse existing roles defined in [RFC7437], the
   definition of "advisor" in Section 4.9 of [RFC7437] seemed
   appropriate.

      An advisor is responsible for such duties as specified by the
      invitation that resulted in the appointment.

      Advisors do not vote on the selection of candidates.

   The position described in this specification could be filled by an
   advisor who would be a non-voting member of the nominating committee,
   who is knowledgeable about the operations of the IAOC, and who has
   duties that could evolve over time as the IAOC itself evolves.

   The only difference between this advisor that requires an update to
   [RFC7437], and any other advisor is that committee members are
   explicitly encouraged to suggest that this advisor be appointed as
   described in this specification.  The text updating [RFC7437] is
   found in Section 3.











Dawkins                   Best Current Practice                 [Page 6]
^L
RFC 8318                 IAOC Advisor for NomCom            January 2018


A.2.  Why Is This Role Not a Liaison?

   Discussions on the IETF NomCom mailing list led to the recognition
   that "liaison" was not the best description of this role.

   The role of liaison defined in Section 4.7 of [RFC7437] places some
   significant obligations on liaisons beyond what is necessary for
   someone to answer questions from the nominating committee about the
   IAOC.  These obligations include the following:

   o  Liaisons are responsible for ensuring the nominating committee in
      general and the Chair in particular execute their assigned duties
      in the best interest of the IETF community.

   o  Liaisons from the IESG, IAB, and Internet Society Board of
      Trustees (if one is appointed) are expected to review the
      operation and execution process of the nominating committee and to
      report any concerns or issues to the Chair of the nominating
      committee immediately.  If they cannot resolve the issue between
      themselves, liaisons must report it according to the dispute
      resolution process stated elsewhere in this document.

   o  Liaisons may have other nominating committee responsibilities as
      required by their respective organizations or requested by the
      nominating committee; such responsibilities may not conflict with
      any other provisions of this document.

   Finally, as mentioned in Section 4.6 of [RFC7437], all of the
   liaisons are included in the pool of people who are eligible to be
   selected as a replacement for a Chair.

      There are a variety of ordinary circumstances that may arise from
      time to time that could result in a Chair being unavailable to
      oversee the activities of the committee.  The Chair, in
      consultation with the Internet Society President, may appoint a
      substitute from a pool comprised of the liaisons currently serving
      on the committee and the prior year's Chair or designee.

   Note: During discussion of this specification, we noted that any
   liaison would be part of the pool of potential substitute nominating
   committee Chairs.  It wasn't clear to the discussion participants
   whether there was an intentional decision to make liaisons voted onto
   the nominating committee eligible to be substitute Chairs.  That
   potential change is out of scope for this specification but may be a
   conversation worth having separately.






Dawkins                   Best Current Practice                 [Page 7]
^L
RFC 8318                 IAOC Advisor for NomCom            January 2018


   All of these obligations are important, but there are always at least
   two full liaisons from the confirming bodies that are already
   responsible for those responsibilities.  It is simply not necessary
   to make the job of helping the nominating committee understand the
   role and operational practices of the IAOC more demanding than it
   must be.

   So, requiring the IAOC to name a formal liaison to the nominating
   committee isn't justified.

A.3.  Why Is This Role Not Required to Be a Sitting IAOC Member?

   In addition to the reasons given in Appendix A.2, the requirement
   that the IAB and IESG liaisons to the nominating committee be sitting
   members of the organizations they represent, whose positions are not
   being reviewed by this nominating committee, is especially
   challenging for the IAOC.

   Many IAOC positions are filled by members who are already members of
   IETF leadership and are subject to review by the nominating
   committee.  This means that limiting an IAOC liaison to one of the
   sitting members would mean that in some years the only individuals
   eligible to serve as liaison for the nominating committee would be
   sitting members of the IAOC that a) were appointed by the previous
   nominating committee and are not being by the current nominating
   committee, or b) were appointed by the IAB or IESG and are not being
   reviewed by the current IAB or IESG.  "Eligible" does not also mean
   "willing and able to serve", so it is possible that an IAOC might
   find itself with no sitting member to send as advisor in some years.

   Although all IAOC liaisons to the nominating committee have served as
   sitting members of the IAOC, given 10 years of IAOC operation, this
   specification assumes that other members of the community have
   sufficient experience to provide guidance if the IAOC chooses to
   suggest such a person.  If any given IAOC thought that was important,
   they could certainly continue to suggest sitting members, but if no
   sitting member was willing and able to serve, the IAOC would be free
   to do the next best thing and would likely be the best qualified
   group to decide who to send.

A.4.  Why Does the Nominating Committee Request an IAOC Advisor?

   This specification could have described the mechanism in one of two
   ways:

   o  the IAOC could simply provide the name of the advisor to the
      nominating committee, or




Dawkins                   Best Current Practice                 [Page 8]
^L
RFC 8318                 IAOC Advisor for NomCom            January 2018


   o  the nominating committee could request the name of an advisor from
      the IAOC.

   Either choice could work.  The reason that this specification chose
   to have the nominating committee make the first move is that this is
   more similar to the way other advisors to the nominating committee
   are selected, except that the nominating committee is asking the IAOC
   for a suggestion before inviting the advisor to join the nominating
   committee.

   The suggestion is, in fact, a suggestion; the nominating committee
   still votes to invite this advisor as they would vote to invite any
   advisor, as described in Section 4.3 of [RFC7437].

Acknowledgements

   Thanks to Adrian Farrel, Alissa Cooper, Andy Malis, Alvaro Retana,
   Joel Halpern, John Klensin, Leslie Daigle, Michael Richardson, Robert
   Sparks, Russ Housley, S.  Moonesamy, Scott Bradner, Stephen Farrell,
   and Ted Hardie for providing feedback on early draft versions of this
   document.

   The input provided by Joel Halpern (2008-2009 nominating committee
   Chair) and Michael Richardson (2014-2015 nominating committee Chair)
   is especially appreciated because only a few people can provide a
   nominating committee Chair's perspective on how useful representation
   from the IAOC has been in practice.

Author's Address

   Spencer Dawkins
   Wonder Hamster Internetworking LLC

   Email: spencerdawkins.ietf@gmail.com

















Dawkins                   Best Current Practice                 [Page 9]
^L