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

Re: [wg-c] Straw Vote



-----BEGIN PGP SIGNED MESSAGE-----

Here are my responses to the "straw vote"


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

Option 2


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

Comment:  This scenario must take into account that there are presently
                  several hundred active, non-global new gTLDs already in
                  existance, operated by numerous registries who seek inclusion
                  into the root.   There exists no statute which gives
ICANN the
                  power to forclose on those existing businesses operating new
                  gTLDs, and being bound by the antitrust laws, ICANN must
                  allow access to the ESSENTIAL FACILITY, the ROOT, on a
                  nondiscriminatory basis, for these existing new gTLDs and
                  the companies who currently operate them, some of whom
                  are accredited by ICANN.


>QUESTION TWO: HOW TO SELECT TLD STRINGS AND REGISTRIES?
>

Option 4

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

Comment:   In the hundreds of existing, non-global new gTLDs presently in
                   operation by several companies, there are thousands of users
                   who have subscribed to these new domains, and intend to use
                   them both in commerce, and as expressive promotions of their
                   content, goods, or services.   There is no authority
which exists
                   who has the right to forclose on the companies operating
these
                   new domains, nor the right to censor the use of these
domains
                   by legitimate clients and users on the internet.
Therefore, all
                   presently functional and populated new gTLDs and SLD-gTLDs
                   must be recognized when taking into account which new gTLDs
                   are added to the ROOT.


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

Option 4

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


Comment:  It is not the place of this committee, of ICANN, or of any government
                  to impose a particular business model on private
companies.  All models
                  must be recognized, and it is up to the individual
companies to determine
                  which model suits them best, or whether to enter the DNS
services
                  industry at all.


>
>QUESTION FOUR:  SHOULD ICANN REQUIRE SHARING?

Option 3


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

Comment:  This is also a business decision, and should not be mandated.
                  It is well known that affiliate sales channels are a
model of choice
                  in today's internet.  It is up to individual companies to
choose.

Respectfully submitted,

Paul Garrin
Founder/CEO
Name.Space, Inc.
http://name-space.com






-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBN7jlPzKqKS1V5mCRAQEBvgP/T1wBvanD9MZXGWKS9n/b8lI4ylz/yES2
P34+zc9YeT7A2Ekt0cftOtQgHhfQeZ22QOUnzrhPZ1dk9dFw6bCWuIreLig46Ig0
aqUms8PMBcMT4Ws/90v72ODyg1J31tA5HeeZZoufoqRiYgpGcwRa1thlex8A9A14
QkRFSXugyig=
=6Mfm
-----END PGP SIGNATURE-----