Not really feasible. If sex.com were being dropped, everyone and their
brother would be submitting a request for it every 5 min 1 sec. As a
result, it would never be re-registered, and there would be constant load
on the registry. True, not as much as now for the brief periods, but it
would be on-going indefinitely (it would be very easy for resellers to
create an automated script that would try to grab it every 5 minutes for
instance).
Mark.
On Thu, 30 Aug 2001, Chuck Hatcher wrote:
> Earlier I suggested a solution which would remove all incentive for
> hammering the registry. Drop any name, at any time of the day or night, but
> wait until it has been 5 minutes (or some other appropriate delay) since
> anyone has tried to register it. Everyone would have an equal chance, and
> those who try too often would never be rewarded.
>
>
> ----- Original Message -----
> From: "Loren Stocker" <[EMAIL PROTECTED]>
> To: "Robert L Mathews" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, August 30, 2001 3:54 PM
> Subject: Re: [No Registry Agents Available...]
>
>
> > Hi Robert,
> >
> > Not a stupid idea at all. I've suggested this myself, only I don't think
> you
> > need to wait more than 15 minutes unless you drop them all at once like
> they
> > may have today (24 hours might be necessary after this mess!).
> >
> > The fact is that the great domains are snapped up within miliseconds --
> the
> > leftovers could then be released for general consumption.
> >
> > The other issue is dropping as many as they did all at once. Verisign is
> > ASKING for it.
> >
> > Best, Loren
> >
> >
> > Robert L Mathews <[EMAIL PROTECTED]> wrote:
> > I note that Verisign's new system to prevent hammering of the registry
> > during drops wasn't working around 2:15 EDT:
> >
> > No Registry Agents to service domain: [rfertefdfs.com]
> >
> > Although I can't tell who has all the connections, this makes me even
> > more suspicious of domain back-ordering services that open many
> > connections. Obviously some registrars are doing automated batch
> > processing in the overflow pool (which is supposedly not allowed), and
> > some OpenSRS resellers are hammering OpenSRS (since the guaranteed
> > OpenSRS pool is full).
> >
> > Can I ask what OpenSRS is doing to solve the latter problem of OpenSRS
> > resellers using too many connections? If resellers do more than a certain
> > number of lookups in a given time period, are subsequent lookups
> > restricted to the registry automated batch pool for a while? (They should
> > be.)
> >
> > BTW, here's my (probably stupid) idea to solve the registry problem: for
> > the first 24 hours after a name is released, it should only be able to be
> > registered through the automated pool, and not the guaranteed or overflow
> > pools. Then the feeding frenzy would occur only in the automated pool.
> > The next day, the domains could be registered through any pool. In this
> > scenario, registrars would allow speculators to set a flag saying they
> > want to try the automated pool, and speculators could have at it... while
> > the rest of us would have normal connections.
> >
> > Even better would be some sort of first-come, first-served back ordering
> > system, implemented by the registry, as someone else described. Not
> > likely in the near future, I guess.
> >
> > --
> > Robert L Mathews, Tiger Technologies
> >
> >
>
>
