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

<?xml version="1.0"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC3935 SYSTEM	 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3935.xml">
<!ENTITY RFC6852 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6852.xml">
<!ENTITY RFC2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
<!ENTITY RFC3777 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3777.xml">
<!ENTITY RFC2850 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2850.xml">
<!ENTITY RFC6220 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6220.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC2860 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2860.xml">
<!ENTITY RFC4071 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4071.xml">
<!ENTITY RFC6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC3172 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3172.xml">
<!ENTITY RFC6793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6793.xml">
<!ENTITY RFC7282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7282.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>

<rfc ipr="trust200902" docName="draft-lear-iana-icg-response-00" category="info">

  <front>
    <title abbrev="IAB IANA ICG Response">
      Draft Response to the Internet Coordination Group Request for
      Proposals on IANA
    </title>
    <author fullname="Eliot Lear" initials="E." surname="Lear" role="editor">
      <organization></organization>
      <address>
        <postal>
          <street>Richtistrasse 7</street>
          <city>Wallisellen</city>
          <code>CH-8304</code>
          <region>ZH</region>
          <country>Switzerland</country>
        </postal>
        <phone>+41 44 878 9200</phone>
        <email>lear@cisco.com</email>
      </address>
    </author>
    <author fullname="Russ Housley" initials="R." surname="Housley"
    role="editor">
      <organization></organization>
      <address>
        <postal>
		   <street>918 Spring Noll Drive</street>
		   <city>Herndon</city>
		   <region>VA</region>
		   <code>20170</code>
		   <country>USA</country>
        </postal>
	<email>housley@vigilsec.com</email>
      </address>
    </author>
    <date />

    <abstract>
      <t>
	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.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="IETF Introduction">
      <t>In March of 2014 the U.S. National Telecommunications
      &amp; 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.
      </t>
      <t>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.
      </t>
    </section>
    <section title="The Formal RFP Response">
    <t>Introduction</t>
      <t>
	NOTE: This section is taken in its entirety from the
	questionnaire, version 10 (27 August 2014).
      </t>
      <t>
Under the IANA <eref target="https://www.icann.org/en/system/files/files/charter-icg-27aug14-en.pdf">Stewardship Transition Coordination Group (ICG)
Charter</eref>, the ICG has four main tasks:
</t>
<t>
<figure><artwork><![CDATA[

    (i) Act as liaison to all interested parties in the IANA
        stewardship transition, including the three "operational
        communities" (i.e., those with direct operational or service
        relationships with the IANA functions operator; namely names,
        numbers, protocol parameters). This task consists of:

          a. Soliciting proposals from the operational communities
          b. Soliciting the input of the broad group of communities
             affected by the IANA functions
   (ii) Assess the outputs of the three operational communities
        for compatibility and interoperability
  (iii) Assemble a complete proposal for the transition
   (iv) Information sharing and public communication

]]></artwork></figure>
</t>
<t>
  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.
</t>
<t>
</t>
<t>0. Complete Formal Responses</t>
<t>
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).  
</t><t>
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. 
</t><t>
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]
</t>
<t>
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.
</t><t>
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. 
</t><t>
The target deadline for all complete formal responses to this RFP is
31 December 2014. 
      </t>
<t></t>
<t>I. Comments</t>
	<t>
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 
&lt;http://forum.icann.org/lists/icg-forum/&gt;.
</t><t>
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.
	</t>
<t></t>
<t>Required Proposal Elements</t>
<t>The ICG encourages each community to submit a single proposal that
  contains the elements described in this section.
</t>
<t>
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.
</t><t>
In the interest of completeness and consistency, proposals should
  cross-reference wherever appropriate the current <eref
  target="http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf">
  IANA Functions Contract</eref> when describing existing arrangements and proposing
  changes to existing arrangements. 
</t>
<t></t>
<t>0. Proposal Type</t>
      <t>
<figure><artwork><![CDATA[

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

   IETF Response:
                  [XXX] Protocol Parameters

]]></artwork></figure>
      </t>
      <t>
	This response states the existing practice of the IETF, and
	also represents the views of the IAB and the IETF.
      </t>
      <t></t>
    <t>I. Description of Community’s Use of IANA Functions</t>
      <t>
<figure><artwork><![CDATA[

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

]]></artwork></figure>
</t>
      <t>IETF Response:</t>
      <t>
	The customer of the IANA protocol parameters function is the
	Internet Engineering Task Force (IETF).
      </t>
      <t>
	The IETF is a global
	voluntary standards organization whose goal is to make the
	Internet work better <xref target="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.
      </t>
     <t>
	The IETF operates an open and transparent manner
	<xref target="RFC6852" />.  The processes that govern the IETF
	are also published in the RFC series.  The Internet Standards
	Process is documented in <xref target="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 <xref target="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.
      </t>
<t>
<figure><artwork><![CDATA[

    o A description of the service or activity.

]]></artwork></figure>
</t>
      <t>
	IETF Response:
      </t>
      <t>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.
      </t>  
<t>
<figure><artwork><![CDATA[

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

]]></artwork></figure>
</t>
<t>
  IETF Response:
  </t>
<t>Administration of the protocol registries are themselves the
  service that is provided to the IETF community by ICANN.
</t>
<t>
<figure><artwork><![CDATA[

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

]]></artwork></figure>
      </t>
     <t>
       IETF Response:
       </t>
     <t>
       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.
      </t>
      <t></t>
      <t>
      <list style="symbols">
	<t>
	  The IETF has specified a number of special use registries.
	  These registries require coordination with the GNSO.  We
	  already perform this coordination.
	</t>
	<t>
	  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.
	</t>
	<t>
	  The IETF specifies the DNS protocol.  From time to time there
	  are changes.  We continue to coordinate with ICANN regarding
	  those changes.
	</t>
	<t>
	  The IETF specifies minimum requirements for root servers.
	  Should those requirements change, we will inform ICANN.
	</t>
	<t>
	  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.
	</t>
	<t>
	  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.<xref target="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.
	</t>
      </list>
      </t>
      <t>
      <figure>
  <artwork>
    <![CDATA[
	[[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.  ]]
]]></artwork></figure>
      </t>
      <t></t>
    <t>III. Existing, Pre-Transition Arrangements</t>
    <t></t>
      <t>This section should describe how existing IANA-related
      arrangements work, prior to the transition.</t>
      <t>A. Policy Sources</t>
      <t>
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:
      </t>
<t><list style="symbols">
    <t>Which IANA service or activity (identified in Section I) is
    affected.</t>
</list>
</t>
<t></t>
<t>IETF Respponse: The protocol parameters registry.</t>
<t></t>
<t>
<list style="symbols">
    <t>A description of how policy is developed and established and who
    is involved in policy development and establishment.</t>
</list>
</t>
<t></t>
<t>
	IETF Response:
</t>
<t>
        Policy for overall management of the registries
	is stated in RFCs in <xref target="RFC6220" /> and
	<xref target="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 <xref target="RFC7282"
	/>  Last calls are made so that there is notice of any
	proposed change to a policy or 	process.
</t>
<t></t>
<t>
<list style="symbols">
    <t>A description of how disputes about policy are resolved.</t>
</list>
</t>
<t></t>
<t>IETF Response:
</t>
<t>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 <xref target="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.
</t>
<t></t>
<t>
<list style="symbols">
    <t>References to documentation of policy development and dispute
    resolution processes.</t>
</list>
  </t>
      <t>
	IETF Response: As mentioned above, <xref target="RFC2026" />
	Section 6.5 specifies a conflict resolution and appeals
	process.
      </t>
<t></t>
      <t>B. Oversight and Accountability</t>
<t></t>
      <t>
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:
</t>
      <t>
	<list style="symbols">
	<t>Which IANA service or activity (identified in Section I) is
	affected.</t>
	</list>
	</t>
	<t>IETF Response: the protocol parameters registries.</t>	
	<t>
	<list style="symbols">
	<t>If not all policy sources identified in Section II.A are
	affected, identify which ones are affected.</t>
	</list>
	</t>
	<t>IETF Response: all policy sources relating to the protocol
	parameters registry have been specified in II.A.
	  </t>
	<t>
	<list style="symbols">
	<t>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.</t>
	</list>
	</t>
	<t>IETF Response:
	</t><t>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 <xref target="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
	  <xref target="RFC2860" />.
	  </t>
	  <t>
        The IAB members are selected and may be recalled through a
        Nominating Committee (NOMCOM) process, which is described in
        <xref target="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.
      </t>
	<t>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.
	</t>
	<t>
	<list style="symbols">
	<t>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.</t>
	</list>
	</t>
      <t>
	IETF Response:
	</t>
      <t>
	A memorandum of understanding (MoU) between
	ICANN and the IETF community has been in place since 2000.  It
	can be found in <xref target="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.
      </t>
      <t>
	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
	<xref target="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 <eref target="http://iaoc.ietf.org/contracts.html" />.
      </t>
      <t>
	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.
      </t>
      <t>
	<list style="symbols">
	<t>Jurisdiction(s) in which the mechanism applies and the legal
	  basis on which the mechanism rests.</t>
	</list>
	</t>
      <t>IETF Response</t>
      <t>
	Because of the nature of the agreement, questions of
	jurisdiction are immaterial.
      </t>
      <t></t>
    <t>IV. Proposed changes to IANA Activities/Services</t>
    <t></t>
      <t>
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.
</t>
<t>
If your community’s proposal carries any implications for existing
policy arrangements described in Section II.A, those implications
should be described here.
</t><t>
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.
      </t>
      <t>
	IETF Response:
      </t>
      <t>
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.
      </t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
      <t>1. The IETF protocol parameter registry function has been and
         continues to be capably provided by the Internet technical
         community.
      </t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
      <t></t> 
      <t>
	2. The protocol parameter registry function requires openness,
	transparency, and accountability. 
      </t>
      <t>
	Existing documentation of how the function is administered and
	overseen is good <xref target="RFC2860" />,
	<xref target="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 parameter function accountable for
	following those processes are understood by all interested
	parties.  We are committed to making improvements here if
	necessary.
      </t>
      <t></t> 
      <t>
	3. Any contemplated changes to the protocol parameter registry
	function should respect existing Internet community agreements. 
      </t>
      <t>
	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.
      </t>
      <t></t>
      <t>
	4. The Internet architecture requires and receives capable
	service by Internet registries. 
      </t>
      <t></t>
      <t>
	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.
      </t>
      <t></t>
      <t>
	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. 
      </t>
      <t></t>
      <t>
	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.
      </t>
      <t></t>
      <t>
	6. The protocol parameters registries are provided as a public
	service.
      </t>
      <t></t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
      <t></t>
    <t>Transition Implications</t>
<t></t>
      <t>
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:
</t><t>
<list>
<t>Description of operational requirements to achieve continuity of
service and possible new service integration throughout the
transition.</t>
<t>Risks to operational continuity</t>
<t>Description of any legal framework requirements in the absence of
the NTIA contract</t>
<t>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.</t>
</list>
</t>
<t>IETF Response:</t>
	<t>
	  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.
	</t>
<t>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.</t>
<t></t>
<t>V.  NTIA Requirements
</t>
<t>
Additionally, NTIA has established that the transition proposal must
meet the following five requirements:
</t>
      <t>
	"Support and enhance the multistakeholder model;"
      </t>
      <t>IETF Response:</t>
      <t>
	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.
      </t>
      <t></t>
      <t>
	"Maintain the security, stability, and resiliency of the
	Internet DNS;"
      </t>
      <t></t>
      <t>IETF Response:</t>
      <t>
	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.
      </t>
      <t></t>
      <t>
	"Meet the needs and expectation of the global customers      and
	partners of the IANA services;"
      </t>
      <t></t>
      <t>IETF Response:</t>
      <t>
	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.
      </t>
      <t></t>
      <t>
	"Maintain the openness of the Internet."
      </t>
      <t></t>
      <t>IETF Response:</t>
      <t>
	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 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.
      </t>
      <t>
	{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.}
      </t>
      <t></t>
    <t>VI.  Community Process</t>
<t></t>
      <t>
This section should describe the process your community used for
developing this proposal, including:
</t>
<t>
  <list>
    <t>The steps that were taken to develop the proposal and to determine
      consensus.</t>
  </list>
</t>
<t>IETF Response:
</t>
       <t>
	 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.
       </t>
  <t>
    <list style="symbols">
      <t>Links to announcements, agendas, mailing lists, consultations and
	meeting proceedings.</t>
    </list>
  </t>
  <t>
    IETF Response: [xxx to be completed in more detail]
  </t>
  <t>
    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.
  </t>
  <t>
    <list style="hanging">
      <t hangText="Creation of an open mailing list to discuss the
		   transition">
	http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html
      </t>
      <t hangText="Announcement of a public session on the transition">
	http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
      </t>
      <t hangText="Announcement by the IESG of the intent to form a
		   working group">
	http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13170.html
      </t>
    </list>
  </t>
    <t>
      <list style="symbols">
	<t>An assessment of the level of consensus behind your community’s
	  proposal, including a description of areas of contention or
	  disagreement.</t>
      </list>
    </t>
    <t>IETF Response: To be completed as the process progresses.
    </t>
  </section>
    <section title="Acknowledgments">
      <t>
      </t>
      <t>
	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.
      </t>
      </section>
  </middle>
  <back>
    <references title="Informative References">
      &RFC3935;
      &RFC6852;
      &RFC2026;
      &RFC3777;
      &RFC2850;
      &RFC6220;
      &RFC5226;
      &RFC2860;
      &RFC4071;
      &RFC3172;
      &RFC7282;
      &RFC6793;
<reference anchor='RFC-INDEX'>

<front>
<title>Index of all Requests for Comments</title>
<author initials='' surname='RFC Editor'  fullname='RFC Editor'>
<organization /></author>
<date year='2014' month='August' />
<abstract>
<t>Index of all Requests for Comments</t></abstract></front>
<seriesInfo name='RFC' value='Index' />
<format type='TXT' target='http://www.rfc-editor.org/rfc/rfc-index.txt' />
</reference>

    </references>
  </back>
</rfc>