<<<
Chronological Index
>>> <<<
Thread Index
>>>
Hypocrisy
- To: allocationmethods@xxxxxxxxx
- Subject: Hypocrisy
- From: Danny Younger <dannyyounger@xxxxxxxxx>
- Date: Tue, 16 Oct 2007 12:07:59 -0700 (PDT)
Over the years we have heard numerous rejections of
the auction concept from members of the BCUC, ISPCP,
and IPC.
For example, the BCUC stated in their June 2005 White
Paper on Internet Domain Name Expansion: "In short,
any supposed benefit from an auction model for new
domain names has a disproportionate cost due to the
increased likelihood of market distortions. Such an
approach is contrary to the public interest and
therefore contrary to ICANN?s core values."
In the February 2006 submission entitled "ISPCP
Position on New gTLD Expansion" the constituency
states: ?The ISPCP believes that an auction model is
a very bad idea.?
The IPC, as reported in the GNSO Initial Report
Introduction of New Generic Top-Level Domains, has
similarly stated: "The IPC doubts the usefulness of
auctions, in view of risks for dominance, bias and
overbidding".
These three constituencies reaffirmed their
above-stated positions on auctions during the GNSO
Washington session that investigated allocation
methodologies (PDP Terms of Reference #3), and thus
the GNSO did not move forward on auctions -- owing
primarily to the beligerence of these three groups on
the topic.
That all changed when the Business Constituency
realized that certain of their members wanted to
obtain O.COM and Y.COM (BC members Overstock.com and
Yahoo! respectively), and that auctions were the only
means by which they could obtain those names
exclusively for themselves.
Those institutions (and others) had already written
correspondence to the ICANN Board asking for the
release of these single-letter second-level reserved
names -- see the letter from Overstock's Chuck Warren
to the ICANN Board and the letter from Yahoo!'s David
Filo to the ICANN Board (both posted in the
correspondence section of the ICANN website).
This led to BC members exclusively populating a GNSO
subcommittee subgroup "researching" this issue --
suddenly greed was more important to this constituency
than adherence to long-held principles.
The subgroup that prepared these recommendations
consisted solely of the following BCUC members: Neil
Blair (who advocates on behalf of Overstock.com in an
effort to acquire O.com), Mike Roddenbaugh (who seeks
to promote Yahoo's interest in obtaining Y.com and
Y.net), Marilyn Cade (who has Overstock.com as a
client) and Alistair Dixon (who along with all the
aforementioned is also a member of the Business
Constituency).
This was a classic example of "Capture by a
Self-interested Faction".
The recommendations were promulgated to an uniformed
and inattentive GNSO Council with the following
considerations noted:
"Methods for allocating released names were discussed
by the Sub-group. Three alternative recommendations
are presented:
[ALT1]: A registry could propose release of single
letter or number strings through the process for new
registry services, which process involves analysis of
any technical or security concerns and provides
opportunity for public input. This approach could
also address concerns raised about allocation of
names, reduction of registrar contributions to the
ICANN budget, and capacity building.
[ALT2]: Currently reserved names may be released
through a framework to be developed, which treats the
release and allocation of single letters in the non
sponsored gTLDs uniformly by allocating them via
auction to parties with demonstrated rights; allocates
funds to benefit ICANN stakeholder interests and
reduce dependency on Registry/Registrar contributions;
provides funds to assist in supporting
capacity-building for applications from developing
countries in some kind of balanced and transparent
manner; and/or provides funds for a Security Institute
focused on root servers, DNSSEC, etc.
[ALT3]: ?Drop and Grab? model putting the names into
the secondary market for auction/sale. Nobody in the
sub-group supports this ALT."
The recommendation, and the above considerations, are
tainted by a self-interest that has further chosen to
disregard the legitimate technical concerns put
forward and made known to the subgroup by respected
expert John Klensin.
John wrote:
Subject: Single-letter second level domains
Your recent note to the GNSO Council about
single-letter domains
(http://gnso.icann.org/mailing-lists/archives/council/msg03148.html)
and the attached report was just called to my
attention. I'm
copying Steve Crocker on this note since the topic is
very much a stability issue and not a provision for
expansion or infrastructure one.
The premise of the report, that the main reason for
reserving single-letter names was to permit future
expansion, is not correct. That explanation is,
instead, the consequence of a long-term, and
oft-repeated, misunderstanding. I've tried explaining
this several time to a number of people and groups
within ICANN including various senior staff, both of
the previous IANA managers, and several of the members
of the community who have been pushing for
single-character registrations.
The notion that single-character names should be
reserved for expansion of the DNS derives from an
almost offhand comment Jon Postel made many years ago.
The essence of the comment was that, given all of the
confusion and problems that had been created by trying
to associate TLDs with specific semantics, we would
have been better off with TLDs named "b ... y"
(reserving "a" and "z" for future expansion and
because people might think they had special value).
When someone asked for a domain name at the second
level, they would then be randomly assigned to one
of those single-character TLDs. A somewhat fanciful
set of notes circulated for a while that elaborated on
this idea. That document never made it into formal
publication although part of it inspired an
alternative option for ENUM that also was never
published. It should be stressed that these ideas
were more of the character of whimsical musings than
serious proposals. They were never considered as
serious proposals even by their originators.
In any event, that particular idea about DNS expansion
would never have produced "Example.a.com". It might
have produced "example.com.b" (as mentioned above, "a"
and "z" were, in that idea, permanently reserved) or,
more likely, "example.d" or "example.cc.b".
There was apparently an entirely separate and
unrelated suggestion about reserving one-character
labels at some level of the DNS for infrastructure
use, much as subdomains of .ARPA are used today.
While I remember hearing about that idea, I think
it was just a suggestion made during a meeting or
conversation. As far as I know, the suggestion was
never written down or explained, much less turned into
a proposal that anyone considered or approved.
The reason for the prohibition on single-character
registrations was strictly a matter of identifier
integrity and DNS stability. Specifically, it was
intended to reduce the odds of false positive errors
if a one-character typing error was made. The
prohibition on the use of underscore ("_") in domain
names, given that hyphen ("-") was going to be
permitted, was largely driven by very similar
considerations. I believe that, had we realized that
we would end up with millions of names in some
TLDs and almost complete saturation of the
two-character and three-character spaces in those
TLDs, registration of two-character SLDs probably
would have been prohibited as well.
That reason has not changed. If one permits (and
encourages, which, in today's market, is much the same
thing), single-letter registrations, it is safe to
assume that all 26 labels will swiftly be populated
(single-digit labels raise some additional
issues because they are very easily used in certain
types of tricky-syntax phishing attacks). Anyone
trying to use one of these labels and making a
single-character mistake will almost certainly reach
an unintended host. In a world in which, for most
users, simply opening a web page associated with an
unknown site can be sufficient for virus infection, it
is simply unwise, and IMO, not in the best interests
of the Internet, for ICANN to consider relaxing the
current rule. But the reason has nothing to do with
DNS expansion, infrastructure, or any other narrowly
technical reason.
Just as we try to learn and extrapolate from our
experience with ASCII domain name labels to IDNs, we
should also take advantage of our experience with IDNs
to inform our decisions about possible changes to
rules about ASCII labels. When the example
of the "paypal" domain (with Cyrillic "a"s) was widely
publicized, one of the primary reactions in the user
and observer communities was outrage that the various
actors in the domain name environment (and the
certificate-issuing environment) had permitted a
registration whose obvious purpose was to make it easy
for users to make a potentially nasty and
identity-compromising mistake. I don't believe we
need that lesson again about single-character SLDs.
regards,
john
At the end of the day what we have here is a very bad
recommendation, unsupported by the technical
community, advanced to an inattentive GNSO Council,
ratified by that Council with less than a scant amount
of discussion, and a recommendation that was motivated
by nothing other than blatant "ICANN-insider" greed.
This was a recommendation pushed through the process
exclusively by vested interests that had little
concern for issues such as homographic spoofing,
identifier integrity or DNS stability -- they just
wanted to their domains regardless of what the
technical community or any other community had to say
about the matter.
Frankly, the Chair of the Reserved Names Working Group
should have been chastised for allowing a subgroup to
be populated exclusively by members of a single
constituency.
A bad process, a bad recommendation -- just another
typical day in the GNSO.
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|