[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [wg-c] Straw Vote Option 2

Russ and all,

  My vote here is for Option #3 with the following stipulations.

1.) That any and all gTLD's registrars have options as to which Registry
      service or their own Registry service.

2.) That any and all gTLD Registrars or potential Registrars may be shared
      non-shared or a combination of both, and that the "Legacy Roots"
      must except any an all applications for entry into the "Legacy Roots"
       if all applications are "Chartered" and such charters are a negotiated
       agreement with the ICANN, NSI and the applying potential gTLD

Russ Smith wrote:

> I vote for option 2 with comments:
> The first issue is that there are already numerous cc TLD's who are
> effectively already acting as ccTLD's.  Addition generic TLD's will not be
> substantially different than the current situation.  I would also disagree
> with implication in the example in option 2 that suggests ICANN would set a
> specific number of TLD's.  ICANN should only be setting standards and
> specifications to qualify.  The marketplace would determine the actual
> number.
> I also do not see the basis for denying additional TLD's.  Company A who has
> a.com is saying we cannot have '.new' because somebody may register a.new.
> However, this also blocks company b from registering b.new, company c from
> registering c.new, etc.  Attempting to block/censor Internet activities is
> usually a losing battle and is detrimental to the Internet overall.
> The notion that the issues of 'famous marks' and dispute policies being
> 'solved' is also not valid.  While you may develop one policy that works
> better than another, etc. the issue will never be 'solved.'  If that were
> possible most trademark issues in the regular world would have been 'solved'
> by now and we would not need all these trademark lawyers.
> I also believe the notion (in Q.3) that ICANN should be deciding the
> business structure of registries as this is well beyond anything that ICANN
> should be contemplating.  The only reason to look at the business structure
> would be for stability.
> http://www.uninett.no/navn/domreg.html - list of ccTLD's
> http://www.domainstats.com/ - stats on ccTLD's.
> Russ Smith
> http://domainia.org
> -----Original Message-----
> From: jmcgivern@ascap.com [mailto:jmcgivern@ascap.com]
> Sent: Friday, August 13, 1999 1:38 AM
> To: mljenkins@rbd-law.com; gregoryh@staff.abanet.org; mkirk@aipla.org;
> lschroeder@aipla.org; mark@hellman.org; smosenkis@ascap.com;
> acollins@ajpark.co.nz; law@sbm.com.ar; felipe@claro.cl;
> ntyree@publishers.org; srosen@bmi.com; remingmj@dbr.com;
> bwfitzgerald@swidlaw.com; donm@bsa.org; eric.fingerhut@shawpittman.com;
> swadyka@slavitgill.com; ooblick@netpolicy.com; martys@interport.net;
> william@dso.net; jwkckid1@ix.netcom.com; ecta@ecta.org;
> jorange@orpat.com; sonn@sonn.at; nils.bortloff@ifpi.org;
> wmcgrath@dmmlaw.com; mheltzer@inta.org; cchicoine@bspmlaw.com;
> nwood@netsearchers.co.uk; tshapiro@mpaa.org; tcohen@mpaa.org;
> hschwartz@fishneave.com; jmd@ogk.com; jwhitehead@riaa.com;
> mflynn@siia.net; dduncan@siia.net; ikaufman@ladasparry.com;
> howard@netnames.com; russ@russ-smith.com; jasonvogel@ibm.net;
> jcohen@shapirocohen.com; vcarrington@shapirocohen.com; scaf@idealaw.com;
> mkirk@aipla.org; metalitz@iipa.com; tatham@dial.pipex.com
> Subject: FW: [wg-c] Straw Vote
> ---------------------- Forwarded by Joan McGivern/ASCAP on 08/13/99 01:37 AM
> ---------------------------
>  (Embedded
>  image moved   "Chicoine, Caroline" <chicoinc@PeperMartin.com>
>  to file:      08/12/99 05:15 PM
>  pic14605.pcx)
> To:   Joan McGivern/ASCAP@ASCAP
> cc:
> Subject:  FW: [wg-c] Straw Vote
> Can you please forward to IPC members.  I do not yet have an email group
> set up for them.
> We have a Wednesday august 18th midnight EDT deadline for responding to
> Quesiton One.
> My proposed response:  Neither. No new gTLDS should be added until the
> uniform dispute policy and famous marks issues are resolved, and then
> only a few on a temporary basis so we can test it out. (this was exactly
> Mike Kirk's response when he agreed that the WGC Report deadline should
> be extneded.)
> -----Original Message-----
> From: Jonathan Weinberg [mailto:weinberg@mail.msen.com]
> Sent: Thursday, August 12, 1999 3:53 PM
> 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
> 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.
>      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 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: 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.


Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208