ICANN/GNSO GNSO Email List Archives

[registrars]


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

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

  • To: "'Paul Stahura'" <stahura@xxxxxxxx>, "'Registrars Constituency'" <registrars@xxxxxxxx>
  • Subject: RE: [registrars] My comments - Verisign batch pool issue
  • From: "Bhavin Turakhia" <bhavin.t@xxxxxxxxxxxxxx>
  • Date: Wed, 13 Oct 2004 14:51:44 +0530
  • Cc: <rlewis@xxxxxxxxxxxx>, "'Bolanos, PJ'" <pj@xxxxxx>
  • In-reply-to: <DA6F8AFB015C544AB4385B5DEBDE1FBB0C24D6@YEW>
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • Thread-index: AcSw0d1Cv527C0BwQJGn3ew2SbKnOQAMzucw


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

Agreed .... I am with you on this ..... The problem is not solved as of
today

> 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 

My proposed solutions do not fix the creds problem in certain probablisitic
cases. I agree. Infact my proposed solutions were half and incomplete. I did
not intend to propsoe them as full fledged solutions.

> 1) Shove more commands per second down the smaller number of 
> connections, therefore the load would not be reduced, or

b/w could be clogged also.

However what I said there is immaterial - since jordyn pointed out something
I overlooked - which is there is genuine usage of the batch pool whch would
be required, so unless verisign gives us 3 pools my solution has an issue
there too

- Bhavin




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