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

Fri Oct 2 15:31:13 UTC 2015

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

This was why we felt history was needed. As an explanation.

   Patrik

On 2 Oct 2015, at 18:17, Mueller, Milton L wrote:

> I would agree with Wolf-U that you'd need a lot more specifics in the paragraph about the web of relationships, I would go further and say that most of the preceding paragraphs are not needed, in that they describe the OCs themselves rather than the cooperative mechanisms among them. I don't think we need to do that.
>
> --MM
>
>> -----Original Message-----
>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of
>> WUKnoben
>> Sent: Thursday, October 1, 2015 5:53 AM
>> To: Lynn St.Amour <Lynn at LStAmour.org>; IANA Stewardship Transition
>> Coordination Group <internal-cg at ianacg.org>
>> Subject: Re: [Internal-cg] how collaboration works today between the OCs
>>
>> I think this is a good summary - at least for insiders. I wonder whether we
>> shouldn't be a bit more specific on how the interrelation between the OCs
>> works. "A web of relationships exists between these OCs, and the
>> relationships and mechanisms evolve as needed." Some examples may be
>> helpful: ICANN board membership, cross-membership between OCs, cross-
>> community working groups...
>>
>> Just an idea.
>>
>> Wolf-Ulrich
>>
>> -----Ursprüngliche Nachricht-----
>> From: Lynn St.Amour
>> Sent: Wednesday, September 30, 2015 10:26 PM
>> To: IANA Stewardship Transition Coordination Group
>> Subject: Re: [Internal-cg] how collaboration works today between the OCs
>>
>> Hi,
>>
>> sending again, as I did not see this come through on our list.
>>
>> --------------
>>
>> Please find attached the suggested text for action item:
>>
>> 10) St. Amour, Gerich, and Fältström to summarize how collaboration works
>> today between the OCs.
>>
>> 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 (although Part
>> 0 is evolving quite significantly and there may be a better place).
>>
>> 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.
>>
>> There has been a significant level of discussion on this amongst the group
>> members.  Elise has some concerns and we agreed to highlight that fact to the
>> ICG as part of our review.  I will leave it to Elise to share those concerns if they
>> have still not been adequately addressed..
>>
>> <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 (OC) 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.
>>
>> -- Policies are defined as "the agreed upon rules developed through
>> community-based processes by which shared Internet resources are
>> managed".
>> -- Oversight here is defined as "to ensure policies and implementation are
>> aligned and promote the coherent long-term development and use of shared
>> Internet resources."
>> -- Implementation of such shared Internet resources (i.e. IANA Functions)
>> should be "in a neutral and responsible manner, guided by the relevant policy
>> and oversight processes".
>>
>> 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.  This transition proposal was developed by the
>> 3 OCs, and existing coordination mechanisms were used to ensure its overall
>> coherence.
>>
>> 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>
>>
>> This could be further edited or split if it fits better elsewhere.   We look
>> forward to the ICG's comments.
>>
>> Best,
>> Lynn, Patrik, Elise
>>
>>
>>
>> _______________________________________________
>> Internal-cg mailing list
>> Internal-cg at mm.ianacg.org
>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org
>>
>>
>> _______________________________________________
>> Internal-cg mailing list
>> Internal-cg at mm.ianacg.org
>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at mm.ianacg.org
> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/attachments/20151002/cc86d048/attachment.asc>