[Internal-cg] Early draft for a charter

[Alissa Cooper]

Hi Milton,

I’m glad we are digging into the details on this. I can appreciate the
challenges in coming to consensus within the diverse names community. But
I think there are some major drawbacks in what you suggest, so I’d like to
probe on our options for addressing that challenge.

I believe there are actually two challenges with coming to consensus in
the names community: the diversity of views, and the lack of a
cross-community decision mechanism that is trusted, or at least
acknowledged, by all of the constituencies. My understanding is that
competing policy proposals often get developed within separate
constituencies, and since there is no cross-community decision mechanism,
decisions ultimately get bumped up to the board, which is far from ideal
for many reasons. For the IANA stewardship transition, I think the first
key question is what the cross-community decision mechanism will be. I
think such a mechanism is absolutely necessary.

You have suggested that the CG should be that mechanism. I think this is
problematic for a few reasons:

1. The CG contains members from outside the names community who, in my
opinion, should not be put in the position of having authority over the
transition plan substance for names. I count myself in that category — it
is not appropriate for me, as an appointee of the IETF, to look at three
different proposals for, say, transitioning oversight of ccTLDs, and
decide which one is “best.” I don’t even know on what basis I would
choose, and in any event it subjugates the agency of the relevant
community to have outsiders choosing their fate.

2. The problem described above is a show-stopper for protocol parameters.
That is, it will not be acceptable for the CG to modify the substance of
an IETF community consensus proposal for protocol parameters if the IETF
community produces such a proposal. The ultimate authority over the
substance of the protocol parameters proposal must reside with the IETF
community, not the CG. If the CG observes problems with any proposal it
receives from the IETF, the remedy for that is to send the proposal back
to the IETF community to get fixed, not to fix it ourselves.

3. If the core of the difficulty in the names community is that views are
so diverse as to be irreconcilable, I’m not sure I understand why the
subset of the CG reps from names organizations would be more likely to
agree on one proposal than would the organizations they represent. Sure,
there are fewer people in the CG than in the community, but that doesn’t
necessarily imply that their views are any less entrenched (not saying
that’s the case — I don’t know most of you or your views! — but just
making an observation).

4. NTIA has specified that the final transition proposal needs to have
broad community support. It’s not clear to me that, if presented with,
say, four different proposals from four different constituency groups, the
CG choosing one of them would actually result in a proposal that could be
claimed to have broad community support. Same goes for if we stitch
together pieces of different names proposals.

In light of the above, I’m wondering about other options for creating a
(somewhat) trusted cross-community decision mechanism for names. I can
think of at least two.

One idea would be to try to establish a single forum where all of the
constituent groups engage with each other and each others’ proposals.
Perhaps this could be the fledgling cross-community working group being
established right now, or if some groups do not trust that structure,
perhaps we in the CG could help to establish a neutral forum where this
discussion could be had and where some community-wide decision-taking
procedure could be established. Of course, depending on how that decision
procedure works, the views may be too diverse to achieve a solution with
broad community support, but better to make that attempt than have the
small CG group declare one proposal the winner.

A less preferable but perhaps still workable idea would be to establish a
subcommittee of the CG comprised of the reps from the various names
constituencies, and have that subcommittee serve as the decision function
that you described (or as the consensus-caller in the single forum
described above). This would eliminate problems #1 and #2 from the above
list, although it may still suffer from problems #3 and #4.

I will end this novel now. Looking forward to further discussion on the
list and in person.

Best,
Alissa

On 7/14/14, 12:15 PM, "Milton L Mueller" <mueller at syr.edu> wrote:

>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