[Internal-cg] Early draft for a charter
WUKnoben
wolf-ulrich.knoben at t-online.de
Tue Jul 15 18:53:44 UTC 2014
I think the group has to be clear about the various consensus levels
everybody has in mind when talking about "consensus". In addition it should
be transparent on whose behalf CG members speak and - if at all -
participate in consensus calls. It could be helpful to mention it in the
charter.
Best regards
Wolf-Ulrich
-----Ursprüngliche Nachricht-----
From: Milton L Mueller
Sent: Tuesday, July 15, 2014 8:30 PM
To: 'Daniel Karrenberg'
Cc: Internal-cg at icann.org
Subject: Re: [Internal-cg] Early draft for a charter
> -----Original Message-----
> The best the CG can do is to produce a unified proposal from the parts
> that
> *do* have consensus in their respective communities and have those
> communities come to consensus about that unified proposal.
Thanks, Daniel. That is not much different from what I am proposing. But I
am calling attention to a fact that is often neglected or deliberately
ignored in these circles, which is that the presence or absence of
"consensus" is not self-evident, that consensus can be (and often is)
claimed when it does not exist, and thus there is a need for independent
assessment of the level of support enjoyed by a proposal. I am also
insisting on the fact - yes, it is a fact - that no proposal coming out of
the DNS world will enjoy total, true _consensus_ if we use the term in the
proper, Quaker sense, meaning full accord, no objections, unanimity. Some of
them may, however, enjoy significant, broad support, broad enough to be
viable. So the CG will have to make judgments about what passes the bar and
what doesn't.
> It may be that the names communities do not realise what is at stake for
> them and that it is in their interest to agree on *something* within a
> reasonable time. If they cannot manage this by themselves then then the CG
> cannot make this happen magically and should not try.
And you recognize, of course, that such an approach gives veto power to any
group that does not want the transition to happen?
There is a long history of obstructionism by small but determined and
powerful interests in the names world. How does this fit in with your
concept of consensus? I wonder why you would consider, say, the GNSO or an
ICANN-composed CCWG as a legitimate modifier or developer of a proposal but
would not consider a CG whose members were appointed as representatives by
the exact same group. Alissa's idea of a subgroup of DNS-related people on
the CG might make sense here.
> Rather the CG should make a proposal that leaves out the IANA functions
> concerning names and disband.
This I regard as irresponsible. An IANA transition that does not include a
viable plan for DNS is not an IANA transition. Full stop. The protocol
parameter registries are not controversial. The number registry issues could
be controversial, but currently are not. If we cannot resolve DNS
controversies, we have resolved nothing, accomplished nothing. So if you are
happy with the status quo, keep singing this tune.
> If the names communities should find that they need help coming to
> consensus it is up to them to find that help somewhere, possibly in
> arbitration or some other process help. That is up to them. But if they
> come
> to us we should say 'No'.
Did I miss the argument as to why? I want an instrumental argument, a
practical argument, not a fable or an anecdote
> Summary: Daniel fully agrees with Alissa and substantially disagrees
> with Milton.
What you agree or disagree with, I hope, are specific arguments or
positions, not people. Personalization of disagreements about the charter
and mission is counterproductive. For one thing, there are about a dozen,
distinct statements or arguments in my last post, some of which are not all
that contestable. Are you saying you disagree with all of them simply
because they come from me? Lets try to do better.
--MM
_______________________________________________
Internal-cg mailing list
Internal-cg at icann.org
https://mm.icann.org/mailman/listinfo/internal-cg
More information about the Internal-cg
mailing list