[Internal-cg] Early draft for a charter

Milton L Mueller mueller at syr.edu
Mon Jul 14 19:15:31 UTC 2014


Jari
Thanks for getting this started. I will try to prepare some amendments but it might be better to start with a rationale that explains why I think it needs amending.

I am afraid the CG will have to be a bit more proactive as the intermediary between these communities. 

You may not see this because your community (IETF, IAB, standards) deals with technical coordination, where there are strong incentives to cooperate and the value of cooperation/consensus almost always outweighs most other differences. 

I am afraid this is not true in the names world, where you are dealing primarily with politics, public policy issues, and conflicts between economic interests. Lots of zero sum games played in that space; true consensus is rare.

The DNS does not define a "community of interest;" it refers to many communities of often conflicting interests. ICANN actually has three distinct organs for DNS policy development: the GNSO, the GAC and the board itself. ICANN staff both implements policy and actively manages the policy development process. One of those organs, the GNSO, consists of 4 separate Stakeholder Groups, and within 2 of the stakeholder groups there are 5 separate "constituencies" which usually vote as a bloc irrespective of the views of the other constituencies. Within the GAC, you have about 60 governments actively represented, and we know how diverse their views can be. This does not even mention the ccNSO, which represents over 100 cc registries with a level of autonomy from ICANN's contractual regime that makes them quite different from the gTLDs and which may (or may not) have economic or political interests aligned with their government. 

Thus, it makes little sense to ask the people on the CG from the names communities to "reflect to the rest of the coordination group the consensus within [their] own community".  It is highly unlikely that a single proposal will emerge from the names communities; it is far more likely that you will get several proposals of various flavors with varying levels of support. Therefore, I think the CG has to be chartered to review and select from among those proposals:
 i) to provide a reality check on their workability, 
ii) to assess their compatibility and interoperability with the numbers and protocol part of the problem, and 
iii) to assess their levels of support. 

In other words, the CG will have to actively construct a proposal based on the "raw materials" we get from the names, numbers and protocol parameters worlds. Of course, if any one of those 3 segments rises in revolt at what we construct from their input, our charter should require us to change it. But I think we need more of a "consult - digest - propose - consult - modify" model than a "passively receive proposals and stick them together into a package" model. This does not mean voting, it does not mean we are a legislature, but it does mean that we will have to take responsibility for boiling down many diverse suggestions into workable proposals.

Please  don't shoot the messenger when I inform/warn you of this; what I say is based on 16 years of experience with ICANN, including careful observation of the differences in the initial formation of the 3 supporting organizations. 

If we define a slightly stronger charter but I prove to be wrong and the names, numbers nad protocol communities defy precedent and miraculously come together consense around a single proposal, we have lost nothing - and no one will be happier than me. But if I am right, we had better be prepared for it, don't you think?

--MM





> -----Original Message-----
> From: internal-cg-bounces at icann.org [mailto:internal-cg-
> bounces at icann.org] On Behalf Of Jari Arkko
> Sent: Sunday, July 13, 2014 7:22 PM
> To: Internal-cg at icann.org
> Subject: [Internal-cg] Early draft for a charter
> 
> (Resent with a more proper subject line)
> 
> Here is a very early draft for a charter of the group, provided as one possible
> starting point for the discussion. Please comment.
> 
> Jari, Russ, Alissa, Lynn
> 
> -
> 
> The coordination group has one deliverable, a proposal to the NTIA regarding
> the transition of NTIA's stewardship of IANA functions to  the multi-
> stakeholder community.
> 
> The coordination group performs, as its name implies, coordination, among
> the communities that are affected by IANA functions. The IANA parameters
> fall into three categories: domain names, number resources, and other
> protocol parameters. While there is some overlap among these categories,
> they have their own communities of interest; it is easiest to have these
> communities proceed on the work in parallel.
> 
> The coordination group has three main tasks:
> 
> (i) Ensuring that the relevant communities are working on their part of the
> transition  plans
> 
>  This involves informing, tracking progress, and highlighting the results or
> remaining  issues.
> 
>  The role of a coordination group member during this phase is just
> 
>    - providing status updates about the progress of his or her community in
>      developing their component,
>    - coordinating which community will develop a transition proposal for each
> area
>      of overlap (e.g., special-use registry)
>   - reflecting to the rest of the coordination group the consensus within the
>     member's own community.
> 
> (ii) Assemble a complete proposal for the transition.
> 
>  This can begin when the reports from the coordination group members from
> each  of the three communities come back with an answer of, "Yes, there is
> consensus  within my community in support of the complete proposal."
> 
>  The assembly effort involves taking the proposals for the different
> components  and verifying that they fulfil the intended full scope, meet the
> intended criteria,  that there are no missing parts, and that the whole fits
> together.
> 
>  The CG might at some point detect problems with the component proposals.
>  At that point the role of the CG is to communicate that back to the relevant
> communities so that they (the relevant communities) can address the issues.
> 
>  This step concludes when the coordination group achieves rough consensus
> that  all conditions have been met.
> 
> (iii) Information sharing and communication.
> 
>  This should be performed continuously throughout the process.




More information about the Internal-cg mailing list