[Internal-cg] Early draft for a charter

[WUKnoben]

Milton,

thanks, I'm fine with your rationale for strengthening the charter and am 
willing to contribute.

For the work of this group it seems really important to know the background 
of each participating member entity and the related process of contributing 
to the transition proposal.
Eg as I mentioned on the call I'm representing a certain part (Commercial 
Stakeholder Group, CSG) of the GNSO, as Milton, Keith and James represent 
other parts. And since there are - to some extent diverse - constituencies 
I'll have counterparts there to communicate with to give and receive 
feedback from this community.

In addition, discussion is going on as to create a cordination group within 
the GNSO (plus other stakeholders??). If that arises our charter may have to 
reflect this to avoid parallelism.

Now, who should do the real work? I'm sure parts of our communities - if not 
all of them - expect this from us with the caveat to say yes, no or amend.
There are many who'd like to call our work into question. Therefore we need 
good understanding for each other and a solid basis.

Best regards

Wolf-Ulrich

-----Ursprüngliche Nachricht----- 
From: Milton L Mueller
Sent: Monday, July 14, 2014 9:15 PM
To: Internal-cg at icann.org
Subject: Re: [Internal-cg] Early draft for a charter

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.

_______________________________________________
Internal-cg mailing list
Internal-cg at icann.org
https://mm.icann.org/mailman/listinfo/internal-cg