draft-ietf-ianaplan-icg-response-07.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 RFC2418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2418.xml">
<!ENTITY RFC3777 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3777.xml">
<!ENTITY RFC2014 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2014.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">
<!ENTITY RFC6761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml">
<!ENTITY RFC6890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6890.xml">
<!ENTITY RFC3307 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3307.xml">
<!ENTITY RFC5771 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5771.xml">
<!ENTITY RFC7020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7020.xml">
<!ENTITY RFC7249 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7249.xml">
<!ENTITY RFC4193 SYSTEM
	 "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC2870 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2870.xml">
<!ENTITY I-D.leiba-cotton-iana-5226bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.leiba-cotton-iana-5226bis">
]>

<?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-ietf-ianaplan-icg-response-07" category="info">

  <front>
    <title abbrev="IANA ICG Response">
      Draft Response to the Internet Coordination Group Request for
      Proposals on the IANA protocol parameters registries
    </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 />
    <workgroup>IANAPLAN</workgroup>
    <abstract>
      <t>
	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.
      </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 Internet Assigned Numbers Authority
      (IANA) functions <xref target="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
      <xref target="ICG-Charter"/>.  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
      <xref target="ICG-RFP"/>.
      </t>
      <t>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 "&gt;&gt;&gt; ",
      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.
      </t>
      <t>We note that the following text was stated as footnote in the
      original RFP:
      </t>
      <t>
<figure><artwork><![CDATA[
	  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.
]]></artwork></figure>
	  </t>
    </section>
    <section title="The Formal RFP Response">
<t>
The entire Request for Proposals, including introduction, can be found
in <xref target="ICG-RFP"/>.
</t>
<t>
<figure><artwork><![CDATA[
>>> 
>>> 0. Proposal Type
>>>
>>> Identify which category of the IANA functions this
>>> submission proposes to address: 
>>>

IETF Response:
                  Protocol Parameters

]]></artwork></figure>
      </t>
      <t>
	This response states the existing practice of the IETF, and
	also represents the views of the Internet Architecture Board
	and the IETF.
      </t>
<t>
<figure><artwork><![CDATA[
>>>
>>> I. Description of Community’s Use of IANA Functions
>>>
>>> This section should list the specific, distinct IANA services
>>> or activities your community relies on. For each IANA service
>>> or activity on which your community relies, please provide the
>>> following:
>>> A description of the service or activity.
>>>
]]></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 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 <xref target="RFC5226"/>.
      </t>  
      <t>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.
      </t>
<t>
<figure><artwork><![CDATA[
>>>
>>> A description of the customer(s) of the service or activity.
>>>
]]></artwork></figure>
</t>
      <t>IETF Response:</t>
      <t>
        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 <xref target="RFC2860"/> and associated
	supplemental agreements that include service level agreements
	(SLAs) established between the IETF and
	ICANN <xref target="MOUSUP"/>.
      </t>
      <t>
	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 <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 in 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 <xref target="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.
      </t>
<t>
<figure><artwork><![CDATA[
>>>
>>> What registries are involved in providing the service or
>>> activity.
>>>
]]></artwork></figure>
</t>
<t>
  IETF Response:
  </t>
<t>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.</t>
<t>
  Administration of the protocol parameters registries is the service
  that is provided to the IETF.
</t>
<t>
<figure><artwork><![CDATA[
>>>
>>> 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>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.
     </t>
     <t>
       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.
      </t>
      <t></t>
      <t>
      <list style="symbols">
	<t>
	  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. <xref target="RFC6761" />
	</t>
	<t>
	  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.
	</t>
	<t>
	  The IETF specifies minimum requirements for root
	  servers. <xref target="RFC2870"/>
	  Those requirements are currently under review, in
	  consultations with the root server community.
	</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.  If
	  and when that happens, the IETF will consult and coordinate
	  with the RIR community, as we have done in the past.
	</t>
	<t>
          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
          <xref target="RFC7020"/>,<xref target="RFC7249"/>.  Special
          address allocation, such as multicast and anycast addresses,
          often require coordination.  Another example of IP addresses
          that are not administered by the RIR system is Unique Local
          Addresses (ULAs) <xref target="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.</t>
	<t>
	  The IETF maintains sub-registries for special IPv4 and IPv6
          assignments.  These are specified in
          <xref target="RFC3307"/>, <xref target="RFC5771"/>, and
          <xref target="RFC6890"/>.  The IETF coordinates such
          assignments with the RIRs.
	</t>
	<t>
	  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 <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>
      </t>
      <t></t>
    <t>&gt;&gt;&gt; II. Existing, Pre-Transition Arrangements</t>
    <t></t>
<t>
<figure><artwork><![CDATA[
>>> 
>>> 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.
>>> 
]]></artwork></figure>
</t>
<t></t>
<t>IETF Response: The protocol parameters registries.</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> A description of how policy is developed and established and
>>> who is involved in policy development and establishment.
>>>
]]></artwork></figure>
</t>
<t></t>
<t>
	IETF Response:
</t>
<t>
        Policy for overall management of the protocol parameters
	registries is stated 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, 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 <xref target="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
	<xref target="I-D.leiba-cotton-iana-5226bis"/>.
</t>
<t></t>
<t><figure><artwork><![CDATA[
>>> 
>>> A description of how disputes about policy are resolved.
>>>
]]></artwork></figure>
</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 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><figure><artwork><![CDATA[
>>> 
>>> References to documentation of policy development and dispute
>>> resolution processes.
>>> 
]]></artwork></figure>
  </t>
      <t>
	IETF Response: As mentioned above, <xref target="RFC2026" />
	Section 6.5 specifies a conflict resolution and appeals
	process.  <xref target="RFC2418" /> specifies working group
	procedures.  Note that both of these documents have been
	amended in later RFCs as indicated in the
	<xref target="RFC-INDEX" />.
      </t>
<t></t>
<t><figure><artwork><![CDATA[
>>> 
>>> 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.
>>>
]]></artwork></figure>
	</t>
	<t>IETF Response: the protocol parameters registries.</t>	
<t><figure><artwork><![CDATA[
>>> 
>>> If not all policy sources identified in Section II.A are
>>> affected, identify which ones are affected.
>>> 
]]></artwork></figure>
	</t>
	<t>IETF Response: All policy sources relating to the protocol
	parameters registry are affected.
	  </t>
<t><figure><artwork><![CDATA[
>>> 
>>> 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.
>>> 
]]></artwork></figure>
	</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
	  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 <xref target="RFC2850" />.
	  </t>
	  <t>
        The IAB members are selected and may be recalled through a
        Nominating Committee (NOMCOM) process, which is described in
        <xref target="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.
      </t>
	<t>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.
	</t>
<t><figure><artwork><![CDATA[
>>> 
>>> 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.
>>> 
]]></artwork></figure>
	</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" />. The MoU defines the work to be
	carried out by the IANA functions operator for the IETF and
	the Internet Research Task Force (IRTF), a peer organization
	to the IETF that focuses on research.<xref target="RFC2014"/>
	Each year a service 
	level agreement is negotiated that supplements the MoU.
      </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.  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
	<xref target="RFC4071" />.  The IAOC works with the IANA
	functions operator to establish annual IANA performance
	metrics <xref target="METRICS"/> and operational procedures,
	and the resulting document 
	is adopted as an supplement to the MoU each year
	<xref target="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.
      </t>
      <t>
          To date there have been no unresolvable disputes or issues
	  between the IETF and the current IANA functions operator.
	<xref target="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.
      </t>
<t><figure><artwork><![CDATA[
>>> 
>>>  Jurisdiction(s) in which the mechanism applies and the legal
>>>  basis on which the mechanism rests.
>>> 
]]></artwork></figure>
	</t>
      <t>IETF Response</t>
      <t>
	This mechanism is global in nature.  The current agreement
	does not specify a jurisdiction.
      </t>
      <t></t>
    <t>&gt;&gt;&gt;III. Proposed Post-Transition Oversight and
    Accountability Arrangements</t>
    <t></t>
<t><figure><artwork><![CDATA[
>>> 
>>> This section should describe what changes your community is
>>> proposing to the arrangements listed in Section II.B in light of
>>> the transition. If your community is proposing to replace one or
>>> more existing arrangements with new arrangements, that
>>> replacement should be explained and all of the elements listed
>>> in Section II.B should be described for the new
>>> arrangements. Your community should provide its rationale and
>>> justification for the new arrangements. 
>>>
>>> If your community’s proposal carries any implications for
>>> existing policy arrangements described in Section II.A, those
>>> implications should be described here.
>>>
>>> If your community is not proposing changes to arrangements
>>> listed in Section II.B, the rationale and justification for that
>>> choice should be provided here.
>>> 
]]></artwork></figure>
      </t>
      <t>
	IETF Response:
      </t>
      <t>
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.
</t><t>
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.
</t><t>
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:
<list style="symbols">
  <t>
    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.
  </t>
  <t>
    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 <xref target="NTIA-Contract"/> to achieve a smooth transition
    to subsequent operator(s), should the need arise. Furthermore, in
    the event of a transition it is the expectation of the IETF
    community that ICANN, the IETF, and subsequent operator(s) will
    work together to minimize disruption in the use the protocol
    parameters registries or other resources currently located at
    iana.org. 
      </t>
  </list>
</t>
      <t>
	In developing our response we have been mindful of the
	following points that the IETF community has discussed over
	the last year <xref target="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.
      </t>
      <t>1. The IETF protocol parameters registries 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 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.
      </t>
      <t></t> 
      <t>
	2. The protocol parameters registries 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 parameters 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 parameters registries
	function should respect existing Internet community agreements. 
      </t>
      <t>
	The protocol parameters registries function is working well.
	The existing Memorandum of Understanding in RFC 2860 defines
	"the technical work to be carried out by the Internet Assigned
	Numbers Authority on behalf of the Internet Engineering Task
	Force and the Internet Research Task Force."  Any
	modifications to the protocol parameters registries function
	should be made using the IETF process to update RFC 6220 and
	other relevant RFCs.  Put quite simply: evolution, not
	revolution.
      </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 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.
      </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>&gt;&gt;&gt; IV Transition Implications</t>
<t></t>
<t><figure><artwork><![CDATA[
>>> 
>>> 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.
>>> 
]]></artwork></figure>
</t>
<t>IETF Response:</t>
	<t>
	  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.
	</t>
<t>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.</t>
<t>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.
</t>
<t></t>
<t><figure><artwork><![CDATA[
>>> 
>>> V.  NTIA Requirements
>>>
>>> Additionally, NTIA has established that the transition proposal
>>> must meet the following five requirements:
>>> 
>>>	"Support and enhance the multistakeholder model;"
>>>
]]></artwork></figure>
      </t>
      <t>IETF Response:</t>
      <t>
	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.
      </t>
      <t></t>
<t><figure><artwork><![CDATA[
>>> 
>>> "Maintain the security, stability, and resiliency of the
>>>  Internet DNS;"
>>> 
]]></artwork></figure>
      </t>
      <t></t>
      <t>IETF Response:</t>
      <t>
	No changes are proposed in this document that affect the security,
	stability, and resiliency of the DNS.
      </t>
      <t></t>
<t><figure><artwork><![CDATA[
>>> 
>>> "Meet the needs and expectation of the global customers and
>>>  partners of the IANA services;"
>>> 
]]></artwork></figure>
      </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 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.
      </t>
      <t></t>
      <t>
        &gt;&gt;&gt;
      </t>
      <t>
	<figure><artwork><![CDATA[
>>>
>>> "Maintain the openness of the Internet."
>>>
]]></artwork></figure>
      </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 parameters registries
	policies.  Further, an implementer anywhere in the world has
	full access to the protocol specification published in the RFC
	series and the protocol parameters registries published at
	iana.org.  Those who require assignments in the IANA protocol
	registries will continue to have their requests satisfied, as
	specified by the existing policies for those registries.
      </t>
      <t>
	<figure><artwork><![CDATA[
>>>
>>> "The proposal must not replace the NTIA role with a
>>>  government-led or an inter-governmental organization solution."
>>>
]]></artwork></figure>
      </t>
      <t>Policy oversight is performed by the IAB, which is neither a
      government-led or an intergovernmental organization.
      </t>
      <t></t>
<t><figure><artwork><![CDATA[
>>> 
>>> 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.
>>> 
]]></artwork></figure>
</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) 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 <xref target="RFC2026"/>
	    <xref target="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. 
       </t>
<t><figure><artwork><![CDATA[
>>> 
>>> Links to announcements, agendas, mailing lists, consultations and
>>> meeting proceedings.
>>> 
]]></artwork></figure>
  </t>
  <t>
    IETF Response:
  </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://mailarchive.ietf.org/arch/msg/ietf-announce/Ztd2ed9U04qSxI-k9-Oj80jJLXc
      </t>
      <t hangText="Announcement of a public session on the transition:">
	http://mailarchive.ietf.org/arch/msg/ietf-announce/M5zVmFFvTbtgVyMB_fjUSW4rJ0c
      </t>
      <t hangText="Announcement by the IESG of the intent to form a
		   working group:">
	http://mailarchive.ietf.org/arch/msg/ietf-announce/QsvU9qX98G2KqB18jy6UfhwKjXk
      </t>
      <t hangText="The working group discussion">
	http://www.ietf.org/mail-archive/web/ianaplan/current/maillist.html
      </t>
      <t hangText="2014-10-06 Interim Meeting Agenda, Minutes, and
      presentations">
	http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/proceedings.html
      </t>
      <t hangText="Working group last call">
	http://mailarchive.ietf.org/arch/msg/ianaplan/EGF9rfJxn5QpQnRXmS2QxYKYR8k
      </t>
      <t hangText="Agenda from IETF 91 IANAPLAN WG meeting">
	https://tools.ietf.org/wg/ianaplan/agenda
	</t>
      <t hangText="Minutes of IETF 91 IANAPLAN WG meeting">
	https://tools.ietf.org/wg/ianaplan/minutes
      </t>
      <t hangText="Shepherd write-up">
	http://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/shepherdwriteup/
      </t>
      <t hangText="IETF last call">
	http://mailarchive.ietf.org/arch/msg/ietf-announce/i5rx6PfjJCRax3Lu4qZ_38P8wBg
      </t>
    </list>
  </t>
<t>
<figure><artwork><![CDATA[
>>> 
>>> An assessment of the level of consensus behind your community’s
>>> proposal, including a description of areas of contention or
>>> disagreement.
>>> 
]]></artwork></figure>
    </t>
    <t>IETF Response: 
    </t>
    <t>
      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 accordance with <xref target="RFC2026"/>.  Several
      suggestions were raised that did not enjoy sufficient support to
      be included.  Specifically:
      </t><t>
      <list style="symbols">
	<t>A suggestion for a stronger statement over what terms the
	  IAOC should negotiate.
	</t>
	<t> A suggestion that "iana.org" and other associated marks be
	  transferred to the IETF trust.
	</t>
	<t>A suggestion that IAOC consider some form of arbitration.
	</t>
      </list>
      </t>
    <t>
      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.
    </t>
    <t>
      During IETF last call, additional people voiced support for the group,
      and no additional people raised objections.
    </t>
    <t>
    </t>
  </section>
    <section title="IANA Considerations">
      <t>
	This memo is a response to a request for proposals.  No
	parameter allocations or changes are sought.
      </t>
    </section>
    <section title="Security Considerations">
      <t>
	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.
      </t>
    </section>
    <section title="IAB Note">
      <t>This section to be filled in by the IAB.
      </t>
    </section>
    <section title="Acknowledgments">
      <t>
      </t>
      <t>
	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.
      </t>
      </section>
  </middle>
  <back>
    <references title="Normative References">
      &RFC2026;
      &RFC2418;
      &RFC2850;
      &RFC2860;
      &RFC3307;
      &RFC3777;
      &RFC3935;
      &RFC4071;
      &RFC5226;
      &RFC5771;
      &RFC6220;
      &RFC6761;
      &RFC6890;
      &RFC7282;
      <reference anchor="NTIA-Announce"
      target="http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions">
	<front>
	  <title>NTIA Announcement of Intent to Transition Key
	  Internet Domain Name Functions</title>
	  <author/>
	  <date month="March" year="2014" />
	</front>
      </reference>
<reference anchor="NTIA-Contract"
    target="http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf">
  <front>
    <title>The NTIA Contract with ICANN</title>
    <author/>
    <date/>
  </front>
</reference>
<reference anchor="MOUSUP"
    target="http://iaoc.ietf.org/contracts.html">
  <front>
    <title>Supplements to RFC 2860 (the Memorandum of Understanding
    between the IETF and ICANN)</title>
    <author/>
    <date/>
  </front>
  </reference>
  <reference anchor="BCP9info"
    target="http://www.rfc-editor.org/info/rfc2026">
    <front>
      <title>Information on "The Internet Standards Process -- Revision 3"
      </title>
      <author/>
      <date/>
    </front>
  </reference>
  <reference anchor="METRICS"
    target="http://www.iana.org/performance/metrics">
    <front>
      <title>Performance Standards Metrics Report</title>
      <author/>
      <date/>
    </front>
  </reference>
    </references>
    <references title="Informative References">
      &RFC6852;
      &RFC2014;
      &RFC3172;
      &RFC6793;
      &RFC7020;
      &RFC7249;
      &RFC4193;
      &RFC2870;
      &I-D.leiba-cotton-iana-5226bis;
      <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>
      <reference anchor="ProtoParamEvo14"
		 target="http://mailarchive.ietf.org/arch/msg/internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k">
	<front>
	  <title>IAB statement on Guiding the Evolution of the IANA
	    Protocol Parameter Registries
	    </title>
	  <author/>
	  <date month="March" year="2014"/>
	</front>
      </reference>
    </references>
    <section title="Changes">
      <t>
	NOTE: This section to be removed by RFC Editor at publication.
      </t>
      <section title="Changes from -06 to -07">
	<t>
	  <list style="symbols">
	    <t>
	      Merge "No new changes are needed" with "No new
	      organizations or structures are required".  Fewer words to
	      say the same thing.
	    </t>
	    <t>consult to consult and coordinate.</t>
	    <t>RFC Editor comments.</t>
	    <t>Edits resulting from Security Area review by Sean
	    Turner.</t>
	    <t>Edits resulting from AD comments.</t>
	    </list>
	</t>
      </section>
      <section title="Changes from -05 to -06">
	<t>
	  <list style="symbols">
	    <t>Inclusion of agreed substantial comments from the AD.
	      </t>
	    <t>Editorial changes.
	    </t>
	    </list>
	</t>
      </section>
      <section title="Changes from -04 to -05">
	<t>
	  <list style="symbols">
	    <t>Change to simpler text for answer about stability and
	      security.</t>
	    <t>Mention of RFC 5226bis.</t>
	  </list>
	</t>
      </section>
      <section title="Changes from -03 to -04">
	<t>
	  <list style="symbols">
	    <t>Additional text regarding what is needed in Section
	    III.</t>
	    <t>Appropriate language modifications in section IV to
	    match the above changes in III.
	    </t>
	    <t>Acknowledgments edits.</t>
	    </list>
	  </t>
	</section>
	    
	      
      <section title="Changes from -02 to -03">
	<t>
	  <list style="symbols">
	    <t>Terminology consistency.</t>
	    <t>Add IAB section.</t>
	    <t>Changes based on WG discussion on what we prefer as
	    part of the transition regarding IPR.
	    </t>
	    <t>Add discussion about .ARPA domain.
	    </t>
	    <t>Elaboration of what registries are involved.
	    </t>
	    <t>Additional text around coordination with ICANN.
	    </t>
	    <t>Working groups can adopt items within their charters.
	      </t>
	    <t>IAB appointments generally last two years.
	    </t>
	    <t>Add mention of the Trust.
	    </t>
	    <t>Security Considerations update.
	    </t>
	    </list>
	  </t>
      </section>
      <section title="Changes from -01 to -02">
	<t>
	  <list style="symbols">
	    <t>A better description special registries and BGP
	       ASNs.
	    </t>
	    <t>Clarity on how the address space and ASNs are
	    delegated.</t>
	    <t>Many editorials corrected.</t>
	    <t>Mention of the annual review as part of the SLAs.</t>
	    <t>Change about how overlap is presented.</t>
	    <t>A number of small wording changes based on feedback.</t>
	  </list>
	</t>
      </section>
      <section title="Changes from -00 to -01">
	<t>
	  <list style="symbols">
	    <t>Front matter greatly reduced.</t>
	    <t>Appendices with charter and RFP added.</t>
	    <t>Jurisdiction text changed.</t>
	    <t>Proposed changes include supplemental agreement(s) to
	      address jurisdiction, dispute resolution, and IPR, including
	      names and marks.
	    </t>
	    <t>Transition implications slightly modified to reference
	      supplemental agreement.</t>
	  </list>
	</t>
      </section>
    </section>
    <section title="The Charter of the IANA Stewardship Coordination
	Group (ICG" anchor="ICG-Charter">

<t>Charter for the IANA Stewardship Transition Coordination Group V.10
</t>
<t>	(August 27, 2014)
</t>
<t>
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.
</t><t>
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.
</t><t>
The IANA stewardship transition process is taking place alongside a
parallel and related process on enhancing ICANN
accountability. While maintaining the accountability of
Internet identifier governance is central to both processes,
this group’s scope is focused on the arrangements required for
the continuance of IANA functions in an accountable and widely
accepted manner after the expiry of the NTIA-ICANN
contract. Nevertheless, the two processes are interrelated and
interdependent and should appropriately coordinate their work.
</t><t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
</t>
<t>
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).
</t><t>
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.
</t>
<t>
b. Solicit broader input
</t>
<t>
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.
</t><t>
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.
</t><t>
The ICG members chosen from a particular community are the official
communication channel between the ICG and that community.
</t><t>
(ii) Assessment
</t><t>
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.
</t><t>
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.
</t><t>
(iii) Assembling and submitting a complete proposal
</t><t>
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.
</t><t>
If changes are required to fix problems or to achieve broader support,
the ICG will work with the operational communities in a manner
similar to what was described in task (ii) above. Updates are
subject to the same verification, review, and consensus
processes as the initial proposals. If, in the ICG’s opinion,
broad public support for the proposal as articulated by the
NTIA is not present, the parts of the proposal that are not
supported return to the liaison phase.
</t><t>
(iv) Information sharing
</t><t>
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.
</t>
    </section>
<section title="IANA Stewardship Transition Coordination Group
		Request for Proposals" anchor="ICG-RFP">
<t>
IANA Stewardship Transition Coordination Group Request for Proposals
</t><t>
8 September 2014
</t>
<t>
Introduction
</t>
<t>
<figure><artwork><![CDATA[
Under the IANA Stewardship Transition Coordination Group (ICG)
Charter, the ICG has four main tasks:

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


   a. Soliciting proposals from the operational communities
   b. Soliciting the input of the broad group of communities
      affected by the
IANA functions

(ii) Assess the outputs of the three operational communities for
     compatibility and interoperability

(iii) Assemble a complete
     proposal for the transition

(iv) Information sharing and public communication

This Request for Proposals (RFP) addresses task (i) of the ICG
Charter. This RFP does not preclude any form of input from the
non-operational communities.

0. Complete Formal Responses

The IANA Stewardship Transition Coordination Group (ICG) seeks
complete formal responses to this RFP through processes which are to
be convened by each of the “operational communities” of IANA (i.e.,
those with direct operational or service relationships with the IANA
functions operator, in connection with names, numbers, or protocol
parameters).

Proposals should be supported by the broad range of stakeholders
participating in the proposal development process. Proposals should
be developed through a transparent process that is open to and
inclusive of all stakeholders interested in participating in the
development of the proposal. In order to help the ICG maintain its
light coordination role, all interested and affected parties are
strongly encouraged to participate directly in these community
processes.

The following link provides information about ongoing community
processes and how to participate in them, and that will continue to
be updated over time:

https://www.icann.org/en/stewardship/community

In this RFP, "IANA" refers to the functions currently specified in
the agreement between NTIA and ICANN
[http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well
as any other functions traditionally performed by the IANA functions
operator. SAC-067

[https://www.icann.org/en/system/files/files/sac-067-en.pdf]
provides one description of the many different meanings of the term
"IANA" and may be useful reading in addition to the documents
constituting the agreement itself.

Communities are asked to adhere to open and inclusive processes in
developing their responses, so that all community members may fully
participate in and observe those processes. Communities are also
asked to actively seek out and encourage wider participation by any
other parties with interest in their response.

A major challenge of the ICG will be to identify and help to
reconcile differences between submitted proposals, in order to
produce a single plan for the transition of IANA
stewardship. Submitted Proposals should therefore focus on those
elements that are considered to be truly essential to the transition
of their specific IANA functions.  The target deadline for all
complete formal responses to this RFP is 15 January 2015.

I. Comments

While the ICG is requesting complete formal proposals through
processes convened by each of the operational communities, and that
all interested parties get involved as early as possible in the
relevant community processes, some parties may choose to provide
comments directly to the ICG about specific aspects of particular
proposals, about the community processes, or about the ICG’s own
processes. Comments may be directly submitted to the ICG any time
via email to icg-forum@icann.org. Comments will be publicly archived
at <http://forum.icann.org/lists/icg-forum/>.

Commenters should be aware that ICG will direct comments received to
the relevant operational communities if appropriate. The ICG will
review comments received as time and resources permit and in
accordance with the overall timeline for the transition. That is,
comments received about specific proposals may not be reviewed until
those proposals have been submitted to the ICG. The ICG may
establish defined public comment periods about specific topics in
the future, after the complete formal responses to the RFP have been
received.

Required Proposal Elements

The ICG encourages each community to submit a single proposal that
contains the elements described in this section.

Communities are requested to describe the elements delineated in the
sections below in as much detail possible, and according to the
suggested format/structure, to allow the ICG to more easily
assimilate the results. While each question is narrowly defined to
allow for comparison between answers, respondents are encouraged to
provide further information in explanatory sections, including
descriptive summaries of policies/practices and associated
references to source documents of specific policies/practices. In
this way, the responses to the questionnaire will be useful at the
operational level as well as to the broader stakeholder communities.

In the interest of completeness and consistency, proposals should
cross-reference wherever appropriate the current IANA Functions
Contract[3] when describing existing arrangements and proposing
changes to existing arrangements.

0. Proposal type

Identify which category of the IANA functions this submission
proposes to address:
 [ ] Names [ ] Numbers [ ] Protocol Parameters

I. Description of Community’s Use of IANA Functions

This section should list the specific, distinct IANA functions your
community relies on. For each IANA function on which your community
relies, please provide the following:

 o A description of the function;
 o A description of the customer(s) of the function;
 o What registries are involved in providing the function;
 o A description of any overlaps or interdependencies between your
   IANA requirements and the functions required by other customer
   communities. 

If your community relies on any other IANA service or activity
beyond the scope of the IANA functions contract, you may describe
them here. In this case please also describe how the service or
activity should be addressed by the transition plan.

II. Existing, Pre-Transition Arrangements

This section should describe how existing IANA-related arrangements
work, prior to the transition.


[3] http://www.ntia.doc.gov/files/ntia/
         publications/sf_26_pg_1-2-final_award_and_sacs.pdf

A. Policy Sources

This section should identify the specific source(s) of policy which
must be followed by the IANA functions operator in its conduct of
the services or activities described above. If there are distinct
sources of policy or policy development for different IANA
functions, then please describe these separately. For each source of
policy or policy development, please provide the following:

 o Which IANA function (identified in Section I) are affected.
 o A description of how policy is developed and established and who
   is involved in policy development and establishment.
 o A description of how disputes about policy are resolved.
 o References to documentation of policy development and dispute
   resolution processes.

B. Oversight and Accountability

This section should describe all the ways in which oversight is
conducted over the IANA functions operator’s provision of the
services and activities listed in Section I and all the ways in
which the IANA functions operator is currently held accountable for
the provision of those services. For each oversight or
accountability mechanism, please provide as many of the following as
are applicable:


Which IANA functions (identified in Section I) are affected.  If the
policy sources identified in Section II.A are affected, identify
which ones are affected and explain in what way.

 o A description of the entity or entities that provide oversight or
   perform accountability functions, including how individuals are
   selected or removed from participation in those entities. 
 o A description of the mechanism (e.g., contract, reporting scheme,
   auditing scheme, etc.). This should include a description of the
   consequences of the IANA functions operator not meeting the
   standards established by the mechanism, the extent to which the
   output of the mechanism is transparent and the terms under which
   the mechanism may change.
 o Jurisdiction(s) in which the mechanism applies and the legal basis
   on which the mechanism rests.

III. Proposed Post-Transition Oversight and Accountability
     Arrangements 

This section should describe what changes your community is
proposing to the arrangements listed in Section II.B in light of the
transition. If your community is proposing to replace one or more
existing arrangements with new arrangements, that replacement should
be explained and all of the elements listed in Section II.B should
be described for the new arrangements. Your community should provide
its rationale and justification for the new arrangements.

If your community’s proposal carries any implications for the
interface between the IANA functions and existing policy arrangements
described in Section II.A, those implications should be described
here.

If your community is not proposing changes to arrangements listed in
Section II.B, the rationale and justification for that choice should
be provided here.

IV. Transition Implications

This section should describe what your community views as the
implications of the changes it proposed in Section III. These
implications may include some or all of the following, or other
implications specific to your community:

Description of operational requirements to achieve continuity of
service and possible new service integration throughout the
transition.

Risks to operational continuity and how they will be addressed.
Description of any legal framework requirements in the absence of the
NTIA contract. Description of how you have tested or evaluated the
workability of any new technical or operational methods proposed in
this document and how they compare to established arrangements.
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.
]]></artwork></figure>
</t>
</section>
<section title="Completed ICG response for the NTIA">
<t>To be filled in with completed response.</t>
</section>
  </back>
</rfc>