CH> Sounds more fair to me than what we have now, and the load on the registry
CH> would be many orders of magnitude less. The number of times a desirable,
CH> soon-to-drop, domain name is currently queried per second must be in the
CH> thousands. This because there is monetary incentive to be there at exactly
CH> the right millisecond (and no penalty for being there at the wrong
CH> millisecond).
you could be right, but perhaps not. We need some real numbers to
figure it out. But I'll make up some fake ones for the sake of
argument. Let's say there were 1000 desirable names and 1000 people
out there in the world that wanted them and knew about the 5 minute
trick. These 1000 people do not tell each other what they are doing.
So now you have 1 million queries every 5 minutes to hold these names
hostage for x amount of days. It might get ugly. This is all
hypothetical of course.
CH> If you don't like my idea, propose a creative alternative. I'm open to
CH> suggestions.
Here are 2 ideas which I believe would take a big load off of the
registry and result in a better system for all:
1) Currently when a registrar does a "status" command on a name, all
they get back is "Permission denied" unless they are the registrar for
that name. The status command tells (among other things) The last
update and the expiration date of the name. If the registrar could
get back the expiration date and last update from the status command
for *all* names, they would stop trying to get a name that has an
expiration date in the future. As it is now, when it has been
determined that supercoolname is going to drop today, customers of all
registrars will hammer on that name for the entire drop period because
they don't know if someone else has snaked it at the beginning of the
session. If they knew, they would no longer attempt to get that name.
I believe this would take a big load off the registry.
2) This is not really related to the batch drops, but is a way to take
a big load off the registry: In any given day, there is an average of
50K - 100K changes to the registry. On any given day, large registrars
(such as Tucows) will do *millions* of check requests on behalf of
their customers against the registry. The obvious solution is to have
a local copy of the registry database (or a *sanitized* version that
just includes the information that can be gained via the RRP
protocol), and then listen for changes from the registry. That is: as
soon as the registry makes a change to its database, it pushes that
change out to the registrar. When the registrar is queried by its
customers, it will answer directly from its local store. This would
reduce the load on the registry by an order of magnitude and as a side
bonus, would even make the registrar's job easier because he is
answering the same number of queries, he just doesn't have to go
across the net to the registry to service his customer.
There are other ideas related to fairness of allocation of dropped
names etc, but I think the 2 ideas above (which have already been
communicated to ICANN) would be a great start.
>> Dawning black-hat (or is it grey?): I want supercoolname, so I check
BTW, I meant Donning, not Dawning... I'm a bit tired... was up at the
break of Don this morning ;-)
regards,
-joe
