IAOC Advisor for NomCom: IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee
Advising the Nominating Committee about IETF administration
Dawkins, S., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee", RFC 8318, DOI 10.17487/RFC8318, January 2018, <https://www.rfc-editor.org/info/rfc8318>.
@misc{rfc8318,
series = {Request for Comments},
number = 8318,
howpublished = {RFC 8318},
publisher = {RFC Editor},
doi = {10.17487/RFC8318},
url = {https://www.rfc-editor.org/info/rfc8318},
author = {S. Dawkins},
title = {{IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee}},
pagetotal = 9,
year = 2018,
month = jan,
} RFC text
Contents
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.
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
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.
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.
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>.
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.
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.
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
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
AI ELI5
On this page
§1The Nominating Committee and Administrative Oversight
The IETF Nominating Committee (NomCom) is responsible for selecting and confirming members of several IETF leadership bodies, including the IETF Administrative Oversight Committee (IAOC), which oversees the administrative structure and operations of the IETF itself.
In practice, the Nominating Committee members who are not specialists in IETF administration may lack detailed knowledge about how the IAOC operates, what its responsibilities are, and what expertise or experience is important for its members. Without this context, the committee may not be able to properly evaluate candidates or provide good oversight of the IAOC's work.
For many years, the IAOC has informally sent a representative to help answer questions from the Nominating Committee, but this practice was never officially documented in the process rules.
A committee picks new leaders for the business side of the organization. The committee members might not know how that side works, so someone from that side comes to explain it.
§2From Informal Practice to Formal Role
RFC 7437 previously allowed any committee member to propose adding an advisor or liaison to the Nominating Committee, but it did not specifically encourage or document the practice of requesting IAOC expertise. Beginning around 2010, the IAOC informally provided a representative to each Nominating Committee.
However, in 2016, when the Nominating Committee was not selecting an IAOC member (because a mid-term vacancy had been filled by a longer-term appointment), the opportunity to request an IAOC advisor was overlooked—precisely because this practice was not part of the documented process. Similarly, in 2017, the practice was almost missed again.
This document formalizes the ad hoc practice so that future Nominating Committees will explicitly remember to request IAOC expertise. It also renames the role from 'liaison' to 'advisor' to better reflect what the person actually does and to avoid confusion with the more formal and demanding role of organizational liaison.
For years someone did this unofficially. But twice the committee almost forgot to ask. So they wrote it down to make sure it does not get forgotten.
§3The Updated Process
RFC 8318 updates RFC 7437 by adding new text to Section 4.3 Structure. The change encourages committee members to propose an IAOC advisor and specifies that the Nominating Committee may choose to ask the IAOC to suggest someone knowledgeable about its operations, although the committee still votes to approve whoever is proposed.
The role is defined as an advisor rather than a liaison. An advisor is a non-voting participant whose duties are specified by the invitation that appointed them, in this case to help the committee understand IAOC operations. Unlike liaisons, advisors are not expected to monitor the committee's process, file disputes, or serve as backup chair candidates. This lighter designation prevents overloading the IAOC representative with responsibilities beyond answering questions about IAOC operations.
The document also makes clear that the advisor need not be a sitting IAOC member. This is important because many IAOC members are subject to review by the current Nominating Committee, which could create a conflict of interest. The IAOC has flexibility to send whoever it judges most qualified to explain its operations.
The updated rules say the committee should ask the business side to send an explainer. The explainer just answers questions; they do not have to watch the committee or be a boss.
§4Why This Approach
The RFC includes a detailed appendix explaining why this solution was chosen over alternatives. Rather than create an entirely new IAOC-specific role (which would be complex and might become obsolete if the IAOC itself changed structure), the authors decided to reuse the existing "advisor" role from RFC 7437, which is simpler and has survived many Nominating Committee cycles.
The role is explicitly an "advisor" rather than a "liaison" because liaisons carry obligations from RFC 7437 that are not necessary for this purpose: liaisons must monitor the committee's execution, can be asked to resolve disputes, and are part of the pool of people eligible to become acting chair if needed. These responsibilities are too demanding for someone whose only job is to answer questions about IAOC operations.
Similarly, the IAOC is not required to send a sitting member. Some years, no sitting member might be available and willing, or the IAOC might judge that someone else in the community would be a better explainer. This flexibility allows the role to work reliably across many Nominating Committee cycles and organizational changes.
They chose the simplest approach that works: ask the business side to send someone smart who is not busy with other big jobs.