[Internal-cg] Early draft for a charter
wolf-ulrich.knoben at t-online.de
Mon Jul 14 19:54:00 UTC 2014
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.
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
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
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
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
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?
> -----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
> starting point for the discussion. Please comment.
> Jari, Russ, Alissa, Lynn
> The coordination group has one deliverable, a proposal to the NTIA
> 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
> transition plans
> This involves informing, tracking progress, and highlighting the results
> 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
> developing their component,
> - coordinating which community will develop a transition proposal for
> of overlap (e.g., special-use registry)
> - reflecting to the rest of the coordination group the consensus within
> 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
> intended criteria, that there are no missing parts, and that the whole
> 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
> communities so that they (the relevant communities) can address the
> 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
More information about the Internal-cg