doc: Add RFC documents

1 files changed, 2075 insertions, 0 deletions

diff --git a/doc/rfc/rfc7979.txt b/doc/rfc/rfc7979.txt
new file mode 100644
index 0000000..06b916c
--- /dev/null
+++ b/doc/rfc/rfc7979.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      E. Lear, Ed.
+Request for Comments: 7979                               R. Housley, Ed.
+Category: Informational                                      August 2016
+ISSN: 2070-1721
+
+
+  Response to the IANA Stewardship Transition Coordination Group (ICG)
+    Request for Proposals on the IANA Protocol Parameters Registries
+
+Abstract
+
+   The U.S. National Telecommunications and Information Administration
+   (NTIA) solicited a request from the Internet Corporation for Assigned
+   Names and Numbers (ICANN) to propose how the NTIA should end its
+   oversight of the Internet Assigned Numbers Authority (IANA)
+   functions.  After broad consultations, ICANN in turn created the IANA
+   Stewardship Transition Coordination Group.  That group solicited
+   proposals for the three major IANA functions: names, numbers, and
+   protocol parameters.  This document contains the IETF response to
+   that solicitation for protocol parameters.  It was included in an
+   aggregate response to the NTIA alongside those for names and
+   numbering resources that are being developed by their respective
+   operational communities.  A reference to that response may be found
+   in the introduction, and additional correspondence is included in the
+   Appendix.
+
+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 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).  Not all documents
+   approved by the IESG are 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/rfc7979.
+
+
+
+
+
+
+
+
+
+
+Lear & Housley                Informational                     [Page 1]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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.  IETF Introduction . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  The Formal RFP Response . . . . . . . . . . . . . . . . . . .   4
+   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
+   5.  IAB Note  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
+   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  22
+   Appendix A.  The Charter of the IANA Stewardship Coordination
+                Group (ICG)  . . . . . . . . . . . . . . . . . . . .  25
+   Appendix B.  IANA Stewardship Transition Coordination Group
+                Request for Proposals  . . . . . . . . . . . . . . .  28
+   Appendix C.  Correspondence of the IETF to the ICG  . . . . . . .  34
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Housley                Informational                     [Page 2]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+1.  IETF Introduction
+
+   In March of 2014, the U.S. National Telecommunications and
+   Information Administration (NTIA) announced its intent to transition
+   oversight of Internet Assigned Numbers Authority (IANA) functions
+   [NTIA-Announce].  In that announcement, NTIA asked the Internet
+   Corporation for Assigned Names and Numbers (ICANN) to establish a
+   process to deliver a proposal for transition.  As part of that
+   process, the IANA Stewardship Transition Coordination Group (ICG) was
+   formed.  The charter for the ICG can be found in Appendix A.  The ICG
+   in turn solicited proposals regarding post-transition arrangements
+   from the names, numbers, and protocol parameters communities in order
+   to put forth a proposal to the NTIA.  The final request for proposal
+   (RFP) can be found in Appendix B.  The response from the ICG to the
+   NTIA may be found at [ICG-Response].
+
+   While there are interactions between all of the IANA functions and
+   IETF standards, this document specifically addresses the protocol
+   parameters registries function.  Section 1 (this section) contains an
+   introduction that is sourced solely within the IETF.  Section 2
+   contains the questionnaire that was written by the ICG and a formal
+   response by the IETF.  We have quoted questions from that
+   questionnaire with ">>> ", and we have prefaced answers to questions
+   being asked with "IETF Response:".  Note that there are small changes
+   to the questions asked in order to match the RFC format.
+
+   We note that the following text was stated as a footnote in the
+   original RFP:
+
+             In this RFP, "IANA" refers to the functions currently
+         specified in the agreement between NTIA and ICANN
+         [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as
+         well as any other functions traditionally performed by the IANA
+         functions operator. SAC-067
+         [https://www.icann.org/en/system/files/files/sac-067-en.pdf]
+         provides one description of the many different meanings of the
+         term "IANA" and may be useful reading in addition to the
+         documents constituting the agreement itself.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Housley                Informational                     [Page 3]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+2.  The Formal RFP Response
+
+   The entire Request for Proposals, including introduction, can be
+   found in Appendix B.
+
+   >>>
+   >>> 0. Proposal Type
+   >>>
+   >>> Identify which category of the IANA functions this
+   >>> submission proposes to address:
+   >>>
+
+   IETF Response:
+                     Protocol Parameters
+
+   This response states the existing practice of the IETF, and also
+   represents the views of the Internet Architecture Board and the IETF.
+
+   >>>
+   >>> I. Description of Community's Use of IANA Functions
+   >>>
+   >>> This section should list the specific, distinct IANA services
+   >>> or activities your community relies on. For each IANA service
+   >>> or activity on which your community relies, please provide the
+   >>> following:
+   >>> A description of the service or activity.
+   >>>
+
+   IETF Response:
+
+   Many IETF protocols make use of commonly defined protocol parameters.
+   These parameters are used by implementers, who are the primary users
+   of the IETF standards and other documents.  To ensure consistent
+   interpretation of these parameter values by independent
+   implementations, and to promote universal interoperability, these
+   IETF protocol specifications define and require globally available
+   registries containing the parameter values and a pointer to any
+   associated documentation.  The IETF uses the IANA protocol parameters
+   registries to store this information in a public location.  The IETF
+   community presently accesses the protocol parameter registries via
+   references based on the iana.org domain name, and makes use of the
+   term "IANA" in the protocol parameter registry processes [RFC5226].
+
+   ICANN currently operates the .ARPA top level domain on behalf of the
+   Internet Architecture Board (IAB).  This zone is used for certain
+   Internet infrastructure services that are delegated beneath it.  The
+   IETF considers .ARPA part of the protocol parameters registries for
+   purposes of this response.
+
+
+
+Lear & Housley                Informational                     [Page 4]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   >>>
+   >>> A description of the customer(s) of the service or activity.
+   >>>
+
+   IETF Response:
+
+   The IANA protocol parameters registries operator maintains the
+   protocol parameters registries for the IETF in conformance with all
+   relevant IETF policies, in accordance with the Memorandum of
+   Understanding [RFC2860] and associated supplemental agreements that
+   include service level agreements (SLAs) established between the IETF
+   and ICANN [MOUSUP].
+
+   The IETF is a global organization that produces voluntary standards,
+   whose mission is to produce high quality, relevant technical and
+   engineering documents that influence the way people design, use, and
+   manage the Internet in such a way as to make the Internet work better
+   [RFC3935].  IETF standards are published in the RFC series.  The IETF
+   is responsible for the key standards that are used on the Internet
+   today, including IP, TCP, DNS, BGP, and HTTP, to name but a few.
+
+   The IETF operates in an open and transparent manner [RFC6852].  The
+   processes that govern the IETF are also published in the RFC series.
+   The Internet Standards Process is documented in [RFC2026].  That
+   document explains not only how standards are developed, but also how
+   disputes about decisions are resolved.  RFC 2026 has been amended a
+   number of times [BCP9info].  The standards process can be amended in
+   the same manner that standards are approved.  That is, someone
+   proposes a change by submitting a temporary document known as an
+   Internet-Draft, the community discusses it, and if rough consensus
+   can be found the change is approved by the Internet Engineering
+   Steering Group (IESG), who also have day-to-day responsibility for
+   declaring IETF consensus on technical decisions, including those that
+   affect the IANA protocol parameters registries.  Anyone may propose a
+   change during a Last Call, and anyone may participate in the
+   community discussion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Housley                Informational                     [Page 5]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   >>>
+   >>> What registries are involved in providing the service or
+   >>> activity.
+   >>>
+
+   IETF Response:
+
+   The protocol parameters registries are the product of IETF work.
+   These also include the top-level registry for the entire IP address
+   space and some of its sub-registries, autonomous system number space,
+   and a number of special use registries with regard to domain names.
+   For more detail please refer to the documentation in the "overlaps or
+   interdependencies" section.
+
+   Administration of the protocol parameters registries is the service
+   that is provided to the IETF.
+
+   >>>
+   >>> A description of any overlaps or interdependencies between your
+   >>> IANA requirements and the functions required by other customer
+   >>> communities.
+   >>>
+
+   IETF Response:
+
+   In this context, the IETF considers "overlap" to be where there is in
+   some way shared responsibility for a single registry across multiple
+   organizations.  In this sense, there is no overlap between
+   organizations because responsibility for each registry is carefully
+   delineated.  There are, however, points of interaction between other
+   organizations, and a few cases where the IETF may further define the
+   scope of a registry for technical purposes.  This is the case with
+   both names and numbers, as described in the paragraphs below.  In all
+   cases, the IETF coordinates with the appropriate organizations.
+
+   It is important to note that the IETF does not have formal
+   membership.  The term "the IETF" includes anyone who wishes to
+   participate in the IETF, and IETF participants may also be members of
+   other communities.  Staff and participants from ICANN and the
+   Regional Internet Registries (RIRs) regularly participate in IETF
+   activities.
+
+   o  The IETF has specified a number of special use registries with
+      regard to domain names.  These registries require coordination
+      with ICANN as the policy authority for the DNS root, including
+      community groups that are responsible for ICANN policy on domain
+      names such as the Generic Names Supporting Organization (GNSO) and
+      the Country Code Names Supporting Organization (ccNSO).  There are
+
+
+
+Lear & Housley                Informational                     [Page 6]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+      already mechanisms in place to perform this coordination, and the
+      capacity to modify those mechanisms to meet new conditions as they
+      might arise.  [RFC6761]
+
+   o  The IETF specifies the DNS protocol.  From time to time there have
+      been and will be updates to that protocol.  As we make changes we
+      will broadly consult the operational community about the impact of
+      those changes, as we have done in the past.
+
+   o  The IETF specifies minimum requirements for root servers.
+      [RFC2870] Those requirements are currently under review, in
+      consultations with the root server community.
+
+   o  The routing architecture has evolved over time, and is expected to
+      continue to do so.  Such evolution may have an impact on
+      appropriate IP address allocation strategies.  If and when that
+      happens, the IETF will consult and coordinate with the RIR
+      community, as we have done in the past.
+
+   o  The IETF is responsible for policy relating to the entire IP
+      address space and AS number space.  Through the IANA protocol
+      parameters registries, the IETF delegates unicast IP address and
+      AS number ranges to the RIRs [RFC7020],[RFC7249].  Special address
+      allocation, such as multicast and anycast addresses, often require
+      coordination.  Another example of IP addresses that are not
+      administered by the RIR system is Unique Local Addresses (ULAs)
+      [RFC4193], where local networks employ a prefix that is not
+      intended to be routed on the public Internet.  New special address
+      allocations are added, from time to time, related to the evolution
+      of the standards.  In all cases, these special assignments are
+      listed in the IANA protocol paramters registries.
+
+   o  The IETF maintains sub-registries for special IPv4 and IPv6
+      assignments.  These are specified in [RFC3307], [RFC5771], and
+      [RFC6890].  The IETF coordinates such assignments with the RIRs.
+
+   o  Changes to IETF standards may have impact on operations of RIRs
+      and service providers.  A recent example is the extensions to BGP
+      to carry the Autonomous System numbers as four-octet entities
+      [RFC6793].  It is important to note that this change occurred out
+      of operational necessity, and it demonstrated strong alignment
+      between the RIRs and the IETF.
+
+
+
+
+
+
+
+
+
+Lear & Housley                Informational                     [Page 7]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   >>> II.  Existing, Pre-Transition Arrangements
+
+   >>>
+   >>> This section should describe how existing IANA-related
+   >>> arrangements work, prior to the transition.
+   >>>
+   >>> A. Policy Sources
+   >>>
+   >>>
+   >>> This section should identify the specific source(s) of policy
+   >>> which must be followed by the IANA functions operator in its
+   >>> conduct of the services or activities described above.  If there
+   >>> are distinct sources of policy or policy development for
+   >>> different IANA activities, then please describe these
+   >>> separately. For each source of policy or policy development,
+   >>> please provide the following:
+   >>>
+   >>> Which IANA service or activity (identified in Section I) is
+   >>> affected.
+   >>>
+
+   IETF Response:
+
+   The protocol parameters registries.
+
+   >>>
+   >>> A description of how policy is developed and established and
+   >>> who is involved in policy development and establishment.
+   >>>
+
+   IETF Response:
+
+   Policy for overall management of the protocol parameters registries
+   is stated in [RFC6220] and [RFC5226].  The first of these documents
+   explains the model for how the registries are to be operated, how
+   policy is set, and how oversight takes place.  RFC 5226 specifies the
+   policies that specification writers may employ when they define new
+   protocol registries in the "IANA Considerations" section of each
+   specification.  All policies at the IETF begin with a proposal in the
+   form of an Internet-Draft.  Anyone may submit such a proposal.  If
+   there is sufficient interest, a working group whose scope includes
+   the proposed work may choose to adopt it, the IESG may choose to
+   create a working group, or an Area Director may choose to sponsor the
+   draft.  In any case, anyone may comment on the proposal as it
+   progresses.  A proposal cannot be passed by the IESG unless it enjoys
+   sufficient community support as to indicate rough consensus
+   [RFC7282].  In each case, a "Last Call" is made so that there is
+   notice of any proposed change to a policy or process.  Anyone may
+
+
+
+Lear & Housley                Informational                     [Page 8]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   comment during a Last Call.  For example, this process is currently
+   being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis].
+
+   >>>
+   >>> A description of how disputes about policy are resolved.
+   >>>
+
+   IETF Response:
+
+   Most disputes are handled at the lowest level through the working
+   group and rough consensus processes.  Should anyone disagree with any
+   action, Section 6.5 of [RFC2026] specifies a multi-level conflict
+   resolution and appeals process that includes the responsible Area
+   Director, the IESG, and the IAB.  Should appeals be upheld, an
+   appropriate remedy is applied.  In the case where someone claims that
+   the procedures themselves are insufficient or inadequate in some way
+   to address a circumstance, one may appeal an IAB decision to the
+   Internet Society Board of Trustees.
+
+   >>>
+   >>> References to documentation of policy development and dispute
+   >>> resolution processes.
+   >>>
+
+   IETF Response:
+
+   As mentioned above, [RFC2026] Section 6.5 specifies a conflict
+   resolution and appeals process.  [RFC2418] specifies working group
+   procedures.  Note that both of these documents have been amended in
+   later RFCs as indicated in the [RFC-INDEX].
+
+   >>>
+   >>> B. Oversight and Accountability
+   >>>
+   >>> This section should describe all the ways in which oversight is
+   >>> conducted over IANA functions operator's provision of the
+   >>> services and activities listed in Section I and all the ways in
+   >>> which IANA functions operator is currently held accountable for
+   >>> the provision of those services. For each oversight or
+   >>> accountability mechanism, please provide as many of the
+   >>> following as are applicable:
+   >>>
+   >>> Which IANA service or activity (identified in Section I) is
+   >>> affected.
+   >>>
+
+
+
+
+
+
+Lear & Housley                Informational                     [Page 9]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   IETF Response:
+
+   The protocol parameters registries.
+
+   >>>
+   >>> If not all policy sources identified in Section II.A are
+   >>> affected, identify which ones are affected.
+   >>>
+
+   IETF Response:
+
+   All policy sources relating to the protocol parameters registry are
+   affected.
+
+   >>>
+   >>> A description of the entity or entities that provide oversight
+   >>> or perform accountability functions, including how individuals
+   >>> are selected or removed from participation in those entities.
+   >>>
+
+   IETF Response:
+
+   The Internet Architecture Board (IAB) is an oversight body of the
+   IETF whose responsibilities include, among other things, confirming
+   appointment of IESG members, managing appeals as discussed above,
+   management of certain domains, including .ARPA [RFC3172], and general
+   architectural guidance to the broader community.  The IAB must
+   approve the appointment of an organization to act as IANA operator on
+   behalf of the IETF.  The IAB is also responsible for establishing
+   liaison relationships with other organizations on behalf of the IETF.
+   The IAB's charter is to be found in [RFC2850].
+
+   The IAB members are selected and may be recalled through a Nominating
+   Committee (NOMCOM) process, which is described in [RFC3777] and its
+   updates.  This process provides for selection of active members of
+   the community who themselves agree upon a slate of candidates.  The
+   active members are chosen randomly from volunteers with a history of
+   participation in the IETF, with limits regarding having too many
+   active members with the same affiliation.  The selection of the
+   active members is performed in a manner that makes it possible for
+   anyone to verify that the correct procedure was followed.  The slate
+   of candidates selected by the active members are sent to the Internet
+   Society Board of Trustees for confirmation.  In general, members are
+   appointed for terms of two years.  The IAB selects its own chair.
+
+   The IAB provides oversight of the protocol parameters registries of
+   the IETF, and is responsible for selecting appropriate operator(s)
+   and related per-registry arrangements.  Especially when relationships
+
+
+
+Lear & Housley                Informational                    [Page 10]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   among protocols call for it, registries are at times operated by, or
+   in conjunction with, other bodies.  Unless the IAB or IETF has
+   concluded that special treatment is needed, the operator for
+   registries is currently ICANN.
+
+   >>>
+   >>> A description of the mechanism (e.g., contract, reporting
+   >>> scheme, auditing scheme, etc.). This should include a
+   >>> description of the consequences of the IANA functions operator
+   >>> not meeting the standards established by the mechanism, the
+   >>> extent to which the output of the mechanism is transparent and
+   >>> the terms under which the mechanism may change.
+   >>>
+
+   IETF Response:
+
+   A memorandum of understanding (MoU) between ICANN and the IETF
+   community has been in place since 2000.  It can be found in
+   [RFC2860].  The MoU defines the work to be carried out by the IANA
+   functions operator for the IETF and the Internet Research Task Force
+   (IRTF), a peer organization to the IETF that focuses on
+   research.[RFC2014] Each year a service level agreement is negotiated
+   that supplements the MoU.
+
+   Day-to-day administration and contract management is the
+   responsibility of the IETF Administrative Director (IAD).  The IETF
+   Administrative Oversight Committee (IAOC) oversees the IAD.  The
+   members of the IAOC are also the trustees of the IETF Trust, whose
+   main purpose is to hold certain intellectual property for the benefit
+   of the IETF as a whole.  IAOC members are appointed by the Internet
+   Society Board of Trustees, the IAB, the IESG, and the NOMCOM
+   [RFC4071].  The IAOC works with the IANA functions operator to
+   establish annual IANA performance metrics [METRICS] and operational
+   procedures, and the resulting document is adopted as an supplement to
+   the MoU each year [MOUSUP].  Starting from 2014, in accordance with
+   these supplements, an annual audit is performed to ensure that
+   protocol parameter requests are being processed according to the
+   established policies.  The conclusions of this audit will be
+   available for anyone in the world to review.
+
+   To date there have been no unresolvable disputes or issues between
+   the IETF and the current IANA functions operator.  [RFC2860]
+   specifies that should a technical dispute arise, "the IANA shall seek
+   and follow technical guidance exclusively from the IESG."  In the
+   unlikely event that a more difficult situation should arise, the IAOC
+   and the IAB would engage ICANN management to address the matter.  The
+   MoU also provides an option for either party to terminate the
+   arrangement with six months notice.  Obviously such action would only
+
+
+
+Lear & Housley                Informational                    [Page 11]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   be undertaken after serious consideration.  In that case a new IANA
+   functions operator would be selected, and a new agreement with that
+   operator would be established.
+
+   >>>
+   >>>  Jurisdiction(s) in which the mechanism applies and the legal
+   >>>  basis on which the mechanism rests.
+   >>>
+
+   IETF Response
+
+   This mechanism is global in nature.  The current agreement does not
+   specify a jurisdiction.
+
+   >>>III.  Proposed Post-Transition Oversight and Accountability
+   >>>Arrangements
+
+   >>>
+   >>> This section should describe what changes your community is
+   >>> proposing to the arrangements listed in Section II.B in light of
+   >>> the transition. If your community is proposing to replace one or
+   >>> more existing arrangements with new arrangements, that
+   >>> replacement should be explained and all of the elements listed
+   >>> in Section II.B should be described for the new
+   >>> arrangements. Your community should provide its rationale and
+   >>> justification for the new arrangements.
+   >>>
+   >>> If your community's proposal carries any implications for
+   >>> existing policy arrangements described in Section II.A, those
+   >>> implications should be described here.
+   >>>
+   >>> If your community is not proposing changes to arrangements
+   >>> listed in Section II.B, the rationale and justification for that
+   >>> choice should be provided here.
+   >>>
+
+   IETF Response:
+
+   No new organizations or structures are required.  Over the years
+   since the creation of ICANN, the IETF, ICANN, and IAB have together
+   created a system of agreements, policies, and oversight mechanisms
+   that already cover what is needed.  This system has worked well
+   without any operational involvement from the NTIA.
+
+   IANA protocol parameters registry updates will continue to function
+   day-to-day, as they have been doing for the last decade or more.  The
+   IETF community is very satisfied with the current arrangement with
+
+
+
+
+Lear & Housley                Informational                    [Page 12]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   ICANN.  RFC 2860 remains in force and has served the IETF community
+   very well.  RFC 6220 has laid out an appropriate service description
+   and requirements.
+
+   However in the absence of the NTIA contract a few new arrangements
+   may be needed in order to ensure the IETF community's expectations
+   are met.  Those expectations are the following:
+
+   o  The protocol parameters registries are in the public domain.  It
+      is the preference of the IETF community that all relevant parties
+      acknowledge that fact as part of the transition.
+
+   o  It is possible in the future that the operation of the protocol
+      parameters registries may be transitioned from ICANN to subsequent
+      operator(s).  It is the preference of the IETF community that, as
+      part of the NTIA transition, ICANN acknowledge that it will carry
+      out the obligations established under C.7.3 and I.61 of the
+      current IANA functions contract between ICANN and the NTIA
+      [NTIA-Contract] to achieve a smooth transition to subsequent
+      operator(s), should the need arise.  Furthermore, in the event of
+      a transition it is the expectation of the IETF community that
+      ICANN, the IETF, and subsequent operator(s) will work together to
+      minimize disruption in the use the protocol parameters registries
+      or other resources currently located at iana.org.
+
+   In developing our response we have been mindful of the following
+   points that the IETF community has discussed over the last year
+   [ProtoParamEvo14] that have led to the following guiding principles
+   for IAB efforts that impact IANA protocol parameter registries.
+   These principles must be taken together; their order is not
+   significant.
+
+   1.  The IETF protocol parameters registries function has been and
+   continues to be capably provided by the Internet technical community.
+
+   The strength and stability of the function and its foundation within
+   the Internet technical community are both important given how
+   critical protocol parameters are to the proper functioning of IETF
+   protocols.
+
+   We think the structures that sustain the protocol parameters
+   registries function need to be strong enough that they can be offered
+   independently by the Internet technical community, without the need
+   for backing from external parties.  And we believe we largely are
+   there already, although the system can be strengthened further, and
+   continuous improvements are being made.
+
+
+
+
+
+Lear & Housley                Informational                    [Page 13]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   2.  The protocol parameters registries function requires openness,
+   transparency, and accountability.
+
+   Existing documentation of how the function is administered and
+   overseen is good [RFC2860], [RFC6220].  Further articulation and
+   clarity may be beneficial.  It is important that the whole Internet
+   community can understand how the function works, and that the
+   processes for registering parameters and holding those who oversee
+   the protocol parameters function accountable for following those
+   processes are understood by all interested parties.  We are committed
+   to making improvements here if necessary.
+
+   3.  Any contemplated changes to the protocol parameters registries
+   function should respect existing Internet community agreements.
+
+   The protocol parameters registries function is working well.  The
+   existing Memorandum of Understanding in RFC 2860 defines "the
+   technical work to be carried out by the Internet Assigned Numbers
+   Authority on behalf of the Internet Engineering Task Force and the
+   Internet Research Task Force."  Any modifications to the protocol
+   parameters registries function should be made using the IETF process
+   to update RFC 6220 and other relevant RFCs.  Put quite simply:
+   evolution, not revolution.
+
+   4.  The Internet architecture requires and receives capable service
+   by Internet registries.
+
+   The stability of the Internet depends on capable provision of not
+   just IETF protocol parameters, but IP numbers, domain names, and
+   other registries.  Furthermore, DNS and IPv4/IPv6 are IETF-defined
+   protocols.  Thus we expect the role of the IETF in standards
+   development, architectural guidance, and allocation of certain name/
+   number parameters to continue.  IP multicast addresses and special-
+   use DNS names are two examples where close coordination is needed.
+   The IETF will continue to coordinate with ICANN, the RIRs, and other
+   parties that are mutually invested in the continued smooth operation
+   of the Internet registries.  We fully understand the need to work
+   together.
+
+   5.  The IETF will continue management of the protocol parameter
+   registry function as an integral component of the IETF standards
+   process and the use of resulting protocols.
+
+   RFC 6220 specifies the role and function of the protocol parameters
+   registry, which is critical to IETF standards processes and IETF
+   protocols.  The IAB, on behalf of the IETF, has the responsibility to
+   define and manage the relationship with the protocol registry
+   operator role.  This responsibility includes the selection and
+
+
+
+Lear & Housley                Informational                    [Page 14]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   management of the protocol parameter registry operator, as well as
+   management of the parameter registration process and the guidelines
+   for parameter allocation.
+
+   6.  The protocol parameters registries are provided as a public
+   service.
+
+   Directions for the creation of protocol parameters registries and the
+   policies for subsequent additions and updates are specified in RFCs.
+   The protocol parameters registries are available to everyone, and
+   they are published in a form that allows their contents to be
+   included in other works without further permission.  These works
+   include, but are not limited to, implementations of Internet
+   protocols and their associated documentation.
+
+   These principles will guide the IAB, IAOC, and the rest of the IETF
+   community as they work with ICANN to establish future IANA
+   performance metrics and operational procedures.
+
+   >>> IV Transition Implications
+
+   >>>
+   >>> This section should describe what your community views as the
+   >>> implications of the changes it proposed in Section III. These
+   >>> implications may include some or all of the following, or other
+   >>> implications specific to your community:
+   >>>
+   >>>  o Description of operational requirements to achieve continuity
+   >>>    of service and possible new service integration throughout
+   >>>    the transition.
+   >>>  o Risks to operational continuity
+   >>>  o Description of any legal framework requirements in the
+   >>>    absence of the NTIA contract
+   >>>  o Description of how you have tested or evaluated the
+   >>>    workability of any new technical or operational methods
+   >>>    proposed in this document and how they compare to established
+   >>>    arrangements.
+   >>>
+
+   IETF Response:
+
+   No structural changes are required for the handling of protocol
+   parameters.  The principles listed above will guide IAB, IAOC, and
+   the rest of the IETF community as they work with ICANN to establish
+   future IANA performance metrics and operational procedures, as they
+   have in the past.
+
+
+
+
+
+Lear & Housley                Informational                    [Page 15]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   As no services are expected to change, no continuity issues are
+   anticipated, and there are no new technical or operational methods
+   proposed by the IETF to test.  The IETF leadership, ICANN, and the
+   RIRs maintain an ongoing informal dialog to spot any unforeseen
+   issues that might arise as a result of other changes.
+
+   What is necessary as part of transition is the completion of any
+   supplemental agreement(s) necessary to achieve the requirements
+   outlined in our response in Section III of this RFP.
+
+   >>>
+   >>> V.  NTIA Requirements
+   >>>
+   >>> Additionally, NTIA has established that the transition proposal
+   >>> must meet the following five requirements:
+   >>>
+   >>>     "Support and enhance the multistakeholder model;"
+   >>>
+
+   IETF Response:
+
+   Because the IETF is open to everyone, participation is open to all
+   stakeholders.  IETF processes outlined in Section I were used to
+   develop this proposal.  Those same processes have been and shall be
+   used to amend governance of the protocol parameters function.  As
+   mentioned previously, anyone may propose amendments to those
+   processes, and anyone may take part in the decision process.
+
+   >>>
+   >>> "Maintain the security, stability, and resiliency of the
+   >>>  Internet DNS;"
+   >>>
+
+   IETF Response:
+
+   No changes are proposed in this document that affect the security,
+   stability, and resiliency of the DNS.
+
+   >>>
+   >>> "Meet the needs and expectation of the global customers and
+   >>>  partners of the IANA services;"
+   >>>
+
+   IETF Response:
+
+   Implementers and their users from around the world make use of the
+   IETF standards and the associated IANA protocol parameters
+   registries.  The current IANA protocol parameters registries system
+
+
+
+Lear & Housley                Informational                    [Page 16]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   is meeting the needs of these global customers.  This proposal
+   continues to meet their needs by maintaining the existing processes
+   that have served them well in the past.
+
+   >>>
+
+   >>>
+   >>> "Maintain the openness of the Internet."
+   >>>
+
+   IETF Response:
+
+   This proposal maintains the existing open framework that allows
+   anyone to participate in the development of IETF standards, including
+   the IANA protocol parameters registries policies.  Further, an
+   implementer anywhere in the world has full access to the protocol
+   specification published in the RFC series and the protocol parameters
+   registries published at iana.org.  Those who require assignments in
+   the IANA protocol registries will continue to have their requests
+   satisfied, as specified by the existing policies for those
+   registries.
+
+   >>>
+   >>> "The proposal must not replace the NTIA role with a
+   >>>  government-led or an inter-governmental organization solution."
+   >>>
+
+   Policy oversight is performed by the IAB, which is neither a
+   government-led or an intergovernmental organization.
+
+   >>>
+   >>> VI.  Community Process
+   >>>
+   >>> This section should describe the process your community used for
+   >>> developing this proposal, including:
+   >>>
+   >>> o The steps that were taken to develop the proposal and to
+   >>>   determine consensus.
+   >>>
+
+   IETF Response:
+
+   The IESG established the IANAPLAN working group to develop this
+   response.  Anyone was welcome to join the discussion and participate
+   in the development of this response.  An open mailing list
+   (ianaplan@ietf.org) has been associated with the working group.  In
+   addition, IETF's IANA practices have been discussed in the broader
+   community, and all input has been welcome.  Normal IETF procedures
+
+
+
+Lear & Housley                Informational                    [Page 17]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   [RFC2026] [RFC2418] were used to determine rough consensus.  The
+   chairs of the working group reviewed open issues and, after an
+   internal working group last call, determined that all had been
+   satisfactorily addressed, and subsequently the IESG did a formal
+   IETF-wide Last Call followed by a formal review and determined that
+   the document had rough consensus.
+
+   >>>
+   >>> Links to announcements, agendas, mailing lists, consultations and
+   >>> meeting proceedings.
+   >>>
+
+   IETF Response:
+
+   The following list is not exhaustive, as there have been many open
+   discussions about this transition within the IETF community in the
+   past few months.
+
+   Creation of an open mailing list to discuss the transition:
+      http://mailarchive.ietf.org/arch/msg/ietf-announce/
+      Ztd2ed9U04qSxI-k9-Oj80jJLXc
+
+   Announcement of a public session on the transition:
+      http://mailarchive.ietf.org/arch/msg/ietf-announce/
+      M5zVmFFvTbtgVyMB_fjUSW4rJ0c
+
+   Announcement by the IESG of the intent to form a working group:
+      http://mailarchive.ietf.org/arch/msg/ietf-announce/
+      QsvU9qX98G2KqB18jy6UfhwKjXk
+
+   The working group discussion:
+      http://www.ietf.org/mail-archive/web/ianaplan/current/
+      maillist.html
+
+   2014-10-06 Interim Meeting Agenda, Minutes, and presentations:
+      http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/
+      proceedings.html
+
+   Working group last call:
+      http://mailarchive.ietf.org/arch/msg/ianaplan/
+      EGF9rfJxn5QpQnRXmS2QxYKYR8k
+
+   Agenda from IETF 91 IANAPLAN WG meeting:
+      http://www.ietf.org/proceedings/91/agenda/agenda-91-ianaplan
+
+   Minutes of IETF 91 IANAPLAN WG meeting:
+      http://www.ietf.org/proceedings/91/minutes/minutes-91-ianaplan
+
+
+
+
+Lear & Housley                Informational                    [Page 18]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   Shepherd write-up:
+      http://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/
+      shepherdwriteup/
+
+   IETF last call:
+      http://mailarchive.ietf.org/arch/msg/ietf-announce/
+      i5rx6PfjJCRax3Lu4qZ_38P8wBg
+
+   >>>
+   >>> An assessment of the level of consensus behind your community's
+   >>> proposal, including a description of areas of contention or
+   >>> disagreement.
+   >>>
+
+   IETF Response:
+
+   This document has attained rough consensus of the IETF Working Group
+   and of the IETF community as a whole, as judged first by the working
+   group chairs and then by the sponsoring Area Director, and then by
+   the IESG in accordance with [RFC2026] during the 18 December 2014
+   IESG telechat.  The IESG has approved the draft, pending insertion of
+   this answer in this section and the IAB approval note.  The IAB
+   approved a statement for inclusion in the document on 19 December
+   2014.
+
+   Over the course of the development of the document, several
+   suggestions were raised that did not enjoy sufficient support to be
+   included.  Two general areas of suggestion that generated much
+   discussion were
+
+   o  A suggestion for a stronger statement over what terms the IAOC
+      should negotiate.
+
+   o  A suggestion that "iana.org" and other associated marks be
+      transferred to the IETF trust.
+
+   At the end of the working group process, although there was not
+   unanimous support for the results, the working group chairs concluded
+   that rough consensus existed in the working group.  The document
+   shepherd's summary of the WG consensus for this document can be found
+   here:
+
+   https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/
+   shepherdwriteup/
+
+   During IETF last call, additional people voiced support for the
+   document.  There were several editorial comments that resulted in
+   changes, as well as some discussion of more substantial comments some
+
+
+
+Lear & Housley                Informational                    [Page 19]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   of which resulted in text changes.  There was some discussion of
+   comments already discussed earlier in the process, and but no new
+   objections were raised during the IETF last call.  A summary of the
+   last call comments can be found from here:
+
+   http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html
+
+   New draft versions were prepared that took into account all the
+   agreed changes from the last call.  The final version was then
+   approved by the IESG.
+
+3.  IANA Considerations
+
+   This memo is a response to a request for proposals.  No parameter
+   allocations or changes are sought.
+
+4.  Security Considerations
+
+   While the agreement, supplements, policies, and procedures around the
+   IANA function have shown strong resiliency, the IETF will continue to
+   work with all relevant parties to facilitate improvements while
+   maintaining availability of the IANA registries.
+
+5.  IAB Note
+
+   The IAB supports the response in this document.
+
+6.  Acknowledgments
+
+   This document describes processes that have been developed by many
+   members of the community over many years.  The initial version of
+   this document was developed collaboratively through both the IAB IANA
+   Strategy Program and the IETF IANAPLAN WG.  Particular thanks go to
+   Jari Arkko, Marc Blanchet, Brian Carpenter, Alissa Cooper, John
+   Curran, Leslie Daigle, Heather Flanagan, Christer Holmberg, John
+   Klensin, Barry Leiba, Milton Mueller, Andrei Robachevsky, Andrew
+   Sullivan, Dave Thaler, Greg Wood, and Suzanne Woolf.
+
+7.  References
+
+7.1.  Normative References
+
+   [BCP9info] "Information on "The Internet Standards Process --
+              Revision 3"", <http://www.rfc-editor.org/info/rfc2026>.
+
+   [METRICS]  IANA, "Performance Standards Metrics Report",
+              <http://www.iana.org/performance/metrics>.
+
+
+
+
+Lear & Housley                Informational                    [Page 20]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   [MOUSUP]   IAOC, "Supplements to RFC 2860 (the Memorandum of
+              Understanding between the IETF and ICANN)",
+              <http://iaoc.ietf.org/contracts.html>.
+
+   [NTIA-Announce]
+              NTIA, "NTIA Announces Intent to Transition Key Internet
+              Domain Name Functions", March 2014,
+              <http://www.ntia.doc.gov/press-release/2014/ntia-
+              announces-intent-transition-key-internet-domain-name-
+              functions>.
+
+   [NTIA-Contract]
+              NTIA, "The NTIA Contract with ICANN",
+              <http://www.ntia.doc.gov/files/ntia/publications/
+              sf_26_pg_1-2-final_award_and_sacs.pdf>.
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
+              <http://www.rfc-editor.org/info/rfc2026>.
+
+   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
+              Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
+              September 1998, <http://www.rfc-editor.org/info/rfc2418>.
+
+   [RFC2850]  Internet Architecture Board and B. Carpenter, Ed.,
+              "Charter of the Internet Architecture Board (IAB)",
+              BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000,
+              <http://www.rfc-editor.org/info/rfc2850>.
+
+   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
+              Understanding Concerning the Technical Work of the
+              Internet Assigned Numbers Authority", RFC 2860,
+              DOI 10.17487/RFC2860, June 2000,
+              <http://www.rfc-editor.org/info/rfc2860>.
+
+   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
+              Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
+              <http://www.rfc-editor.org/info/rfc3307>.
+
+   [RFC3777]  Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
+              and Recall Process: Operation of the Nominating and Recall
+              Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004,
+              <http://www.rfc-editor.org/info/rfc3777>.
+
+   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
+              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
+              <http://www.rfc-editor.org/info/rfc3935>.
+
+
+
+
+Lear & Housley                Informational                    [Page 21]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc4071>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
+              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
+              DOI 10.17487/RFC5771, March 2010,
+              <http://www.rfc-editor.org/info/rfc5771>.
+
+   [RFC6220]  McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed.,
+              Huston, G., Ed., and Internet Architecture Board,
+              "Defining the Role and Function of IETF Protocol Parameter
+              Registry Operators", RFC 6220, DOI 10.17487/RFC6220, April
+              2011, <http://www.rfc-editor.org/info/rfc6220>.
+
+   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
+              RFC 6761, DOI 10.17487/RFC6761, February 2013,
+              <http://www.rfc-editor.org/info/rfc6761>.
+
+   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
+              "Special-Purpose IP Address Registries", BCP 153,
+              RFC 6890, DOI 10.17487/RFC6890, April 2013,
+              <http://www.rfc-editor.org/info/rfc6890>.
+
+   [RFC7282]  Resnick, P., "On Consensus and Humming in the IETF",
+              RFC 7282, DOI 10.17487/RFC7282, June 2014,
+              <http://www.rfc-editor.org/info/rfc7282>.
+
+7.2.  Informative References
+
+   [I-D.leiba-cotton-iana-5226bis]
+              Cotton, M., Leiba, B., and D. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", Work in
+              Progress, draft-leiba-cotton-iana-5226bis-17, July 2016.
+
+
+
+
+
+
+
+
+
+
+
+Lear & Housley                Informational                    [Page 22]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   [ICG-Response]
+              IANA Stewardship Transition Coordination Group, "Proposal
+              to Transition the Stewardship of the Internet Assigned
+              Numbers Authority (IANA) Functions from the U.S. Commerce
+              Department's National Telecommunications and Information
+              Administration (NTIA) to the Global Multistakeholder
+              Community", 11 March 2016,
+              <https://www.icann.org/en/system/files/files/
+              iana-stewardship-transition-proposal-10mar16-en.pdf>.
+
+   [ProtoParamEvo14]
+              IAB Chair, "Subject: Re: [Internetgovtech] Guiding the
+              Evolution of the IANA Protocol Parameter Registries",
+              March 2014, <http://mailarchive.ietf.org/arch/msg/
+              internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k>.
+
+   [RFC-INDEX]
+              RFC Editor, "RFC Index",
+              <http://www.rfc-editor.org/rfc/rfc-index.txt>.
+
+   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
+              and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014,
+              October 1996, <http://www.rfc-editor.org/info/rfc2014>.
+
+   [RFC2870]  Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
+              Name Server Operational Requirements", RFC 2870,
+              DOI 10.17487/RFC2870, June 2000,
+              <http://www.rfc-editor.org/info/rfc2870>.
+
+   [RFC3172]  Huston, G., Ed., "Management Guidelines & Operational
+              Requirements for the Address and Routing Parameter Area
+              Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
+              September 2001, <http://www.rfc-editor.org/info/rfc3172>.
+
+   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
+              <http://www.rfc-editor.org/info/rfc4193>.
+
+   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
+              Autonomous System (AS) Number Space", RFC 6793,
+              DOI 10.17487/RFC6793, December 2012,
+              <http://www.rfc-editor.org/info/rfc6793>.
+
+   [RFC6852]  Housley, R., Mills, S., Jaffe, J., Aboba, B., and L.
+              St.Amour, "Affirmation of the Modern Paradigm for
+              Standards", RFC 6852, DOI 10.17487/RFC6852, January 2013,
+              <http://www.rfc-editor.org/info/rfc6852>.
+
+
+
+
+Lear & Housley                Informational                    [Page 23]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   [RFC7020]  Housley, R., Curran, J., Huston, G., and D. Conrad, "The
+              Internet Numbers Registry System", RFC 7020,
+              DOI 10.17487/RFC7020, August 2013,
+              <http://www.rfc-editor.org/info/rfc7020>.
+
+   [RFC7249]  Housley, R., "Internet Numbers Registries", RFC 7249,
+              DOI 10.17487/RFC7249, May 2014,
+              <http://www.rfc-editor.org/info/rfc7249>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Housley                Informational                    [Page 24]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+Appendix A.  The Charter of the IANA Stewardship Coordination Group
+             (ICG)
+
+   Charter for the IANA Stewardship Transition Coordination Group V.10
+
+   (August 27, 2014)
+
+   The IANA stewardship transition coordination group (ICG) has one
+   deliverable: a proposal to the U.S.  Commerce Department National
+   Telecommunications and Information Administration (NTIA) regarding
+   the transition of NTIA's stewardship of the IANA functions to the
+   global multi-stakeholder community.  The group will conduct itself
+   transparently, consult with a broad range of stakeholders, and ensure
+   that its proposals support the security and stability of the IANA
+   functions.
+
+   The group's mission is to coordinate the development of a proposal
+   among the communities affected by the IANA functions.  The IANA
+   functions are divided into three main categories: domain names,
+   number resources, and other protocol parameters.  The domain names
+   category falls further into the country code and generic domain name
+   sub-categories.  While there is some overlap among all of these
+   categories, each poses distinct organizational, operational and
+   technical issues, and each tends to have distinct communities of
+   interest and expertise.  For those reasons it is best to have work on
+   the three categories of IANA parameters proceed autonomously in
+   parallel and be based in the respective communities.
+
+   The IANA stewardship transition process is taking place alongside a
+   parallel and related process on enhancing ICANN accountability.
+   While maintaining the accountability of Internet identifier
+   governance is central to both processes, this group's scope is
+   focused on the arrangements required for the continuance of IANA
+   functions in an accountable and widely accepted manner after the
+   expiry of the NTIA-ICANN contract.  Nevertheless, the two processes
+   are interrelated and interdependent and should appropriately
+   coordinate their work.
+
+   The coordination group has four main tasks:
+   (i) Act as liaison to all interested parties, including the three
+       "operational communities" (i.e., those with direct operational
+       or service relationship with IANA; namely names, numbers,
+       protocol parameters). This task consists of:
+        a. Soliciting proposals from the operational communities
+        b. Soliciting the input of the broad group of communities
+           affected by the IANA functions
+   (ii) Assess the outputs of the three operational communities for
+        compatibility and interoperability
+
+
+
+Lear & Housley                Informational                    [Page 25]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   (iii) Assemble a complete proposal for the transition
+   (iv) Information sharing and public communication
+   Describing each in more detail:
+      (i) Liaison
+        a. Solicit proposals
+
+   The ICG expects a plan from the country code and generic name
+   communities (possibly a joint one), a plan from the numbers
+   community, and a plan from the protocol parameters community.
+   Members of the ICG will ensure that the communities from which they
+   are drawn are working on their part of the transition plans.  This
+   involves informing them of requirements and schedules, tracking
+   progress, and highlighting the results or remaining issues.  The role
+   of a coordination group member during this phase is to provide status
+   updates about the progress of his or her community in developing
+   their component, and to coordinate which community will develop a
+   transition proposal for each area of overlap (e.g., special-use
+   registry).
+
+   While working on the development of their proposals, the operational
+   communities are expected to address common requirements and issues
+   relating to the transition, in as far as they affect their parts of
+   the stewardship of IANA functions.
+
+   b.  Solicit broader input
+
+   The ICG is open for input and feedback from all interested parties.
+   While no set of formal requirements related to a transition proposal
+   will be requested outside the operational communities, everyone's
+   input is welcome across all topics.
+
+   The ICG expects that all interested parties get involved as early as
+   possible in the relevant community processes.  Input received
+   directly by the ICG may be referred to the relevant community
+   discussion.
+
+   The ICG members chosen from a particular community are the official
+   communication channel between the ICG and that community.
+
+   (ii) Assessment
+
+   When the group receives output from the communities it will discuss
+   and assess their compatibility and interoperability with the
+   proposals of the other communities.  Each proposal should be
+   submitted with a clear record of how consensus has been reached for
+   the proposal in the community, and provide an analysis that shows the
+
+
+
+
+
+Lear & Housley                Informational                    [Page 26]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   proposal is in practice workable.  The ICG should also compile the
+   input it has received beyond the operational communities, and review
+   the impacts of this input.
+
+   The ICG might at some point detect problems with the component
+   proposals.  At that point the role of the ICG is to communicate that
+   back to the relevant communities so that they (the relevant
+   communities) can address the issues.  It is not in the role of the
+   ICG to develop proposals or to select from among competing proposals.
+
+   (iii) Assembling and submitting a complete proposal
+
+   The assembly effort involves taking the proposals for the different
+   components and verifying that the whole fulfills the intended scope,
+   meets the intended criteria, that there are no missing parts, and
+   that the whole fits together.  The whole also needs to include
+   sufficient independent accountability mechanisms for running the IANA
+   function.  The ICG will then develop a draft final proposal that
+   achieves rough consensus within the ICG itself.  The ICG will then
+   put this proposal up for public comment involving a reasonable period
+   of time for reviewing the draft proposal, analyzing and preparing
+   supportive or critical comments.  The ICG will then review these
+   comments and determine whether modifications are required.  If no
+   modifications are needed, and the coordination group agrees, the
+   proposal will be submitted to NTIA.
+
+   If changes are required to fix problems or to achieve broader
+   support, the ICG will work with the operational communities in a
+   manner similar to what was described in task (ii) above.  Updates are
+   subject to the same verification, review, and consensus processes as
+   the initial proposals.  If, in the ICG's opinion, broad public
+   support for the proposal as articulated by the NTIA is not present,
+   the parts of the proposal that are not supported return to the
+   liaison phase.
+
+   (iv) Information sharing
+
+   The ICG serves as a central clearinghouse for public information
+   about the IANA stewardship transition process.  Its secretariat
+   maintains an independent, publicly accessible and open website, under
+   its own domain, where status updates, meetings and notices are
+   announced, proposals are stored, the ICG members are listed, etc.  As
+   the development of the transition plans will take some time, it is
+   important that information about ongoing work is distributed early
+   and continuously.  This will enable sharing of ideas and the
+   detection of potential issues.
+
+
+
+
+
+Lear & Housley                Informational                    [Page 27]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+Appendix B.  IANA Stewardship Transition Coordination Group Request for
+             Proposals
+
+   IANA Stewardship Transition Coordination Group Request for Proposals
+
+   8 September 2014
+
+   Introduction
+
+   Under the IANA Stewardship Transition Coordination Group (ICG)
+   Charter, the ICG has four main tasks:
+
+   (i) Act as liaison to all interested parties in the IANA
+       stewardship transition, including the three "operational
+       communities" (i.e., those with direct operational or service
+       relationships with the IANA functions operator; namely names,
+       numbers, protocol parameters). This task consists of:
+
+      a. Soliciting proposals from the operational communities
+      b. Soliciting the input of the broad group of communities
+         affected by the IANA functions
+
+   (ii) Assess the outputs of the three operational communities for
+        compatibility and interoperability
+
+   (iii) Assemble a complete proposal for the transition
+
+   (iv) Information sharing and public communication
+
+   This Request for Proposals (RFP) addresses task (i) of the ICG
+   Charter. This RFP does not preclude any form of input from the
+   non-operational communities.
+
+   0. Complete Formal Responses
+
+   The IANA Stewardship Transition Coordination Group (ICG) seeks
+   complete formal responses to this RFP through processes which are to
+   be convened by each of the "operational communities" of IANA (i.e.,
+   those with direct operational or service relationships with the IANA
+   functions operator, in connection with names, numbers, or protocol
+   parameters).
+
+   Proposals should be supported by the broad range of stakeholders
+   participating in the proposal development process. Proposals should
+   be developed through a transparent process that is open to and
+   inclusive of all stakeholders interested in participating in the
+   development of the proposal. In order to help the ICG maintain its
+   light coordination role, all interested and affected parties are
+
+
+
+Lear & Housley                Informational                    [Page 28]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   strongly encouraged to participate directly in these community
+   processes.
+
+   The following link provides information about ongoing community
+   processes and how to participate in them, and that will continue to
+   be updated over time:
+
+   https://www.icann.org/en/stewardship/community
+
+   In this RFP, "IANA" refers to the functions currently specified in
+   the agreement between NTIA and ICANN
+   [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well
+   as any other functions traditionally performed by the IANA functions
+   operator. SAC-067
+
+   [https://www.icann.org/en/system/files/files/sac-067-en.pdf]
+   provides one description of the many different meanings of the term
+   "IANA" and may be useful reading in addition to the documents
+   constituting the agreement itself.
+
+   Communities are asked to adhere to open and inclusive processes in
+   developing their responses, so that all community members may fully
+   participate in and observe those processes. Communities are also
+   asked to actively seek out and encourage wider participation by any
+   other parties with interest in their response.
+
+   A major challenge of the ICG will be to identify and help to
+   reconcile differences between submitted proposals, in order to
+   produce a single plan for the transition of IANA
+   stewardship. Submitted Proposals should therefore focus on those
+   elements that are considered to be truly essential to the transition
+   of their specific IANA functions.  The target deadline for all
+   complete formal responses to this RFP is 15 January 2015.
+
+   I. Comments
+
+   While the ICG is requesting complete formal proposals through
+   processes convened by each of the operational communities, and that
+   all interested parties get involved as early as possible in the
+   relevant community processes, some parties may choose to provide
+   comments directly to the ICG about specific aspects of particular
+   proposals, about the community processes, or about the ICG's own
+   processes. Comments may be directly submitted to the ICG any time
+   via email to icg-forum@icann.org. Comments will be publicly archived
+   at <http://forum.icann.org/lists/icg-forum/>.
+
+
+
+
+
+
+Lear & Housley                Informational                    [Page 29]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   Commenters should be aware that ICG will direct comments received to
+   the relevant operational communities if appropriate. The ICG will
+   review comments received as time and resources permit and in
+   accordance with the overall timeline for the transition. That is,
+   comments received about specific proposals may not be reviewed until
+   those proposals have been submitted to the ICG. The ICG may
+   establish defined public comment periods about specific topics in
+   the future, after the complete formal responses to the RFP have been
+   received.
+
+   Required Proposal Elements
+
+   The ICG encourages each community to submit a single proposal that
+   contains the elements described in this section.
+
+   Communities are requested to describe the elements delineated in the
+   sections below in as much detail possible, and according to the
+   suggested format/structure, to allow the ICG to more easily
+   assimilate the results. While each question is narrowly defined to
+   allow for comparison between answers, respondents are encouraged to
+   provide further information in explanatory sections, including
+   descriptive summaries of policies/practices and associated
+   references to source documents of specific policies/practices. In
+   this way, the responses to the questionnaire will be useful at the
+   operational level as well as to the broader stakeholder communities.
+
+   In the interest of completeness and consistency, proposals should
+   cross-reference wherever appropriate the current IANA Functions
+   Contract[3] when describing existing arrangements and proposing
+   changes to existing arrangements.
+
+   0. Proposal type
+
+   Identify which category of the IANA functions this submission
+   proposes to address:
+    [ ] Names [ ] Numbers [ ] Protocol Parameters
+
+   I. Description of Community's Use of IANA Functions
+
+   This section should list the specific, distinct IANA functions your
+   community relies on. For each IANA function on which your community
+   relies, please provide the following:
+
+    o A description of the function;
+    o A description of the customer(s) of the function;
+    o What registries are involved in providing the function;
+
+
+
+
+
+Lear & Housley                Informational                    [Page 30]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+    o A description of any overlaps or interdependencies between your
+      IANA requirements and the functions required by other customer
+      communities.
+
+   If your community relies on any other IANA service or activity
+   beyond the scope of the IANA functions contract, you may describe
+   them here. In this case please also describe how the service or
+   activity should be addressed by the transition plan.
+
+   II. Existing, Pre-Transition Arrangements
+
+   This section should describe how existing IANA-related arrangements
+   work, prior to the transition.
+
+
+   [3] http://www.ntia.doc.gov/files/ntia/
+            publications/sf_26_pg_1-2-final_award_and_sacs.pdf
+
+   A. Policy Sources
+
+   This section should identify the specific source(s) of policy which
+   must be followed by the IANA functions operator in its conduct of
+   the services or activities described above. If there are distinct
+   sources of policy or policy development for different IANA
+   functions, then please describe these separately. For each source of
+   policy or policy development, please provide the following:
+
+    o Which IANA function (identified in Section I) are affected.
+    o A description of how policy is developed and established and who
+      is involved in policy development and establishment.
+    o A description of how disputes about policy are resolved.
+    o References to documentation of policy development and dispute
+      resolution processes.
+
+   B. Oversight and Accountability
+
+   This section should describe all the ways in which oversight is
+   conducted over the IANA functions operator's provision of the
+   services and activities listed in Section I and all the ways in
+   which the IANA functions operator is currently held accountable for
+   the provision of those services. For each oversight or
+   accountability mechanism, please provide as many of the following as
+   are applicable:
+
+   Which IANA functions (identified in Section I) are affected.  If the
+   policy sources identified in Section II.A are affected, identify
+   which ones are affected and explain in what way.
+
+
+
+
+Lear & Housley                Informational                    [Page 31]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+    o A description of the entity or entities that provide oversight or
+      perform accountability functions, including how individuals are
+      selected or removed from participation in those entities.
+    o A description of the mechanism (e.g., contract, reporting scheme,
+      auditing scheme, etc.). This should include a description of the
+      consequences of the IANA functions operator not meeting the
+      standards established by the mechanism, the extent to which the
+      output of the mechanism is transparent and the terms under which
+      the mechanism may change.
+    o Jurisdiction(s) in which the mechanism applies and the legal basis
+      on which the mechanism rests.
+
+   III. Proposed Post-Transition Oversight and Accountability
+        Arrangements
+
+   This section should describe what changes your community is
+   proposing to the arrangements listed in Section II.B in light of the
+   transition. If your community is proposing to replace one or more
+   existing arrangements with new arrangements, that replacement should
+   be explained and all of the elements listed in Section II.B should
+   be described for the new arrangements. Your community should provide
+   its rationale and justification for the new arrangements.
+
+   If your community's proposal carries any implications for the
+   interface between the IANA functions and existing policy arrangements
+   described in Section II.A, those implications should be described
+   here.
+
+   If your community is not proposing changes to arrangements listed in
+   Section II.B, the rationale and justification for that choice should
+   be provided here.
+
+   IV. Transition Implications
+
+   This section should describe what your community views as the
+   implications of the changes it proposed in Section III. These
+   implications may include some or all of the following, or other
+   implications specific to your community:
+
+   Description of operational requirements to achieve continuity of
+   service and possible new service integration throughout the
+   transition.
+
+   Risks to operational continuity and how they will be addressed.
+   Description of any legal framework requirements in the absence of the
+   NTIA contract. Description of how you have tested or evaluated the
+   workability of any new technical or operational methods proposed in
+   this document and how they compare to established arrangements.
+
+
+
+Lear & Housley                Informational                    [Page 32]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   Description of how long the proposals in Section III are expected to
+   take to complete, and any intermediate milestones that may occur
+   before they are completed.
+
+   V. NTIA Requirements
+
+   Additionally, NTIA has established that the transition proposal must
+   meet the following five requirements:
+    o Support and enhance the multistakeholder model;
+    o Maintain the security, stability, and resiliency of the Internet
+      DNS;
+    o Meet the needs and expectation of the global customers and
+      partners of the IANA functions;
+    o Maintain the openness of the Internet;
+    o The proposal must not replace the NTIA role with a government-led
+      or an inter-governmental organization solution.
+
+   This section should explain how your community's proposal meets these
+   requirements and how it responds to the global interest in the IANA
+   functions.
+
+   VI. Community Process
+
+   This section should describe the process your community used for
+   developing this proposal, including:
+    o The steps that were taken to develop the proposal and to determine
+      consensus.
+    o Links to announcements, agendas, mailing lists, consultations and
+      meeting proceedings.
+    o An assessment of the level of consensus behind your community's
+      proposal, including a description of areas of contention or
+      disagreement.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Housley                Informational                    [Page 33]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+Appendix C.  Correspondence of the IETF to the ICG
+
+   The following messages were sent to the ICG:
+
+
+   From: Jari Arkko <jari.arkko@piuha.net>
+   Subject: Re: [Internal-cg] Question from the ICG
+   Date: 20 Feb 2015 23:46:20 GMT+2
+   To: Alissa Cooper <alissa@cooperw.in>, ICG <internal-cg@icann.org>
+   Cc: Izumi Okutani <izumi@nic.ad.jp>
+
+   Dear Alissa and the ICG,
+
+   We refer to the question that the ICG asked the IETF community
+   on 9 Feb 2015
+
+   http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html
+
+   > The numbers proposal sees these changes as a requirement of the
+   > transition and the protocols parameters proposal does not.  If
+   > these aspects of the proposals are perceived as incompatible would
+   > the numbers and protocol parameters communities be willing to
+   > modify their proposals to reconcile them?
+
+   We do not observe incompatibilities between the proposals from the
+   numbers and protocol parameters communities.  The numbers
+   community expresses a preference to transfer the trademark and
+   domain, while the IETF proposal does not oppose such transfer.
+   This is not an incompatibility, it is something that can be
+   satisfied by implementation of both number and protocol
+   parameters community's proposals, as already specified.
+
+   To confirm this, and to determine whether the transfer
+   of the trademark and domain would be acceptable,
+   we consulted the community.  It is the opinion of the
+   IANAPLAN working group that they would support a
+   decision by the IETF Trust to hold the trademark and domain
+   on behalf of the Internet community.  For details, see
+   http://www.ietf.org/mail-archive/web/ianaplan/current/msg01659.html
+
+   The IETF Trust also looked at this issue.  The trustees decided that
+   the IETF Trust would be willing to hold intellectual property rights
+   relating to the IANA function, including the IANA trademark and the
+   IANA.ORG domain name.  For details, see
+   http://www.ietf.org/mail-archive/web/ianaplan/current/msg01664.html
+
+   In short, we find no incompatibility between the proposals and no
+   need to modify the protocol parameters proposal.
+
+
+
+Lear & Housley                Informational                    [Page 34]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   Best Regards,
+   Jari Arkko and Russ Housley on behalf of the IETF community and
+   the IETF Trust
+
+   From: Jari Arkko <jari.arkko@piuha.net>
+   Subject: [Internal-cg] IETF response to the time frame inquiry
+   Date: 5 Jun 2015 13:39:50 GMT+3
+   To: Alissa Cooper <alissa@cooperw.in>
+   Cc: ICG <internal-cg@ianacg.org>
+
+   This is a response to a query regarding transition finalisation and
+   implementation time frames, sent to the IANAPLAN working
+   group list by the chairs of the IANA Transition Coordination
+   Group (ICG) on May 27th.
+
+   While I am carrying this response back to the ICG, the substance
+   of this response has been discussed in the IANAPLAN working
+   group and the relevant parts of IETF leadership.  I believe this
+   response represents the (rough) consensus opinion that
+   emerged in the discussion, as well as the current state
+   of IANA arrangement updates that our leadership bodies
+   have been working on.
+
+   The IETF is ready today to take the next steps in the
+   implementation of the transition of the stewardship.
+   In our case, most of the necessary framework is already
+   in place and implemented in preceding years.
+
+   The remaining step is an updated agreement with
+   ICANN which addresses two issues.  These issues are
+   outlined in Section 2.III in the Internet Draft
+   draft-ietf-ianaplan-icg-response-09.txt:
+
+   o The protocol parameters registries are in the public domain.  It
+   is the preference of the IETF community that all relevant parties
+   acknowledge that fact as part of the transition.
+
+   o It is possible in the future that the operation of the protocol
+   parameters registries may be transitioned from ICANN to subsequent
+   operator(s).  It is the preference of the IETF community that, as
+   part of the NTIA transition, ICANN acknowledge that it will carry
+   out the obligations established under C.7.3 and I.61 of the
+   current IANA functions contract between ICANN and the NTIA
+   [NTIA-Contract] to achieve a smooth transition to subsequent
+   operator(s), should the need arise.  Furthermore, in the event of
+   a transition it is the expectation of the IETF community that
+
+
+
+
+
+Lear & Housley                Informational                    [Page 35]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   ICANN, the IETF, and subsequent operator(s) will work together to
+   minimize disruption in the use of the protocol parameters registries
+   or other resources currently located at iana.org.
+
+   The IETF Administrative Oversight Committee (IAOC) has
+   decided to use an update of our yearly IETF-ICANN Service Level
+   Agreement (SLA) as the mechanism for this updated
+   agreement.  They have drafted the update and from our
+   perspective it could be immediately executed.  Once the updated
+   agreement is in place, the transition would be substantially
+   complete, with only the NTIA contract lapse or termination
+   as a final step.
+
+   Of course, we are not alone in this process.  Interactions
+   with other parts of the process may bring additional
+   tasks that need to be executed either before or
+   after the transition.  First, the ICG, the RIRs,
+   and IETF have discussed the possibility of aligning
+   the treatment of IANA trademarks and domains.  The
+   IETF Trust has signalled that it would be willing to do this,
+   if asked.  We are awaiting coordination on this
+   to complete, but see no problem in speedy
+   execution once the decision is made.  From our
+   perspective this is not a prerequisite for the transition,
+   however.
+
+   In addition, the names community has proposed the
+   creation of a 'Post Transition IANA' (PTI).  If the existing
+   agreements between the IETF and ICANN remain in place
+   and the SLAs discussed above are not affected, the IETF
+   transition would take place as described above.  That is
+   our preference.  If the final details of the PTI plan require
+   further action from the IETF, more work and community
+   agreement would be required.  The timeline for that work
+   cannot be set until the scope is known.
+
+   Jari Arkko, IETF Chair
+   (reporting his summary of the situation)
+
+   From: Jari Arkko <jari.arkko@piuha.net>
+   Subject: [Internal-cg] Response from IETF IANAPLAN WG regarding the
+   ICG question on coordination
+   Date: 8 Oct 2015 10:13:07 GMT+3
+   To: IANA etc etc Coordination Group <internal-cg@ianacg.org>
+
+
+   The IANAPLAN working group has discussed the coordination
+   question from the ICG.  In the working group's opinion,
+
+
+
+Lear & Housley                Informational                    [Page 36]
+
+RFC 7979                    IANA ICG Response                August 2016
+
+
+   informal coordination exists today and will continue, which
+   is consistent with the commitment requested by the ICG.
+
+   This is also consistent with an overall coordination commitment
+   already indicated in the IANAPLAN proposal.  The proposal
+   is a consensus document of the IETF.  From the proposal:
+
+   The IETF will continue to coordinate with ICANN, the RIRs, and other
+   parties that are mutually invested in the continued smooth operation
+   of the Internet registries.
+
+   The coordination approach is also consistent with the
+   comments that were sent by the IAB to the ICG during the
+   public comment period.  See
+   https://www.iab.org/documents/correspondence-reports-documents/2015-
+   2/iab-comments-on-icg-proposal/.
+
+   Jari Arkko,
+   IETF Chair and the Area Director for the IANAPLAN WG
+
+Authors' Addresses
+
+   Eliot Lear (editor)
+   Richtistrasse 7
+   Wallisellen, ZH  CH-8304
+   Switzerland
+
+   Phone: +41 44 878 9200
+   Email: lear@cisco.com
+
+
+   Russ Housley (editor)
+   918 Spring Knoll Drive
+   Herndon, VA  20170
+   United States of America
+
+   Email: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Housley                Informational                    [Page 37]
+