[wg-c] Straw Vote

[Jonathan Weinberg <weinberg@mail.msen.com>]

	WG-C began its work more than a month ago now (some WG members joined more
recently), and I think we've gotten a lot done.  To try to get us forward
to the next stage, I've been working with Javier on an options memo
summarizing the viewpoints that people have expressed on the list so far.
(Specifically, I put together an initial draft, Javier commented on the
draft, and I revised it in accordance with his comments.  Javier hasn't
seen this final version, though, and if you don't like it, you should
complain to me, not him.)

	I'd like us to start taking straw votes on these questions.  I don't mean
these votes to be formal or conclusive.  Rather, they're a tool for
revealing whether we may in fact have rough consensus on any of the issues
I've listed — something that's hard to tell in the course of everyday
discussion, given the strength and eloquence of individual voices on each
side.  I think it makes sense to take the votes successively, rather than
all at once.  That way, folks will have the opportunity, if they want, to
argue each question as it arises.

	So as a beginning, list members should cast votes on Question One.  You
should cast votes under the subject line "Straw Vote," and the sender
should indicate whether he or she is voting for "Option One," "Option Two,"
or "Neither."  Voters are free to include explanations of their votes and
arguments for their positions — or they can just cast votes.  It's up to
you.  The only requirement is that anybody voting for "Neither" *must*
explain what his or her preferred policy choice is.  Voting should close at
midnight EDT on August 18.  (I don't think we really need that long, and I
expect it'll make sense to take less time for the remaining questions, but
I figure it's better to err on the side of inclusiveness the first time out.)

	A note on nomenclature:  I use "gTLD" below to include any top-level
domain other than a ccTLD.  That is, I'm including both TLDs that have a
charter limiting registrations and those that do not.

	Thanks.

Jon


Jon Weinberg
co-chair, WG-C
weinberg@msen.com



QUESTION ONE: HOW MANY NEW gTLDS, AND HOW FAST?

Option 1:	Without regard to whether it would be desirable to have many
gTLDs in the long term, ICANN should proceed now by adding only a few, and
then pausing for evaluation.  Only after assessing the results should it
initiate any action to add more.

Option 2:	ICANN should implement a plan contemplating the authorization of
many new gTLDs over the next few years.  (Example: ICANN might plan to
authorize up to 10-12 new registries, each operating 1-3 new gTLDs, each
year, for a period of five years; each year's authorizations would be
staggered over the course of the year.)  This option would place the burden
on opponents, if evidence comes in demonstrating that additional new gTLDs
are a bad idea or that the rollout is too fast, to bring that evidence to
ICANN's attention and call for a halt or a slowdown.


QUESTION TWO: HOW TO SELECT TLD STRINGS AND REGISTRIES?

	Option 1:  ICANN should decide on a set of new gTLD strings, and then
solicit applications from would-be registries (or existing registries) to
run those TLDs.  In picking the new gTLD strings, it should use an ad hoc
approach to choose the new gTLDs that it thinks will best serve the
Internet community.  Each proponent of a new gTLD would apply to the NC for
formation of a WG devoted to that gTLD string (or to several strings).  The
WG would then generate a charter for each proposed new TLD, and it would be
up to the NC and ICANN to approve the WG's product.  This process would
likely generate some broad-based TLDs along with some more narrowly focused
ones (which might have restrictive registration policies).

	Option 2: Same as Option One, except that a standing WG would make
periodic proposals for new gTLDs.

	Option 3:  ICANN should decide on a set of new gTLD strings, and then
solicit applications from would-be registries (or existing registries) to
run those TLDs.  Before picking the new gTLD strings, it should agree on a
predetermined structure for the namespace (such as a Yellow Pages-type
taxonomy).  All new gTLDs, under this approach, would be limited-purpose.
This approach would be responsive to Dennis Jennings' concern that "the set
of gTLDs that are active must, to be successful, be clearly understood by
the vast majority of Internet  users (in English) to point to clearly
defined and (ideally) non-overlapping sub-sets of the possible Internet
hosts."

	Option 4:  ICANN should start by adding the existing "alternate" gTLDs,
and then find a neutral method to continue adding new TLD strings, focusing
on names that have already been proposed.

	Option 5:  ICANN should pick a set of registries, according to
predetermined, objective criteria.  The registries would then choose their
own gTLD strings, subject to some process or rules under which ICANN could
resolve conflicts, and could deem certain gTLD strings out of bounds.  This
approach would incorporate a mechanism under which existing registries
could apply for authorization to add additional gTLD strings.  The
registry-selection criteria might reserve a certain number of slots for
registries based in each region of the world.


QUESTION THREE: SHOULD REGISTRIES BE FOR-PROFIT OR NON-PROFIT?  HOW MANY
gTLDS SHOULD THEY RUN?

	Option 1: All registries would be run on a not-for-profit, cost-recovery
basis.  (The "registry operator," in the sense that Emergent was the
operator of the planned CORE registry, could be a for-profit company.)
Registries could operate any number of gTLDs.

	Option 2:  Some registries would be run on a not-for-profit, cost-recovery
basis, and could operate any number of gTLDs.  Other registries, however,
could be run on a for-profit basis, and would be limited to one gTLD each.

	Option 3:  Some registries would be run on a not-for-profit, cost-recovery
basis, and could operate any number of gTLDs..  Other registries, however,
could be run on a for-profit basis, and would be limited to a small number
of gTLDs (say, three).

	Option 4:  Some registries would be run on a not-for-profit, cost-recovery
basis.  Other registries, however, could be run on a for-profit basis.  Any
registry could operate any number of gTLDs.


QUESTION FOUR:  SHOULD ICANN REQUIRE SHARING?

	Option 1: All gTLDs would be shared (that is, open to competitive
registrars).

	Option 2:  An ICANN rule would presumptively require that gTLDs be shared,
but ICANN would allow exceptions in particular cases.  (A single registry
might run both shared and non-shared gTLDs.)

	Option 3:  ICANN would not require registries to support competitive
registrars in any of their gTLDs, although registries might independently
choose to do so.