draft-ietf-ianaplan-icg-response-07.txt

IANAPLAN                                                    E. Lear, Ed.
Internet-Draft                                           R. Housley, Ed.
Intended status: Informational                         December 18, 2014
Expires: June 21, 2015


Draft Response to the Internet Coordination Group Request for Proposals
               on the IANA protocol parameters registries
                  draft-ietf-ianaplan-icg-response-07

Abstract

   The U.S.  NTIA has solicited a request from ICANN to propose how the
   NTIA should end its oversight of the IANA functions.  After broad
   consultations, ICANN has in turn created the IANA Stewardship
   Transition Coordination Group.  That group solicited proposals for
   thre three major IANA functions: names, numbers, and protocol
   parameters.  This document contains the IETF response to that
   solicitation for protocol parameters.  It is meant to be included in
   an aggregate response to the NTIA alongside those for names and
   numbering resources that are being developed by their respective
   operational communities.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 21, 2015.

Copyright Notice

   Copyright (c) 2014 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



Lear & Housley           Expires June 21, 2015                  [Page 1]

Internet-Draft             IANA ICG Response               December 2014


   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 . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Formal RFP Response . . . . . . . . . . . . . . . . . . .   3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   5.  IAB Note  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Appendix A.  Changes  . . . . . . . . . . . . . . . . . . . . . .  22
     A.1.  Changes from -06 to -07 . . . . . . . . . . . . . . . . .  22
     A.2.  Changes from -05 to -06 . . . . . . . . . . . . . . . . .  22
     A.3.  Changes from -04 to -05 . . . . . . . . . . . . . . . . .  23
     A.4.  Changes from -03 to -04 . . . . . . . . . . . . . . . . .  23
     A.5.  Changes from -02 to -03 . . . . . . . . . . . . . . . . .  23
     A.6.  Changes from -01 to -02 . . . . . . . . . . . . . . . . .  23
     A.7.  Changes from -00 to -01 . . . . . . . . . . . . . . . . .  24
   Appendix B.  The Charter of the IANA Stewardship Coordination
                Group (ICG . . . . . . . . . . . . . . . . . . . . .  24
   Appendix C.  IANA Stewardship Transition Coordination Group
                Request for Proposals  . . . . . . . . . . . . . . .  27
   Appendix D.  Completed ICG response for the NTIA  . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1.  IETF Introduction

   In March of 2014 the U.S.  National Telecommunications & 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 B.  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 C.




Lear & Housley           Expires June 21, 2015                  [Page 2]

Internet-Draft             IANA ICG Response               December 2014


   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 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.


2.  The Formal RFP Response

   The entire Request for Proposals, including introduction, can be
   found in Appendix C.

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



Lear & Housley           Expires June 21, 2015                  [Page 3]

Internet-Draft             IANA ICG Response               December 2014


   >>> 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.

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










Lear & Housley           Expires June 21, 2015                  [Page 4]

Internet-Draft             IANA ICG Response               December 2014


   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.

   >>>
   >>> 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.
   >>>




Lear & Housley           Expires June 21, 2015                  [Page 5]

Internet-Draft             IANA ICG Response               December 2014


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



Lear & Housley           Expires June 21, 2015                  [Page 6]

Internet-Draft             IANA ICG Response               December 2014


      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.

   >>> 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.








Lear & Housley           Expires June 21, 2015                  [Page 7]

Internet-Draft             IANA ICG Response               December 2014


   >>>
   >>> 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
   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.








Lear & Housley           Expires June 21, 2015                  [Page 8]

Internet-Draft             IANA ICG Response               December 2014


   >>>
   >>> 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 accountab le 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.
   >>>


   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:





Lear & Housley           Expires June 21, 2015                  [Page 9]

Internet-Draft             IANA ICG Response               December 2014


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



Lear & Housley           Expires June 21, 2015                 [Page 10]

Internet-Draft             IANA ICG Response               December 2014


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



Lear & Housley           Expires June 21, 2015                 [Page 11]

Internet-Draft             IANA ICG Response               December 2014


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



Lear & Housley           Expires June 21, 2015                 [Page 12]

Internet-Draft             IANA ICG Response               December 2014


      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].  Discussions during the IETF 89 meeting in London
   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.

   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



Lear & Housley           Expires June 21, 2015                 [Page 13]

Internet-Draft             IANA ICG Response               December 2014


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




Lear & Housley           Expires June 21, 2015                 [Page 14]

Internet-Draft             IANA ICG Response               December 2014


   >>>
   >>> 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.

   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:



Lear & Housley           Expires June 21, 2015                 [Page 15]

Internet-Draft             IANA ICG Response               December 2014


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



Lear & Housley           Expires June 21, 2015                 [Page 16]

Internet-Draft             IANA ICG Response               December 2014


   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
   [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:





Lear & Housley           Expires June 21, 2015                 [Page 17]

Internet-Draft             IANA ICG Response               December 2014


   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://m
      ailarchive.ietf.org/arch/msg/ietf-announce/
      Ztd2ed9U04qSxI-k9-Oj80jJLXc

   Announcement of a public session on the transition:  http://mailarchi
      ve.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  https://tools.ietf.org/wg/
      ianaplan/agenda

   Minutes of IETF 91 IANAPLAN WG meeting  https://tools.ietf.org/wg/
      ianaplan/minutes

   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 by the IESG in



Lear & Housley           Expires June 21, 2015                 [Page 18]

Internet-Draft             IANA ICG Response               December 2014


   accordance with [RFC2026].  Several suggestions were raised that did
   not enjoy sufficient support to be included.  Specifically:

   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.

   o  A suggestion that IAOC consider some form of arbitration.

   At the end, three individuals in the community made clear that they
   did not support the results, while many others did.  The chairs
   concluded that rough consensus existed in the working group.

   During IETF last call, additional people voiced support for the
   group, and no additional people raised objections.

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

   This section to be filled in by the IAB.

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





Lear & Housley           Expires June 21, 2015                 [Page 19]

Internet-Draft             IANA ICG Response               December 2014


7.1.  Normative References

   [BCP9info]
              , "Information on "The Internet Standards Process --
              Revision 3" ", , <http://www.rfc-editor.org/info/rfc2026>.

   [METRICS]  , "Performance Standards Metrics Report", ,
              <http://www.iana.org/performance/metrics>.

   [MOUSUP]   , "Supplements to RFC 2860 (the Memorandum of
              Understanding between the IETF and ICANN)", ,
              <http://iaoc.ietf.org/contracts.html>.

   [NTIA-Announce]
              , "NTIA Announcement of 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]
              , "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, October 1996.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

   [RFC2850]  Internet Architecture Board and B. Carpenter, "Charter of
              the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
              May 2000.

   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860, June 2000.

   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, August 2002.

   [RFC3777]  Galvin, J., "IAB and IESG Selection, Confirmation, and
              Recall Process: Operation of the Nominating and Recall
              Committees", BCP 10, RFC 3777, June 2004.

   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF", BCP
              95, RFC 3935, October 2004.




Lear & Housley           Expires June 21, 2015                 [Page 20]

Internet-Draft             IANA ICG Response               December 2014


   [RFC4071]  Austein, R. and B. Wijnen, "Structure of the IETF
              Administrative Support Activity (IASA)", BCP 101, RFC
              4071, April 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
              March 2010.

   [RFC6220]  McPherson, D., Kolkman, O., Klensin, J., Huston, G.,
              Internet Architecture Board, "Defining the Role and
              Function of IETF Protocol Parameter Registry Operators",
              RFC 6220, April 2011.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, February 2013.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153, RFC
              6890, April 2013.

   [RFC7282]  Resnick, P., "On Consensus and Humming in the IETF", RFC
              7282, June 2014.

7.2.  Informative References

   [I-D.leiba-cotton-iana-5226bis]
              Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", draft-
              leiba-cotton-iana-5226bis-11 (work in progress), November
              2014.

   [ProtoParamEvo14]
              , "IAB statement on Guiding the Evolution of the IANA
              Protocol Parameter Registries ", March 2014, <http://
              mailarchive.ietf.org/arch/msg/internetgovtech/
              4EQ4bnEfE5ZkrPAtSAO2OBZM03k>.

   [RFC-INDEX]
              RFC Editor, , "Index of all Requests for Comments", RFC
              Index, August 2014.

   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
              and Procedures", BCP 8, RFC 2014, October 1996.




Lear & Housley           Expires June 21, 2015                 [Page 21]

Internet-Draft             IANA ICG Response               December 2014


   [RFC2870]  Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
              Name Server Operational Requirements", BCP 40, RFC 2870,
              June 2000.

   [RFC3172]  Huston, G., "Management Guidelines & Operational
              Requirements for the Address and Routing Parameter Area
              Domain ("arpa")", BCP 52, RFC 3172, September 2001.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793, December
              2012.

   [RFC6852]  Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.
              Amour, "Affirmation of the Modern Paradigm for Standards",
              RFC 6852, January 2013.

   [RFC7020]  Housley, R., Curran, J., Huston, G., and D. Conrad, "The
              Internet Numbers Registry System", RFC 7020, August 2013.

   [RFC7249]  Housley, R., "Internet Numbers Registries", RFC 7249, May
              2014.

Appendix A.  Changes

   NOTE: This section to be removed by RFC Editor at publication.

A.1.  Changes from -06 to -07

   o  Merge "No new changes are needed" with "No new organizations or
      structures are required".  Fewer words to say the same thing.

   o  consult to consult and coordinate.

   o  RFC Editor comments.

   o  Edits resulting from Security Area review by Sean Turner.

   o  Edits resulting from AD comments.

A.2.  Changes from -05 to -06

   o  Inclusion of agreed substantial comments from the AD.

   o  Editorial changes.




Lear & Housley           Expires June 21, 2015                 [Page 22]

Internet-Draft             IANA ICG Response               December 2014


A.3.  Changes from -04 to -05

   o  Change to simpler text for answer about stability and security.

   o  Mention of RFC 5226bis.

A.4.  Changes from -03 to -04

   o  Additional text regarding what is needed in Section III.

   o  Appropriate language modifications in section IV to match the
      above changes in III.

   o  Acknowledgments edits.

A.5.  Changes from -02 to -03

   o  Terminology consistency.

   o  Add IAB section.

   o  Changes based on WG discussion on what we prefer as part of the
      transition regarding IPR.

   o  Add discussion about .ARPA domain.

   o  Elaboration of what registries are involved.

   o  Additional text around coordination with ICANN.

   o  Working groups can adopt items within their charters.

   o  IAB appointments generally last two years.

   o  Add mention of the Trust.

   o  Security Considerations update.

A.6.  Changes from -01 to -02

   o  A better description special registries and BGP ASNs.

   o  Clarity on how the address space and ASNs are delegated.

   o  Many editorials corrected.

   o  Mention of the annual review as part of the SLAs.




Lear & Housley           Expires June 21, 2015                 [Page 23]

Internet-Draft             IANA ICG Response               December 2014


   o  Change about how overlap is presented.

   o  A number of small wording changes based on feedback.

A.7.  Changes from -00 to -01

   o  Front matter greatly reduced.

   o  Appendices with charter and RFP added.

   o  Jurisdiction text changed.

   o  Proposed changes include supplemental agreement(s) to address
      jurisdiction, dispute resolution, and IPR, including names and
      marks.

   o  Transition implications slightly modified to reference
      supplemental agreement.

Appendix B.  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.



Lear & Housley           Expires June 21, 2015                 [Page 24]

Internet-Draft             IANA ICG Response               December 2014


   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
   (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







Lear & Housley           Expires June 21, 2015                 [Page 25]

Internet-Draft             IANA ICG Response               December 2014


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



Lear & Housley           Expires June 21, 2015                 [Page 26]

Internet-Draft             IANA ICG Response               December 2014


   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.

Appendix C.  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: &#8232;

      a. Soliciting proposals from the operational communities
      b. Soliciting the input of the broad group of communities
         affected by the&#8232;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



Lear & Housley           Expires June 21, 2015                 [Page 27]

Internet-Draft             IANA ICG Response               December 2014


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



Lear & Housley           Expires June 21, 2015                 [Page 28]

Internet-Draft             IANA ICG Response               December 2014


   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/>.

   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.




Lear & Housley           Expires June 21, 2015                 [Page 29]

Internet-Draft             IANA ICG Response               December 2014


   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;
    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.



Lear & Housley           Expires June 21, 2015                 [Page 30]

Internet-Draft             IANA ICG Response               December 2014


   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.

    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



Lear & Housley           Expires June 21, 2015                 [Page 31]

Internet-Draft             IANA ICG Response               December 2014


   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.
   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           Expires June 21, 2015                 [Page 32]

Internet-Draft             IANA ICG Response               December 2014


Appendix D.  Completed ICG response for the NTIA

   To be filled in with completed response.

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 Noll Drive
   Herndon, VA  20170
   USA

   Email: housley@vigilsec.com





























Lear & Housley           Expires June 21, 2015                 [Page 33]