GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7979

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7979.txt · Last modified: 2016/08/30 00:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki