[wg-c] Straw Vote

[John Charles Broomfield <jbroom@manta.outremer.com>]

Here is my reply to the straw vote:

>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.

Actually both answers are not really exclusive. A plan should be implemented
to be able to add quite a lot of new gTLDs (a few hundred, not a few
tens of thousands) over the next few years. The first batch should be very
slow and limited however to be able to evaluate the consequence:
Answer: both 1 & 2

>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.

Option 2 would be the best approach. If we are contemplating adding more
gTLDs for the benefit of the 'net, and we are thinking of adding quite a
few, setting up a work-group for each and every new gTLD would be too
cumbersome. We'd be flooded by workgroups.
As I feel that a registry should be able to equally run ANY given
combination of letters as a gTLD, having it choose what gTLDs it "wants"
serves no useful purpose to the community.

>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.

Option 1.


>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.

Option 2. In general, the rule would be "make it shared" so that registrars
can compete on gaining service. However, it could be possible that a
chartered and enforced registry exists (much like ".edu" today), and being a
low volume registry, if it has to add the burden of setting up a procedure
to interact the authorizing agency for that TLD with the registry &
registrar, that could make this particular case too complicated to make it
worth mandating shared. In any case, with small cases such as those, I'd be
surprised if the registrars would complain that they don't have a unified
interface for that TLD. As it's low volume, they wouldn't care (low volume
means few registrations, therefore no profit for the registrar).


In summary:
Question 1:	Options 1&2
Question 2:	Option 2
Question 3:	Option 1
Question 4:	Option 2

Yours, John Broomfield.