[registrars] [ga] Re: Further Thoughts on Deleted Names, with some SnapNamesstats (fwd)

[Rick H Wesson <wessorh@ar.com>]

all:

An interesting post of the GA list, relivant to our discussion on the RWL
proposal.

-rick
---------- Forwarded message ----------
Date: Sat, 5 Jan 2002 14:29:32 -0800
From: William X Walsh <william@wxsoft.info>
Reply-To: William X Walsh <william@userfriendly.com>
To: ga@dnso.org
Subject: [ga] Re: Further Thoughts on Deleted Names, with some SnapNames stats


Excellent post, George.  I've taken the liberty of forwarding this
post to the General Assembly mailing list of the DNSO where it may
also be of interest.  Anyone keeping tabs can put me down as 100% in
agreement with George's points.

And I STRONGLY encourage resellers interested in helping to prevent
this asinine proposal by Verisign from going forward to join the
DNSO General Assembly mailing list and make your voice heard there as
well.

The list is a bit disfunctional, but as someone else pointed out to me
this last week, the list IS read by the important staff members at
ICANN, and is referenced by several of the constituency mailing lists
when they discussions on issues like this.  So ignore the
disfunctionality and get your points across.

http://www.dnso.org/listsdnso.html for more information.

-wxw




Saturday, Saturday, January 05, 2002, 1:27:19 PM, George Kirikos wrote:

> Hello,

> Excellent posts, Joseph and Harold.

> I'm glad that folks are finally seeing that Verisign has not proven to
> us that there is a technical problem at the current time with the
> operation of the deletion process. Months ago these same technical
> fixes were proposed to reduce the "check" load on Verisign. Since
> they've not been implemented, or even COMMENTED UPON by Verisign my
> conclusion is that there never was a problem in the first place.
> Verisign simply created the myth that there was a problem to further
> their business interests.

> If there truly is a problem, why have they refused to implement the
> simple technical fixes that so many have proposed? Rate-limiting
> connections, pushing out lists of candidate drop names, and returning
> richer error codes (e.g. new expiration date) so folks don't hammer the
> registry to attempt to catch names that were already caught are MUCH
> simpler to implement than the creation of a Waiting List Service, and
> would solve any fictional problem that Verisign thinks it is
> experiencing.

> If the registry source code was Open Source, I bet folks here would be
> able to patch up the code to implement the above in a matter of DAYS,
> literally. All of the above technologies are so simple, yet Verisign
> hasn't even commented on them. I think they have an obligation to
> comment on them, and explain why they refuse to implement them.

> My background is in economics and finance. It is far easier to explain
> Verisign's behaviour in the context of an abusive monopolist seeking to
> crowd out competitors, exert further control over the registry, and
> maximize its own profits. As Occam's Razor tells us, the simplest
> explanation is most likely to be the truth. Forcing everyone to
> subscribe to a "waiting list" using the SnapNames business model is the
> behaviour of a monopolist seeking to earn more money per registration.
> Verisign says that the "SnapNames" business model is a proven and
> accepted one. I beg to differ. There are currently numerous competing
> firms and registrars attempting to register expired domains now, using
> the existing fair and transparent system. Let me name just a few:

> 1) NameWinner (by Dotster) -- they use an auction methodology, and the
> name is only billed if the name is caught. One can register a name for
> as low as $25, HALF the SnapNames fee. Dotster has been catching a
> similar quantity of names as Snap, thus is a big competitor that will
> be shut out should Verisign monopolize dropped names. Dotster uses at
> least 2 registrar connections.

> 2) NicGenie.com (by Parava) -- similar to Dotster above, but with an
> even lower price of $20, which is 60% below SnapNames. While not as
> successful as NameWinner, they still catch some good names, using only
> a single registrar connection.

> 3) eNom "Drop Club" -- using at least 2 registrar connections, they
> rent out fractional usage for a set monthly fee, for unlimited usage.
> So, names can be caught for essentially the $6 wholesale fee. eNOM is a
> serious challenger to SnapNames and NameWinner, catching a high
> quantity of names monthly.

> 4) IARegistry -- not sure of the precise details, but from what I can
> tell it's a drop club similar to eNom, but with a single license.

> 5) AWRegistry -- similar to IARegistry and eNOM from what I can tell,
> although most of the names seem to go to one major client.

> 6) Signature Domains -- uses entire registry for its own portfolio,
> from what I can tell.

> 7) INWW, OnlineNic.com, AddressCreation, AllDomains.com, Eastcom.com,
> PayCenter.com -- all successfully using "drop club" style systems, from
> what I can tell.

> 8) ExpireFish.com (new, don't know too much about them; looks like a
> SnapNames clone).

> SnapNames hasn't been in business even a year, if I'm not mistaken.
> None of their "SnapBacks" has ever expired worthless, as they've not
> gone to maturity. I would not want to be them (or a registrar under the
> Waiting List System) when a registrant is told at the end of the year
> that they paid $49 or $89 or whatever for nothing, as the name got
> renewed. If we want a true "test bed", let us wait until SnapNames has
> been in business for more than a year, to see how they handle to
> customer support issue of thousands of customers seeking out refunds,
> for not having received the name they were going for. That would be a
> learning experience everyone would benefit from, before making such a
> drastic change to a functioning system. By the way, in any "Waiting
> List System", existing SnapBack holders should not be grandfathered or
> given priority -- there should be a landrush period (this goes without
> saying, but some folks have suggested this will sneak through, as few
> people have noticed this situation). I'd also like to see
> Verisign/SnapNames explain how the Waiting List System itself won't be
> hammered, as people try to catch names while holders are switching
> their slots.

> The fact is, we have a healthy and competitive market now, much to the
> dismay of SnapNames and Verisign, who would like to exert control and
> dominance over the system as monopolists, and reduce consumer choice.
> It's the duty of ICANN, and the registrar community to watch over the
> behaviour of Verisign (a monopolist) and SnapNames (a monopolist
> wanna-be). I've used SnapNames on occasion, and have nothing against
> their business model. The only problem with them is that they want to
> become a monopolist themselves, and shut out consumer and registrar
> choice.

> I'd also like to point out the "myth" of SnapNames' success. Given the
> above, it's clear that there are a lot of competitors to SnapNames. The
> majority of registrars are NOT SnapNames partners (when it comes to
> numbers of connections being used to catch drops). Also, if you count
> the number of domains that are actually caught, SnapNames doesn't have
> a majority there either. The above 7 groups (and there are many that
> I'm not aware of) catch quite a few names. The only area where
> SnapNames dominates is in the issuance of self-serving press releases.
> None of the above 7 groups can hold a candle to SnapNames in that
> regard.

> The typical SnapNames "mythology" about deleted names is that their
> clients are pure and noble, and everyone else is an "abusive
> speculator" that must be stopped. SnapNames publishes a list of names
> they've caught, at:

> http://www.snapnames.com/hot100.html

> In case they decide to remove that list, I've saved a copy at:

> http://www.loffs.com/images/hot100.txt

> Let us analyze this list, and see who some of SnapNames's "pure and
> noble" clients are:

> a) UltSearch.com owns 19 of the 100 names (participates on many other
> drop systems too).
> b) BuyDomains.com - 16 of the 100 names (all for sale, too!)
> c) DirectSeek/PTI Networks/Frank and Michelle Schilling -- 6 names
> (participants on other drop systems too).
> d) 5 other names were explicitly for sale in the WHOIS info, or were
> pointed at Afternic, a domain auction site.
> e) Michele Dinoia -- 2 names (a high volume domain registrant via
> AWRegistry, among others)
> f) 7 names seem to raise some trademark issues:
> i) advil.net (and the domain is for sale!)
> ii) xeroxprinters.com
> iii) wall-mart.com (redirecting to Amazon.com for now, using the
> "hotdealsweb-20" affiliate tag)
> iv) NokiaTunes.com
> v) HondaAccord.com
> vi) VolkswagonParts.com -- redirects to an "abortion is murder" site,
> with a picture of a headless fetus (gruesome)
> vii) UnitedAir.com (nice use of Flash in the WHOIS; see the WHOIS at
> www.netsol.com for this one)

> I'm not saying that any of the above are "abusive speculators" (well, I
> think I'm safe on the volkswagonparts.com one!), but I personally would
> like to have SnapNames provde a precise definition of "abusive
> speculator". Does it have to do with a high volume of registrations?
> Does it involve trademark violations? Does it have to do with offering
> the name up immediately for sale? Does it mean using a non-SnapNames
> system (many of SnapNames' biggest customers use alternatives too).
> Personally, I think any registrant is innocent, until proven guilty via
> the UDRP process. But, I want to know Verisign and SnapNames' precise
> definition of abusive registrants, as they routinely trash the clients
> of competing drop systems, and are the ones saying that there is a
> current problem that needs to be "solved". Once we have a clear
> definition, we can see how many of SnapNames' own clients fit that
> profile.

> What makes any registrar think they'll get a share of the above big
> customers should Verisign be given a monopoly is beyond me. Registrars
> would be shooting themselves in the foot, since they no longer have the
> ability to compete in the open process we have now (and many registrars
> are clearly kicking Snapnames' butt in this open competition; no wonder
> SnapNames' would want to no longer compete, as they're worried that
> their model isn't working). Any registrar such as Tucows/Register.com,
> eNom, Dotster, Parava, the Asian registries, itsy-bitsy register, etc.
> should ask themselves "Will the UltSearches and BuyDomains of this
> world be buying from me, if this goes through, or will they seek out
> the lowest cost reseller, with no margin for me?" Will Verisign be
> making all the profit based on its $40 monopolist charge?

> What's in it for registrants, who are the consumers in all this? ICANN
> needs to be watching out for the end user (since many of the registrars
> can't be trusted, when they openly talk about picking a price to
> maximize profits). When there's a monopoly (and Verisign is clearly
> seeking to create a new and highly lucrative one for itself here), it's
> the consumers that suffer most through higher prices and reduced
> choice. Competitors who are fairly competing now will also suffer.

> In conclusion, I think I speak for many who want:

> 1) Clear and proven definitions of what constitutes "abusive
> behaviour".
> Prove to me and others that this is not an invention of the monopolist
> registry operator Verisign, seeking to maximize profits through a
> self-serving "fix" of its own choosing.

> 2) Clear explanations as to why the numerous simple and inexpensive
> technical solutions that have been proposed to reduce registry load
> have not been implemented.

> 3) Explanations why we need a "test bed" at all, one that will be
> highly profitable to Verisign and SnapNames alone, at the expense of
> both consumers and competing registrars, given that the current system
> seems to be working just fine (competitive business models offered; no
> major complaints from any consumers seen on ICANN message boards,
> except complaining about Verisign not releasing all on-hold names as
> they're required to do).

> 4) The "discussion period" of 3 weeks for such a period should be
> extended to at least 6 to 9 months, to give the opportunity for
> registrars to get input from their clients, for ICANN to get input from
> registrars and registrants, and for Verisign to have time to implement
> the technical fixes that they've refused to do. Verisign's refusal to
> implement fixes such as "rate-limiting" technology and extended
> response codes (and others already proposed by numerous other parties)
> can only be explained by a desire to perpetuate the mythology of having
> "unsolvable problems", so they can try to push through a cash grab ($60
> million/yr by their estimates) and assert dominance over registrars and
> registrants alike. Pushing through a major change as a "done deal" is
> not the behaviour a monopolist should be allowed to get away with.

> Sincerely,

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

> P.S. Feel free to forward this email to any other appropriate
> discussion forums.





> --- Joseph McDonald <joe@vpop.net> wrote:
>>
>> >>Okay, well, how should they solve it, then? If you have an idea,
>> I'd love
>> >>to hear it (and I'm not being sarcastic). I honestly don't think
>> it's
>> >>solvable -- there is a virtually infinite demand for some names,
>> and the
>> >>registry/registrars/resellers can't supply virtually infinite
>> connection
>> >>resources.
>>
>> HW> Simple. Every registrar has access to the batch-pool.  The
>> registry
>> HW> complains of tens of millions of worthless "checks" during drop
>> times.  An
>> HW> additional response code signifying a name has been registered IN
>> THE LAST
>> HW> 24 HOURS would stop the registrars from continuing to pursue that
>> name.
>>
>> YES!  I believe Tucows proposed a very similar idea to Verisign:
>> Right now, if you do a "check" command on a domain, and you are not
>> the registrar for that domain, you receive an error message,
>> otherwise
>> you get the expiration date.  The proposal was to have the check
>> command return the expiration date regardless of who was the
>> registrar.  This would eliminate *huge* number of check/add commands
>> and
>> largely solve the problem, just as your IN_THE_LAST_24_HOURS flag
>> would.  Either one is fine by me.
>>
>> There was another proposal which would also take a huge load off of
>> the registry: The top registrars do millions of check commands
>> against
>> the registry on a daily basis to support normal operations. On
>> average
>> there are less than 50K adds and 50K drops performed at the registry
>> each day. Let's say the top 4 registrars each do 2.5 million checks a
>> day (my guess is that this is a conservative number) for a total of
>> 10
>> million checks a day. The idea is that the registry can push those
>> 100K changes out to the registrars, thus saving 9.6 *million*
>> transactions a day, which is more than 100 per second, and when you
>> figure in the peaks, you may be talking 200 per second during busy
>> times.
>>
>> I also think that the registry should publish a list of names to be
>> dropped and when they will be dropped to all the registrars.  This
>> would eliminate check/add commands on names that people think are
>> going to drop, but really aren't going to drop.
>>
>> Implementing those 3 proposals (the first one could probably be
>> implemented in an hour) would probably bring the load on the registry
>> down to record lows.
>>
>> regards,
>> -joe
>>

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