doc: Add RFC documents

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]
+