RE: [wg-c] Straw Vote

[Jean-Michel Becar <Jean-Michel.Becar@etsi.fr>]

QUESTION 1:

Option 1

Jean-Michel Bécar
becar@etsi.fr
http://www.etsi.org
E.T.S.I. Project Manager
Tel	: +33 (0)4 92 94 43 15
Mobile  	: +33 (0)6 82 80 19 31
Fax      	: +33 (0)4 92 38 52 15



> -----Original Message-----
> From: Jonathan Weinberg [mailto:weinberg@mail.msen.com]
> Sent: Thursday, August 12, 1999 22:53
> To: wg-c@dnso.org
> Subject: [wg-c] Straw Vote
> 
> 
> 	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.
>