ICANN/DNSO
DNSO Mailling lists archives

[nc-transfer]


<<< Chronological Index >>>    <<< Thread Index >>>

[nc-transfer] FW: [ga] WLS: Dotster posts the definitive arguments against it, and more

  • To: "Transfer TF (E-mail)" <nc-transfer@dnso.org>
  • Subject: [nc-transfer] FW: [ga] WLS: Dotster posts the definitive arguments against it, and more
  • From: "Cade,Marilyn S - LGA" <mcade@att.com>
  • Date: Wed, 10 Jul 2002 23:47:24 -0400
  • Sender: owner-nc-transfer@dnso.org
  • Thread-Index: AcIoiDMC9Ftinq+rQ2q30KKILp+ylQABUw4w
  • Thread-Topic: [ga] WLS: Dotster posts the definitive arguments against it, and more


Posted by chair. Marilyn
-----Original Message-----
From: George Kirikos [mailto:gkirikos@yahoo.com]
Sent: Wednesday, July 10, 2002 10:56 PM
To: ga@dnso.org
Subject: [ga] WLS: Dotster posts the definitive arguments against it,
and more


Hello,

Tonight, Dotster (owner of NameWinner) posted what I consider to be the
best document to date summarizing the arguments against WLS. It can be
seen here:

http://www.dnso.org/clubpublic/nc-transfer/Arc00/msg00341.html

It should be considered mandatory reading by anyone on the Names
Council and on the ICANN Board, when considering the WLS proposal. I
agree with and support the Dotster position 100%.

In order to stay under my 5 posts/day limit, I'd like to also mention
that when Louis Touton directed the WLS debate to the Task Force, it
was to see whether at a first glance there would be any major negative
effects from it. If there were negative effects, the full consensus
process should be invoked, and WLS should not be fast-tracked. See:

http://www.icann.org/minutes/report-vgrs-wls-17apr02.htm

"If, however, there are specific reasons to conclude that the
legitimate interests of others are likely to be harmed, then ICANN's
existing obligation to seek consensus whenever possible before acting
suggests that it should invoke the formal consensus development
mechanisms that currently exist prior to any decision by the ICANN
Board."

Notice in particular the words "ICANN's existing obligations to seek
consensus". However, in the post by Jeffrey Neuman of of Neustar at:

http://www.dnso.org/clubpublic/ga/Arc10/msg02786.html

he writes "I do not believe that it can be said that there is a
consensus to prevent its introduction." Of course, Mr. Neuman has
things completely backwards -- the consensus must be FOR the
introduction of WLS, to pass the acceptance. He should know better.

I find it interesting that Neustar is now involved in the debate. Given
that Verisign and SnapNames are pretty silent on the lists right now
(perhaps licking their wounds, or not wanting to provide free
"discovery" in the event of lawsuits), maybe they can point me and Task
Force members to some examples where monopolistic paid waiting lists
are in operation, where the consumers are charged even if they don't
ultimately receive the product/service? 

I can get on a waiting list for many products for free. Or, for Toronto
Maple Leafs season tickets, one can place a refundable security deposit
only. Or for an apartment, a landlord might ask for a refundable
security deposit. But, none of these are like WLS, where one might get
charged for no service (if a name is renewed), and the price of the
security deposit is several hundred percent higher than the cost of the
service itself.

Since Neustar runs various telephone number allocations, perhaps they
can provide examples of where there is a "WLS-like" scheme to reserve
vanity telephone numbers that are being recycled? Surely proponents of
WLS can provide some examples where a WLS-like scheme was a solution to
a real problem in resource allocations.

Sincerely,

George Kirikos
http://www.kirikos.com/


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>