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