[Internal-cg] How many proposals? and ccTLDs/gTLDs

Alissa Cooper alissa at cooperw.in
Thu Aug 14 00:53:31 UTC 2014

Over in the thread about the communities RFP [1], some of us have been
discussing how many proposals the ICG should request and expect. We also
discussed this in London.

My feeling is that as far as full community proposals — i.e., documents that
contain all five sections of the latest RFP proposal [2], fully completed —
we should be open to receiving either 3 proposals (names, numbers, protocol
parameters) or 4 proposals (gTLDs, ccTLDs, numbers, protocol parameters).
>From all the discussions I’ve had with ccTLD folks, it seems as though both
their current arrangements and what they may potentially propose for
post-transition arrangements could differ from what gets proposed for gTLDs
(although not necessarily in incompatible ways). I think we should be open
to this possibility. Of course, we would expect the ccTLD community and the
gTLD community to work together to try to align themselves on areas of
overlap, in the same way that we expect all of the other communities to do
so. And our preference would still be for 3 proposals rather than 4.

Saying that we should be open to accepting 3 or 4 full proposals is *not*
the same as saying we should be open to receiving 10 or 20, where any
stakeholder can submit a full proposal. I don’t think this would be
productive, and I don’t know what we as the ICG would do with proposals that
do not come from the operational communities. Of course, we want individual
stakeholders to be able to provide input and feedback, and I think we’ve
done a good job of outlining our expectations as far as how that will work
in the charter. But soliciting input is different from soliciting a full
proposal for any of the functions — those should come from the operational

This leaves the case Milton has pointed out, where an operational community
splits into two or three groups that produce separate proposals for the same
function. Again, this is not ideal, and I think we should set the
expectation that we want to receive at most 1 proposal from each operational
community (with the caveat above about ccTLDs vs. gTLDs). If it turns out
that we get two or three proposals for the same function from different
factions of the same community, we’ll have to deal with that then (I don’t
know how), but the expectation we should set from the outset is for
uniformity within each community.

One way to smooth over the potential faction problem would be to build on
one of the requirements we already have in the RFP (Section V), which is for
the communities to provide an assessment of the consensus level and a
description of areas of contention or disagreement. If a particular
community develops a minority faction with a counter-proposal to what the
rest of the community proposes, it could be documented there (and we would
probably want to elaborate that better in the RFP). But I think this would
only work if the counter-proposal could be viewed as a minority opinion, and
I’m not sure if that’s a plausible scenario for any of the communities.

Thoughts? I mostly want to jump start this discussion among the names folks,
as I expect it to be fairly straightforward the protocol parameters
community to produce a single proposal, and the same for numbers.


[1] http://mm.icann.org/pipermail/internal-cg/2014-August/000869.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140813/7eef8006/attachment.html>

More information about the Internal-cg mailing list