draft-lear-iana-icg-response-00.txt

Network Working Group                                       E. Lear, Ed.
Internet-Draft                                           R. Housley, Ed.
Intended status: Informational                        September 01, 2014
Expires: March 05, 2015


Draft Response to the Internet Coordination Group Request for Proposals
                                on IANA
                    draft-lear-iana-icg-response-00

Abstract

   This document contains the a draft response to a request for
   proposals from the IANA Stewardship Transition Coordination Group
   regarding the protocol parameters registries.  It is meant to be
   included in an aggregate proposal that also includes contributions
   covering names and addresses that will be submitted from their
   respective operational communities.  The IETF community is invited to
   comment and propose changes to this document.

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 March 05, 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
   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



Lear & Housley           Expires March 05, 2015                 [Page 1]

Internet-Draft           IAB IANA ICG Response            September 2014


   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 . . . . . . . . . . . . . . . . . . .   2
   3.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   4.  Informative References  . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  IETF Introduction

   In March of 2014 the U.S.  National Telecommunications & Information
   Administration (NTIA) announced its intent to transition oversight of
   IANA functions.  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.  They solicited proposals regarding the respective functions
   that IANA performs, in order that they may put forth a proposal to
   the NTIA.

   While there are interactions between all of the IANA functions and
   IETF standards, this document specifically addresses the protocol
   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.  Because much of this memo is taken from a
   questionnaire we mark answers to questions being asked as "IETF
   Response:".  There are Small changes to the content of the questions
   asked in order to match the RFC format.

2.  The Formal RFP Response

   Introduction

   NOTE: This section is taken in its entirety from the questionnaire,
   version 10 (27 August 2014).

   Under the IANA Stewardship Transition Coordination Group (ICG)
   Charter [1], 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



Lear & Housley           Expires March 05, 2015                 [Page 2]

Internet-Draft           IAB IANA ICG Response            September 2014


           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 from 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 are expected to enjoy a broad consensus of support from all
   interested parties.  During the development of their proposals, the
   operational communities are requested to consult and work with other
   affected parties.  Likewise, in order to help the ICG maintain its
   light coordination role, all other affected parties are strongly
   encouraged to participate in 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: [XXX LINK]

   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.



Lear & Housley           Expires March 05, 2015                 [Page 3]

Internet-Draft           IAB IANA ICG Response            September 2014


   The target deadline for all complete formal responses to this RFP is
   31 December 2014.

   I.  Comments

   While the ICG is requesting complete formal proposals from the
   operational communities only, 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 [2] when describing existing arrangements and proposing
   changes to existing arrangements.

   0.  Proposal Type




Lear & Housley           Expires March 05, 2015                 [Page 4]

Internet-Draft           IAB IANA ICG Response            September 2014


      Identify which category of the IANA functions this submission
      proposes to address:

      IETF Response:
                     [XXX] Protocol Parameters



   This response states the existing practice of the IETF, and also
   represents the views of the IAB 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:

       o A description of the customer(s) of the service or activity.
       [N.B. the IETF response has swapped this question with the next.]



   IETF Response:

   The customer of the IANA protocol parameters function is the Internet
   Engineering Task Force (IETF).

   The IETF is a global voluntary standards organization whose goal is
   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 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, and those amendments are indicated in [RFC-INDEX].
   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 Community
   (IESG).  Anyone may propose such a change, and anyone may participate
   in the community discussion.



Lear & Housley           Expires March 05, 2015                 [Page 5]

Internet-Draft           IAB IANA ICG Response            September 2014


       o 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 IETF's primary
   users of the IETF standards and other documents.  To ensure
   consistent interpretation of these parameter values by independent
   implementations, a globally available registry contains the parameter
   values and a pointer to documentation of the associated semantic
   intent.  The IETF uses the IANA protocol parameter registries for
   this purpose.


       o What registries are involved in providing the service or
         activity.



   IETF Response:

   Administration of the protocol registries are themselves the service
   that is provided to the IETF community by ICANN.


       o A description of any overlaps or interdependencies between your
         IANA requirements and the functions required by other customer
         communities



   IETF Response:

   It is important to note that the IETF includes anyone who wishes to
   participate, including anyone from ICANN or the RIRs, and many people
   from those organizations regularly do.

   o  The IETF has specified a number of special use registries.  These
      registries require coordination with the GNSO.  We already perform
      this coordination.

   o  The IETF may, from time to time, define and allocate new ranges of
      IP addresses.  If one or more registries are required, the IETF
      will coordinate with appropriate organizations, such as the RIRs
      or ICANN.




Lear & Housley           Expires March 05, 2015                 [Page 6]

Internet-Draft           IAB IANA ICG Response            September 2014


   o  The IETF specifies the DNS protocol.  From time to time there are
      changes.  We continue to coordinate with ICANN regarding those
      changes.

   o  The IETF specifies minimum requirements for root servers.  Should
      those requirements change, we will inform ICANN.

   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.  As and when that
      happens, we will consult with the RIR community, as we have done
      in the past.

   o  IETF standards changes may have impact on operations of RIRs and
      service providers.  A recent example is the expansion of the BGP
      community field from 16 to 32 bits.[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.


       [[RH2]I think there are two areas of overlap:

         Addresses: special-purpose addresses, such as anycast.  We need
         to set up procedures to coordinate assignments.

         Names: special-purpose names, such as .local.  We need to set
         up procedures to coordinate such assignments.  ]]


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

   o  Which IANA service or activity (identified in Section I) is
      affected.

   IETF Respponse: The protocol parameters registry.




Lear & Housley           Expires March 05, 2015                 [Page 7]

Internet-Draft           IAB IANA ICG Response            September 2014


   o  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 registries is stated in RFCs 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, the Internet Engineering Steering Group
   may choose to create a working group or an Area Director may choose
   to sponsor the draft.  In either 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]  Last calls are made so that there is notice of
   any proposed change to a policy or process.

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

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

   B.  Oversight and Accountability









Lear & Housley           Expires March 05, 2015                 [Page 8]

Internet-Draft           IAB IANA ICG Response            September 2014


   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:

   o  Which IANA service or activity (identified in Section I) is
      affected.

   IETF Response: the protocol parameters registries.

   o  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 have been specified in II.A.

   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.

   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 is also
   responsible for establishing liaison relationships with other
   orgnaizations on behalf of the IETF.  The IAB's charter is to be
   found in [RFC2860].

   The IAB members are selected and may be recalled through a Nominating
   Committee (NOMCOM) process, which is described in [RFC3777].  This
   process provides for selection of active members of the community who
   themselves agree upon a slate of candidates.  Those candidates are
   sent to the ISOC Board of Trustees for confirmation.  In general,
   members serve for two years.  The IAB selects its own chair.

   The IAB provides oversight of the protocol parameter 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, many registries are 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.




Lear & Housley           Expires March 05, 2015                 [Page 9]

Internet-Draft           IAB IANA ICG Response            September 2014


   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.

   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].  It has been amended several times.  The MoU defines the
   work to be carried out by the IANA staff for the IETF and IRTF.

   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.  IAOC
   members are appointed by the Internet Society Board of Trustees, the
   IAB, the IESG, and the NOMCOM [RFC4071].  The IAOC works with ICANN
   to establish annual IANA performance metrics and operational
   procedures, and the resulting document is adopted as an addendum to
   the MoU each year [3].

   To date there have been no unresolvable disputes or issues.  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.

   o  Jurisdiction(s) in which the mechanism applies and the legal basis
      on which the mechanism rests.

   IETF Response

   Because of the nature of the agreement, questions of jurisdiction are
   immaterial.

   IV.  Proposed changes to IANA Activities/Services

   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.




Lear & Housley           Expires March 05, 2015                [Page 10]

Internet-Draft           IAB IANA ICG Response            September 2014


   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 changes are required, as 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 covers what is
   needed.

   First and foremost, IANA protocol parameter registry updates will
   continue to function day-to-day, as they have been doing for the last
   decade or more.  The IETF community is quite 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.

   Discussions during IETF 89 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 parameter registry 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 parameter registry
   function needs 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 parameter registry 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



Lear & Housley           Expires March 05, 2015                [Page 11]

Internet-Draft           IAB IANA ICG Response            September 2014


   community can understand how the function works, and that the
   processes for registering parameters and holding those who oversee
   the protocol parameter 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 parameter registry
   function should respect existing Internet community agreements.

   The protocol parameter registry 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 parameter
   registry 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
   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.



Lear & Housley           Expires March 05, 2015                [Page 12]

Internet-Draft           IAB IANA ICG Response            September 2014


   Directions for the creation of protocol parameter 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.

   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

      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.

   IETF Response:

   No structural changes are required.  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 issuees 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.

   V.  NTIA Requirements





Lear & Housley           Expires March 05, 2015                [Page 13]

Internet-Draft           IAB IANA ICG Response            September 2014


   Additionally, NTIA has established that the transition proposal must
   meet the following five requirements:

   "Support and enhance the multistakeholder model;"

   IETF Response:

   Everyone is welcome to participate in IETF activities.  The policies
   and procedures are outlined in the documents we named above.  In-
   person attendance is not required for participation, and many people
   participate in email discussions that have never attended an IETF
   meeting.  An email account is the only requirement to participate.
   The IETF makes use of both formal and informal lines of communication
   to collaborate with other organizations within the multistakeholder
   ecosystem.

   "Maintain the security, stability, and resiliency of the Internet
   DNS;"

   IETF Response:

   The DNS relies on some of the IETF protocol parameters registries.
   As the current IANA functions operator, ICANN performs its task very
   well, usually exceeding the service level agreement metrics.[Metrics]
   Security, stability, and resiliency of the Internet DNS is best
   protected by maintaining the current service in its current form.

   "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 parameter registries.
   The current IANA protocol parameter registry 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 parameter registry policies.  Further, an
   implementer anywhere in the world has full access to the protocol
   specification published n the RFC series and the protocol parameter



Lear & Housley           Expires March 05, 2015                [Page 14]

Internet-Draft           IAB IANA ICG Response            September 2014


   registries published at iana.org.  Those who require assignments in
   the IANA protocol registries will continue to be able to do so, as
   specified by the existing policies for those registries.

   {We will have an open discussion, make changes based on that
   discussion, and then conduct a Last Call to confirm that there is
   rough consensus for the proposal.}

   VI.  Community Process

   This section should describe the process your community used for
   developing this proposal, including:

      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) was associated with the working group.  In
   addition, IETF's IANA practices have been discussed in the broader
   community, and all input is welcome.

   o  Links to announcements, agendas, mailing lists, consultations and
      meeting proceedings.

   IETF Response: [xxx to be completed in more detail]

   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://www.ietf.org/mail-archive/web/ietf-announce/current/
      msg12978.html

   Announcement of a public session on the transition  http://
      www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html

   Announcement by the IESG of the intent to form a      working group
      http://www.ietf.org/mail-archive/web/ietf-announce/current/
      msg13170.html

   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 March 05, 2015                [Page 15]

Internet-Draft           IAB IANA ICG Response            September 2014


   IETF Response: To be completed as the process progresses.

3.  Acknowledgments

   This document does not define new processes, and so it seems we
   acknowledge all of the preceding IAB members and members of the
   community who developed the processes that we describe.  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, John Klensin, Andrei Robachevsky, Andrew
   Sullivan, Leslie Daigle, and Barry Leiba.

4.  Informative References

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

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

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

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

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

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




Lear & Housley           Expires March 05, 2015                [Page 16]

Internet-Draft           IAB IANA ICG Response            September 2014


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

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

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

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 March 05, 2015                [Page 17]