Difference between revisions of "Ianaplan - current draft"

Latest revision as of 21:42, 16 December 2014

IANAPLAN E. Lear, Ed.

Internet-Draft R. Housley, Ed.

Intended status: Informational November 26, 2014

Expires: May 30, 2015

Draft Response to the Internet Coordination Group Request for Proposals

on the IANA protocol parameters registries

draft-ietf-ianaplan-icg-response-06

1 Abstract
2 1. IETF Introduction
3 2. The Formal RFP Response
4 3. IANA Considerations
5 4. Security Considerations
6 5. IAB Note
7 6. Acknowledgments
8 7. Informative References
9 Appendix A. Changes
10 A.1. Changes from -05 to -06
11 A.2. Changes from -04 to -05
12 A.3. Changes from -03 to -04
13 A.4. Changes from -02 to -03
14 A.5. Changes from -01 to -02
15 A.6. Changes from -00 to -01
16 Appendix B. The Charter of the IANA Stewardship Coordination Group (ICG
17 Appendix C. IANA Stewardship Transition Coordination Group Request for
18 Authors' Addresses

Abstract

This document contains the IETF 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 domain names and numbering resources that will be submitted from their respective operational communities. The IETF community is invited to comment and propose changes to this document.

1. IETF Introduction

In March of 2014 the U.S. National Telecommunications & Information Administration (NTIA) announced its intent to transition oversight of Internet Assigned Numbers Authority (IANA) functions. In that announcement, NTIA asked the Internet Corporation for Assigned Names and Numbers (ICANN) to establish a process to deliver a proposal for transition. As part of that process, the IANA Stewardship Transition Coordination Group (ICG) was formed. The charter for the ICG can be found in Appendix B. They solicited proposals regarding post- transition arrangements from the three functional areas in order to put forth a proposal to the NTIA. The final request for proposal (RFP) can be found in Appendix C.

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. Because much of this memo is taken from a questionnaire we have quoted questions with " " and we have prefaced answers to questions being asked with "IETF Response:".

Note that there are small changes to the content of the questions asked in order to match the RFC format.

As if to demonstrate the last point, the following text was included in a footnote in the original RFP:

In this RFP, "IANA" refers to the functions currently specified in the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/ iana-functions-purchase-order] as well as any other functions traditionally performed by the IANA functions operator. SAC-067 [1] provides one description of the many different meanings of the term "IANA" and may be useful reading in addition to the documents constituting the agreement itself.

2. The Formal RFP Response

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

  0. Proposal Type
  Identify which category of the IANA functions this
  submission proposes to address:

IETF Response: [XXX] Protocol Parameters

This response states the existing practice of the IETF, and also represents the views of the Internet Architecture Board and the IETF.

  I. Description of Community's Use of IANA Functions
  This section should list the specific, distinct IANA services
  or activities your community relies on. For each IANA service
  or activity on which your community relies, please provide the
  following:
  A description of the service or activity.

IETF Response:

Many IETF protocols make use of commonly defined protocol parameters. These parameters are used by implementers, who are the primary users of the IETF standards and other documents. To ensure consistent interpretation of these parameter values by independent implementations, and to promote universal interoperability, these IETF protocol specifications define and require globally available registries containing the parameter values and a pointer to any associated documentation. The IETF uses the IANA protocol parameters registries to store this information in a public location. The IETF community presently accesses the protocol parameter registries via references based on iana.org domain name, and makes use of the term "IANA" in the protocol parameter registry processes [RFC5226].

ICANN currently operates the .ARPA top level domain on behalf of the Internet Architecture Board (IAB). This zone is used for certain Internet infrastructure services that are delegated beneath it. We consider .ARPA part of the protocol parameters registries for purposes of this response.

  A description of the customer(s) of the service or activity.

IETF Response:

The IANA protocol parameters registries operator maintains the protocol parameters registries for the IETF in conformance with all relevant IETF policies, in accordance with the Memorandum of Understanding [RFC2860] and associated supplemental agreements that include service level agreements (SLAs) established between the IETF and ICANN [MOUSUP].

The IETF is a global organization that produces voluntary standards, whose goal is to make the Internet work better [RFC3595]. IETF standards are published in the RFC series. The IETF is responsible for the key standards that are used on the Internet today, including IP, TCP, DNS, BGP, and HTTP, to name but a few.

The IETF operates in an open and transparent manner [RFC6852]. The processes that govern the IETF are also published in the RFC series. The Internet Standards Process is documented in [RFC2026]. That document explains not only how standards are developed, but also how disputes about decisions are resolved. RFC 2026 has been amended a number of times, and those amendments are indicated in [RFC-INDEX]. The standards process can be amended in the same manner that standards are approved. That is, someone proposes a change by submitting a temporary document known as an Internet-Draft, the

community discusses it, and if rough consensus can be found the change is approved by the Internet Engineering Steering Group (IESG), who also have day-to-day responsibility for declaring IETF consensus on technical decisions, including those that affect the IANA protocol parameters registries. Anyone may propose a change during a Last Call, and anyone may participate in the community discussion.

  What registries are involved in providing the service or
  activity.

IETF Response:

The protocol parameters registries are the product of IETF work. These also include the top-level registry for the entire IP address space and some of its sub-registries, autonomous system number space, and a number of special use registries with regard to domain names. For more detail please refer to the documentation in the "overlaps or interdependencies" section.

Administration of the protocol parameters registries is the service that is provided to the IETF.

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

IETF Response:

In this context, the IETF considers "overlap" to be where there is in some way shared responsibility for a single registry across multiple organizations. In this sense, there is no overlap between organizations because responsibility for each registry is carefully delineated. There are, however, points of interaction between other organizations, and a few cases where we may further define the scope of a registry for technical purposes. This is the case with both names and numbers, as described in the paragraphs below. In all cases, the IETF coordinates with the appropriate organizations.

It is important to note that the IETF includes anyone who wishes to participate. Staff and participants from ICANN or the Regional Internet Registries (RIRs) regularly participate in IETF activities.

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 them to meet new conditions as they might arise. [RFC6761]

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.

The IETF specifies minimum requirements for root servers.

[RFC2870] Those requirements are currently under review, in consultations with the root server community.

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.

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 RIR system [RFC7020],[RFC7249]. Special address allocation, such as multicast and anycast addresses, often require coordination. Another example of IP addresses that are not administered by the RIR system is Unique Local Addresses (ULAs) [RFC4193], where local networks employ a prefix that is not intended to be routed on the public Internet. New special address allocations are added, from time to time, related to the evolution of the standards. In all cases, these special assignments are listed in the IANA protocol paramters registries.

The IETF maintains sub-registries for special IPv4 and IPv6

assignments. These are specified in [RFC3307], [RFC5771], and [RFC6890]. The IETF coordinates such assignments with the RIRs.

IETF standards changes may have impact on operations of RIRs and

service providers. A recent example is the extensions to BGP to carry the Autonomous System numbers as four-octet entities [RFC6793]. It is important to note that this change occurred out of operational necessity, and it demonstrated strong alignment between the RIRs and the IETF.

  II.  Existing, Pre-Transition Arrangements

  This section should describe how existing IANA-related
  arrangements work, prior to the transition.
  A. Policy Sources
  This section should identify the specific source(s) of policy
  which must be followed by the IANA functions operator in its
  conduct of the services or activities described above.  If there
  are distinct sources of policy or policy development for
  different IANA activities, then please describe these
  separately. For each source of policy or policy development,
  please provide the following:
  Which IANA service or activity (identified in Section I) is
  affected.

IETF Response: The protocol parameters registries.

  A description of how policy is developed and established and
  who is involved in policy development and establishment.

IETF Response:

Policy for overall management of the protocol parameters registries is stated in [RFC6220] and [RFC5226]. The first of these documents explains the model for how the registries are to be operated, how policy is set, and how oversight takes place. RFC 5226 specifies the policies that specification writers may employ when they define new protocol registries in the "IANA Considerations" section of each specification. All policies at the IETF begin with a proposal in the form of an Internet-Draft. Anyone may submit such a proposal. If there is sufficient interest, a working group whose scope includes the proposed work may choose to adopt it, the IESG may choose to create a working group, or an Area Director may choose to sponsor the draft. In any case, anyone may comment on the proposal as it progresses. A proposal cannot be passed by the IESG unless it enjoys sufficient community support as to indicate rough consensus [RFC7282]. In each case, a "Last Call" is made so that there is notice of any proposed change to a policy or process. Anyone may

comment during a Last Call. For example, this process is currently being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis].

  A description of how disputes about policy are resolved.

IETF Response:

Most disputes are handled at the lowest level through the working group and rough consensus processes. Should anyone disagree with any action, Section 6.5 of [RFC2026] specifies a multi-level conflict resolution and appeals process that includes the responsible Area Director, the IESG, and the IAB. Should appeals be upheld, an appropriate remedy is applied. In the case where someone claims that the procedures themselves are insufficient or inadequate in some way to address a circumstance, one may appeal an IAB decision to the Internet Society Board of Trustees.

  References to documentation of policy development and dispute
  resolution processes.

IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a conflict resolution and appeals process. [RFC2418] specifies working group procedures. Note that both of these documents have been amended in later RFCs as indicated in the [RFC-INDEX]. Please also see the references at the bottom of this document.

  B. Oversight and Accountability
  This section should describe all the ways in which oversight is
  conducted over IANA functions operator's provision of the
  services and activities listed in Section I and all the ways in
  which IANA functions operator is currently held accountab le for
  the provision of those services. For each oversight or
  accountability mechanism, please provide as many of the
  following as are applicable:
  Which IANA service or activity (identified in Section I) is
  affected.

IETF Response: the protocol parameters registries.

  If not all policy sources identified in Section II.A are
  affected, identify which ones are affected.

IETF Response: all policy sources relating to the protocol parameters registry are affected.

  A description of the entity or entities that provide oversight
  or perform accountability functions, including how individuals
  are selected or removed from participation in those entities.

IETF Response:

The Internet Architecture Board (IAB) is an oversight body of the IETF whose responsibilities include, among other things, confirming appointment of IESG members, managing appeals as discussed above, management of certain domains, including .ARPA [RFC3172], and general architectural guidance to the broader community. The IAB must approve the appointment of an organization to act as IANA operator on behalf of the IETF. The IAB is also responsible for establishing liaison relationships with other organizations on behalf of the IETF. The IAB's charter is to be found in [RFC2850].

The IAB members are selected and may be recalled through a Nominating Committee (NOMCOM) process, which is described in [RFC3777]. This process provides for selection of active members of the community who themselves agree upon a slate of candidates. The active members are chosen randomly from volunteers with a history of participation in the IETF, with limits regarding having too many active members with the same affiliation. The selection of the active members is performed in a manner that makes it possible for anyone to verify that the correct procedure was followed. The slate of candidates selected by the active members are sent to the Internet Society Board of Trustees for confirmation. In general, members are appointed for terms of two years. The IAB selects its own chair.

The IAB provides oversight of the protocol parameters registries of the IETF, and is responsible for selecting appropriate operator(s) and related per-registry arrangements. Especially when relationships among protocols call for it, 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.

  A description of the mechanism (e.g., contract, reporting
  scheme, auditing scheme, etc.). This should include a
  description of the consequences of the IANA functions operator
  not meeting the standards established by the mechanism, the
  extent to which the output of the mechanism is transparent and
  the terms under which the mechanism may change.

IETF Response:

A memorandum of understanding (MoU) between ICANN and the IETF community has been in place since 2000. It can be found in [RFC2860]. The MoU defines the work to be carried out by the IANA functions operator for the IETF and the Internet Research Task Force (IRTF), a peer organization to the IETF that focuses on research. Each year a service level agreement is negotiated that supplements the MoU.

Day-to-day administration and contract management is the responsibility of the IETF Administrative Director (IAD). The IETF Administrative Oversight Committee (IAOC) oversees the IAD. The members of the IAOC are also the trustees of the IETF Trust, whose main purpose is to hold certain intellectual property for the benefit of the IETF as a whole. IAOC members are appointed by the Internet Society Board of Trustees, the IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with the IANA functions operator to establish annual IANA performance metrics [METRICS] and operational procedures, and the resulting document is adopted as an supplement to the MoU each year [MOUSUP]. Starting from 2014, in accordance with these supplements, an annual audit is performed to ensure that protocol parameter requests are being processed according to the established policies. The conclusions of this audit will be available for anyone in the world to review.

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

   Jurisdiction(s) in which the mechanism applies and the legal

   basis on which the mechanism rests.

IETF Response

This mechanism is global in nature. The current agreement does not specify a jurisdiction.

 III.  Proposed Post-Transition Oversight and Accountability

Arrangements

  This section should describe what changes your community is
  proposing to the arrangements listed in Section II.B in light of
  the transition. If your community is proposing to replace one or
  more existing arrangements with new arrangements, that
  replacement should be explained and all of the elements listed
  in Section II.B should be described for the new
  arrangements. Your community should provide its rationale and
  justification for the new arrangements.
  If your community's proposal carries any implications for
  existing policy arrangements described in Section II.A, those
  implications should be described here.
  If your community is not proposing changes to arrangements
  listed in Section II.B, the rationale and justification for that
  choice should be provided here.

IETF Response:

No major changes 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. Therefore, no new organizaitons or structures are needed.

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

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:

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.

It is possible in the future that the operation of the protocol

parameters registries may be transitioned from ICANN to subsequent operator(s). It is the preference of the IETF community that, as part of the NTIA transition, ICANN acknowledge that it will carry out the obligations established under C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract] to achieve a smooth transition to subsequent operator(s), should the need arise. Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN, the IETF, and subsequent operator(s) will work together to minimize disruption in the use the protocol parameters registries or other resources currently located at iana.org.

Discussions during the IETF 89 meeting in London led to the following guiding principles for IAB efforts that impact IANA protocol parameter registries. These principles must be taken together; their order is not significant.

1. The IETF protocol parameters registries function has been and continues to be capably provided by the Internet technical community.

The strength and stability of the function and its foundation within the Internet technical community are both important given how critical protocol parameters are to the proper functioning of IETF protocols.

We think the structures that sustain the protocol parameters registries function need to be strong enough that they can be offered independently by the Internet technical community, without the need for backing from external parties. And we believe we largely are there already, although the system can be strengthened further, and continuous improvements are being made.

2. The protocol parameters registries function requires openness, transparency, and accountability.

Existing documentation of how the function is administered and overseen is good [RFC2860], [RFC6220]. Further articulation and clarity may be beneficial. It is important that the whole Internet community can understand how the function works, and that the

processes for registering parameters and holding those who oversee the protocol parameters function accountable for following those processes are understood by all interested parties. We are committed to making improvements here if necessary.

3. Any contemplated changes to the protocol parameters registries function should respect existing Internet community agreements.

The protocol parameters registries function is working well. The existing Memorandum of Understanding in RFC 2860 defines "the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force." Any modifications to the protocol parameters registries function should be made using the IETF process to update RFC 6220 and other relevant RFCs. Put quite simply: evolution, not revolution.

4. The Internet architecture requires and receives capable service by Internet registries.

The stability of the Internet depends on capable provision of not just IETF protocol parameters, but IP numbers, domain names, and other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. Thus we expect the role of the IETF in standards development, architectural guidance, and allocation of certain name/ number parameters to continue. IP multicast addresses and special- use DNS names are two examples where close coordination is needed. The IETF will continue to coordinate with ICANN, the RIRs, and other parties that are mutually invested in the continued smooth operation of the Internet registries. We fully understand the need to work together.

5. The IETF will continue management of the protocol parameter registry function as an integral component of the IETF standards process and the use of resulting protocols.

RFC 6220 specifies the role and function of the protocol parameters registry, which is critical to IETF standards processes and IETF protocols. The IAB, on behalf of the IETF, has the responsibility to define and manage the relationship with the protocol registry operator role. This responsibility includes the selection and management of the protocol parameter registry operator, as well as management of the parameter registration process and the guidelines for parameter allocation.

6. The protocol parameters registries are provided as a public service.

Directions for the creation of protocol parameters registries and the policies for subsequent additions and updates are specified in RFCs. The protocol parameters registries are available to everyone, and they are published in a form that allows their contents to be included in other works without further permission. These works include, but are not limited to, implementations of Internet protocols and their associated documentation.

These principles will guide the IAB, IAOC, and the rest of the IETF community as they work with ICANN to establish future IANA performance metrics and operational procedures.

  IV Transition Implications

  This section should describe what your community views as the
  implications of the changes it proposed in Section III. These
  implications may include some or all of the following, or other
  implications specific to your community:
   o Description of operational requirements to achieve continuity
     of service and possible new service integration throughout
     the transition.
   o Risks to operational continuity
   o Description of any legal framework requirements in the
     absence of the NTIA contract
   o Description of how you have tested or evaluated the
     workability of any new technical or operational methods
     proposed in this document and how they compare to established
     arrangements.

IETF Response:

No structural changes are required. The principles listed above will guide IAB, IAOC, and the rest of the IETF community as they work with ICANN to establish future IANA performance metrics and operational procedures, as they have in the past.

As no services are expected to change, no continuity issues are anticipated, and there are no new technical or operational methods proposed by the IETF to test. The IETF leadership, ICANN, and the RIRs maintain an ongoing informal dialog to spot any unforeseen issues that might arise as a result of other changes.

What is necessary as part of transition is the completion of any supplemental agreement(s) necessary to achieve the requirements outlined in our response in Section III of this RFP.

  V.  NTIA Requirements
  Additionally, NTIA has established that the transition proposal
  must meet the following five requirements:
  "Support and enhance the multistakeholder model;"

IETF Response:

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

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

IETF Response:

No changes are proposed in this document that affect the security, stability, and resiliency of the DNS.

  "Meet the needs and expectation of the global customers and
   partners of the IANA services;"

IETF Response:

Implementers and their users from around the world make use of the IETF standards and the associated IANA protocol parameters registries. The current IANA protocol parameters registries system is meeting the needs of these global customers. This proposal

continues to meet their needs by maintaining the existing processes that have served them well in the past.

  "Maintain the openness of the Internet."

IETF Response:

This proposal maintains the existing open framework that allows anyone to participate in the development of IETF standards, including the IANA protocol parameters registries policies. Further, an implementer anywhere in the world has full access to the protocol specification published in the RFC series and the protocol parameters registries published at iana.org. Those who require assignments in the IANA protocol registries will continue to be able to do so, as specified by the existing policies for those registries.

  VI.  Community Process
  This section should describe the process your community used for
  developing this proposal, including:
  o The steps that were taken to develop the proposal and to
    determine consensus.

IETF Response:

The IESG established the IANAPLAN working group to develop this response. Anyone was welcome to join the discussion and participate in the development of this response. An open mailing list (ianaplan@ietf.org) was associated with the working group. In addition, IETF's IANA practices have been discussed in the broader community, and all input is welcome.

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

IETF Response:

The following list is not exhaustive, as there have been many open discussions about this transition within the IETF community in the past few months.

Creation of an open mailing list to discuss the transition: http://w ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html

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

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

The working group discussion http://www.ietf.org/mail-archive/web/ ianaplan/current/maillist.html

Working group last call http://www.ietf.org/mail-archive/web/ ianaplan/current/msg00760.html

  An assessment of the level of consensus behind your community's
  proposal, including a description of areas of contention or
  disagreement.

IETF Response: To be completed as the process progresses.

3. IANA Considerations

This memo is a response a request for proposals. No parameter allocations or changes are sought.

4. Security Considerations

While the agreement, supplements, policies, and procedures around the IANA function have shown strong resiliency, the IETF will continue to work with all relevant parties to facilitate improvements while maintaining availability of the IANA registries.

5. IAB Note

This section to be filled in by the IAB.

6. Acknowledgments

This document describes processes that have been developed by many members of the community over many years. The initial version of this document was developed collaboratively through both the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew Sullivan, Leslie Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter, Greg Wood, John Curran, Milton Mueller, Alissa Cooper, Andrei Robachevsky, and Suzanne Woolf.

7. Informative References

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

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

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

[NTIA-Contract] , "The NTIA Contract with ICANN", , <http:// www.ntia.doc.gov/files/ntia/publications/ sf_26_pg_1-2-final_award_and_sacs.pdf>.

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

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

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

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

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

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

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

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

[RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC 3595, September 2003.

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

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

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

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

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

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

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

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

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

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

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

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

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

Appendix A. Changes

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

A.1. Changes from -05 to -06

Inclusion of agreed substantial comments from the AD.

Editorial changes.

A.2. Changes from -04 to -05

Change to simpler text for answer about stability and security.

Mention of RFC 5226bis.

A.3. Changes from -03 to -04

Additional text regarding what is needed in Section III.

Appropriate language modifications in section IV to match the

above changes in III.

Acknowledgments edits.

A.4. Changes from -02 to -03

Terminology consistency.

Add IAB section.

Changes based on WG discussion on what we prefer as part of the

transition regarding IPR.

Add discussion about .ARPA domain.

Elaboration of what registries are involved.

Additional text around coordination with ICANN.

Working groups can adopt items within their charters.

IAB appointments generally last two years.

Add mention of the Trust.

Security Considerations update.

A.5. Changes from -01 to -02

A better description special registries and BGP ASNs.

Clarity on how the address space and ASNs are delegated.

Many editorials corrected.

Mention of the annual review as part of the SLAs.

Change about how overlap is presented.

A number of small wording changes based on feedback.

A.6. Changes from -00 to -01

Front matter greatly reduced.

Appendices with charter and RFP added.

Jurisdiction text changed.

Proposed changes include supplemental agreement(s) to address

jurisdiction, dispute resolution, and IPR, including names and marks.

Transition implications slightly modified to reference

supplemental agreement.

Appendix B. The Charter of the IANA Stewardship Coordination Group (ICG

Charter for the IANA Stewardship Transition Coordination Group V.10

(August 27, 2014)

The IANA stewardship transition coordination group (ICG) has one deliverable: a proposal to the U.S. Commerce Department National Telecommunications and Information Administration (NTIA) regarding the transition of NTIA's stewardship of the IANA functions to the global multi-stakeholder community. The group will conduct itself transparently, consult with a broad range of stakeholders, and ensure that its proposals support the security and stability of the IANA functions.

The group's mission is to coordinate the development of a proposal among the communities affected by the IANA functions. The IANA functions are divided into three main categories: domain names, number resources, and other protocol parameters. The domain names category falls further into the country code and generic domain name sub-categories. While there is some overlap among all of these categories, each poses distinct organizational, operational and technical issues, and each tends to have distinct communities of interest and expertise. For those reasons it is best to have work on the three categories of IANA parameters proceed autonomously in parallel and be based in the respective communities.

The IANA stewardship transition process is taking place alongside a parallel and related process on enhancing ICANN accountability. While maintaining the accountability of Internet identifier governance is central to both processes, this group's scope is focused on the arrangements required for the continuance of IANA functions in an accountable and widely accepted manner after the expiry of the NTIA-ICANN contract. Nevertheless, the two processes are interrelated and interdependent and should appropriately coordinate their work.

The coordination group has four main tasks: (i) Act as liaison to all interested parties, including the three "operational communities" (i.e., those with direct operational or service relationship with IANA; namely names, numbers, protocol parameters). This task consists of: a. Soliciting proposals from the operational communities b. Soliciting the input of the broad group of communities affected by the IANA functions (ii) Assess the outputs of the three operational communities for compatibility and interoperability (iii) Assemble a complete proposal for the transition (iv) Information sharing and public communication Describing each in more detail: (i) Liaison a. Solicit proposals

The ICG expects a plan from the country code and generic name communities (possibly a joint one), a plan from the numbers community, and a plan from the protocol parameters community. Members of the ICG will ensure that the communities from which they are drawn are working on their part of the transition plans. This involves informing them of requirements and schedules, tracking progress, and highlighting the results or remaining issues. The role of a coordination group member during this phase is to provide status updates about the progress of his or her community in developing their component, and to coordinate which community will develop a transition proposal for each area of overlap (e.g., special-use registry).

While working on the development of their proposals, the operational communities are expected to address common requirements and issues relating to the transition, in as far as they affect their parts of the stewardship of IANA functions.

b. Solicit broader input

The ICG is open for input and feedback from all interested parties. While no set of formal requirements related to a transition proposal will be requested outside the operational communities, everyone's input is welcome across all topics.

The ICG expects that all interested parties get involved as early as possible in the relevant community processes. Input received directly by the ICG may be referred to the relevant community discussion.

The ICG members chosen from a particular community are the official communication channel between the ICG and that community.

(ii) Assessment

When the group receives output from the communities it will discuss and assess their compatibility and interoperability with the proposals of the other communities. Each proposal should be submitted with a clear record of how consensus has been reached for the proposal in the community, and provide an analysis that shows the proposal is in practice workable. The ICG should also compile the input it has received beyond the operational communities, and review the impacts of this input.

The ICG might at some point detect problems with the component proposals. At that point the role of the ICG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues. It is not in the role of the ICG to develop proposals or to select from among competing proposals.

(iii) Assembling and submitting a complete proposal

The assembly effort involves taking the proposals for the different components and verifying that the whole fulfills the intended scope, meets the intended criteria, that there are no missing parts, and that the whole fits together. The whole also needs to include sufficient independent accountability mechanisms for running the IANA function. The ICG will then develop a draft final proposal that achieves rough consensus within the ICG itself. The ICG will then put this proposal up for public comment involving a reasonable period of time for reviewing the draft proposal, analyzing and preparing supportive or critical comments. The ICG will then review these comments and determine whether modifications are required. If no modifications are needed, and the coordination group agrees, the proposal will be submitted to NTIA.

If changes are required to fix problems or to achieve broader support, the ICG will work with the operational communities in a manner similar to what was described in task (ii) above. Updates are subject to the same verification, review, and consensus processes as the initial proposals. If, in the ICG's opinion, broad public support for the proposal as articulated by the NTIA is not present, the parts of the proposal that are not supported return to the liaison phase.

(iv) Information sharing

The ICG serves as a central clearinghouse for public information about the IANA stewardship transition process. Its secretariat maintains an independent, publicly accessible and open website, under its own domain, where status updates, meetings and notices are announced, proposals are stored, the ICG members are listed, etc. As the development of the transition plans will take some time, it is important that information about ongoing work is distributed early and continuously. This will enable sharing of ideas and the detection of potential issues.

Appendix C. IANA Stewardship Transition Coordination Group Request for

Proposals

IANA Stewardship Transition Coordination Group Request for Proposals

8 September 2014

Introduction

Under the IANA1 Stewardship Transition Coordination Group (ICG) Charter,2 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 [2] as well as any other functions traditionally performed by the IANA functions operator. SAC-067

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

Authors' Addresses

Eliot Lear (editor)

Richtistrasse 7

Wallisellen, ZH CH-8304

Switzerland

Phone: +41 44 878 9200

Email: lear@cisco.com

Russ Housley (editor)

918 Spring Noll Drive

Herndon, VA 20170

USA

Email: housley@vigilsec.com

Difference between revisions of "Ianaplan - current draft"

Latest revision as of 21:42, 16 December 2014

Contents

Abstract

1. IETF Introduction

2. The Formal RFP Response

3. IANA Considerations

4. Security Considerations

5. IAB Note

6. Acknowledgments

7. Informative References

Appendix A. Changes

A.1. Changes from -05 to -06

A.2. Changes from -04 to -05

A.3. Changes from -03 to -04

A.4. Changes from -02 to -03

A.5. Changes from -01 to -02

A.6. Changes from -00 to -01

Appendix B. The Charter of the IANA Stewardship Coordination Group (ICG

Appendix C. IANA Stewardship Transition Coordination Group Request for

Authors' Addresses

Navigation menu

Personal tools

Namespaces

Variants

Views

Actions

Search

Navigation

Tools

@@ Line 1: / Line 1: @@
-{{IETF}}
-:IANAPLAN
-:Internet-Draft............................ R. Housley, Ed.
-:Intended status: Informational ........... November 26 2014
-:Expires: May 30 2015
-<center> Draft Response to the Internet Coordination Group Request for Proposals
-on the IANA protocol parameters registries<br/>draft-ietf-ianaplan-icg-response-06 </center>
-== Abstract ==
+:IANAPLAN                                                    E. Lear, Ed.
+:Internet-Draft                                           R. Housley, Ed.
-This document contains the IETF response to a request for proposals
+:Intended status: Informational                         November 26, 2014
-from the IANA Stewardship Transition Coordination Group regarding the
+:Expires: May 30, 2015
-protocol parameters registries.  It is meant to be included in an
-aggregate proposal that also includes contributions covering domain
-names and numbering resources that will be submitted from their
-respective operational communities.  The IETF community is invited to
-comment and propose changes to this document.
-== Status of This Memo  ==
-This Internet-Draft is submitted in full conformance with the
-provisions of BCP 78 and BCP 79.
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF).  Note that other groups may also distribute
-working documents as Internet-Drafts.  The list of current Internet-
-Drafts is at http://datatracker.ietf.org/drafts/current/.
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-This Internet-Draft will expire on May 30 2015.
-== Copyright Notice  ==
-Copyright (c) 2014 IETF Trust and the persons identified as the
-document authors.  All rights reserved.
-This document is subject to BCP 78 and the IETF Trust's Legal
-Provisions Relating to IETF Documents
-: (http://trustee.ietf.org/license-info) in effect on the date of
-publication of this document.  Please review these documents
-carefully, as they describe your rights and restrictions with respect
-to this document.  Code Components extracted from this document must
-include Simplified BSD License text as described in Section 4.e of
-the Trust Legal Provisions and are provided without warranty as
-described in the Simplified BSD License.
-Appendix B.  The Charter of the IANA Stewardship Coordination
+<center>Draft Response to the Internet Coordination Group Request for Proposals
-Group (ICG . . . . . . . . . . . . . . . . . . . . .
+on the IANA protocol parameters registries<br/>
-Appendix C.  IANA Stewardship Transition Coordination Group
+draft-ietf-ianaplan-icg-response-06</center>
-Request for Proposals  . . . . . . . . . . . . . . .  24
-Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30
+==Abstract==
-== 1.  IETF Introduction  ==
+This document contains the IETF response to a request for proposals
+from the IANA Stewardship Transition Coordination Group regarding the
-In March of 2014 the U.S.  National Telecommunications & Information
+protocol parameters registries.  It is meant to be included in an
-Administration (NTIA) announced its intent to transition oversight of
+aggregate proposal that also includes contributions covering domain
-Internet Assigned Numbers Authority (IANA) functions.  In that
+names and numbering resources that will be submitted from their
-announcement, NTIA asked the Internet Corporation for Assigned Names
+respective operational communities.  The IETF community is invited to
-and Numbers (ICANN) to establish a process to deliver a proposal for
+comment and propose changes to this document.
-transition.  As part of that process, the IANA Stewardship Transition
-Coordination Group (ICG) was formed.  The charter for the ICG can be
+==1.  IETF Introduction==
-found in Appendix B.  They solicited proposals regarding post-
-transition arrangements from the three functional areas in order to
+In March of 2014 the U.S.  National Telecommunications & Information
-put forth a proposal to the NTIA.  The final request for proposal
+Administration (NTIA) announced its intent to transition oversight of
-(RFP) can be found in Appendix C.
+Internet Assigned Numbers Authority (IANA) functions.  In that
+announcement, NTIA asked the Internet Corporation for Assigned Names
-While there are interactions between all of the IANA functions and
+and Numbers (ICANN) to establish a process to deliver a proposal for
-IETF standards, this document specifically addresses the protocol
+transition.  As part of that process, the IANA Stewardship Transition
-parameters registries function.  Section 1 (this section) contains an
+Coordination Group (ICG) was formed.  The charter for the ICG can be
-introduction that is sourced solely within the IETF.  Section 2
+found in Appendix B.  They solicited proposals regarding post-
-contains the questionnaire that was written by the ICG and a formal
+transition arrangements from the three functional areas in order to
-response by the IETF.  Because much of this memo is taken from a
+put forth a proposal to the NTIA.  The final request for proposal
-questionnaire we have quoted questions with ">>> " and we have
+(RFP) can be found in Appendix C.
-prefaced answers to questions being asked with "IETF Response:."
+While there are interactions between all of the IANA functions and
-Note that there are small changes to the content of the questions
+IETF standards, this document specifically addresses the protocol
-asked in order to match the RFC format.
+parameters registries function.  Section 1 (this section) contains an
+introduction that is sourced solely within the IETF.  Section 2
-As if to demonstrate the last point, the following text was included
+contains the questionnaire that was written by the ICG and a formal
-in a footnote in the original RFP:
+response by the IETF.  Because much of this memo is taken from a
+questionnaire we have quoted questions with "   " and we have
-In this RFP, IANA refers to the functions currently specified in
+prefaced answers to questions being asked with "IETF Response:".
-the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/
-iana-functions-purchase-order] as well as any other functions
+Note that there are small changes to the content of the questions
-traditionally performed by the IANA functions operator.  SAC-067
+asked in order to match the RFC format.
-[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
+As if to demonstrate the last point, the following text was included
-may be useful reading in addition to the documents constituting the
+in a footnote in the original RFP:
-agreement itself.
+In this RFP, "IANA" refers to the functions currently specified in
-== 2.  The Formal RFP Response  ==
+the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/
+iana-functions-purchase-order] as well as any other functions
-The entire Request for Proposals, including introduction, can be
+traditionally performed by the IANA functions operator.  SAC-067
-found in Appendix C.
+[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
-  >>> 0. Proposal Type
+agreement itself.
-  >>>
-  >>> Identify which category of the IANA functions this
+==2.  The Formal RFP Response==
-  >>> submission proposes to address:
-  >>>
+The entire Request for Proposals, including introduction, can be
+found in Appendix C.
-IETF Response:
-[XXX] Protocol Parameters
+. Proposal Type
+   Identify which category of the IANA functions this
-This response states the existing practice of the IETF, and also
+   submission proposes to address:
-represents the views of the Internet Architecture Board and the IETF.
+IETF Response:
-  >>>
+[XXX] Protocol Parameters
-  >>> I. Description of Community's Use of IANA Functions
-  >>>
+This response states the existing practice of the IETF, and also
-  >>> This section should list the specific, distinct IANA services
+represents the views of the Internet Architecture Board and the IETF.
-  >>> or activities your community relies on. For each IANA service
-  >>> or activity on which your community relies, please provide the
+   I. Description of Community's Use of IANA Functions
-  >>> following:
+   This section should list the specific, distinct IANA services
-  >>> A description of the service or activity.
+   or activities your community relies on. For each IANA service
-  >>>
+   or activity on which your community relies, please provide the
+   following:
-IETF Response:
+   A description of the service or activity.
-Many IETF protocols make use of commonly defined protocol parameters.
+IETF Response:
-These parameters are used by implementers, who are the primary users
-of the IETF standards and other documents.  To ensure consistent
+Many IETF protocols make use of commonly defined protocol parameters.
-interpretation of these parameter values by independent
+These parameters are used by implementers, who are the primary users
-implementations, and to promote universal interoperability, these
+of the IETF standards and other documents.  To ensure consistent
-IETF protocol specifications define and require globally available
+interpretation of these parameter values by independent
-registries containing the parameter values and a pointer to any
+implementations, and to promote universal interoperability, these
-associated documentation.  The IETF uses the IANA protocol parameters
+IETF protocol specifications define and require globally available
-registries to store this information in a public location.  The IETF
+registries containing the parameter values and a pointer to any
-community presently accesses the protocol parameter registries via
+associated documentation.  The IETF uses the IANA protocol parameters
-references based on iana.org domain name, and makes use of the term
+registries to store this information in a public location.  The IETF
-IANA in the protocol parameter registry processes [RFC5226].
+community presently accesses the protocol parameter registries via
+references based on iana.org domain name, and makes use of the term
-ICANN currently operates the .ARPA top level domain on behalf of the
+"IANA" in the protocol parameter registry processes [RFC5226].
-Internet Architecture Board (IAB).  This zone is used for certain
-Internet infrastructure services that are delegated beneath it.  We
+ICANN currently operates the .ARPA top level domain on behalf of the
-consider .ARPA part of the protocol parameters registries for
+Internet Architecture Board (IAB).  This zone is used for certain
-purposes of this response.
+Internet infrastructure services that are delegated beneath it.  We
+consider .ARPA part of the protocol parameters registries for
-  >>>
+purposes of this response.
-  >>> A description of the customer(s) of the service or activity.
-  >>>
+   A description of the customer(s) of the service or activity.
 IETF Response:
 The IANA protocol parameters registries operator maintains the
 protocol parameters registries for the IETF in conformance with all
 relevant IETF policies, in accordance with the Memorandum of
 Understanding [RFC2860] and associated supplemental agreements that
 include service level agreements (SLAs) established between the IETF
 and ICANN [MOUSUP].
 The IETF is a global organization that produces voluntary standards,
 whose goal is to make the Internet work better [RFC3595].  IETF
 standards are published in the RFC series.  The IETF is responsible
 for the key standards that are used on the Internet today, including
 IP, TCP, DNS, BGP, and HTTP, to name but a few.
 The IETF operates in an open and transparent manner [RFC6852].  The
 processes that govern the IETF are also published in the RFC series.
 The Internet Standards Process is documented in [RFC2026].  That
 document explains not only how standards are developed, but also how
 disputes about decisions are resolved.  RFC 2026 has been amended a
 number of times, and those amendments are indicated in [RFC-INDEX].
 The standards process can be amended in the same manner that
 standards are approved.  That is, someone proposes a change by
 submitting a temporary document known as an Internet-Draft, the
-community discusses it, and if rough consensus can be found the
-change is approved by the Internet Engineering Steering Group (IESG),
+community discusses it, and if rough consensus can be found the
-who also have day-to-day responsibility for declaring IETF consensus
+change is approved by the Internet Engineering Steering Group (IESG),
-on technical decisions, including those that affect the IANA protocol
+who also have day-to-day responsibility for declaring IETF consensus
-parameters registries.  Anyone may propose a change during a Last
+on technical decisions, including those that affect the IANA protocol
-Call, and anyone may participate in the community discussion.
+parameters registries.  Anyone may propose a change during a Last
+Call, and anyone may participate in the community discussion.
-  >>> 21
-  >>> What registries are involved in providing the service or
+   What registries are involved in providing the service or
-  >>> activity.
+   activity.
-  >>>
+IETF Response:
-IETF Response:
+The protocol parameters registries are the product of IETF work.
-The protocol parameters registries are the product of IETF work.
+These also include the top-level registry for the entire IP address
-These also include the top-level registry for the entire IP address
+space and some of its sub-registries, autonomous system number space,
-space and some of its sub-registries, autonomous system number space,
+and a number of special use registries with regard to domain names.
-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.
+interdependencies" section.
 Administration of the protocol parameters registries is the service
 that is provided to the IETF.
-  >>>
+   A description of any overlaps or interdependencies between your
-  >>> A description of any overlaps or interdependencies between your
+   IANA requirements and the functions required by other customer
-  >>> IANA requirements and the functions required by other customer
+   communities
-  >>> communities
-  >>>
+IETF Response:
-IETF Response:
+In this context, the IETF considers "overlap" to be where there is in
+some way shared responsibility for a single registry across multiple
-In this context, the IETF considers overlap to be where there is in
+organizations.  In this sense, there is no overlap between
-some way shared responsibility for a single registry across multiple
+organizations because responsibility for each registry is carefully
-organizations.  In this sense, there is no overlap between
+delineated.  There are, however, points of interaction between other
-organizations because responsibility for each registry is carefully
+organizations, and a few cases where we may further define the scope
-delineated.  There are, however, points of interaction between other
+of a registry for technical purposes.  This is the case with both
-organizations, and a few cases where we may further define the scope
+names and numbers, as described in the paragraphs below.  In all
-of a registry for technical purposes.  This is the case with both
+cases, the IETF coordinates with the appropriate organizations.
-names and numbers, as described in the paragraphs below.  In all
-cases, the IETF coordinates with the appropriate organizations.
+It is important to note that the IETF includes anyone who wishes to
+participate.  Staff and participants from ICANN or the Regional
-It is important to note that the IETF includes anyone who wishes to
+Internet Registries (RIRs) regularly participate in IETF activities.
-participate.  Staff and participants from ICANN or the Regional
-Internet Registries (RIRs) regularly participate in IETF activities.
+*The IETF has specified a number of special use registries with
+regard to domain names.  These registries require coordination
-o  The IETF has specified a number of special use registries with
+with ICANN as the policy authority for the DNS root, including
-regard to domain names.  These registries require coordination
+community groups that are responsible for ICANN policy on domain
-with ICANN as the policy authority for the DNS root, including
+names such as the Generic Names Supporting Organization (GNSO) and
-community groups that are responsible for ICANN policy on domain
+the Country Code Names Supporting Organization (ccNSO).  There are
-names such as the Generic Names Supporting Organization (GNSO) and
+already mechanisms in place to perform this coordination, and the
-the Country Code Names Supporting Organization (ccNSO).  There are
+capacity to modify them to meet new conditions as they might
-already mechanisms in place to perform this coordination, and the
+arise.  [RFC6761]
-capacity to modify them to meet new conditions as they might
-arise.  [RFC6761]
+*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
-o  The IETF specifies the DNS protocol.  From time to time there have
+will broadly consult the operational community about the impact of
-been and will be updates to that protocol.  As we make changes we
+those changes, as we have done in the past.
-will broadly consult the operational community about the impact of
-those changes, as we have done in the past.
+*The IETF specifies minimum requirements for root servers.
+[RFC2870] Those requirements are currently under review, in
-o  The IETF specifies minimum requirements for root servers.
+consultations with the root server community.
-[RFC2870] Those requirements are currently under review, in
-consultations with the root server community.
+*The routing architecture has evolved over time, and is expected to
+continue to do so.  Such evolution may have an impact on
-o  The routing architecture has evolved over time, and is expected to
+appropriate IP address allocation strategies.  As and when that
-continue to do so.  Such evolution may have an impact on
+happens, we will consult with the RIR community, as we have done
-appropriate IP address allocation strategies.  As and when that
+in the past.
-happens, we will consult with the RIR community, as we have done
-in the past.
+*The IETF is responsible for policy relating to the entire IP
+address space and AS number space.  Through the IANA protocol
-o  The IETF is responsible for policy relating to the entire IP
+parameters registries, the IETF delegates unicast IP address and
-address space and AS number space.  Through the IANA protocol
+AS number ranges to the RIR system [RFC7020],[RFC7249].  Special
-parameters registries, the IETF delegates unicast IP address and
+address allocation, such as multicast and anycast addresses, often
-AS number ranges to the RIR system [RFC7020],[RFC7249].  Special
+require coordination.  Another example of IP addresses that are
-address allocation, such as multicast and anycast addresses, often
+not administered by the RIR system is Unique Local Addresses
-require coordination.  Another example of IP addresses that are
+(ULAs) [RFC4193], where local networks employ a prefix that is not
-not administered by the RIR system is Unique Local Addresses
+intended to be routed on the public Internet.  New special address
-(ULAs) [RFC4193], where local networks employ a prefix that is not
+allocations are added, from time to time, related to the evolution
-intended to be routed on the public Internet.  New special address
+of the standards.  In all cases, these special assignments are
-allocations are added, from time to time, related to the evolution
+listed in the IANA protocol paramters registries.
-of the standards.  In all cases, these special assignments are
-listed in the IANA protocol paramters registries.
+*The IETF maintains sub-registries for special IPv4 and IPv6
+assignments.  These are specified in [RFC3307], [RFC5771], and
-o  The IETF maintains sub-registries for special IPv4 and IPv6
+[RFC6890].  The IETF coordinates such assignments with the RIRs.
-assignments.  These are specified in [RFC3307], [RFC5771], and
-[RFC6890].  The IETF coordinates such assignments with the RIRs.
+*IETF standards changes may have impact on operations of RIRs and
+service providers.  A recent example is the extensions to BGP to
-o  IETF standards changes may have impact on operations of RIRs and
+carry the Autonomous System numbers as four-octet entities
-service providers.  A recent example is the extensions to BGP to
+[RFC6793].  It is important to note that this change occurred out
-carry the Autonomous System numbers as four-octet entities
+of operational necessity, and it demonstrated strong alignment
-[RFC6793].  It is important to note that this change occurred out
+between the RIRs and the IETF.
-of operational necessity, and it demonstrated strong alignment
-between the RIRs and the IETF.
+   II.  Existing, Pre-Transition Arrangements
-  >>> II.  Existing, Pre-Transition Arrangements
+   This section should describe how existing IANA-related
+   arrangements work, prior to the transition.
-  >>>
+   A. Policy Sources
-  >>> This section should describe how existing IANA-related
+   This section should identify the specific source(s) of policy
-  >>> arrangements work, prior to the transition.
+   which must be followed by the IANA functions operator in its
-  >>>
+   conduct of the services or activities described above.  If there
-  >>> A. Policy Sources
+   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,
-  >>> This section should identify the specific source(s) of policy
+   please provide the following:
-  >>> which must be followed by the IANA functions operator in its
+   Which IANA service or activity (identified in Section I) is
-  >>> conduct of the services or activities described above.  If there
+   affected.
-  >>> are distinct sources of policy or policy development for
-  >>> different IANA activities, then please describe these
+IETF Response: The protocol parameters registries.
-  >>> separately. For each source of policy or policy development,
-  >>> please provide the following:
+   A description of how policy is developed and established and
-  >>>
+   who is involved in policy development and establishment.
-  >>> Which IANA service or activity (identified in Section I) is
-  >>> affected.
+IETF Response:
-  >>>
+Policy for overall management of the protocol parameters registries
-IETF Response: The protocol parameters registries.
+is stated in [RFC6220] and [RFC5226].  The first of these documents
+explains the model for how the registries are to be operated, how
-  >>>
+policy is set, and how oversight takes place.  RFC 5226 specifies the
-  >>> A description of how policy is developed and established and
+policies that specification writers may employ when they define new
-  >>> who is involved in policy development and establishment.
+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
-IETF Response:
+there is sufficient interest, a working group whose scope includes
+the proposed work may choose to adopt it, the IESG may choose to
-Policy for overall management of the protocol parameters registries
+create a working group, or an Area Director may choose to sponsor the
-is stated in [RFC6220] and [RFC5226].  The first of these documents
+draft.  In any case, anyone may comment on the proposal as it
-explains the model for how the registries are to be operated, how
+progresses.  A proposal cannot be passed by the IESG unless it enjoys
-policy is set, and how oversight takes place.  RFC 5226 specifies the
+sufficient community support as to indicate rough consensus
-policies that specification writers may employ when they define new
+[RFC7282].  In each case, a "Last Call" is made so that there is
-protocol registries in the "IANA Considerations" section of each
+notice of any proposed change to a policy or process.  Anyone may
-specification.  All policies at the IETF begin with a proposal in the
-form of an Internet-Draft.  Anyone may submit such a proposal.  If
+comment during a Last Call.  For example, this process is currently
-there is sufficient interest, a working group whose scope includes
+being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis].
-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
+   A description of how disputes about policy are resolved.
-draft.  In any case, anyone may comment on the proposal as it
-progresses.  A proposal cannot be passed by the IESG unless it enjoys
+IETF Response:
-sufficient community support as to indicate rough consensus
-[RFC7282].  In each case, a "Last Call" is made so that there is
+Most disputes are handled at the lowest level through the working
-notice of any proposed change to a policy or process.  Anyone may
+group and rough consensus processes.  Should anyone disagree with any
-comment during a Last Call.  For example, this process is currently
+action, Section 6.5 of [RFC2026] specifies a multi-level conflict
-being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis].
+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
-  >>> A description of how disputes about policy are resolved.
+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.
-IETF Response:
+   References to documentation of policy development and dispute
-Most disputes are handled at the lowest level through the working
+   resolution processes.
-group and rough consensus processes.  Should anyone disagree with any
-action, Section 6.5 of [RFC2026] specifies a multi-level conflict
+IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a
-resolution and appeals process that includes the responsible Area
+conflict resolution and appeals process.  [RFC2418] specifies working
-Director, the IESG, and the IAB.  Should appeals be upheld, an
+group procedures.  Note that both of these documents have been
-appropriate remedy is applied.  In the case where someone claims that
+amended in later RFCs as indicated in the [RFC-INDEX].  Please also
-the procedures themselves are insufficient or inadequate in some way
+see the references at the bottom of this document.
-to address a circumstance, one may appeal an IAB decision to the
-Internet Society Board of Trustees.
+   B. Oversight and Accountability
+   This section should describe all the ways in which oversight is
-  >>>
+   conducted over IANA functions operator's provision of the
-  >>> References to documentation of policy development and dispute
+   services and activities listed in Section I and all the ways in
-  >>> resolution processes.
+   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
-IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a
+   following as are applicable:
-conflict resolution and appeals process.  [RFC2418] specifies working
+   Which IANA service or activity (identified in Section I) is
-group procedures.  Note that both of these documents have been
+   affected.
-amended in later RFCs as indicated in the [RFC-INDEX].  Please also
-see the references at the bottom of this document.
+IETF Response: the protocol parameters registries.
-  >>>
+   If not all policy sources identified in Section II.A are
-  >>> B. Oversight and Accountability
+   affected, identify which ones are affected.
-  >>>
-  >>> This section should describe all the ways in which oversight is
+IETF Response: all policy sources relating to the protocol parameters
-  >>> conducted over IANA functions operator's provision of the
+registry are affected.
-  >>> services and activities listed in Section I and all the ways in
-  >>> which IANA functions operator is currently held accountab le for
+   A description of the entity or entities that provide oversight
-  >>> the provision of those services. For each oversight or
+   or perform accountability functions, including how individuals
-  >>> accountability mechanism, please provide as many of the
+   are selected or removed from participation in those entities.
-  >>> following as are applicable:
-  >>>
+IETF Response:
-  >>> Which IANA service or activity (identified in Section I) is
-  >>> affected.
+The Internet Architecture Board (IAB) is an oversight body of the
-  >>>
+IETF whose responsibilities include, among other things, confirming
-IETF Response: the protocol parameters registries.
+appointment of IESG members, managing appeals as discussed above,
+management of certain domains, including .ARPA [RFC3172], and general
-  >>>
+architectural guidance to the broader community.  The IAB must
-  >>> If not all policy sources identified in Section II.A are
+approve the appointment of an organization to act as IANA operator on
-  >>> affected, identify which ones are affected.
+behalf of the IETF.  The IAB is also responsible for establishing
-  >>>
+liaison relationships with other organizations on behalf of the IETF.
+The IAB's charter is to be found in [RFC2850].
-IETF Response: all policy sources relating to the protocol parameters
-registry are affected.
+The IAB members are selected and may be recalled through a Nominating
+Committee (NOMCOM) process, which is described in [RFC3777].  This
-  >>>
+process provides for selection of active members of the community who
-  >>> A description of the entity or entities that provide oversight
+themselves agree upon a slate of candidates.  The active members are
-  >>> or perform accountability functions, including how individuals
+chosen randomly from volunteers with a history of participation in
-  >>> are selected or removed from participation in those entities.
+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
-IETF Response:
+that the correct procedure was followed.  The slate of candidates
+selected by the active members are sent to the Internet Society Board
-The Internet Architecture Board (IAB) is an oversight body of the
+of Trustees for confirmation.  In general, members are appointed for
-IETF whose responsibilities include, among other things, confirming
+terms of two years.  The IAB selects its own chair.
-appointment of IESG members, managing appeals as discussed above,
-management of certain domains, including .ARPA [RFC3172], and general
+The IAB provides oversight of the protocol parameters registries of
-architectural guidance to the broader community.  The IAB must
+the IETF, and is responsible for selecting appropriate operator(s)
-approve the appointment of an organization to act as IANA operator on
+and related per-registry arrangements.  Especially when relationships
-behalf of the IETF.  The IAB is also responsible for establishing
+among protocols call for it, many registries are operated by, or in
-liaison relationships with other organizations on behalf of the IETF.
+conjunction with, other bodies.  Unless the IAB or IETF has concluded
-The IAB's charter is to be found in [RFC2850].
+that special treatment is needed, the operator for registries is
-The IAB members are selected and may be recalled through a Nominating
+currently ICANN.
-Committee (NOMCOM) process, which is described in [RFC3777].  This
-process provides for selection of active members of the community who
+   A description of the mechanism (e.g., contract, reporting
-themselves agree upon a slate of candidates.  The active members are
+   scheme, auditing scheme, etc.). This should include a
-chosen randomly from volunteers with a history of participation in
+   description of the consequences of the IANA functions operator
-the IETF, with limits regarding having too many active members with
+   not meeting the standards established by the mechanism, the
-the same affiliation.  The selection of the active members is
+   extent to which the output of the mechanism is transparent and
-performed in a manner that makes it possible for anyone to verify
+   the terms under which the mechanism may change.
-that the correct procedure was followed.  The slate of candidates
-selected by the active members are sent to the Internet Society Board
+IETF Response:
-of Trustees for confirmation.  In general, members are appointed for
-terms of two years.  The IAB selects its own chair.
+A memorandum of understanding (MoU) between ICANN and the IETF
+community has been in place since 2000.  It can be found in
-The IAB provides oversight of the protocol parameters registries of
+[RFC2860].  The MoU defines the work to be carried out by the IANA
-the IETF, and is responsible for selecting appropriate operator(s)
+functions operator for the IETF and the Internet Research Task Force
-and related per-registry arrangements.  Especially when relationships
+(IRTF), a peer organization to the IETF that focuses on research.
-among protocols call for it, many registries are operated by, or in
+Each year a service level agreement is negotiated that supplements
-conjunction with, other bodies.  Unless the IAB or IETF has concluded
+the MoU.
-that special treatment is needed, the operator for registries is
-currently ICANN.
+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
-  >>> A description of the mechanism (e.g., contract, reporting
+members of the IAOC are also the trustees of the IETF Trust, whose
-  >>> scheme, auditing scheme, etc.). This should include a
+main purpose is to hold certain intellectual property for the benefit
-  >>> description of the consequences of the IANA functions operator
+of the IETF as a whole.  IAOC members are appointed by the Internet
-  >>> not meeting the standards established by the mechanism, the
+Society Board of Trustees, the IAB, the IESG, and the NOMCOM
-  >>> extent to which the output of the mechanism is transparent and
+[RFC4071].  The IAOC works with the IANA functions operator to
-  >>> the terms under which the mechanism may change.
+establish annual IANA performance metrics [METRICS] and operational
-  >>>
+procedures, and the resulting document is adopted as an supplement to
+the MoU each year [MOUSUP].  Starting from 2014, in accordance with
-IETF Response:
+these supplements, an annual audit is performed to ensure that
+protocol parameter requests are being processed according to the
-===  A memorandum of understanding (MoU) between ICANN and the IETF ===
+established policies.  The conclusions of this audit will be
-community has been in place since 2000.  It can be found in
+available for anyone in the world to review.
-[RFC2860].  The MoU defines the work to be carried out by the IANA
-functions operator for the IETF and the Internet Research Task Force
+To date there have been no unresolvable disputes or issues.  In the
-: (IRTF), a peer organization to the IETF that focuses on research.
+unlikely event that a more difficult situation should arise, the IAOC
-Each year a service level agreement is negotiated that supplements
+and the IAB would engage ICANN management to address the matter.  The
-the MoU.
+MoU also provides an option for either party to terminate the
+arrangement with six months notice.  Obviously such action would only
-Day-to-day administration and contract management is the
+be undertaken after serious consideration.
-responsibility of the IETF Administrative Director (IAD).  The IETF
-Administrative Oversight Committee (IAOC) oversees the IAD.  The
+    Jurisdiction(s) in which the mechanism applies and the legal
-members of the IAOC are also the trustees of the IETF Trust, whose
-main purpose is to hold certain intellectual property for the benefit
+    basis on which the mechanism rests.
-of the IETF as a whole.  IAOC members are appointed by the Internet
-Society Board of Trustees, the IAB, the IESG, and the NOMCOM
+IETF Response
-[RFC4071].  The IAOC works with the IANA functions operator to
-establish annual IANA performance metrics [METRICS] and operational
+This mechanism is global in nature.  The current agreement does not
-procedures, and the resulting document is adopted as an supplement to
+specify a jurisdiction.
-the MoU each year [MOUSUP].  Starting from 2014 in accordance with
-these supplements, an annual audit is performed to ensure that
+   III.  Proposed Post-Transition Oversight and Accountability
-protocol parameter requests are being processed according to the
+Arrangements
-established policies.  The conclusions of this audit will be
-available for anyone in the world to review.
+   This section should describe what changes your community is
+   proposing to the arrangements listed in Section II.B in light of
-To date there have been no unresolvable disputes or issues.  In the
+   the transition. If your community is proposing to replace one or
-unlikely event that a more difficult situation should arise, the IAOC
+   more existing arrangements with new arrangements, that
-and the IAB would engage ICANN management to address the matter.  The
+   replacement should be explained and all of the elements listed
-MoU also provides an option for either party to terminate the
+   in Section II.B should be described for the new
-arrangement with six months notice.  Obviously such action would only
+   arrangements. Your community should provide its rationale and
-be undertaken after serious consideration.
+   justification for the new arrangements.
+   If your community's proposal carries any implications for
-  >>>
+   existing policy arrangements described in Section II.A, those
-  >>>  Jurisdiction(s) in which the mechanism applies and the legal
+   implications should be described here.
-  >>>  basis on which the mechanism rests.
+   If your community is not proposing changes to arrangements
-  >>>
+   listed in Section II.B, the rationale and justification for that
+   choice should be provided here.
-IETF Response
+IETF Response:
-This mechanism is global in nature.  The current agreement does not
-specify a jurisdiction.
+No major changes are required.  Over the years since the creation of
+ICANN, the IETF, ICANN, and IAB have together created a system of
-   >>>III.  Proposed Post-Transition Oversight and Accountability
+agreements, policies, and oversight mechanisms that already cover
-Arrangements
+what is needed.  This system has worked well without any operational
+involvement from the NTIA.  Therefore, no new organizaitons or
-  >>>
+structures are needed.
-  >>> This section should describe what changes your community is
-  >>> proposing to the arrangements listed in Section II.B in light of
+IANA protocol parameters registry updates will continue to function
-  >>> the transition. If your community is proposing to replace one or
+day-to-day, as they have been doing for the last decade or more.  The
-  >>> more existing arrangements with new arrangements, that
+IETF community is quite satisfied with the current arrangement with
-  >>> replacement should be explained and all of the elements listed
+ICANN.  RFC 2860 remains in force and has served the IETF community
-  >>> in Section II.B should be described for the new
+very well.  RFC 6220 has laid out an appropriate service description
-  >>> arrangements. Your community should provide its rationale and
+and requirements.
-  >>> justification for the new arrangements.
-  >>>
+However in the absence of the NTIA contract a few new arrangements
-  >>> If your community's proposal carries any implications for
+may be needed in order to ensure the IETF community's expectations
-  >>> existing policy arrangements described in Section II.A, those
+are met.  Those expectations are the following:
-  >>> implications should be described here.
-  >>>
+*The protocol parameters registries are in the public domain.  It
-  >>> If your community is not proposing changes to arrangements
+is the preference of the IETF community that all relevant parties
-  >>> listed in Section II.B, the rationale and justification for that
+acknowledge that fact as part of the transition.
-  >>> choice should be provided here.
-  >>>
+*It is possible in the future that the operation of the protocol
+parameters registries may be transitioned from ICANN to subsequent
-IETF Response:
+operator(s).  It is the preference of the IETF community that, as
+part of the NTIA transition, ICANN acknowledge that it will carry
-No major changes are required.  Over the years since the creation of
+out the obligations established under C.7.3 and I.61 of the
-ICANN, the IETF, ICANN, and IAB have together created a system of
+current IANA functions contract between ICANN and the NTIA
-agreements, policies, and oversight mechanisms that already cover
+[NTIA-Contract] to achieve a smooth transition to subsequent
-what is needed.  This system has worked well without any operational
+operator(s), should the need arise.  Furthermore, in the event of
-involvement from the NTIA.  Therefore, no new organizaitons or
+a transition it is the expectation of the IETF community that
-structures are needed.
+ICANN, the IETF, and subsequent operator(s) will work together to
+minimize disruption in the use the protocol parameters registries
-IANA protocol parameters registry updates will continue to function
+or other resources currently located at iana.org.
-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
+Discussions during the IETF 89 meeting in London led to the following
-ICANN.  RFC 2860 remains in force and has served the IETF community
+guiding principles for IAB efforts that impact IANA protocol
-very well.  RFC 6220 has laid out an appropriate service description
+parameter registries.  These principles must be taken together; their
-and requirements.
+order is not significant.
-However in the absence of the NTIA contract a few new arrangements
+.  The IETF protocol parameters registries function has been and
-may be needed in order to ensure the IETF community's expectations
+continues to be capably provided by the Internet technical community.
-are met.  Those expectations are the following:
+The strength and stability of the function and its foundation within
-o  The protocol parameters registries are in the public domain.  It
+the Internet technical community are both important given how
-is the preference of the IETF community that all relevant parties
+critical protocol parameters are to the proper functioning of IETF
-acknowledge that fact as part of the transition.
+protocols.
-o  It is possible in the future that the operation of the protocol
+We think the structures that sustain the protocol parameters
-parameters registries may be transitioned from ICANN to subsequent
+registries function need to be strong enough that they can be offered
-operator(s).  It is the preference of the IETF community that, as
+independently by the Internet technical community, without the need
-part of the NTIA transition, ICANN acknowledge that it will carry
+for backing from external parties.  And we believe we largely are
-out the obligations established under C.7.3 and I.61 of the
+there already, although the system can be strengthened further, and
-current IANA functions contract between ICANN and the NTIA
+continuous improvements are being made.
-[NTIA-Contract] to achieve a smooth transition to subsequent
-operator(s), should the need arise.  Furthermore, in the event of
+.  The protocol parameters registries function requires openness,
-a transition it is the expectation of the IETF community that
+transparency, and accountability.
-ICANN, the IETF, and subsequent operator(s) will work together to
-minimize disruption in the use the protocol parameters registries
+Existing documentation of how the function is administered and
-or other resources currently located at iana.org.
+overseen is good [RFC2860], [RFC6220].  Further articulation and
+clarity may be beneficial.  It is important that the whole Internet
-Discussions during the IETF 89 meeting in London led to the following
+community can understand how the function works, and that the
-guiding principles for IAB efforts that impact IANA protocol
-parameter registries.  These principles must be taken together; their
+processes for registering parameters and holding those who oversee
-order is not significant.
+the protocol parameters function accountable for following those
+processes are understood by all interested parties.  We are committed
-===  1.  The IETF protocol parameters registries function has been and  ===
+to making improvements here if necessary.
-continues to be capably provided by the Internet technical community.
+.  Any contemplated changes to the protocol parameters registries
-The strength and stability of the function and its foundation within
+function should respect existing Internet community agreements.
-the Internet technical community are both important given how
-critical protocol parameters are to the proper functioning of IETF
+The protocol parameters registries function is working well.  The
-protocols.
-We think the structures that sustain the protocol parameters
-registries function need to be strong enough that they can be offered
-independently by the Internet technical community, without the need
-for backing from external parties.  And we believe we largely are
-there already, although the system can be strengthened further, and
-continuous improvements are being made.
-===  2.  The protocol parameters registries function requires openness,  ===
-transparency, and accountability.
-Existing documentation of how the function is administered and
-overseen is good [RFC2860], [RFC6220].  Further articulation and
-clarity may be beneficial.  It is important that the whole Internet
-community can understand how the function works, and that the
-processes for registering parameters and holding those who oversee
-the protocol parameters function accountable for following those
-processes are understood by all interested parties.  We are committed
-to making improvements here if necessary.
-===  3.  Any contemplated changes to the protocol parameters registries ===
-function should respect existing Internet community agreements.
-The protocol parameters registries function is working well.  The
 existing Memorandum of Understanding in RFC 2860 defines "the
-  technical work to be carried out by the Internet Assigned Numbers
+technical work to be carried out by the Internet Assigned Numbers
-  Authority on behalf of the Internet Engineering Task Force and the
+Authority on behalf of the Internet Engineering Task Force and the
-  Internet Research Task Force."  Any modifications to the protocol
+Internet Research Task Force."  Any modifications to the protocol
 parameters registries function should be made using the IETF process
 to update RFC 6220 and other relevant RFCs.  Put quite simply:
 evolution, not revolution.
-===  4.  The Internet architecture requires and receives capable service ===
+.  The Internet architecture requires and receives capable service
 by Internet registries.
 The stability of the Internet depends on capable provision of not
 just IETF protocol parameters, but IP numbers, domain names, and
 other registries.  Furthermore, DNS and IPv4/IPv6 are IETF-defined
 protocols.  Thus we expect the role of the IETF in standards
 development, architectural guidance, and allocation of certain name/
 number parameters to continue.  IP multicast addresses and special-
 use DNS names are two examples where close coordination is needed.
 The IETF will continue to coordinate with ICANN, the RIRs, and other
 parties that are mutually invested in the continued smooth operation
 of the Internet registries.  We fully understand the need to work
 together.
-===  5.  The IETF will continue management of the protocol parameter  ===
+.  The IETF will continue management of the protocol parameter
 registry function as an integral component of the IETF standards
 process and the use of resulting protocols.
 RFC 6220 specifies the role and function of the protocol parameters
 registry, which is critical to IETF standards processes and IETF
 protocols.  The IAB, on behalf of the IETF, has the responsibility to
 define and manage the relationship with the protocol registry
 operator role.  This responsibility includes the selection and
 management of the protocol parameter registry operator, as well as
 management of the parameter registration process and the guidelines
 for parameter allocation.
-===  6.  The protocol parameters registries are provided as a public  ===
+.  The protocol parameters registries are provided as a public
 service.
 Directions for the creation of protocol parameters registries and the
 policies for subsequent additions and updates are specified in RFCs.
 The protocol parameters registries are available to everyone, and
 they are published in a form that allows their contents to be
 included in other works without further permission.  These works
 include, but are not limited to, implementations of Internet
 protocols and their associated documentation.
 These principles will guide the IAB, IAOC, and the rest of the IETF
 community as they work with ICANN to establish future IANA
 performance metrics and operational procedures.
-  >>> IV Transition Implications
+   IV Transition Implications
-  >>>
+   This section should describe what your community views as the
-  >>> This section should describe what your community views as the
+   implications of the changes it proposed in Section III. These
-  >>> implications of the changes it proposed in Section III. These
+   implications may include some or all of the following, or other
-  >>> implications may include some or all of the following, or other
+   implications specific to your community:
-  >>> implications specific to your community:
+    o Description of operational requirements to achieve continuity
-  >>>
+      of service and possible new service integration throughout
-  >>>  o Description of operational requirements to achieve continuity
+      the transition.
-  >>>  of service and possible new service integration throughout
+    o Risks to operational continuity
-  >>>  the transition.
+    o Description of any legal framework requirements in the
-  >>>  o Risks to operational continuity
+      absence of the NTIA contract
-  >>>  o Description of any legal framework requirements in the
+    o Description of how you have tested or evaluated the
-  >>>  absence of the NTIA contract
+      workability of any new technical or operational methods
-  >>>  o Description of how you have tested or evaluated the
+      proposed in this document and how they compare to established
-  >>>  workability of any new technical or operational methods
+      arrangements.
-  >>>  proposed in this document and how they compare to established
-  >>>  arrangements.
+IETF Response:
-  >>>
+No structural changes are required.  The principles listed above will
-IETF Response:
+guide IAB, IAOC, and the rest of the IETF community as they work with
+ICANN to establish future IANA performance metrics and operational
-No structural changes are required.  The principles listed above will
+procedures, as they have in the past.
-guide IAB, IAOC, and the rest of the IETF community as they work with
-ICANN to establish future IANA performance metrics and operational
+As no services are expected to change, no continuity issues are
-procedures, as they have in the past.
+anticipated, and there are no new technical or operational methods
+proposed by the IETF to test.  The IETF leadership, ICANN, and the
-As no services are expected to change, no continuity issues are
+RIRs maintain an ongoing informal dialog to spot any unforeseen
-anticipated, and there are no new technical or operational methods
+issues that might arise as a result of other changes.
-proposed by the IETF to test.  The IETF leadership, ICANN, and the
-RIRs maintain an ongoing informal dialog to spot any unforeseen
+What is necessary as part of transition is the completion of any
-issues that might arise as a result of other changes.
+supplemental agreement(s) necessary to achieve the requirements
+outlined in our response in Section III of this RFP.
-What is necessary as part of transition is the completion of any
-supplemental agreement(s) necessary to achieve the requirements
+   V.  NTIA Requirements
-outlined in our response in Section III of this RFP.
+   Additionally, NTIA has established that the transition proposal
+   must meet the following five requirements:
-  >>>
+   "Support and enhance the multistakeholder model;"
-  >>> V.  NTIA Requirements
-  >>>
+IETF Response:
-  >>> Additionally, NTIA has established that the transition proposal
-  >>> must meet the following five requirements:
+Everyone is welcome to participate in IETF activities.  The policies
-  >>>
+and procedures are outlined in the documents we named above.  In-
-  >>> "Support and enhance the multistakeholder model;"
+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.
-IETF Response:
+The IETF makes use of both formal and informal lines of communication
+to collaborate with other organizations within the multistakeholder
-Everyone is welcome to participate in IETF activities.  The policies
+ecosystem.
-and procedures are outlined in the documents we named above.  In-
-person attendance is not required for participation, and many people
+   "Maintain the security, stability, and resiliency of the
-participate in email discussions that have never attended an IETF
+    Internet DNS;"
-meeting.  An email account is the only requirement to participate.
-The IETF makes use of both formal and informal lines of communication
+IETF Response:
-to collaborate with other organizations within the multistakeholder
-ecosystem.
+No changes are proposed in this document that affect the security,
+stability, and resiliency of the DNS.
-  >>>
-  >>> "Maintain the security, stability, and resiliency of the
+   "Meet the needs and expectation of the global customers and
-  >>>  Internet DNS;"
+    partners of the IANA services;"
-  >>>
+IETF Response:
-IETF Response:
+Implementers and their users from around the world make use of the
-No changes are proposed in this document that affect the security,
+IETF standards and the associated IANA protocol parameters
-stability, and resiliency of the DNS.
+registries.  The current IANA protocol parameters registries system
+is meeting the needs of these global customers.  This proposal
-  >>>
-  >>> "Meet the needs and expectation of the global customers and
+continues to meet their needs by maintaining the existing processes
-  >>>  partners of the IANA services;"
+that have served them well in the past.
-  >>>
+   "Maintain the openness of the Internet."
-IETF Response:
+IETF Response:
-Implementers and their users from around the world make use of the
-IETF standards and the associated IANA protocol parameters
+This proposal maintains the existing open framework that allows
-registries.  The current IANA protocol parameters registries system
+anyone to participate in the development of IETF standards, including
-is meeting the needs of these global customers.  This proposal
+the IANA protocol parameters registries policies.  Further, an
-continues to meet their needs by maintaining the existing processes
+implementer anywhere in the world has full access to the protocol
-that have served them well in the past.
+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 be able to do so, as
+specified by the existing policies for those registries.
-  >>>
-  >>> "Maintain the openness of the Internet."
+   VI.  Community Process
-  >>>
+   This section should describe the process your community used for
+   developing this proposal, including:
-IETF Response:
+   o The steps that were taken to develop the proposal and to
+     determine consensus.
-This proposal maintains the existing open framework that allows
-anyone to participate in the development of IETF standards, including
+IETF Response:
-the IANA protocol parameters registries policies.  Further, an
-implementer anywhere in the world has full access to the protocol
+The IESG established the IANAPLAN working group to develop this
-specification published in the RFC series and the protocol parameters
+response.  Anyone was welcome to join the discussion and participate
-registries published at iana.org.  Those who require assignments in
+in the development of this response.  An open mailing list
-the IANA protocol registries will continue to be able to do so, as
+(ianaplan@ietf.org) was associated with the working group.  In
-specified by the existing policies for those registries.
+addition, IETF's IANA practices have been discussed in the broader
+community, and all input is welcome.
-  >>>
-  >>> VI.  Community Process
+   Links to announcements, agendas, mailing lists, consultations and
-  >>>
+   meeting proceedings.
-  >>> This section should describe the process your community used for
-  >>> developing this proposal, including:
+IETF Response:
-  >>>
-  >>> o The steps that were taken to develop the proposal and to
+The following list is not exhaustive, as there have been many open
-  >>> determine consensus.
+discussions about this transition within the IETF community in the
-  >>>
+past few months.
-IETF Response:
+Creation of an open mailing list to discuss the transition:  http://w
+ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html
-The IESG established the IANAPLAN working group to develop this
-response.  Anyone was welcome to join the discussion and participate
+Announcement of a public session on the transition:  http://
-in the development of this response.  An open mailing list
+www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
-: (ianaplan@ietf.org) was associated with the working group.  In
-addition, IETF's IANA practices have been discussed in the broader
+Announcement by the IESG of the intent to form a working group:
-community, and all input is welcome.
+http://www.ietf.org/mail-archive/web/ietf-announce/current/
+msg13170.html
-  >>>
-  >>> Links to announcements, agendas, mailing lists, consultations and
+The working group discussion  http://www.ietf.org/mail-archive/web/
-  >>> meeting proceedings.
+ianaplan/current/maillist.html
-  >>>
+Working group last call  http://www.ietf.org/mail-archive/web/
-IETF Response:
+ianaplan/current/msg00760.html
-The following list is not exhaustive, as there have been many open
+   An assessment of the level of consensus behind your community's
-discussions about this transition within the IETF community in the
+   proposal, including a description of areas of contention or
-past few months.
+   disagreement.
-Creation of an open mailing list to discuss the transition:  http://w
+IETF Response: To be completed as the process progresses.
-ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html
+==3.  IANA Considerations==
-Announcement of a public session on the transition:  http://
-www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
+This memo is a response a request for proposals.  No parameter
+allocations or changes are sought.
-Announcement by the IESG of the intent to form a working group:
-http://www.ietf.org/mail-archive/web/ietf-announce/current/
+==4.  Security Considerations==
-msg13170.html
+While the agreement, supplements, policies, and procedures around the
-The working group discussion  http://www.ietf.org/mail-archive/web/
+IANA function have shown strong resiliency, the IETF will continue to
-ianaplan/current/maillist.html
+work with all relevant parties to facilitate improvements while
+maintaining availability of the IANA registries.
-Working group last call  http://www.ietf.org/mail-archive/web/
-ianaplan/current/msg00760.html
+==5.  IAB Note==
-  >>>
+This section to be filled in by the IAB.
-  >>> An assessment of the level of consensus behind your community's
-  >>> proposal, including a description of areas of contention or
+==6.  Acknowledgments==
-  >>> disagreement.
-  >>>
+This document describes processes that have been developed by many
+members of the community over many years.  The initial version of
-IETF Response: To be completed as the process progresses.
+this document was developed collaboratively through both the IAB IANA
+Strategy Program and the IETF IANAPLAN WG.  Particular thanks go to
-== 3.  IANA Considerations  ==
+Jari Arkko, John Klensin, Andrei Robachevsky, Andrew Sullivan, Leslie
+Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter, Greg Wood, John
-This memo is a response a request for proposals.  No parameter
+Curran, Milton Mueller, Alissa Cooper, Andrei Robachevsky, and
-allocations or changes are sought.
+Suzanne Woolf.
-== 4.  Security Considerations  ==
+==7.  Informative References==
-While the agreement, supplements, policies, and procedures around the
+[I-D.leiba-cotton-iana-5226bis]
-IANA function have shown strong resiliency, the IETF will continue to
-work with all relevant parties to facilitate improvements while
-maintaining availability of the IANA registries.
-== 5.  IAB Note  ==
-This section to be filled in by the IAB.
-== 6.  Acknowledgments ==
-This document describes processes that have been developed by many
-members of the community over many years.  The initial version of
-this document was developed collaboratively through both the IAB IANA
-Strategy Program and the IETF IANAPLAN WG.  Particular thanks go to
-Jari Arkko, John Klensin, Andrei Robachevsky, Andrew Sullivan, Leslie
-Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter, Greg Wood, John
-Curran, Milton Mueller, Alissa Cooper, Andrei Robachevsky, and
-Suzanne Woolf.
-== 7.  Informative References  ==
-[I-D.leiba-cotton-iana-5226bis]
 Cotton, M., Leiba, B., and T. Narten, "Guidelines for
-Writing an IANA Considerations Section in RFCs," draft-
+Writing an IANA Considerations Section in RFCs", draft-
 leiba-cotton-iana-5226bis-11 (work in progress), November
 .
-[METRICS]  , "Performance Standards Metrics Report," ,
+[METRICS]  , "Performance Standards Metrics Report", ,
 <http://www.iana.org/performance/metrics>.
-[MOUSUP] , "Supplements to RFC 2860 (the Memorandum of
+[MOUSUP]   , "Supplements to RFC 2860 (the Memorandum of
-Understanding between the IETF and ICANN)," ,
+Understanding between the IETF and ICANN)", ,
 <http://iaoc.ietf.org/contracts.html>.
 [NTIA-Contract]
-, "The NTIA Contract with ICANN," , <http://
+, "The NTIA Contract with ICANN", , <http://
 www.ntia.doc.gov/files/ntia/publications/
 sf_26_pg_1-2-final_award_and_sacs.pdf>.
 [RFC-INDEX]
-RFC Editor, , "Index of all Requests for Comments," RFC
+RFC Editor, , "Index of all Requests for Comments", RFC
 Index, August 2014.
 [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
-3," BCP 9 RFC 2026 October 1996.
+", BCP 9, RFC 2026, October 1996.
 [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
-Procedures," BCP 25 RFC 2418 September 1998.
+Procedures", BCP 25, RFC 2418, September 1998.
 [RFC2850]  Internet Architecture Board and B. Carpenter, "Charter of
-the Internet Architecture Board (IAB)," BCP 39 RFC 2850
+the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
 May 2000.
 [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
 Understanding Concerning the Technical Work of the
-Internet Assigned Numbers Authority," RFC 2860 June 2000.
+Internet Assigned Numbers Authority", RFC 2860, June 2000.
 [RFC2870]  Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
-Name Server Operational Requirements," BCP 40 RFC 2870
+Name Server Operational Requirements", BCP 40, RFC 2870,
 June 2000.
 [RFC3172]  Huston, G., "Management Guidelines & Operational
 Requirements for the Address and Routing Parameter Area
-Domain (arpa"")""," BCP 52 RFC 3172 September 2001.
+Domain ("arpa")", BCP 52, RFC 3172, September 2001.
 [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
-Addresses," RFC 3307 August 2002.
+Addresses", RFC 3307, August 2002.
-[RFC3595]  Wijnen, B., "Textual Conventions for IPv6 Flow Label," RFC
+[RFC3595]  Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC
-September 2003.
+, September 2003.
 [RFC3777]  Galvin, J., "IAB and IESG Selection, Confirmation, and
 Recall Process: Operation of the Nominating and Recall
-Committees," BCP 10 RFC 3777 June 2004.
+Committees", BCP 10, RFC 3777, June 2004.
 [RFC4071]  Austein, R. and B. Wijnen, "Structure of the IETF
-Administrative Support Activity (IASA)," BCP 101 RFC
+Administrative Support Activity (IASA)", BCP 101, RFC
-April 2005.
+, April 2005.
 [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-Addresses," RFC 4193 October 2005.
+Addresses", RFC 4193, October 2005.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-IANA Considerations Section in RFCs," BCP 26 RFC 5226
+IANA Considerations Section in RFCs", BCP 26, RFC 5226,
 May 2008.
 [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
-IPv4 Multicast Address Assignments," BCP 51 RFC 5771
+IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
 March 2010.
 [RFC6220]  McPherson, D., Kolkman, O., Klensin, J., Huston, G.,
 Internet Architecture Board, "Defining the Role and
-Function of IETF Protocol Parameter Registry Operators,"
+Function of IETF Protocol Parameter Registry Operators",
-RFC 6220 April 2011.
+RFC 6220, April 2011.
-[RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names,"
+[RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
-RFC 6761 February 2013.
+RFC 6761, February 2013.
 [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
-Autonomous System (AS) Number Space," RFC 6793 December
+Autonomous System (AS) Number Space", RFC 6793, December
 .
 [RFC6852]  Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.
-Amour, "Affirmation of the Modern Paradigm for Standards,"
+Amour, "Affirmation of the Modern Paradigm for Standards",
-RFC 6852 January 2013.
+RFC 6852, January 2013.
 [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
-"Special-Purpose IP Address Registries," BCP 153 RFC
+"Special-Purpose IP Address Registries", BCP 153, RFC
-April 2013.
+, April 2013.
 [RFC7020]  Housley, R., Curran, J., Huston, G., and D. Conrad, "The
-Internet Numbers Registry System," RFC 7020 August 2013.
+Internet Numbers Registry System", RFC 7020, August 2013.
-[RFC7249]  Housley, R., "Internet Numbers Registries," RFC 7249 May
+[RFC7249]  Housley, R., "Internet Numbers Registries", RFC 7249, May
 .
-[RFC7282]  Resnick, P., "On Consensus and Humming in the IETF," RFC
+[RFC7282]  Resnick, P., "On Consensus and Humming in the IETF", RFC
-June 2014.
+, June 2014.
-== Appendix A.  Changes  ==
+==Appendix A.  Changes==
 NOTE: This section to be removed by RFC Editor at publication.
-== A.1.  Changes from -5 to -6 ==
+==A.1.  Changes from -05 to -06==
-o  Inclusion of agreed substantial comments from the AD.
+*Inclusion of agreed substantial comments from the AD.
-o  Editorial changes.
+*Editorial changes.
-== A.2.  Changes from -4 to -5 ==
+==A.2.  Changes from -04 to -05==
-o  Change to simpler text for answer about stability and security.
+*Change to simpler text for answer about stability and security.
-o  Mention of RFC 5226bis.
+*Mention of RFC 5226bis.
-== A.3.  Changes from -3 to -4 ==
+==A.3.  Changes from -03 to -04==
-o  Additional text regarding what is needed in Section III.
+*Additional text regarding what is needed in Section III.
-o  Appropriate language modifications in section IV to match the
+*Appropriate language modifications in section IV to match the
 above changes in III.
-o  Acknowledgments edits.
+*Acknowledgments edits.
-== A.4.  Changes from -2 to -3 ==
+==A.4.  Changes from -02 to -03==
-o  Terminology consistency.
+*Terminology consistency.
-o  Add IAB section.
+*Add IAB section.
-o  Changes based on WG discussion on what we prefer as part of the
+*Changes based on WG discussion on what we prefer as part of the
 transition regarding IPR.
-o  Add discussion about .ARPA domain.
+*Add discussion about .ARPA domain.
-o  Elaboration of what registries are involved.
+*Elaboration of what registries are involved.
-o  Additional text around coordination with ICANN.
+*Additional text around coordination with ICANN.
-o  Working groups can adopt items within their charters.
+*Working groups can adopt items within their charters.
-o  IAB appointments generally last two years.
+*IAB appointments generally last two years.
-o  Add mention of the Trust.
+*Add mention of the Trust.
-o  Security Considerations update.
+*Security Considerations update.
-== A.5.  Changes from -1 to -2 ==
+==A.5.  Changes from -01 to -02==
-o  A better description special registries and BGP ASNs.
+*A better description special registries and BGP ASNs.
-o  Clarity on how the address space and ASNs are delegated.
+*Clarity on how the address space and ASNs are delegated.
-o  Many editorials corrected.
+*Many editorials corrected.
-o  Mention of the annual review as part of the SLAs.
+*Mention of the annual review as part of the SLAs.
-o  Change about how overlap is presented.
+*Change about how overlap is presented.
-o  A number of small wording changes based on feedback.
+*A number of small wording changes based on feedback.
-== A.6.  Changes from 0 to -1 ==
+==A.6.  Changes from -00 to -01==
-o  Front matter greatly reduced.
+*Front matter greatly reduced.
-o  Appendices with charter and RFP added.
+*Appendices with charter and RFP added.
-o  Jurisdiction text changed.
+*Jurisdiction text changed.
-o  Proposed changes include supplemental agreement(s) to address
+*Proposed changes include supplemental agreement(s) to address
 jurisdiction, dispute resolution, and IPR, including names and
 marks.
-o  Transition implications slightly modified to reference
+*Transition implications slightly modified to reference
 supplemental agreement.
-== Appendix B.  The Charter of the IANA Stewardship Coordination Group (ICG  ==
+==Appendix B.  The Charter of the IANA Stewardship Coordination Group (ICG==
 Charter for the IANA Stewardship Transition Coordination Group V.10
-: (August 27 2014)
+(August 27, 2014)
-The IANA stewardship transition coordination group (ICG) has one
-deliverable: a proposal to the U.S.  Commerce Department National
+The IANA stewardship transition coordination group (ICG) has one
-Telecommunications and Information Administration (NTIA) regarding
+deliverable: a proposal to the U.S.  Commerce Department National
-the transition of NTIA's stewardship of the IANA functions to the
+Telecommunications and Information Administration (NTIA) regarding
-global multi-stakeholder community.  The group will conduct itself
+the transition of NTIA's stewardship of the IANA functions to the
-transparently, consult with a broad range of stakeholders, and ensure
+global multi-stakeholder community.  The group will conduct itself
-that its proposals support the security and stability of the IANA
+transparently, consult with a broad range of stakeholders, and ensure
-functions.
+that its proposals support the security and stability of the IANA
+functions.
-The group's mission is to coordinate the development of a proposal
-among the communities affected by the IANA functions.  The IANA
+The group's mission is to coordinate the development of a proposal
-functions are divided into three main categories: domain names,
+among the communities affected by the IANA functions.  The IANA
-number resources, and other protocol parameters.  The domain names
+functions are divided into three main categories: domain names,
-category falls further into the country code and generic domain name
+number resources, and other protocol parameters.  The domain names
-sub-categories.  While there is some overlap among all of these
+category falls further into the country code and generic domain name
-categories, each poses distinct organizational, operational and
+sub-categories.  While there is some overlap among all of these
-technical issues, and each tends to have distinct communities of
+categories, each poses distinct organizational, operational and
-interest and expertise.  For those reasons it is best to have work on
+technical issues, and each tends to have distinct communities of
-the three categories of IANA parameters proceed autonomously in
+interest and expertise.  For those reasons it is best to have work on
-parallel and be based in the respective communities.
+the three categories of IANA parameters proceed autonomously in
+parallel and be based in the respective communities.
-The IANA stewardship transition process is taking place alongside a
-parallel and related process on enhancing ICANN accountability.
+The IANA stewardship transition process is taking place alongside a
-While maintaining the accountability of Internet identifier
+parallel and related process on enhancing ICANN accountability.
-governance is central to both processes, this group's scope is
+While maintaining the accountability of Internet identifier
-focused on the arrangements required for the continuance of IANA
+governance is central to both processes, this group's scope is
-functions in an accountable and widely accepted manner after the
+focused on the arrangements required for the continuance of IANA
-expiry of the NTIA-ICANN contract.  Nevertheless, the two processes
+functions in an accountable and widely accepted manner after the
-are interrelated and interdependent and should appropriately
+expiry of the NTIA-ICANN contract.  Nevertheless, the two processes
-coordinate their work.
+are interrelated and interdependent and should appropriately
+coordinate their work.
-The coordination group has four main tasks:
-: (i) Act as liaison to all interested parties, including the three
+The coordination group has four main tasks:
-"operational communities" (i.e., those with direct operational
+(i) Act as liaison to all interested parties, including the three
-or service relationship with IANA; namely names, numbers,
+"operational communities" (i.e., those with direct operational
-protocol parameters). This task consists of:
+or service relationship with IANA; namely names, numbers,
-a. Soliciting proposals from the operational communities
+protocol parameters). This task consists of:
-b. Soliciting the input of the broad group of communities
+a. Soliciting proposals from the operational communities
-affected by the IANA functions
+b. Soliciting the input of the broad group of communities
-: (ii) Assess the outputs of the three operational communities for
+affected by the IANA functions
-compatibility and interoperability
+(ii) Assess the outputs of the three operational communities for
-: (iii) Assemble a complete proposal for the transition
+compatibility and interoperability
-: (iv) Information sharing and public communication
+(iii) Assemble a complete proposal for the transition
-Describing each in more detail:
+(iv) Information sharing and public communication
-(i) Liaison
+Describing each in more detail:
-a. Solicit proposals
+(i) Liaison
+a. Solicit proposals
-The ICG expects a plan from the country code and generic name
-communities (possibly a joint one), a plan from the numbers
+The ICG expects a plan from the country code and generic name
-community, and a plan from the protocol parameters community.
+communities (possibly a joint one), a plan from the numbers
-Members of the ICG will ensure that the communities from which they
+community, and a plan from the protocol parameters community.
-are drawn are working on their part of the transition plans.  This
+Members of the ICG will ensure that the communities from which they
-involves informing them of requirements and schedules, tracking
+are drawn are working on their part of the transition plans.  This
-progress, and highlighting the results or remaining issues.  The role
+involves informing them of requirements and schedules, tracking
-of a coordination group member during this phase is to provide status
+progress, and highlighting the results or remaining issues.  The role
-updates about the progress of his or her community in developing
+of a coordination group member during this phase is to provide status
-their component, and to coordinate which community will develop a
+updates about the progress of his or her community in developing
-transition proposal for each area of overlap (e.g., special-use
+their component, and to coordinate which community will develop a
-registry).
+transition proposal for each area of overlap (e.g., special-use
+registry).
-While working on the development of their proposals, the operational
-communities are expected to address common requirements and issues
+While working on the development of their proposals, the operational
-relating to the transition, in as far as they affect their parts of
+communities are expected to address common requirements and issues
-the stewardship of IANA functions.
+relating to the transition, in as far as they affect their parts of
+the stewardship of IANA functions.
-b.  Solicit broader input
+b.  Solicit broader input
-The ICG is open for input and feedback from all interested parties.
-While no set of formal requirements related to a transition proposal
+The ICG is open for input and feedback from all interested parties.
-will be requested outside the operational communities, everyone's
+While no set of formal requirements related to a transition proposal
-input is welcome across all topics.
+will be requested outside the operational communities, everyone's
+input is welcome across all topics.
-The ICG expects that all interested parties get involved as early as
-possible in the relevant community processes.  Input received
+The ICG expects that all interested parties get involved as early as
-directly by the ICG may be referred to the relevant community
+possible in the relevant community processes.  Input received
-discussion.
+directly by the ICG may be referred to the relevant community
+discussion.
-The ICG members chosen from a particular community are the official
-communication channel between the ICG and that community.
+The ICG members chosen from a particular community are the official
+communication channel between the ICG and that community.
-: (ii) Assessment
+(ii) Assessment
-When the group receives output from the communities it will discuss
-and assess their compatibility and interoperability with the
+When the group receives output from the communities it will discuss
-proposals of the other communities.  Each proposal should be
+and assess their compatibility and interoperability with the
-submitted with a clear record of how consensus has been reached for
+proposals of the other communities.  Each proposal should be
-the proposal in the community, and provide an analysis that shows the
+submitted with a clear record of how consensus has been reached for
-proposal is in practice workable.  The ICG should also compile the
+the proposal in the community, and provide an analysis that shows the
-input it has received beyond the operational communities, and review
+proposal is in practice workable.  The ICG should also compile the
-the impacts of this input.
+input it has received beyond the operational communities, and review
+the impacts of this input.
-The ICG might at some point detect problems with the component
-proposals.  At that point the role of the ICG is to communicate that
+The ICG might at some point detect problems with the component
-back to the relevant communities so that they (the relevant
+proposals.  At that point the role of the ICG is to communicate that
-communities) can address the issues.  It is not in the role of the
+back to the relevant communities so that they (the relevant
-ICG to develop proposals or to select from among competing proposals.
+communities) can address the issues.  It is not in the role of the
+ICG to develop proposals or to select from among competing proposals.
-: (iii) Assembling and submitting a complete proposal
+(iii) Assembling and submitting a complete proposal
-The assembly effort involves taking the proposals for the different
-components and verifying that the whole fulfills the intended scope,
+The assembly effort involves taking the proposals for the different
-meets the intended criteria, that there are no missing parts, and
+components and verifying that the whole fulfills the intended scope,
-that the whole fits together.  The whole also needs to include
+meets the intended criteria, that there are no missing parts, and
-sufficient independent accountability mechanisms for running the IANA
+that the whole fits together.  The whole also needs to include
-function.  The ICG will then develop a draft final proposal that
+sufficient independent accountability mechanisms for running the IANA
-achieves rough consensus within the ICG itself.  The ICG will then
+function.  The ICG will then develop a draft final proposal that
-put this proposal up for public comment involving a reasonable period
+achieves rough consensus within the ICG itself.  The ICG will then
-of time for reviewing the draft proposal, analyzing and preparing
+put this proposal up for public comment involving a reasonable period
-supportive or critical comments.  The ICG will then review these
+of time for reviewing the draft proposal, analyzing and preparing
-comments and determine whether modifications are required.  If no
+supportive or critical comments.  The ICG will then review these
-modifications are needed, and the coordination group agrees, the
+comments and determine whether modifications are required.  If no
-proposal will be submitted to NTIA.
+modifications are needed, and the coordination group agrees, the
+proposal will be submitted to NTIA.
-If changes are required to fix problems or to achieve broader
-support, the ICG will work with the operational communities in a
+If changes are required to fix problems or to achieve broader
-manner similar to what was described in task (ii) above.  Updates are
+support, the ICG will work with the operational communities in a
-subject to the same verification, review, and consensus processes as
+manner similar to what was described in task (ii) above.  Updates are
-the initial proposals.  If, in the ICG's opinion, broad public
+subject to the same verification, review, and consensus processes as
-support for the proposal as articulated by the NTIA is not present,
+the initial proposals.  If, in the ICG's opinion, broad public
-the parts of the proposal that are not supported return to the
+support for the proposal as articulated by the NTIA is not present,
-liaison phase.
+the parts of the proposal that are not supported return to the
+liaison phase.
-: (iv) Information sharing
+(iv) Information sharing
-The ICG serves as a central clearinghouse for public information
-about the IANA stewardship transition process.  Its secretariat
+The ICG serves as a central clearinghouse for public information
-maintains an independent, publicly accessible and open website, under
+about the IANA stewardship transition process.  Its secretariat
-its own domain, where status updates, meetings and notices are
+maintains an independent, publicly accessible and open website, under
-announced, proposals are stored, the ICG members are listed, etc.  As
+its own domain, where status updates, meetings and notices are
-the development of the transition plans will take some time, it is
+announced, proposals are stored, the ICG members are listed, etc.  As
-important that information about ongoing work is distributed early
+the development of the transition plans will take some time, it is
-and continuously.  This will enable sharing of ideas and the
+important that information about ongoing work is distributed early
-detection of potential issues.
+and continuously.  This will enable sharing of ideas and the
+detection of potential issues.
-== Appendix C.  IANA Stewardship Transition Coordination Group Request for  ==
-Proposals
+==Appendix C.  IANA Stewardship Transition Coordination Group Request for==
+Proposals
-IANA Stewardship Transition Coordination Group Request for Proposals
-September 2014
+IANA Stewardship Transition Coordination Group Request for Proposals
-Introduction
+September 2014
-Under the IANA1 Stewardship Transition Coordination Group (ICG)
+Introduction
-Charter,2 the ICG has four main tasks:
+Under the IANA1 Stewardship Transition Coordination Group (ICG)
-: (i) Act as liaison to all interested parties in the IANA
+Charter,2 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
+communities" (i.e., those with direct operational or service
 relationships with the IANA functions operator; namely names,
 numbers, protocol parameters). This task consists of: &#8232;
 a. Soliciting proposals from the operational communities
 b. Soliciting the input of the broad group of communities
 affected by the&#8232;IANA functions
-: (ii) Assess the outputs of the three operational communities for
+(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
+(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 ===
+. 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
+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
+"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  ===
+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  ===
+. 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 function;
-: o A description of the customer(s) of the function;
+o A description of the customer(s) of the function;
-: o What registries are involved in providing 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.
+work, prior to the transition.
-[3] http://www.ntia.doc.gov/files/ntia/
-publications/sf_26_pg_1-2-final_award_and_sacs.pdf
+[3] http://www.ntia.doc.gov/files/ntia/
+publications/sf_26_pg_1-2-final_award_and_sacs.pdf
-===  A. Policy Sources  ===
+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
+This section should identify the specific source(s) of policy which
-the services or activities described above. If there are distinct
+must be followed by the IANA functions operator in its conduct of
-sources of policy or policy development for different IANA
+the services or activities described above. If there are distinct
-functions, then please describe these separately. For each source of
+sources of policy or policy development for different IANA
-policy or policy development, please provide the following:
+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
+o Which IANA function (identified in Section I) are affected.
-is involved in policy development and establishment.
+o A description of how policy is developed and established and who
-: o A description of how disputes about policy are resolved.
+is involved in policy development and establishment.
-: o References to documentation of policy development and dispute
+o A description of how disputes about policy are resolved.
-resolution processes.
+o References to documentation of policy development and dispute
+resolution processes.
-B. Oversight and Accountability
+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
+This section should describe all the ways in which oversight is
-services and activities listed in Section I and all the ways in
+conducted over the IANA functions operator's provision of the
-which the IANA functions operator is currently held accountable for
+services and activities listed in Section I and all the ways in
-the provision of those services. For each oversight or
+which the IANA functions operator is currently held accountable for
-accountability mechanism, please provide as many of the following as
+the provision of those services. For each oversight or
-are applicable:
+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 IANA functions (identified in Section I) are affected.  If the
-which ones are affected and explain in what way.
+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
+o A description of the entity or entities that provide oversight or
-selected or removed from participation in those entities.
+perform accountability functions, including how individuals are
-: o A description of the mechanism (e.g., contract, reporting scheme,
+selected or removed from participation in those entities.
-auditing scheme, etc.). This should include a description of the
+o A description of the mechanism (e.g., contract, reporting scheme,
-consequences of the IANA functions operator not meeting the
+auditing scheme, etc.). This should include a description of the
-standards established by the mechanism, the extent to which the
+consequences of the IANA functions operator not meeting the
-output of the mechanism is transparent and the terms under which
+standards established by the mechanism, the extent to which the
-the mechanism may change.
+output of the mechanism is transparent and the terms under which
-: o Jurisdiction(s) in which the mechanism applies and the legal basis
+the mechanism may change.
-on which the mechanism rests.
+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
+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
+This section should describe what changes your community is
-transition. If your community is proposing to replace one or more
+proposing to the arrangements listed in Section II.B in light of the
-existing arrangements with new arrangements, that replacement should
+transition. If your community is proposing to replace one or more
-be explained and all of the elements listed in Section II.B should
+existing arrangements with new arrangements, that replacement should
-be described for the new arrangements. Your community should provide
+be explained and all of the elements listed in Section II.B should
-its rationale and justification for the new arrangements.
+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
+If your community's proposal carries any implications for the
-described in Section II.A, those implications should be described
+interface between the IANA functions and existing policy arrangements
-here.
+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
+If your community is not proposing changes to arrangements listed in
-be provided here.
+Section II.B, the rationale and justification for that choice should
+be provided here.
-IV. Transition Implications
+IV. Transition Implications
-This section should describe what your community views as the
-implications of the changes it proposed in Section III. These
+This section should describe what your community views as the
-implications may include some or all of the following, or other
+implications of the changes it proposed in Section III. These
-implications specific to your community:
+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
+Description of operational requirements to achieve continuity of
-transition.
+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
+Risks to operational continuity and how they will be addressed.
-NTIA contract. Description of how you have tested or evaluated the
+Description of any legal framework requirements in the absence of the
-workability of any new technical or operational methods proposed in
+NTIA contract. Description of how you have tested or evaluated the
-this document and how they compare to established arrangements.
+workability of any new technical or operational methods proposed in
-Description of how long the proposals in Section III are expected to
+this document and how they compare to established arrangements.
-take to complete, and any intermediate milestones that may occur
+Description of how long the proposals in Section III are expected to
-before they are completed.
+take to complete, and any intermediate milestones that may occur
+before they are completed.
-V. NTIA Requirements
+V. NTIA Requirements
-Additionally, NTIA has established that the transition proposal must
-meet the following five requirements:
+Additionally, NTIA has established that the transition proposal must
-: o Support and enhance the multistakeholder model;
+meet the following five requirements:
-: o Maintain the security, stability, and resiliency of the Internet
+o Support and enhance the multistakeholder model;
-DNS;
+o Maintain the security, stability, and resiliency of the Internet
-: o Meet the needs and expectation of the global customers and
+DNS;
-partners of the IANA functions;
+o Meet the needs and expectation of the global customers and
-: o Maintain the openness of the Internet;
-: o The proposal must not replace the NTIA role with a government-led
+partners of the IANA functions;
-or an inter-governmental organization solution.
+o Maintain the openness of the Internet;
+o The proposal must not replace the NTIA role with a government-led
-This section should explain how your community's proposal meets these
+or an inter-governmental organization solution.
-requirements and how it responds to the global interest in the IANA
-functions.
+This section should explain how your community's proposal meets these
+requirements and how it responds to the global interest in the IANA
-VI. Community Process
+functions.
-This section should describe the process your community used for
-developing this proposal, including:
+VI. Community Process
-: o The steps that were taken to develop the proposal and to determine
+This section should describe the process your community used for
-consensus.
+developing this proposal, including:
-: o Links to announcements, agendas, mailing lists, consultations and
+o The steps that were taken to develop the proposal and to determine
-meeting proceedings.
+consensus.
-: o An assessment of the level of consensus behind your community's
+o Links to announcements, agendas, mailing lists, consultations and
-proposal, including a description of areas of contention or
+meeting proceedings.
-disagreement.
+o An assessment of the level of consensus behind your community's
+proposal, including a description of areas of contention or
-== Authors' Addresses  ==
+disagreement.
-:Eliot Lear (editor)
+==Authors' Addresses==
-:Richtistrasse 7
-:Wallisellen, ZH  CH-8304
+:Eliot Lear (editor)
-:Switzerland
+:Richtistrasse 7
+:Wallisellen, ZH  CH-8304
-:Phone: 41 44 878 9200
+:Switzerland
-:Email: lear@cisco.com
+:Phone: +41 44 878 9200
-:Russ Housley (editor)
+:Email: lear@cisco.com
-:918 Spring Noll Drive
-:Herndon, VA  20170
+:Russ Housley (editor)
-:USA
+:918 Spring Noll Drive
+:Herndon, VA  20170
+:USA
 :Email: housley@vigilsec.com