RFC 8128

IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee

πŸ“… published March 2017, from ietf

Internet Architecture Board (IAB) πŸ’–

Title block vibes πŸŽ€: This doc is RFC 8128 ("IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee") by C. Morgan (AMS), published March 2017. Category is Informational 🌸, and the ISSN is 2070-1721. It doesn't obsolete or update anything, so no drama there ✨.


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 πŸ¦‹

Okay so this one is not an Internet Standards Track spec, it's just published for info πŸ“š. It's a product of the Internet Architecture Board (IAB) and it basically represents what the IAB decided was valuable enough to keep on the permanent record. It reflects IAB consensus 🫢. Docs the IAB approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 7841 πŸ™ˆ.

Want the current status, errata, or a place to send feedback? Check http://www.rfc-editor.org/info/rfc8128 🧚.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Read those carefully, bestie, because they spell out your rights and restrictions πŸ’œ.

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 (hardware and software both!) used to make changes to the DNS root zone, and the mechanisms used to distribute the DNS root zone. It then makes recommendations to the ICANN Board πŸ‘‘. As stipulated in [RZERC-Charter], the IETF is called on 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 lays out how the IETF makes that selection πŸŽ€.

In short, this document covers the timeframe and procedures the IAB follows 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 demonstrable involvement in the IETF, especially active participation in IETF Working Groups 🫢.

The candidate is expected to have clearly demonstrated technical competence in Internet technology relating to the DNS root zone, and to be able to explain those technical issues so the ICANN Board gets sound technical perspectives 🧠. They're also expected to understand the respective roles and responsibilities of the IETF and ICANN, and to be able to explain those roles to both organizational communities πŸ¦‹.

The candidate will be a representative or delegate of the IETF. They're expected to be able to call on experts in the IETF community as needed, so the ICANN Board gets the highest-quality technical advice available πŸ˜­πŸ™Œ.

3. IETF-Nominated RZERC Member Selection Process 🧚

3.1. Term Length πŸ“

The IETF appointment to the RZERC serves a one-year term. This appointment can be renewed for up to three additional one-year terms πŸ”₯.

If the incumbent is willing to serve another term and hasn't yet hit the term limits above, the IAB may ask the IETF community for feedback on the incumbent to figure out whether a full selection process is actually necessary. If the IAB decides it isn't, the incumbent may be reappointed by the IAB for another year πŸ’œ.

3.2. Nominations and Eligibility πŸ“£

Except 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 call will specify how nominations are accepted and how the list of nominees gets published. It 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 info for each candidate, details about their background and qualifications 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 too, the IAB will balance time constraints and potential conflicts of interest from those members when considering nominees βš–οΈ.

IAB members who accept a nomination will recuse themselves from selection discussions πŸ™ˆ.

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 with 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. The basic timeframe requirements for the IETF process are:

  • 4-6 weeks for solicitation of nominations or review of incumbent
  • 4-6 weeks for review of nominees, deliberation, and selection

In Q2 of each year, the IAB will announce the specific dates for that year's RZERC selection process (taking into account IETF and ICANN meeting dates, 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 seats whose terms are ending. However, if an IETF-appointed RZERC member can't serve the full term, the IAB may, at its discretion, immediately select a replacement to serve the rest of the term using the interim process defined in Section 3.5.1. If the IAB doesn't 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 πŸ¦‹.

5. Security Considerations πŸ”

This document does not describe any technical protocols and has no implications for network security. Honestly, no security drama here, bestie 😌✨.

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 πŸ’Œ

πŸ“¦ where this page comes from