How was the Internet Number Community proposal developed?
The Internet Number Community proposal is the result of discussions regarding IANA stewardship in all five RIR regional communities, and reflects the output of each of these discussions. Each of the RIRs has published archives of these community discussions on their websites, as well as the positions that came out of those discussions.
- AFRINIC IANA oversight transition information page
- APNIC IANA oversight transition information page
- ARIN IANA oversight transition information page
- LACNIC IANA oversight transition information page
- RIPE IANA oversight transition information page
To develop a unified proposal, a Consolidated RIR IANA Stewardship Proposal (CRISP) team was convened in December 2014. This team is made up of two community members and one RIR staff member from each RIR service region. Working between December 2014 and January 2015, the CRISP team met regularly via public teleconferences and held discussions via publicly archived mailing lists to draft the Internet Number Community proposal.
Archives of all of this work and these discussions are available.
– See “VI. Community Process” of the proposal for more details on how the Internet Number Community proposal was developed.
– VI. Community Process
What new “oversight” mechanism is being proposed?
Today, ICANN, as the current IANA Numbering Services Operator, is obligated by the NTIA agreement to manage the IANA Number Registries according to policies developed by the Internet Number Community.
Although the IANA operator escalation and reporting mechanisms are public in nature, the NTIA has an oversight role in the provision of the services through its contract with ICANN. This is described in Section II.B.3.i.NTIA of the proposal.
The Internet Number Community proposes establishing a new stewardship mechanism as follows:
- A new contractual arrangement is established between the RIRs (as community-based stewards of the Internet number resources) and the IANA Numbering Services Operator (ICANN) for the provision of IANA Numbering Services (which is described in Section “I.A. The service or activity” of the Internet Number Community proposal).
- Establishment of a Review Committee, with representatives from the community in each RIR region, to advise the NRO EC on the review of the IANA functions operator’s performance and meeting of identified service levels.
The proposed arrangement would place stewardship of the global Internet number resources in the hands of the open RIR communities, represented by the RIRs as the direct stakeholders of the IANA Numbering Services.
The proposal (in section III.A.3) contains a list of 12 principles to be used in drafting a service level agreement (SLA) that reflect the global community’s priorities and concerns, taking into consideration elements in the existing NTIA agreements that, in the interest of stability and continuity, could be integrated in the new contract.
The CRISP team’s proposal does not include a detailed set of legal provisions, as these are expected to be drafted by legal staff from the RIRs as a part of implementation. Based on these principles, the RIRs will develop the SLA text.
What specifically is the “element of oversight” which is referred to in section II.B.2, and how is it to be replaced under this proposal?
The element of oversight that the NTIA provides for the IANA Numbering Services is the ability to change the contract with ICANN. This is stated in the very next paragraph of the CRISP proposal (the last paragraph of section II.B.2), immediately after the sentence that says “it would remove a significant element of oversight.” ICANN has historically provided IANA Numbering Services via the IANA Number Registries under the terms of the NTIA IANA Functions contract, and therefore IANA Numbering Services for the RIRs are currently subject to change in accordance with that agreement.
In section II.B.2, the proposal says that a decision by the NTIA to discontinue its stewardship would “have no significant impact on the continuity of IANA Numbering Services,” but it would “remove a significant element of oversight.” This seems contradictory.
One statement refers to operations and the other statement refers to oversight, so there is no contradiction.
Where the proposal says “would have no significant impact on the continuity of IANA Numbering Services currently provided by ICANN,” it’s talking about operations. The NTIA has no operational role whatsoever: number resource requests from the RIRs to the IANA are not approved by the NTIA, or even seen
by the NTIA before the results are published. Removal of the NTIA’s stewardship will have no impact on operations of the IANA Numbering Services, because the NTIA plays no role in operations.
Where the proposal states this “would remove a significant element of oversight”, it’s referring to the NTIA’s oversight role, which is the ability to monitor performance and to terminate or renew the contract.
How will the Review Committee be established?
The Review Committee should be a team composed of suitably qualified Internet Number Community representatives from each RIR region. The selection of the Review Committee members should be conducted in an open, transparent, and bottom-up manner appropriate for each RIR region. There should be equal representation from each RIR region within the Review Committee. Based on these requirements, RIRs will initiate the process of setting up the Review Committee. The RIR community already has precedents and well-established processes for selecting community representatives from each RIR region, such as processed used in selecting representatives to the ASO AC and the CRISP Team.
How is the Review Committee related to any other ICANN-related review committees?
It is not related to any other committees. The Review Committee’s role is to provide advice to the RIRs in conducting reviews on the service level of IANA Numbering Services. Its scope is limited to the number resources component of the IANA function, which has no overlaps with other ICANN-related review committees.
Would ICANN continue to serve as the IANA functions operator?
The Internet Number Community proposal does not suggest changing the IANA functions operator (which would remain ICANN). The Number Community is very satisfied with the performance of ICANN in the role of the IANA Numbering Services Operator, and places a high priority on stability and continuity.
However, by making the RIRs the contract holding entities, the proposed arrangement would allow for future changes to the operational arrangement and parties. This is an important aspect of the proposal, as it ensures the independence and authority of the bottom-up community decision-making process.
This is also a key element of ensuring accountability of the IANA Numbering Services operator to maintain stable, reliable and secure service.
The CRISP proposal does not in any way affect the structure, arrangements or processes for IANA-related policy-making, including ICANN’s role in the global Policy Development Process (gPDP, as detailed in the attachment to the ASO Memorandum of Understanding). If the role of IANA functions operator were to move to a different entity, the ICANN Board would retain its role in ratifying global policy proposals. Changing the gPDP would require an entirely separate discussion and process.
Does the Number Community proposal suggest “breaking up” the IANA functions?
The Internet Number Community proposal notes the critical importance of coordination across the various IANA functions; it does not suggest that these functions should have different operators. The communities have also expressed a clear priority for continuity and stability in the operation of the IANA functions.
The proposal does identify a specific subset of the IANA functions –the IANA Numbering Services– which are of specific relevance to the Internet Number Community and over which that the affected community has authority. In the same way, the proposal assumes that those IANA functions relating to domain names and protocol parameters fall under the authority of the open communities dealing with those functions,since the administration of IANA registries must ultimately meet the needs and expectation of the global customers and partners of the IANA services.
In that sense, instead of “breaking up” the IANA functions, the proposal suggests separately treating the stewardship of the IANA functions per function, with each “affected community” (the communities concerned with numbers, names and protocol parameters, as identified by the IANA Stewardship Transition Coordination Group) acting as steward for their subset of the IANA functions. This could mean that a single IANA functions operator (such as ICANN) would have contractual relationships with each of these three communities or their representatives. This reflects the realities of stakeholders of each of the IANA function, as it can be observed from the fact that there are three operational communities developing the IANA stewardship transition proposal.
Should these communities decide at some point in the future that different operators should manage these functions, the proposal stresses the importance of coordination across all IANA steward and operational parties.
The CRISP proposal is based on the understanding that the Number Community has stewardship of the number-related IANA functions. This, however, does not preclude Number Community support for a single, complete IANA stewardship solution to be developed by the IANA Stewardship Transition Coordination Group (ICG), as long as that solution respects and incorporates the authority of the open, bottom-up Number Community.
The numbers proposal sees the transfer of the IANA mark and domain 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?
The numbers proposal does not set a “MUST” condition to transfer the mark and domain to the IETF Trust or to any other specific entity, and the IETF proposal does not say it will oppose transfer of the mark and domain to the IETF Trust, so we do not observe any incompatibilities. From discussions on the IETF ianaplan group, we observe that subsequent decisions by the IETF ianaplan group and the IETF further support the position that there is no conflict.
Given the stated need for “communication and coordination” between the communities, how is this to be achieved under this proposal?
This proposal assumes that specific IANA customers (i.e., the Number Community, the protocol parameters community, and the names community) will have independent arrangements with the IANA Functions Operator related to maintenance of the specific registries for which they are responsible. At the same time, the Internet Number Community wishes to emphasize the importance of communication and coordination between these communities to ensure the stability of the IANA services. Such communication and coordination would be especially vital should the three communities reach different decisions regarding the identity of the IANA Functions Operator after the transition. Efforts to facilitate this communication and coordination should be undertaken by the affected communities via processes distinct from this stewardship transition process. In the event that all three communities (numbers, protocol parameters, and names) choose the same IANA operator, then we expect that minimal coordination will be required. In the event that different IANA operators are chosen by different communities, then coordination will be required to ensure coherency of the IANA functions. The numbers proposal merely records that coordination may be necessary for such future possibility. If such event occurs in the future which requires coordination, there is an existing mechanism, which enables such coordination, as SOs and ACs representing the three operational communities. We could make use of such existing mechanism.
In its transition proposal the Number Community has proposed that a new contract be established between the IANA Numbering Services Operator and the five RIRs. This arrangement would allow the RIRs to cancel and rebid the contract if needed, for example, to find a new IANA Numbering Services Operator. If such a circumstance were to arise, how easy or difficult would this be in practice and to what extent might this create any disruptions?
As stated in our proposal, there are no concrete needs or plans to change its operator at this point. The Internet Number Community is proposing the ability for the RIRs to choose the IANA Numbering Services operator as a possibility if needed. The arrangement to terminate and rebid the contract if needed already exists in the contract between the NTIA and ICANN as the IANA Functions Operator.
The SLA provides the RIRs with the option to terminate the SLA during its term if the Operator failures to perform and, after going through arbitration, fails to remedy such failure to perform, or not to renew the SLA at the end of its term.
With regards to termination, we note that the NTIA contract provides the US government with the same reasons for termination (page 2 of the NTIA contract and sections E.2.g.1.ii and I.67.i of the NTIA contract). Additionally the NTIA contract gives the option to the US government to terminate the NTIA contract for more reasons (sections I.51 and I.52 of the NTIA contract).
Based on the above, we believe that the SLA provides fewer reasons for the termination of the SLA than the NTIA contract and thus it would not be easier to terminate and rebid the SLA.
With regards to rebidding for the contract, the NTIA has a rebidding process today called “Request for Proposal”, which allows proposals from anyone interested in serving as the IANA Functions Operator, not limiting candidates of the bidding to the existing IANA Functions Operator (as an example of this process we refer to the last re-issue of the Request for Proposal (RFP) made on April 16, 2012, published on the NTIA website).
Further, the Number Community have listed “Continuity of Operations” in the numbers proposal, as a principle to be reflected in the SLA, “If, at the end of the term, the RIRs decide to sign an agreement for provision of IANA Numbering Services by a different party, the previous IANA Numbering Services Operator will be obliged to ensure an orderly transition of the function while maintaining continuity and security of operations.”
As stated in the number resources proposal, the Internet Number Community has expressed its strong desire for stability of the IANA Numbering Services. RIRs, as the direct customers of the IANA Numbering Services, will be more strongly affected than NTIA, if any disruptions are created as a result of a cancelation or rebidding of the contract. It is in the interests of the RIRs to ensure continued stability of the IANA Numbering Services in a possible event of changing the IANA Numbering Services operator.