<<<
Chronological Index
>>> <<<
Thread Index
>>>
[wildcard-comments] Should we allow Verisign to profit from non-performance?
- To: <wildcard-comments@xxxxxxxxx>
- Subject: [wildcard-comments] Should we allow Verisign to profit from non-performance?
- From: "J. Vogel" <jvogel@xxxxxxxxxxx>
- Date: Tue, 21 Oct 2003 17:08:56 -0500
- Sender: owner-wildcard-comments@xxxxxxxxx
As a registry operator, operating under contract with ICANN, Verisign's
role is to administer the registry or the database containing all valid
registrations of .com and .net names. Their job, simply put, is to
ensure that a name that is appropriately registered is maintained in the
database. WLS and SiteFinder both are designed in such a way that
Verisign will maximize their cash intake precisely by not doing their
job, or at least by not doing it as well as they could. Here's how....
With WLS, Verisign's proposal is to limit subscriptions on any
particular domain name to the first purchaser, or one subscription per
name at a time. Once that subscription is sold, it must either expire or
be used before another one may be sold on that name. Such limiting means
that Verisign must sell subscriptions on as many different names as
possible to enjoy maximum revenue. Another limiting factor is that many
names are currently under multi-year registration, and will not expire
within the one year lifetime of a WLS subscription, making those names
extremely unattractive targets of WLS subscriptions. One of the ways
they propose counter that limitation is to promote the WLS as a benefit
to consumers by describing it as a sort of insurance policy in the event
of inadvertent removal of their domain name from the registry. This
"insurance" would also be of purported benefit in cases where
registrants neglected to renew their domain names for some reason.
Since it is much cheaper for the registrant to renew than to buy the
"insurance", it will be hard to sell subscriptions on that basis. (It
would make more sense to take the money required for the WLS
subscription and apply it to renewals). If, however, Verisign could
"accidentally" drop the name from the registry and thus "use up" the
current subscription on it, they would be able to then immediately sell
another subscription on the name - AND - they would also demonstrate the
"value" of having such a subscription to existing domain owners - on all
names, not just those that will expire within the next year.
The more Verisign can get away with not maintaining valid names in the
registry as their contract stipulates, or more subtly, the more they can
promote the fear in consumers that the registry may not do their job
correctly, the more money they can make. Since Verisign would obviously
get in trouble with consumers and/or ICANN if they accidentally dropped
too many names, doing so would not be in their best interest, but if
they can get away with dropping an "acceptable" number of names, they
will benefit from being able to sell new subscriptions on those names
(increase the churn rate), and also from validating their sales pitch
for the service on all names they haven't dropped. The goal will be to
find that "magic level" of incompetence which will maximize their
profits.
Because of the relatively high profit potential to the registry on WLS
subscriptions as opposed to normal registrations, a seemingly small
percentage of decline in performance under the ICANN contract could
yield the registry operator a significant boost in income levels, making
it highly tempting for those making the decisions at Verisign to
actively pursue controlled non-performance.
The scenario for SiteFinder is very similar. Since Verisign will only be
able to monetize traffic on names that are not in the registry database
or (as the service was originally implemented) that do not have valid
name servers in the database, SiteFinder will make Verisign more money
by having fewer names actually registered. Since pay-per-click rates on
advertising are relatively low, Verisign itself would probably benefit
more from the actual registration of a name than from miscellaneous
traffic on that name if it were unregistered. If a way were found to
raise the profitability on the traffic to those names (or some of them)
beyond what they make for selling the registration of that name, this
conflict would then become more pronounced.
Verisign could have their cake and eat it too though. Any name which is
registered and drawing significant traffic would make Verisign more
money in a 24 hour period if they could capture that traffic, and all
that would be required would be to inadvertently lose the name servers
for a that name for a while. They still get paid for the registration,
but they also get paid for not getting it in or maintaining it in the
database promptly or correctly. Or.. in the case of a name which has
been put on Registrar-Hold for any reason, if and when that
Registrar-Hold is removed, Verisign will benefit more the longer they
can delay the actual re-activation of the name. This will be especially
true for names which already draw high traffic levels. SiteFinder is a
bad idea for a lot of reasons, but this is an example of why it is bad
because its goal is to make Verisign money.
These are just a few methods, and I am sure there are several ways I
haven't thought of whereby the more poorly Verisign performs under their
ICANN contract, the more they will make, and again, the goal for them
will be to find that level of sub-optimum performance which will
maximize profitability while still performing at "acceptable" levels.
This is an inherent problem with any system where one must weigh cost
against the benefit of perfecting performance, but as you increase the
value of non-performance, the scales will tip more in that direction.
For an organization such as ICANN, who have stated that part of their
mission is to maximize the performance of the DNS system, does it make
any sense at all to employ contractors who are proposing ways in which
they can get paid more by offering less than perfect performance?
John Vogel
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|