IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee
draft-dawkins-iesg-nomcom-advisor-iaoc-01.txt

Abstract

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

This document updates RFC 7437.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 9, 2018.

Copyright Notice

Copyright (c) 2017 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 (http://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
• 2. Discussion Venue
• 3. Background on IAOC Liaisons to Nominating Committees
• 4. Issues with IAOC Naming a Liaison
• 5. Why an Advisor?
• 6. BCP Text Changes
• 6.1. Change to Section 4.3, 'Structure'
• 7. Security Considerations
• 8. IANA Considerations
• 9. Acknowledgements
• 10. Normative References
• Author's Address

1. Introduction

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

This document updates [RFC7437].

Note:

In https://www.ietf.org/mail-archive/web/ietf-nomcom/current/msg00518.html, Brian Carpenter asked the reasonable question - why is the justification about six times as long as the actual changed BCP text? Spencer's answer was that this ad hoc role has been called a "liaison" since at least 2010, but in conferring with the current IAOC, what the IAOC intends to send is better described as an "advisor", so it seemed reasonable to explain why this proposal goes in a new direction.

Spencer is, of course, interested in hearing from other people about that.

2. Discussion Venue

Please direct questions and comments to the IETF-Nomcom mailing list, at https://www.ietf.org/mailman/listinfo/ietf-nomcom. The subscribers to the IETF Discussion mailing list will likely be grateful for that.

3. 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], appointing an IAOC member for term longer than two years. In 2017, the NomCom selected an IAOC member, but the opportunity to request a liaison from the IAOC was overlooked, because because this practice wasn't part of the documented process. [RFC7437].

This specification adds the previously ad hoc role to [RFC7437], so future Nominating Committees will be less likely to overlook it.

4. Issues with IAOC Naming a Liaison

Discussions about this topic led to the recognition that "Liaison" was not the best description of this role.

The role of Liaison defined in [RFC7437], Section 4.7 places some significant obligations on Liaisons that aren't necessary for Nominating Committee to ask questions and get answers about the IAOC that come up in deliberations. These obligations include

• Liaisons are responsible for ensuring the nominating committee in general and the Chair in particular execute their assigned duties in the best interests of the IETF community.
• Liaisons from the IESG, IAB, and Internet Society Board of Trustees (if one was appointed) are expected to review the operation and executing process of the nominating committee and to report any concerns or issues to the Chair of the nominating committee immediately. If they can not resolve the issue between themselves, liaisons must report it according to the dispute resolution process stated elsewhere in this document.
• Liaisons may have other nominating committee responsibilities as required by their respective organizations or requested by the nominating committee, except that such responsibilities may not conflict with any other provisions of this document.

[RFC7437], Section 4.8 requires the IESG and IAB liaisons to be sitting members of the organization they represent. Because so many IAOC positions are filled by members who are already members of IETF leadership who are subject to review by the Nominating Committee, limiting an IAOC Liaison to one of the sitting members would mean that in some years, only the person who was appointed by the previous Nominating Committee and not being reviewed by this Nominating Committee, and the person who was appointed by the IAB or IESG and not being reviewed by the IAB/IESG, would be eligible sitting members of the IAOC who could serve as a Liaison for the Nominating Committee.

Although past IAOC Liaisions to the Nominating Committee have all been sitting members of the IAOC, after 10 years of IAOC operation, it is thought that other members of the community have sufficent experience to provide guidance if the IAOC chooses to provide such a person.

Finally, in [RFC7437],Section 4.6, 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 he prior year's Chair or designee.

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

So, requiring the IAOC to name a formal Liaison to the Nominating Committee isn't justified.

Note:

In https://www.ietf.org/mail-archive/web/ietf-nomcom/current/msg00520.html, Adrian Farrel challenged the idea that an IAOC Advisor to the Nomcom might not be a currently sitting member of the IAOC. Spencer's answers are that the IAOC's membership is complex, with a number of ex officio members whose positions are subject to Nomcom review, or to IAB review, or to IESG review; defining who was, and who was not, eligible to serve as IAOC Advisor to the Nomcom would be complicated, and likely overtaken by events given that IASA 2.0 is already being planned, and could easily change the membership of the IAOC; requiring an IAOC Advisor to the Nomcom to be a sitting member of the IAOC required us to define a new role, because neither the Advisor nor the Liaison role matched the role we would be defining; and past IAOCs have sent sitting members to serve, so if the IAOC thought that was important, they could certainly continue to pick sitting members, but if no sitting member was willing/able to serve, the IAOC would be free to do the next best thing, and would likely be the best group to decide who to send.

Spencer is, of course, interested in hearing from other people about that.

5. Why 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 too complex. Anticipating every corner case in IETF process BCPs is challenging and error-prone, 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), so the structure of the IAOC itself could be changing in a relatively short period of time. Instead, the decision was made to describe how the IAOC provides an Advisor to the Nominating Committee, building on mature text that has survived many Nominating Committee cycles.

After investigation, the definition of Advisor in [RFC7437] Section 4.9 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 would be filled by a non-voting member of the Nominating Committee, who is knowledgeable about the operations of the IAOC, with duties that could evolve over time as the IAOC itself evolves.

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

6. 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].

6.1. Change to Section 4.3, '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.

7. Security Considerations

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

8. IANA Considerations

This document makes no requests of IANA, and the RFC Editor can safely remove this section during publication.

9. Acknowledgements

Thanks to Alissa Cooper, Alvaro Retana, Leslie Daigle, Russ Housley, and Ted Hardie for providing feedback on questions arising during work on early versions of this document.

10. Normative References

Author's Address