ICANN/DNSO
DNSO Mailling lists archives

[ga]


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

Re: [ga] WLS


Why wasn't it published in one of the many papers produced by VeriSign
and SnapNames and otherwise broadcast to the masses?

In particular, why wasn't that fact plainly stated in the most recent
51 page marketing spin and misinformation pollution published by
SnapNames for the ICANN Board? There wasn't any mention of it and
that's particularly curious in light of all the justification noise
proffered by SnapNames on that very subject.

Mentioning it on the phone and devoting two sentences to it here,
seems quite disingenuous in face of all of the other communication
activities and publications by VeriSign and SnapNames.

Furthermore, I'm not sure if VeriSign could accord the same privilege
to all of SnapNames' current competitors given the differing business
models. That is, however, in my opinion, inadequate justification to
accord SnapNames any special consideration.  They should be treated
the same as every other competitor in the current market.  The
sideways threat of lawsuits for tortuous interference is nothing more
than just another barrage of misinformation pollution without
substance.



Saturday, June 22, 2002, 1:28:45 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
GC> William, 

GC> In one of the Transfer TF WLS calls I invited other businesses who might
GC> experience contractual issues as a result of WLS implementation to contact
GC> VGRS and said that we would consider accomodation there if it was possible.
GC> I have not heard from anyone.

GC> Chuck

GC> -----Original Message-----
GC> From: William X Walsh [mailto:william@wxsoft.info]
GC> Sent: Saturday, June 22, 2002 9:21 AM
GC> To: Mason Cole
GC> Cc: 'John Berryhill'; ga@dnso.org
GC> Subject: Re: [ga] WLS


GC> Friday, June 21, 2002, 5:05:49 PM, Mason Cole wrote:

>>>> In terms of strategy with the legal mumbo-jumbo, though, it will work 
>>>> as well on the board as did IOD's same tactics.  Whoever wrote the 
>>>> stuff about how SnapNames is required to bring along its 
>>>> pre-registered customers, or else they will sue ICANN, should look 
>>>> over how well that played in Marina Del Rey the last time that tune 
>>>> was heard. . . .  In fact, those snapbacks can remain post-WLS 
>>>> snapbacks and not be breached at all.

>> A clarification:  Please note that SnapBack customers will not be brought
>> along, as is mentioned here.  Under VeriSign's proposal, names for which
>> there exist SnapBacks will not be allowed into the WLS system.  All must
>> compete over those names as they do today.  Thus is "grandfathering" an
>> unfortunate misnomer.  And, as you mention, SnapBacks remain SnapBacks
>> post-WLS.  What would constitute tortious interference would be to allow
GC> WLS
>> orders on those names for which there are currently paid-up contracts
>> (SnapBack orders) on specific names.

GC> But of course, the same courtesy is not to be extended to the
GC> customers of other registrars operating such services.

GC> Thus giving Snapnames an advantage even now.

GC> I see Snapnames has the same principles of Verisign in dealing with
GC> the public.

GC> Snapnames can't compete with registrars offering snapnames-like
GC> services, so they seek to make them irrelevant by getting an exclusive
GC> contract from the registry and circumvent the competition altogether.

GC> Your company's tactics disgusted me when they were first launched, and
GC> throwing your lot in with Verisign has only lowered my opinion even
GC> further.




----
Don Brown - Dallas, Texas USA     Internet Concepts, Inc.
donbrown_l@inetconcepts.net         http://www.inetconcepts.net
PGP Key ID: 04C99A55              (972) 788-2364  Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
----

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


  • Follow-Ups:
  • References:

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