[Internal-cg] how collaboration works today between the OCs

[Lynn St.Amour]

Please find attached updated text for the action item (apologies for the delay, just too many action items here and elsewhere).

10) St. Amour, Gerich, and Fältström to summarize how collaboration works today between the OCs.

Intro:   Our task was to summarize how collaboration works today between the OCs.  In doing so, we recognized that the 3 OC model had not really been elaborated on in the ICG's proposal and as that was the basic underpinning, we tried to cover both. 

Our current thinking is that in Part 0 a new section after paragraph 01 could be useful.  Basically, a high level model introduction, though we may still want to split this into two sections.

The text below is based on RFC 2860, SAC-067, and the Internet Organizations (I*) Shared Resource document at https://www.internetsociety.org/sites/default/files/is-internetresources-201308-en.pdf .   Note: the text below would need to incorporate appropriate references. 

As Patrik said previously, the key thing we felt was missing in the discussions so far is that for each registry there is already a given OC that has requested it, and because of that is in charge. To explain this without talking about history we felt was extremely difficult.  It is definitely not the case that an OC that requires a registry "must" have it managed by the IANA Function at ICANN. What is discussed is what parameters and judgement OCs use when they make a decision on where to host a registry, and the fact they do (and always have) counted cooperation and collaboration as important parameters for that decision."

There seemed to be support for keeping the background and historical information in, so that is what is reflected here -- though obviously up to the full ICG.

<start>

The Internet’s incredible growth and success has been due in large part to its shared global ownership, use of open standards, and freely accessible processes for technology and policy development.  The smooth operation of the Internet depends upon a global, collaborative and community-driven approach to managing key shared resources. 

Some of the most important shared resources are Internet Protocol addresses, Domain Names/DNS Root Zone Management, and Protocol Parameters.    Taken together these are referred to as the Internet Assigned Numbers Authority (IANA) Function. 

The IANA Functions Operator (IFO) performs a set of administrative coordinating services, under policy direction from 3 Operating Communities (OCs), for many of the identifiers that allow the global Internet to operate.  The three “operational communities” (OCs) are: the domain names community (organized around ICANN’s supporting organizations and advisory committees); the number resources community (organized around the regional address registries or RIRs); and the protocol parameters community (organized around the Internet Engineering Task Force (IETF)).

The identifiers are:

1) Domain Name System (DNS) Root Zone; 
2) Internet Numbers Registry;
3) Protocol Parameter Registry, including the “Address and Routing Parameter Area” (.ARPA) TLD;
4) INTernational treaty organizations (.INT) top-level domain.

The services above are performed under a number of independent operational agreements between the Operating Communities (OCs) and ICANN (as the current IANA Functions Operator), as well as under a contract between ICANN and the USG Department of Commerce given their stewardship role over these functions.

It is important to note that the Policy and many of the Oversight responsibilities for these tasks lie with the operational communities and not the IANA Functions Operator (IFO), hence they do not form part of the IFO's responsibilities.  

Community specific (and community defined) global policy development and oversight processes exist in the OCs as part of their responsibilities for ensuring the continued smooth operation of the global Internet.  A web of relationships exists between these OCs, and the relationships and mechanisms evolve as needed.  

Currently, there is a multitude of collaboration mechanisms in place.  The most obvious is that participants in the OCs also participate in the activities of other OCs, with the degree of formality decided by the OCs involved.  Some examples:  RIR participants also participate in IETF working groups;  IETF participants participate in TLD-related activities at ICANN; the IETF appoints people to the ICANN TLG as well as a liaison to the ICANN Board; ICANN staff and participants participate in IETF working groups; the IESG has daily operational contact with the IANA staff; etc.).

Some historical information may be useful here, and also described in Section 2 of SAC-067 <https://www.icann.org/en/system/files/files/sac-067-en.pdf>, RFC2860 and of course the webpage for the IANA Function at ICANN <http://www.iana.org/about>.   IANA started as a service to the community provided by one individual: Dr Jonathan B. Postel.  Later the service was housed in  ISI in Marina del Rey (where Dr. Postel was working), and it was specifically designed for what is now the Protocol Parameters Operational Community (IETF).   The IANA Function was later contracted to ISI by the US Government as part of the Teranode contract, and that was subsequently replaced by the agreement between the US Gov and ICANN.  This is the set of activities the US Government is now looking to transfer back to the private sector.  

Cooperation between the communities has always existed.  Prior to ICANN's formation, IANA supported multiple policy development processes and each OC decided on registry policy and place of implementation for each of the registries they were responsible for defining.

Another more specific example of cooperation has to do with IP addresses.  The IETF sets the over all policy for IP addresses, while the  RIRs set the detailed policy for subsets of the addresses.  Some blocks are to be used for routing on the Internet, and IANA registers this over arching allocation.  When RIRs later request addresses from IANA,  IN-ADDR.ARPA and IP6.ARPA zones (and whois) are updated accordingly, through IANA, although the ARPA TLD is managed by IAB.  In brief, IETF sets the over arching policy, RIRs set the detailed policy, and IANA registers and coordinates those allocations.  The individual OC proposals go into a lot of detail about the intersections/collaboration between the registries (see paras 2016-2019, 3027, and P1.Annex A).

Coordination across the OCs is clearly an essential component to the Internet's successful development, and collaboration is an integral part of the OCs operating and policy development processes.   In the specific case of the IANA Functions, each community has clearly restated their ongoing commitment to cooperation.  That commitment to cooperate has led to the situation we have today, where nearly all registries are with the IANA Functions Operator (at ICANN) even though the operational and policy decisions for where these registries will be located, and how they will be run, is decentralized.

<end>

Again, this could be further edited or split if it fits better elsewhere.   We look forward to the ICG's comments.

Best,
Lynn, Patrik