RE: [registrars] My comments - Verisign batch pool issue

[Paul Stahura <stahura@xxxxxxxx>]

Bhavin,

I would also "suggest you to look around".  The phantom registrars ("creds")
issue is not resolved.
If Verisign put through all the pending creds today, there would be an
immediate flood of new cred applications at ICANN tomorrow.  
Even if the top 5 registrars signed up for the NSI/Tucows
action-before-deletion model, there would still be an increase in the
phantom registrars because the total per-registrar ICANN fees are much less
than even a reduced total market size.  

Plus, what if ICANN (or some court) decides that what NSI and Tucows are
doing/contemplating is against the rules?  Even if it isn't, what happens to
the names from those registrars who choose not to implement a similar
service? What about names that are below the minimum bid amounts set by NSI
and Tucows?  Answer: names will still drop.  And again, it costs nothing to
pound the registry.

Neither of your proposed solutions fixes the problem, unless 1) most big
registrars opt-in for the NSI/Tucows auction-before-deletion method and 2)we
get ICANN, and 3) registrants, and 4) probably Verisign, and lets throw in
5) pool.com and 6) snapnames, to agree to that. I doubt that even two of
those will agree and for damn sure not anytime soon.   But if it did happen,
then yes, it would reduce the value of a cred to zero.

Therefore, until we figure THAT out, names will still drop and there will
continue to be economic pressure to get accredited in order to gain more
access to the batch pool.

Also you say:
"Verisign can clearly reduce the number of connections from 10 to 5 or even
1 and reduce their load by 1/40th of the original load."

This is NOT True, because if Verisign did that the phantom registrars would
1) Shove more commands per second down the smaller number of connections,
therefore the load would not be reduced, or
2) Get more creds from ICANN to grab more connections (no matter how few you
get) so again the load would not be reduced.

As long as pounding is free, all the registry resources allocated for the
batch pool will be used up, even if those resources are small or not worth
much (due to shrinking market size), because zero cost is infinitely less
than even a small benefit.

Before you know it, we'll be down to one connection each, and the volume
registrars will have to incorporate more fake subsidiary companies just to
get more registrar applications in to ICANN just to keep doing their
"normal" business in the batch pool.  And when that happens, the cred
situation can really cascade.


The fake creds do not help competition, they do not help consumers, they do
not help our industry, they cause inefficiencies and they shrink the
registry capacity for everyone ("real" and "fake" creds alike) on a per-cred
basis.

As for the ICANN budget, face it: 

#1 the ICANN budget is not going to be "compromised" anyway.  Have you read
our contracts? ICANN has the ability to extract their current budget amount
from us pretty much no matter how we slice and dice it.  But at least
without a bunch of fake creds out there, ICANN will be a more efficient
ICANN because ICANN's costs will be less, because they won't need to police
all these registrars with all the names distributed, almost randomly, across
all of them, and because the won't have to spend a bunch of resources
accrediting folks.

#2 Surprise: the ICANN budget is a "ratio" model.  There are two registrar
funding buckets: one which is equal on a per-registrar basis and the other
which is based on a ratio, which is X times the number of transactions. 

This is exactly the same as the proposed registry model.  There would be two
registry pools: one in which access is equal on a per-registrar basis and
the other in which access is X times the number of transactions.

By the way, that is exactly how the framers of the US Constitution set up
the US government. There are two houses: one in which the votes are equal on
a per-state basis, and the other in which the votes are X times the
population. 

What can be fairer than bringing the registry model in line with these other
two models?









-----Original Message-----
From: owner-registrars@xxxxxxxxxxxxxx
[mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Bhavin Turakhia
Sent: Sunday, October 10, 2004 3:59 PM
To: 'Registrars Constituency'
Cc: rlewis@xxxxxxxxxxxx; 'Bolanos, PJ'
Subject: [registrars] My comments - Verisign batch pool issue


Hi all,

Was out for 2 weeks and therefore unable to comment. Here is my brief
statements

* the real problem is not verisign getting pounded. I don't think that ever
was the issue. The number of connections were reduced from 40 per registrar
to 10 per registrar in the last 8 months. There is statistical data from
reliable that shows that there were more commands being sent to the batch
pool in Jan 2004 than there are as of today. Verisign can clearly reduce the
number of connections from 10 to 5 or even 1 and reduce their load by 1/40th
of the orignal load. The orignal system supported 100+ registrars at 40
connections. At 1 connection per registrar they should be able to support
4000 (I don't think we will reach that number ever considering the new
NSI/TUCOWS model as such discourages any phantom creds now)

* the real problem is phantom creds - ie registrars who accredited simply
for batch pool access. The two solutions proposed by verisign to a certain
extent take care of that issue, but the solutions are not effective

* Solution 1 will render ICANN ending up with less than 50% of the 3.8
million they orignally anticipated collecting. This means in some indirect
way we shall bear the brunt of that, or ICANN shall

* Solution 1 also gives more chances to larger registrars, thus being
unequal

* Solution 2 to my mind as everyone points out can actually be worse - since
it will bring about a status quo amongst the larger players to such an
extent that noone except verisign will make the money


* I do not think either of the solutions should be implemented. Infact here
are the ONLY solutions that make sense -


=====================
MY PROPOSED SOLUTIONS
=====================

Solution 1: DO NOTHING
----------------------

* This is the simplest solution and it works. The market has considerably
changed since this debate came up.

* Firstly most registrars may shortly not allow names to expire judging NSI
and TUCOWS' latest move. Infact I am quite certain of this eventuality - for
various reasons which I will separately discuss. This has already prevented
addtl phantom applications from applying. I will send out some hard data on
this shortly

* Secondly for the ones that already exist the number of names will reduce
considerably

* Thirdly for the ones that exist - verisign can simply reduce the number of
connects to 5 or even 1 and have enuf bandwidth within their existing
infrastructure to not impact them


Solution 2: IMPLEMENT THEIR FIRST SOLUTION WITH SLIGHT MODIFICATIONS
--------------------------------------------------------------------

* If solution 1 is implemented it needs to be fair and at the same time not
jeopardize the ICANN budget. This maybe done as follows

* create a separate pool where ONLY expired domain names maybe registered,
so that both larger or smaller registrars get the same ratio of connect to
this pool

* modify the icann budget such that access to this pool does not fall in the
forgiveness criteria

* some of you may say that this model will not prevent the phantom creds
issue - but I would suggest you to look around. That issue is already
resolved.



ONCE AGAIN ...... It is important to put up an official position on this
one. I wonder (and I am new here ;) ) .... If we should  ballot this. If yes
then I can draft a ballot and send it out, after which we could share the
official results with the concerned parties




Best Regards
Bhavin Turakhia
Founder, CEO and Chairman
DirectI
--------------------------------------
http://www.directi.com
Direct Line: +91 (22) 5679 7600
Direct Fax: +91 (22) 5679 7510
Board Line (USA): +1 (415) 240 4172
Board Line (India): +91 (22) 5679 7500
--------------------------------------