summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8318.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8318.txt')
-rw-r--r--doc/rfc/rfc8318.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc8318.txt b/doc/rfc/rfc8318.txt
new file mode 100644
index 0000000..a74300d
--- /dev/null
+++ b/doc/rfc/rfc8318.txt
@@ -0,0 +1,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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+