summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8128.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8128.txt')
-rw-r--r--doc/rfc/rfc8128.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc8128.txt b/doc/rfc/rfc8128.txt
new file mode 100644
index 0000000..20f168b
--- /dev/null
+++ b/doc/rfc/rfc8128.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB) C. Morgan
+Request for Comments: 8128 AMS
+Category: Informational March 2017
+ISSN: 2070-1721
+
+
+ IETF Appointment Procedures for
+ the ICANN Root Zone Evolution Review Committee
+
+Abstract
+
+ This memo outlines the process by which the IETF makes an appointment
+ to the ICANN Root Zone Evolution Review Committee (RZERC).
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Architecture Board (IAB)
+ and represents information that the IAB has deemed valuable to
+ provide for permanent record. It represents the consensus of the
+ Internet Architecture Board (IAB). Documents approved for
+ publication by the IAB are not a candidate for any level of Internet
+ Standard; see 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
+ http://www.rfc-editor.org/info/rfc8128.
+
+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.
+
+
+
+
+
+
+
+
+
+
+Morgan Informational [Page 1]
+
+RFC 8128 RZERC March 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Desirable Qualifications for an IETF-Nominated RZERC Member . 2
+ 3. IETF-Nominated RZERC Member Selection Process . . . . . . . . 3
+ 3.1. Term Length . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.2. Nominations and Eligibility . . . . . . . . . . . . . . . 3
+ 3.3. Selection . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.4. Timeframe . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.5. Mid-term Vacancies . . . . . . . . . . . . . . . . . . . 4
+ 3.5.1. Interim Appointment Process . . . . . . . . . . . . . 4
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
+ 6. Normative References . . . . . . . . . . . . . . . . . . . . 5
+ IAB Members at the Time of Approval . . . . . . . . . . . . . . . 5
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
+
+1. Introduction
+
+ The ICANN Root Zone Evolution Review Committee (RZERC) reviews
+ proposed architectural changes to the content of the DNS root zone,
+ the systems including both hardware and software components used in
+ executing changes to the DNS root zone, and the mechanisms used for
+ distribution of the DNS root zone, and makes recommendations to the
+ ICANN Board. As stipulated in [RZERC-Charter], the IETF is called
+ upon to name its delegate to the committee.
+
+ The IAB will select one person for a one-year term. This appointment
+ can be renewed for up to three additional one-year terms. This memo
+ outlines the process by which the IETF makes that selection.
+
+ In brief, this document describes the timeframe and procedures for
+ the IAB to solicit public input and make a selection for the open
+ position.
+
+2. Desirable Qualifications for an IETF-Nominated RZERC Member
+
+ Candidates for the RZERC should have a demonstrable involvement in
+ the IETF with a particular focus on active participation in IETF
+ Working Groups.
+
+ The candidate is expected to possess clearly demonstrated technical
+ competence in Internet technology relating to the DNS root zone and
+ be able to articulate those technology issues such that the ICANN
+ Board can be provided with sound technical perspectives. The
+ candidate is also expected to be able to understand the respective
+ roles and responsibilities of the IETF and ICANN and be able to
+ articulate these roles within both organizational communities.
+
+
+
+Morgan Informational [Page 2]
+
+RFC 8128 RZERC March 2017
+
+
+ The candidate will be a representative or a delegate of the IETF. It
+ is expected that the candidate would be able to call on experts in
+ the IETF community as required, to ensure that the ICANN Board
+ receives the highest-quality technical advice available.
+
+3. IETF-Nominated RZERC Member Selection Process
+
+3.1. Term Length
+
+ The IETF appointment to the RZERC will serve a one-year term. This
+ appointment can be renewed for up to three additional one-year terms.
+
+ In cases when the incumbent is willing to serve for an additional
+ term and has not yet exceeded the term limits described above, the
+ IAB may ask the IETF community for feedback on the incumbent to find
+ out whether it is necessary to run a full selection process. If the
+ IAB determines that it is not necessary to run a full selection
+ process, the incumbent may be reappointed by the IAB for another
+ year.
+
+3.2. Nominations and Eligibility
+
+ Except in cases when the IAB has decided to reappoint the incumbent,
+ each year, the IAB will make a public call for nominations on the
+ IETF Announce <ietf-announce@ietf.org> mailing list. The public call
+ will specify the manner by which nominations will be accepted and the
+ means by which the list of nominees will be published. The call for
+ nominations will also include the expected workload for the position,
+ as provided by the current IETF-appointed RZERC member.
+
+ Self-nominations are permitted. Along with the name and contact
+ information for each candidate, details about the candidate's
+ background and qualifications for the position should be attached to
+ the nomination. All IETF participants are eligible for nomination.
+ While IETF NomCom members, IAB members, IAOC members, and IESG
+ members are eligible, the IAB will balance time constraints and
+ potential conflicts of interest from those members in its
+ consideration of nominees.
+
+ IAB members who accept a nomination will recuse themselves from
+ selection discussions.
+
+
+
+
+
+
+
+
+
+
+Morgan Informational [Page 3]
+
+RFC 8128 RZERC March 2017
+
+
+3.3. Selection
+
+ The IAB will publish the list of nominated persons, review the
+ material, and make a selection.
+
+ The IAB will consider potential conflicts with a position on the
+ ICANN RZERC and any other ICANN committees supported by nominated
+ candidates.
+
+3.4. Timeframe
+
+ The IAB expects to seat new RZERC members in time for ICANN's annual
+ general meeting in Q4 of each year. Basic timeframe requirements for
+ the IETF process are as follows:
+
+ o 4-6 weeks for solicitation of nominations or review of incumbent
+
+ o 4-6 weeks for review of nominees, deliberation, and selection
+
+ In Q2 of each year, the IAB will announce the specific dates for the
+ RZERC selection process for that year (taking into account the
+ particular dates of IETF and ICANN meetings, etc.) following the
+ guidelines above.
+
+3.5. Mid-term Vacancies
+
+ This document describes the process for the general, annual
+ appointment of RZERC members to fill the seats of members whose terms
+ are ending. However, if an IETF-appointed member of the RZERC is
+ unable to serve his or her full term, the IAB may, at its discretion,
+ immediately select a replacement to serve the remainder of the term
+ using the interim process defined in Section 3.5.1. If the IAB does
+ not invoke the interim process, the next annual selection process
+ will fill the vacancy.
+
+3.5.1. Interim Appointment Process
+
+ If the IAB elects to fill the mid-term vacancy before the next annual
+ selection, a separate timeline will be announced and the rest of the
+ process described in this document will be followed.
+
+4. IANA Considerations
+
+ This document does not require any IANA actions.
+
+
+
+
+
+
+
+Morgan Informational [Page 4]
+
+RFC 8128 RZERC March 2017
+
+
+5. Security Considerations
+
+ This document does not describe any technical protocols and has no
+ implications for network security.
+
+6. Normative References
+
+ [RZERC-Charter]
+ ICANN, "Root Zone Evolution Review Committee (RZERC)
+ Charter", August 2016,
+ <https://www.icann.org/en/system/files/files/
+ revised-rzerc-charter-08aug16-en.pdf>.
+
+IAB Members at the Time of Approval
+
+ Jari Arkko
+ Ralph Droms
+ Ted Hardie
+ Joe Hildebrand
+ Russ Housley
+ Lee Howard
+ Erik Nordmark
+ Robert Sparks
+ Andrew Sullivan
+ Dave Thaler
+ Martin Thomson
+ Brian Trammell
+ Suzanne Woolf
+
+Author's Address
+
+ Cindy Morgan
+ AMS
+
+ Email: cmorgan@amsl.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morgan Informational [Page 5]
+