RFC 7979

Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries

📅 published August 2016, from ietf

🎀 RFC 7979: Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries

Okay bestie, this is the IETF's official reply to a big "who should look after the IANA stuff" question 💅✨

Title block facts 📋

  • Organization: Internet Engineering Task Force (IETF) 🌸
  • Editors: E. Lear, Ed. and R. Housley, Ed. 💜
  • Category: Informational 🦋
  • Date: August 2016 🍓
  • ISSN: 2070-1721 ✨
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈

Abstract ✨

So the U.S. National Telecommunications and Information Administration (NTIA) asked the Internet Corporation for Assigned Names and Numbers (ICANN) to figure out how the NTIA could stop overseeing the Internet Assigned Numbers Authority (IANA) functions 👑. After lots of consultations, ICANN made the IANA Stewardship Transition Coordination Group. That group asked for proposals on the three big IANA functions: names, numbers, and protocol parameters 🧚. This document is the IETF's answer for protocol parameters. It went into one big joint response to the NTIA, next to the answers from the names and numbering communities, who are building their own. You can find the link to that response in the introduction, and extra correspondence is in the Appendix 💖.

Status of This Memo 🌈

This document is not an Internet Standards Track specification. It's published for informational purposes, so no standard here 🫶.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🔥. Not everything the IESG approves is up for any level of Internet Standard, though. See Section 2 of RFC 7841 for that 💅.

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7979 🎀.

Copyright (c) 2016 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) as they stand on the publication date. Please read these carefully, because they describe your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as the Simplified BSD License describes 🦋.

Table of Contents 🍓

1.  IETF Introduction . . . . . . . . . . . . . . . . . . . . . .   3
2.  The Formal RFP Response . . . . . . . . . . . . . . . . . . .   4
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
5.  IAB Note  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  22
Appendix A.  The Charter of the IANA Stewardship Coordination
             Group (ICG)  . . . . . . . . . . . . . . . . . . . .  25
Appendix B.  IANA Stewardship Transition Coordination Group
             Request for Proposals  . . . . . . . . . . . . . . .  28
Appendix C.  Correspondence of the IETF to the ICG  . . . . . . .  34
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1. IETF Introduction 🧚

Okay so in March 2014, the NTIA said it wanted to hand over oversight of the IANA functions 📣. In that announcement, the NTIA asked ICANN to set up a process for a transition proposal 👑. As part of that, the IANA Stewardship Transition Coordination Group (ICG) was formed. You can find its charter in Appendix A. The ICG then asked the names, numbers, and protocol parameters communities for proposals about how things should work after the transition, so it could put together one proposal for the NTIA. The final request for proposal (RFP) is in Appendix B, and the ICG's response to the NTIA is at [ICG-Response] 💖.

This document is only about the protocol parameters registries function, even though all the IANA functions touch IETF standards in some way 🌸. This section is the intro, and it comes only from inside the IETF. Section 2 has the questionnaire the ICG wrote, plus the IETF's formal answers. Questions from that questionnaire are marked with ">>> ", and answers are marked with "IETF Response:". The questions were tweaked a little so they'd fit the RFC format ✨.

The original RFP had a footnote, which goes like this 💅:

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

2. The Formal RFP Response 🦋

The whole Request for Proposals, intro included, is in Appendix B 📖.

Here's the first question, marked up the way the original quotes it:

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

IETF Response: Protocol Parameters 🎀

This response describes the IETF's existing practice, and it also reflects the views of the Internet Architecture Board and the IETF 👑.

Next up is section I, about how the community uses IANA functions. The question asks for a list of the specific, distinct IANA services or activities the community depends on. For each one, it asks for this 💜:

>>>
>>> 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: Okay, so tons of IETF protocols use commonly defined protocol parameters 🌈. The implementers, who are the main users of IETF standards and other documents, use these parameters 🫶. To keep parameter values interpreted consistently across independent implementations, and to make everything work together everywhere, IETF protocol specifications define and require globally available registries. Those registries hold the parameter values, plus a pointer to any related documentation 🔥. The IETF uses the IANA protocol parameters registries to keep that info in one public place. The community currently reaches the protocol parameter registries through references based on the iana.org domain name, and it uses the term "IANA" in its protocol parameter registry processes [RFC5226] 💅.

ICANN currently runs the .ARPA top level domain on behalf of the Internet Architecture Board (IAB) 🧚. This zone holds some Internet infrastructure services that are delegated beneath it. For this response, the IETF counts .ARPA as part of the protocol parameters registries ✨.

Next, the ICG asks about the customers 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 registries for the IETF, following all the relevant IETF policies. It does this under the Memorandum of Understanding [RFC2860], plus the supplemental agreements, which include the service level agreements (SLAs) between the IETF and ICANN [MOUSUP] 🌸.

The IETF is a global group that makes voluntary standards 🦋. Its mission is to produce high quality, relevant technical and engineering documents that shape how people design, use, and manage the Internet, so the Internet works better [RFC3935] 🌟. IETF standards get published in the RFC series. The IETF is responsible for key standards people use on the Internet today, like IP, TCP, DNS, BGP, and HTTP, to name just a few 🔥.

The IETF works in an open and transparent way [RFC6852] 🍓. The processes that govern it are published in the RFC series too. The Internet Standards Process is documented in [RFC2026], which explains how standards get developed and also how disputes about decisions get resolved 💜. RFC 2026 has been amended several times [BCP9info] 🎀. The standards process can be changed the same way standards get approved. Someone proposes a change by submitting a temporary document called an Internet-Draft, the community talks it through, and if rough consensus is reached, the Internet Engineering Steering Group (IESG) approves it. The IESG also handles day-to-day decisions about declaring IETF consensus on technical matters, including ones that affect the IANA protocol parameters registries 👑. Anyone can propose a change during a Last Call, and anyone can join the community discussion ✨.

The ICG also asks which registries are involved in providing the service or activity 🧚:

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

IETF Response: The protocol parameters registries are the product of IETF work 💅. They also include the top-level registry for the entire IP address space, some of its sub-registries, the autonomous system number space, and a number of special use registries for domain names. For more detail, check the documentation in the "overlaps or interdependencies" section 🌈. Running the protocol parameters registries is the service the IANA provides to the IETF 💖.

Last but not least for now, the ICG asks about overlaps and interdependencies between the IANA requirements and the functions other customer communities need 🫶:

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

IETF Response: When the IETF says "overlap," it means shared responsibility for a single registry across multiple organizations 🔥. By that definition there's no overlap, because responsibility for each registry is carefully spelled out 🎀. There are, however, points of interaction with other organizations, and a few cases where the IETF might further define a registry's scope for technical reasons. That's the case for both names and numbers, as the paragraphs below explain. In every case, the IETF coordinates with the appropriate organizations 🦋.

It's important to know the IETF doesn't have formal membership 💜. "The IETF" means anyone who wants to take part in it, and IETF participants can also belong to other communities. Staff and participants from ICANN and the Regional Internet Registries (RIRs) regularly take part in IETF activities 🌸✨.

The IETF has set up a bunch of special use registries for domain names 🌐, and they need coordination with ICANN, the policy authority for the DNS root 👑. That includes community groups like the Generic Names Supporting Organization (GNSO) and the Country Code Names Supporting Organization (ccNSO). The good news is that the coordination mechanisms already exist, and there's capacity to change them if new conditions pop up ✨ [RFC6761]

  • The IETF specifies the DNS protocol, and it has been updated and will keep being updated 🔄 Whenever changes happen, the IETF will broadly consult the operational community about their impact, same as it's done before 🫶
  • 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 keep evolving 🛣️ That evolution may affect which IP address allocation strategies make sense. If and when that happens, the IETF will consult and coordinate with the RIR community, just like it has 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 RIRs [RFC7020],[RFC7249]. Special address allocations, like multicast and anycast addresses, often need coordination 🔀 Another example is Unique Local Addresses (ULAs) [RFC4193], where local networks use a prefix that isn't meant to be routed on the public Internet 🏠 New special address allocations get added from time to time as the standards evolve 🌱 In every case, these special assignments are listed in the IANA protocol parameters registries 📋
  • The IETF maintains sub-registries for special IPv4 and IPv6 assignments 🧩 These are specified in [RFC3307], [RFC5771], and [RFC6890]. The IETF coordinates these assignments with the RIRs 🤝
  • Changes to IETF standards can affect RIR and service provider operations 📡 A recent example is the extension to BGP that carries Autonomous System numbers as four-octet entities [RFC6793]. That change happened out of operational necessity, and it showed strong alignment between the RIRs and the IETF, which is iconic behavior honestly 💖

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 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 ⚖️ If 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] 📚

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 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 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 👀 Its responsibilities include, among other things, confirming appointment of IESG members, managing appeals as discussed above, managing certain domains (including .ARPA [RFC3172]), and providing 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 can be found in [RFC2850].

The IAB members are selected, and may be recalled, through a Nominating Committee (NOMCOM) process, which is described in [RFC3777] and its updates 🎀 This process provides for selection of active members of the community, who themselves agree upon a slate of candidates. The active members are chosen randomly from volunteers with a history of participation in the IETF, with limits on having too many active members with the same affiliation 🎲 The selection of the active members is performed in a way that makes it possible for anyone to verify that the correct procedure was followed 🔍 The slate of candidates selected by the active members is 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 IETF protocol parameters registries, and is responsible for selecting appropriate operator(s) and related per-registry arrangements 🗂️ Especially when relationships among protocols call for it, registries are sometimes 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 for the Internet Research Task Force (IRTF), a peer organization to the IETF that focuses on research [RFC2014]. Each year, a service level agreement is negotiated that supplements the MoU.

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

To date, there have been no unresolvable disputes or issues between the IETF and the current IANA functions operator 🥰 [RFC2860] specifies that should a technical dispute arise, "the IANA shall seek and follow technical guidance exclusively from the IESG." In the unlikely event that a more difficult situation should arise, the IAOC and the IAB would engage ICANN management to address the matter. The MoU also provides an option for either party to terminate the arrangement with six months' notice. Obviously, such action would only be taken after serious consideration 🙏 In that case, a new IANA functions operator would be selected, and a new agreement with that operator would be established.

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

IETF Response

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

III. Proposed Post-Transition Oversight and Accountability Arrangements 🎀

okay so this is the RFP template talking to the community. This section should describe what changes your community is proposing to the arrangements in Section II.B because of the transition. If you're replacing one or more existing arrangements with new ones, explain the replacement and describe every element listed in Section II.B for the new arrangements. Your community should give its rationale and justification for the new arrangements. If your community's proposal has any implications for the existing policy arrangements in Section II.A, describe those implications here. If your community is not proposing changes to the arrangements in Section II.B, give the rationale and justification for that choice here.

IETF Response:

No new organizations or structures are required. 💅 Over the years since ICANN was created, the IETF, ICANN, and IAB have together built a system of agreements, policies, and oversight mechanisms that already covers what's needed. It has worked really well with zero operational involvement from the NTIA. 🙌

IANA protocol parameters registry updates will keep running day-to-day, the same way they have for the last decade or more. ✨ The IETF community is very satisfied with the current arrangement with ICANN. RFC 2860 is still in force and has served the IETF community very well. 🫶 RFC 6220 laid out an appropriate service description and requirements.

However, without the NTIA contract, a few new arrangements may be needed so the IETF community's expectations are still met. Those expectations are:

  • 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 that the operation of the protocol parameters registries may be transitioned from ICANN to subsequent operator(s) in the future. It is the preference of the IETF community that, as part of the NTIA transition, ICANN acknowledges 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, if a transition happens, the IETF community expects ICANN, the IETF, and subsequent operator(s) to work together to minimize disruption in the use of the protocol parameters registries or other resources currently located at iana.org. 🌸

In developing our response, we kept in mind the following points that the IETF community has discussed over the last year [ProtoParamEvo14]. These points led to the guiding principles below for IAB efforts that affect 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 to be offered independently by the Internet technical community, without the need for backing from external parties. We believe we're largely there already, although the system can be strengthened further, and continuous improvements are being made. ✨

  1. 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's important that the whole Internet community can understand how the function works, and that the processes for registering parameters, and for holding those who oversee the protocol parameters function accountable for following those processes, are understood by all interested parties. We're committed to making improvements here if necessary. 💖

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

  1. 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 also IP numbers, domain names, and other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. So 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 keep coordinating 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. 🤝

  1. 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. That responsibility includes selecting and managing the protocol parameter registry operator, as well as managing the parameter registration process and the guidelines for parameter allocation. 🎀

  1. The protocol parameters registries are provided as a public service. 🫧

Directions for creating 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're published in a form that allows their contents to be included in other works without further permission. These works include, but aren't 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 sees as the implications of the changes it proposed in Section III. These implications may include some or all of the following, or other implications specific to your community: - Description of operational requirements to achieve continuity of service and possible new service integration throughout the transition. - Risks to operational continuity. - Description of any legal framework requirements in the absence of the NTIA contract. - Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements.

IETF Response:

No structural changes are required for handling protocol parameters. 🌷 The principles listed above 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, the same way they have in the past.

Since no services are expected to change, no continuity issues are anticipated, and the IETF hasn't proposed any new technical or operational methods to test. ✨ The IETF leadership, ICANN, and the RIRs keep an ongoing informal dialog to spot any unforeseen issues that might come up as a result of other changes. 🫶

What's necessary as part of the transition is completing any supplemental agreement(s) needed 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:

Because the IETF is open to everyone, participation is open to all stakeholders. 🌍 The IETF processes outlined in Section I were used to develop this proposal. Those same processes have been, and shall be, used to amend governance of the protocol parameters function. As mentioned previously, anyone may propose amendments to those processes, and anyone may take part in the decision process. 🙌

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

IETF Response:

No changes proposed in this document 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 keeps meeting 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 developing 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 to the protocol parameters registries published at iana.org. Those who need assignments in the IANA protocol registries will keep having their requests satisfied, as specified by the existing policies for those registries. 🌈

"The proposal must not replace the NTIA role with a government-led or an inter-governmental organization solution."

Policy oversight is performed by the IAB, which is neither a government-led nor an intergovernmental organization. 🏛️

VI. Community Process 🧚

This section should describe the process your community used to develop this proposal, including: - The steps that were taken to develop the proposal and to determine consensus.

IETF Response:

The IESG set up the IANAPLAN working group to put this response together 💅 Anyone was welcome to join the chat and help build it 🫶 There's an open mailing list (ianaplan@ietf.org) attached to the group, and the IETF's IANA practices got talked about across the wider community too, with all input welcome 🌸 The group used the normal IETF procedures [RFC2026] [RFC2418] to figure out rough consensus 🔥 The chairs went through the open issues, and after an internal working group last call they decided every single one had been handled satisfactorily ✨ Then the IESG ran a formal IETF-wide Last Call, followed by a formal review, and concluded the document had rough consensus 👑

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

IETF Response:

The list below isn't exhaustive, since there have been tons of open discussions about this transition in the IETF community over the last few months 🦋

Creation of an open mailing list to discuss the transition:
   http://mailarchive.ietf.org/arch/msg/ietf-announce/
   Ztd2ed9U04qSxI-k9-Oj80jJLXc

Announcement of a public session on the transition:
   http://mailarchive.ietf.org/arch/msg/ietf-announce/
   M5zVmFFvTbtgVyMB_fjUSW4rJ0c

Announcement by the IESG of the intent to form a working group:
   http://mailarchive.ietf.org/arch/msg/ietf-announce/
   QsvU9qX98G2KqB18jy6UfhwKjXk

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

2014-10-06 Interim Meeting Agenda, Minutes, and presentations:
   http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/
   proceedings.html

Working group last call:
   http://mailarchive.ietf.org/arch/msg/ianaplan/
   EGF9rfJxn5QpQnRXmS2QxYKYR8k

Agenda from IETF 91 IANAPLAN WG meeting:
   http://www.ietf.org/proceedings/91/agenda/agenda-91-ianaplan

Minutes of IETF 91 IANAPLAN WG meeting:
   http://www.ietf.org/proceedings/91/minutes/minutes-91-ianaplan

Shepherd write-up:
   http://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/
   shepherdwriteup/

IETF last call:
   http://mailarchive.ietf.org/arch/msg/ietf-announce/
   i5rx6PfjJCRax3Lu4qZ_38P8wBg
>>>
>>> An assessment of the level of consensus behind your community's
>>> proposal, including a description of areas of contention or
>>> disagreement.
>>>

IETF Response:

This document has reached rough consensus across the IETF Working Group and the IETF community as a whole 🎀 The working group chairs judged it first, then the sponsoring Area Director, and then the IESG did, in accordance with [RFC2026], during the 18 December 2014 IESG telechat 💜 The IESG has approved the draft, pending insertion of this answer in this section and the IAB approval note 🦋 The IAB approved a statement for inclusion in the document on 19 December 2014 🌈

Lots of ideas got tossed around while this was being written, but a bunch of them didn't have enough support to make it in 🙈 The two big ones that sparked the most debate were:

  • A suggestion for a stronger statement over what terms the IAOC ought to negotiate.
  • A suggestion that "iana.org" and other associated marks be transferred to the IETF trust.

By the end of the working group process, not everyone was on board, but the chairs concluded that rough consensus existed in the working group 🥹 The document shepherd's summary of the WG consensus for this document can be found here:

https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/
shepherdwriteup/

During IETF Last Call, more people spoke up in support of the document 📣 There were several editorial comments that led to changes, plus some discussion of more substantial comments, some of which led to text changes. Some comments had already been discussed earlier in the process, but no new objections came up during the IETF Last Call 💅 A summary of the Last Call comments can be found here:

http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html

New draft versions were prepared that took into account all the agreed changes from the Last Call, and then the IESG approved the final version ✨

3. IANA Considerations 📝

This memo is a response to a request for proposals. No parameter allocations or changes are being asked for 🌸

4. Security Considerations 🔒

Okay, serious moment 😭 Even though the agreement, supplements, policies, and procedures around the IANA function have shown really strong resiliency, the IETF will keep working with all relevant parties to facilitate improvements while maintaining availability of the IANA registries. Full seriousness, no cap.

5. IAB Note 👑

The IAB is totally backing the response in this document 🫶

6. Acknowledgments 💜

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

7. References 📚

7.1. Normative References

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

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

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

[NTIA-Announce]
           NTIA, "NTIA Announces Intent to Transition Key Internet
           Domain Name Functions", March 2014,
           <http://www.ntia.doc.gov/press-release/2014/ntia-
           announces-intent-transition-key-internet-domain-name-
           functions>.

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

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
           <http://www.rfc-editor.org/info/rfc2026>.

[RFC2418]  Bradner, S., "IETF Working Group Guidelines and
           Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
           September 1998, <http://www.rfc-editor.org/info/rfc2418>.

[RFC2850]  Internet Architecture Board and B. Carpenter, Ed.,
           "Charter of the Internet Architecture Board (IAB)",
           BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000,
           <http://www.rfc-editor.org/info/rfc2850>.

[RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
           Understanding Concerning the Technical Work of the
           Internet Assigned Numbers Authority", RFC 2860,
           DOI 10.17487/RFC2860, June 2000,
           <http://www.rfc-editor.org/info/rfc2860>.

[RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
           Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
           <http://www.rfc-editor.org/info/rfc3307>.

[RFC3777]  Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
           and Recall Process: Operation of the Nominating and Recall
           Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004,
           <http://www.rfc-editor.org/info/rfc3777>.

[RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
           BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
           <http://www.rfc-editor.org/info/rfc3935>.

[RFC4071]  Austein, R., Ed. and B. Wijnen, Ed., "Structure of the
           IETF Administrative Support Activity (IASA)", BCP 101,
           RFC 4071, DOI 10.17487/RFC4071, April 2005,
           <http://www.rfc-editor.org/info/rfc4071>.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           DOI 10.17487/RFC5226, May 2008,
           <http://www.rfc-editor.org/info/rfc5226>.

[RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
           IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
           DOI 10.17487/RFC5771, March 2010,
           <http://www.rfc-editor.org/info/rfc5771>.

[RFC6220]  McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed.,
           Huston, G., Ed., and Internet Architecture Board,
           "Defining the Role and Function of IETF Protocol Parameter
           Registry Operators", RFC 6220, DOI 10.17487/RFC6220, April
           2011, <http://www.rfc-editor.org/info/rfc6220>.

[RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
           RFC 6761, DOI 10.17487/RFC6761, February 2013,
           <http://www.rfc-editor.org/info/rfc6761>.

[RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
           "Special-Purpose IP Address Registries", BCP 153,
           RFC 6890, DOI 10.17487/RFC6890, April 2013,
           <http://www.rfc-editor.org/info/rfc6890>.

[RFC7282]  Resnick, P., "On Consensus and Humming in the IETF",
           RFC 7282, DOI 10.17487/RFC7282, June 2014,
           <http://www.rfc-editor.org/info/rfc7282>.

7.2. Informative References 📚✨

bestie, these are the background reads the doc points to. Here's the full list, no cap 💅

[I-D.leiba-cotton-iana-5226bis] Cotton, M., Leiba, B., and D. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", Work in Progress, draft-leiba-cotton-iana-5226bis-17, July 2016.

[ICG-Response] IANA Stewardship Transition Coordination Group, "Proposal to Transition the Stewardship of the Internet Assigned Numbers Authority (IANA) Functions from the U.S. Commerce Department's National Telecommunications and Information Administration (NTIA) to the Global Multistakeholder Community", 11 March 2016, https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf.

[ProtoParamEvo14] IAB Chair, "Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries", March 2014, http://mailarchive.ietf.org/arch/msg/internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k.

[RFC-INDEX] RFC Editor, "RFC Index", http://www.rfc-editor.org/rfc/rfc-index.txt.

[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, October 1996, http://www.rfc-editor.org/info/rfc2014.

[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", RFC 2870, DOI 10.17487/RFC2870, June 2000, http://www.rfc-editor.org/info/rfc2870.

[RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, http://www.rfc-editor.org/info/rfc3172.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, http://www.rfc-editor.org/info/rfc4193.

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, http://www.rfc-editor.org/info/rfc6793.

[RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.Amour, "Affirmation of the Modern Paradigm for Standards", RFC 6852, DOI 10.17487/RFC6852, January 2013, http://www.rfc-editor.org/info/rfc6852.

[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, August 2013, http://www.rfc-editor.org/info/rfc7020.

[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, DOI 10.17487/RFC7249, May 2014, http://www.rfc-editor.org/info/rfc7249.

Appendix A. The Charter of the IANA Stewardship Coordination Group (ICG) 🦋

Charter for the IANA Stewardship Transition Coordination Group V.10

(August 27, 2014)

okay so the ICG has exactly one deliverable: a proposal to the U.S. Commerce Department's National Telecommunications and Information Administration (NTIA) about moving NTIA's stewardship of the IANA functions over to the global multi-stakeholder community. The group has to conduct itself transparently, consult a broad range of stakeholders, and make sure its proposals support the security and stability of the IANA functions 🔥

The group's mission is to coordinate developing that proposal across the communities affected by the IANA functions. The IANA functions split into three main categories: domain names, number resources, and other protocol parameters. The domain names category then splits further into country code and generic subcategories. There's some overlap between all of these, but each one has its own organizational, operational, and technical issues, and each tends to have its own communities of interest and expertise. That's why it's best to let work on the three categories run autonomously and in parallel, based in their respective communities 🌸

The IANA stewardship transition is happening alongside a parallel, related process on enhancing ICANN accountability. Accountability of Internet identifier governance is central to both, but this group's scope is focused on the arrangements needed to keep the IANA functions running in an accountable and widely accepted way after the NTIA-ICANN contract expires. Still, the two processes are interrelated and interdependent, and they 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. ICG members will make sure the communities they come from are working on their part of the transition plans. That means informing them of requirements and schedules, tracking progress, and highlighting results or remaining issues. During this phase, a coordination group member's job is to give status updates on how their community is doing with its component, and to coordinate which community will develop a transition proposal for each area of overlap (e.g., special-use registry) ✨

While working on their proposals, the operational communities are expected to address common requirements and issues relating to the transition, 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. No set of formal requirements related to a transition proposal will be requested outside the operational communities, but 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 was 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 that input 🧐

The ICG might at some point detect problems with the component proposals. At that point, the ICG's role is to communicate those problems back to the relevant communities so that they can address the issues. It is not the ICG's role to develop proposals or to select from among competing proposals 🚫

(iii) Assembling and submitting a complete proposal

The assembly effort means taking the proposals for the different components and verifying that the whole fulfills the intended scope, meets the intended criteria, has no missing parts, and 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. Next, the ICG will put this proposal up for public comment, with a reasonable period of time for reviewing the draft, analyzing it, 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 NTIA is not present, the parts of the proposal that aren't 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, ICG members are listed, and so on. Since developing the transition plans will take some time, it's important that information about ongoing work is shared early and continuously. That's how ideas get shared and potential issues get spotted early 👀

Appendix B. IANA Stewardship Transition Coordination Group Request for Proposals 🎀

IANA Stewardship Transition Coordination Group Request for Proposals

8 September 2014

Introduction

Under the IANA Stewardship Transition Coordination Group (ICG) Charter, the ICG has four main tasks:

  • (i) Act as liaison to all interested parties in the IANA stewardship transition, including the three "operational communities" (i.e., those with direct operational or service relationships with the IANA functions operator; namely names, numbers, protocol parameters). This task consists of:
    • 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) wants complete, formal responses to this RFP 💌 Each "operational community" of IANA (meaning anyone with a direct operational or service relationship with the IANA functions operator, for names, numbers, or protocol parameters) gets to convene its own process to put one together ✨

Proposals should have backing from a broad range of stakeholders 🫶 They should come out of a transparent process that's open to everyone who wants to take part in building the proposal. To help the ICG keep its light coordination role, every interested and affected party is strongly encouraged to jump into these community processes directly 🦋

Info about the ongoing community processes, how to join them, and updates over time lives at https://www.icann.org/en/stewardship/community 🌸

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

[https://www.icann.org/en/system/files/files/sac-067-en.pdf] gives one take on the many different meanings of "IANA," and it's a great read alongside the agreement itself 📚

Communities are asked to run open, inclusive processes when they write their responses, so every community member can fully take part in and watch those processes unfold 👀 They're also asked to actively look for and encourage wider participation from anyone else who cares about their response 📣

Here's the big challenge for the ICG: figuring out where submitted proposals clash and helping reconcile them, so we end up with one single plan for transitioning IANA stewardship 🧩 That's why submitted proposals should focus on the elements that are truly essential to transitioning 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 asking for complete formal proposals through processes convened by each operational community, it also wants every interested party to get involved as early as possible in those community processes 🌈 Some parties might still want to send comments straight to the ICG about specific parts of particular proposals, the community processes, or the ICG's own processes 💬 You can email comments to the ICG at any time via icg-forum@icann.org, and they'll be publicly archived at <http://forum.icann.org/lists/icg-forum/> 📮

Commenters should know that the ICG will send comments to the relevant operational communities where that makes sense 🦋 The ICG will review comments as time and resources allow, and in line with the overall transition timeline. So comments about specific proposals might not get looked at until those proposals have been submitted to the ICG 🕰️ The ICG may set up defined public comment periods on specific topics later on, once the complete formal responses to the RFP are in 💜

Required Proposal Elements

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

Communities are asked to describe the elements laid out below in as much detail as possible, following the suggested format and structure so the ICG can easily digest everything 🧁 Each question is narrowly defined so answers can be compared, but respondents are encouraged to add more info in explanatory sections. That includes descriptive summaries of policies and practices, plus references to the source documents for specific policies and practices 📑 That way, the answers will be useful at the operational level and to the wider stakeholder communities too 🌟

For completeness and consistency, proposals should cross-reference the current IANA Functions Contract[3] wherever appropriate, both when describing existing arrangements and when proposing changes to them 🎀

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 your community relies on, please provide the following:

  • A description of the function;
  • A description of the customer(s) of the function;
  • What registries are involved in providing the function;
  • 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 that 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 that the IANA functions operator must follow in its conduct of the services or activities described above 📜 If there are distinct sources of policy, or distinct policy development for different IANA functions, please describe them separately. For each source of policy or policy development, please provide the following:

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

B. Oversight and Accountability

This section should describe all the ways oversight is conducted over the IANA functions operator's provision of the services and activities listed in Section I, and all the ways the IANA functions operator is currently held accountable for providing 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.

  • 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.
  • 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.
  • 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 ones, explain that replacement, and describe all of the elements listed in Section II.B for the new arrangements. Your community should also give its rationale and justification for the new arrangements 💡

If your community's proposal has any implications for the interface between the IANA functions and the existing policy arrangements described in Section II.A, describe those implications here 🔗

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

IV. Transition Implications

This section should describe what your community sees 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

NTIA has also established that the transition proposal must meet the following five requirements 👑

  • Support and enhance the multistakeholder model;
  • Maintain the security, stability, and resiliency of the Internet DNS;
  • Meet the needs and expectation of the global customers and partners of the IANA functions;
  • Maintain the openness of the Internet;
  • 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 to develop this proposal, including:

  • The steps that were taken to develop the proposal and to determine consensus.
  • Links to announcements, agendas, mailing lists, consultations, and meeting proceedings.
  • An assessment of the level of consensus behind your community's proposal, including a description of areas of contention or disagreement.

Appendix C. Correspondence of the IETF to the ICG ✨

Okay so this is the final stretch, bestie 💅 Here's the paper trail of every message the IETF sent over to the ICG. Iconic lore. 📜

The following messages were sent to the ICG:

From: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [Internal-cg] Question from the ICG
Date: 20 Feb 2015 23:46:20 GMT+2
To: Alissa Cooper <alissa@cooperw.in>, ICG <internal-cg@icann.org>
Cc: Izumi Okutani <izumi@nic.ad.jp>

Dear Alissa and the ICG,

We refer to the question that the ICG asked the IETF community
on 9 Feb 2015

http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html

> The numbers proposal sees these changes as a requirement of the
> transition and the protocols parameters proposal does not.  If
> these aspects of the proposals are perceived as incompatible would
> the numbers and protocol parameters communities be willing to
> modify their proposals to reconcile them?

We do not observe incompatibilities between the proposals from the
numbers and protocol parameters communities.  The numbers
community expresses a preference to transfer the trademark and
domain, while the IETF proposal does not oppose such transfer.
This is not an incompatibility, it is something that can be
satisfied by implementation of both number and protocol
parameters community's proposals, as already specified.

To confirm this, and to determine whether the transfer
of the trademark and domain would be acceptable,
we consulted the community.  It is the opinion of the
IANAPLAN working group that they would support a
decision by the IETF Trust to hold the trademark and domain
on behalf of the Internet community.  For details, see
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01659.html

The IETF Trust also looked at this issue.  The trustees decided that
the IETF Trust would be willing to hold intellectual property rights
relating to the IANA function, including the IANA trademark and the
IANA.ORG domain name.  For details, see
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01664.html

In short, we find no incompatibility between the proposals and no
need to modify the protocol parameters proposal.

Best Regards,
Jari Arkko and Russ Housley on behalf of the IETF community and
the IETF Trust

From: Jari Arkko <jari.arkko@piuha.net>
Subject: [Internal-cg] IETF response to the time frame inquiry
Date: 5 Jun 2015 13:39:50 GMT+3
To: Alissa Cooper <alissa@cooperw.in>
Cc: ICG <internal-cg@ianacg.org>

This is a response to a query regarding transition finalisation and
implementation time frames, sent to the IANAPLAN working
group list by the chairs of the IANA Transition Coordination
Group (ICG) on May 27th.

While I am carrying this response back to the ICG, the substance
of this response has been discussed in the IANAPLAN working
group and the relevant parts of IETF leadership.  I believe this
response represents the (rough) consensus opinion that
emerged in the discussion, as well as the current state
of IANA arrangement updates that our leadership bodies
have been working on.

The IETF is ready today to take the next steps in the
implementation of the transition of the stewardship.
In our case, most of the necessary framework is already
in place and implemented in preceding years.

The remaining step is an updated agreement with
ICANN which addresses two issues.  These issues are
outlined in Section 2.III in the Internet Draft
draft-ietf-ianaplan-icg-response-09.txt:

o The protocol parameters registries are in the public domain.  It
is the preference of the IETF community that all relevant parties
acknowledge that fact as part of the transition.

o It is possible in the future that the operation of the protocol
parameters registries may be transitioned from ICANN to subsequent
operator(s).  It is the preference of the IETF community that, as
part of the NTIA transition, ICANN acknowledge that it will carry
out the obligations established under C.7.3 and I.61 of the
current IANA functions contract between ICANN and the NTIA
[NTIA-Contract] to achieve a smooth transition to subsequent
operator(s), should the need arise.  Furthermore, in the event of
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 of the protocol parameters registries
or other resources currently located at iana.org.

The IETF Administrative Oversight Committee (IAOC) has
decided to use an update of our yearly IETF-ICANN Service Level
Agreement (SLA) as the mechanism for this updated
agreement.  They have drafted the update and from our
perspective it could be immediately executed.  Once the updated
agreement is in place, the transition would be substantially
complete, with only the NTIA contract lapse or termination
as a final step.

Of course, we are not alone in this process.  Interactions
with other parts of the process may bring additional
tasks that need to be executed either before or
after the transition.  First, the ICG, the RIRs,
and IETF have discussed the possibility of aligning
the treatment of IANA trademarks and domains.  The
IETF Trust has signalled that it would be willing to do this,
if asked.  We are awaiting coordination on this
to complete, but see no problem in speedy
execution once the decision is made.  From our
perspective this is not a prerequisite for the transition,
however.

In addition, the names community has proposed the
creation of a 'Post Transition IANA' (PTI).  If the existing
agreements between the IETF and ICANN remain in place
and the SLAs discussed above are not affected, the IETF
transition would take place as described above.  That is
our preference.  If the final details of the PTI plan require
further action from the IETF, more work and community
agreement would be required.  The timeline for that work
cannot be set until the scope is known.

Jari Arkko, IETF Chair
(reporting his summary of the situation)

From: Jari Arkko <jari.arkko@piuha.net>
Subject: [Internal-cg] Response from IETF IANAPLAN WG regarding the
ICG question on coordination
Date: 8 Oct 2015 10:13:07 GMT+3
To: IANA etc etc Coordination Group <internal-cg@ianacg.org>

The IANAPLAN working group has discussed the coordination
question from the ICG.  In the working group's opinion,
informal coordination exists today and will continue, which
is consistent with the commitment requested by the ICG.

This is also consistent with an overall coordination commitment
already indicated in the IANAPLAN proposal.  The proposal
is a consensus document of the IETF.  From the proposal:

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.

The coordination approach is also consistent with the
comments that were sent by the IAB to the ICG during the
public comment period.  See
https://www.iab.org/documents/correspondence-reports-documents/2015-
2/iab-comments-on-icg-proposal/.

Jari Arkko,
IETF Chair and the Area Director for the IANAPLAN WG

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 Knoll Drive
Herndon, VA  20170
United States of America

Email: housley@vigilsec.com

That's the whole RFC, periodt! 🦋🌈

📦 where this page comes from