[registrars] My comments - Verisign batch pool issue

[Donny Simonton]

Paul,
Excellent.  I couldn't have said it better myself!

Donny

> -----Original Message-----
> From: owner-registrars at gnso.icann.org [mailto:owner-
> registrars at gnso.icann.org] On Behalf Of Paul Stahura
> Sent: Tuesday, October 12, 2004 10:08 PM
> To: 'Bhavin Turakhia'; 'Registrars Constituency'
> Cc: rlewis at verisign.com; 'Bolanos, PJ'
> Subject: RE: [registrars] My comments - Verisign batch pool issue
> 
> 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 at gnso.icann.org
> [mailto:owner-registrars at gnso.icann.org] On Behalf Of Bhavin Turakhia
> Sent: Sunday, October 10, 2004 3:59 PM
> To: 'Registrars Constituency'
> Cc: rlewis at verisign.com; '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
> --------------------------------------