RE: [registrars] Verisign batch pool advisory

[Paul Stahura <stahura@xxxxxxxx>]

Donny,
I wish it were so... that it solved even one part of the problem or that it
depended on the number of names.
Those 100 domains are spaced out in time over the drop period (either
ordered or unordered lists).  You would for sure pound full-bore with all 5
company A registrars during the time (lets say 3 second period) when you
thought any one of the 100 was about to drop (if list is ordered as it is
today), and it is in your interest to pound during the in-between time for
the upcoming one since there is no cost.
If all 100 names happened to drop in the first five minutes, which probably
would not happen statistically, then you are correct, you'd pound
continuously for 5 minutes from all 5 registrars one name at a time then
stop.
But as I said in my previous post, even if that were the case you wouldn't
need the modified check command to tell when to stop pounding, you could do
a one normal check commands on say each of the next 20 names after the 100th
name in your list and if any one of them came back as available you'd know
to stop pounding.
If just one of the 100 were to occur toward the end of the drop (very
likely), it would be in your interest (due to zero cost) to pound full-bore
for that one name with all 5 registrars continuously throughout the drop
period.
Even if you were going after just one name, you could do normal check
commands on the following 20 or so and know when to stop pounding, so the
modified check is unnecessary in an ordered list.  In an unordered list it
would help slightly in the "going after one name case" but I don't think
that happens too often if at all, and if it did, I doubt that guy is
pounding with more than one registrar.
Paul

-----Original Message-----
From: Donny Simonton [mailto:donny@xxxxxxxxxxxxxxx] 
Sent: Wednesday, October 06, 2004 3:23 PM
To: 'Paul Stahura'; 'Jay Westerdal'; registrars@xxxxxxxxxxxxxx
Subject: RE: [registrars] Verisign batch pool advisory

Paul,
Actually, when you think about it, it all depends on how many domains that
registrar is attempting to register.  Let's say company A has 5 registrars,
and they have 100 domains they are going after, they could possibly be done
for the day in 5 minutes with a modified check command.  So they wouldn't
pound the registry after those 5 minutes because they don't have any more
domains to register anymore.

Now if company B is going after 5,000 domains with there 5 registrars, they
may be registering domains throughout the entire drop.

I like the idea of the modified check command, but it doesn't solve the
overall problem it just solves other problems.

Donny

> -----Original Message-----
> From: owner-registrars@xxxxxxxxxxxxxx [mailto:owner-
> registrars@xxxxxxxxxxxxxx] On Behalf Of Paul Stahura
> Sent: Wednesday, October 06, 2004 5:03 PM
> To: 'Jay Westerdal'; registrars@xxxxxxxxxxxxxx
> Subject: RE: [registrars] Verisign batch pool advisory
> 
> David and Jay,
> 
> Not true.  It would halt their pounding for that name, but they would
> still
> pound full-bore for another name because it is free.
> 
> The modified check command does not solve the problem because
> you can already tell very quickly whether a name is newly registered
> because
> a name just after that name becomes available (if name2.com is available
> then the name just before it, name1.com, was recently registered so stop
> pounding for name1.com and move on to name11.com if that is one you want).
> And even if you did know instantly (by using the modified check command
> you
> suggest) that a name was newly registered, you would just move on to the
> next name (or another name if the list is unordered) more quickly.  You
> are
> full-pounding all the time regardless, just not for the newly registered
> name, but for other names that have yet to become available.
> 
> I agree with Jordyn it's a "tragedy of the commons problem" and the ratio
> model is the best solution.
> 
> Paul
> 
> -----Original Message-----
> From: owner-registrars@xxxxxxxxxxxxxx
> [mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Jay Westerdal
> Sent: Wednesday, October 06, 2004 3:02 PM
> To: registrars@xxxxxxxxxxxxxx
> Subject: RE: [registrars] Verisign batch pool advisory
> 
> Agreed, if a modified check command was made, registrars could determine
> when the domain was registered and it would halt their pounding when they
> knew the domain was already aquired. 3/4 of all pounding is because of
> a lack of information about dates.
> 
> In a related issue PIR is purposing taking away dates in the info command.
> Thus producing less available information to registrars and thus will
> cause
> themselves more pounding on their registry.
> 
> -----Original Message-----
> From: owner-registrars@xxxxxxxxxxxxxx
> [mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of dwascheriar
> Sent: Wednesday, October 06, 2004 2:34 PM
> To: Paul Goldstone; Paul Stahura
> Cc: 'Registrars Constituency'; David Wascher
> Subject: RE: [registrars] Verisign batch pool advisory
> 
> Paul,
> The top 10% of the names being checked are the ones that causes Verisign's
> infrastructure to start causing them problems. The single domain in that
> 10%
> is exactly the point and business models for the new accreditation. These
> are all 3.5 year conversations and conference calls we had that would take
> care of the top 10% of the drop names. All in all, we came up with some
> very
> good ways to "Fix" this part of the problem while still allowing anyone
> with
> a drop business model to operate.
> 
> In MDR Verisign held a question and answer session which a modified check
> command would tell us if the domain was newly registered. If this little
> piece was implemented then approx the first 7 min of the drop would be hit
> the hardest and then drastically drop off reducing the load. Instead we
> continue to have less connections so to compensate new accreditations are
> being sought after.
> 
> 
> David Wascher
> IAregistry.com
> > -----Original Message-----
> > From: owner-registrars@xxxxxxxxxxxxxx
> > [mailto:owner-registrars@xxxxxxxxxxxxxx]On Behalf Of Paul Goldstone
> > Sent: Wednesday, October 06, 2004 4:13 PM
> > To: Paul Stahura
> > Cc: 'Registrars Constituency'
> > Subject: RE: [registrars] Verisign batch pool advisory
> >
> >
> > That's going on the assumption that every new registrar is going for
> > the same dropped name as existing registrars and not creating any new
> > registrations either.
> >
> > Anyway, I just feel that this is not our issue to resolve or pay for.
> >
> > Regards,
> > ~Paul
> >
> > At 12:50 PM 10/6/2004 -0700, Paul Stahura wrote:
> > >Its nearly the same problem, but in this case, instead of the costs (to
> > >pound with say another 100 or whatever connections they give a
> registrar)
> > >being "very close to absolutely nothing" the costs would still
> > be very low.
> > >The only costs would be the ICANN accreditation fees and an
> incorporation
> > >fee, which are relatively low, plus these costs GO DOWN with the
> > increasing
> > >number of registrars due to ICANN's budget structure.  Note those
> "paying
> > >registrars" you speak of who are buying more access are not
> > paying VeriSign
> > >for it. With status-quo, the math works out to a capacity size
> > at over 4,000
> > >registrars (400,000 connections all pounding full-bore) at
> > stead-state.  And
> > >again, we (all the pounding registrars) would not register even one
> more
> > >name than we did with the system that did not have that huge capacity
> > >investment.
> > >
> > >
> > >-----Original Message-----
> > >From: Paul Goldstone [mailto:paulg@xxxxxxxxxxxx]
> > >Sent: Wednesday, October 06, 2004 12:20 PM
> > >To: Paul Stahura
> > >Cc: Tim Ruiz; 'Bhavin Turakhia'; 'Registrars Constituency'
> > >Subject: RE: [registrars] Verisign batch pool advisory
> > >
> > >Paul,
> > >
> > >That's a fair point but you can't pound the batch pool any more than
> > >the connections you're given.  So, if registrars would use the max,
> > >whatever that max is (10, 20, 100 connections), why don't Verisign
> > >simply keep the original number of connections and yes, increase their
> > >capabilities as they get more paying registrars on board?  ie. why is
> > >this even a discussion?  Will we be discussing whois usage next?
> > >
> > >Regards,
> > >~Paul
> > >
> > >At 11:18 AM 10/6/2004 -0700, Paul Stahura wrote:
> > >>Paul
> > >>
> > >>Even if VeriSign spent nearly an infinite amount of money on
> > this problem
> > >>(to "expand their capabilities"), and if we kept the status quo, then,
> > >>because it costs very close to absolutely nothing to pound the
> > crap out of
> > >>the registry, all registrars would increase their registry
> > pounding rates
> > >to
> > >>the level that would immediately use up absolutely all the vast
> > >capabilities
> > >>that the nearly infinite amount of money purchased.   While at the
> same
> > >>time, we would not register even one more name than we did with
> > the system
> > >>that did not have the vast capabilities.
> > >>
> > >>Best,
> > >>Paul
> > >>
> > >>-----Original Message-----
> > >>From: owner-registrars@xxxxxxxxxxxxxx
> > >>[mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Paul Goldstone
> > >>Sent: Wednesday, October 06, 2004 10:00 AM
> > >>To: Tim Ruiz
> > >>Cc: 'Bhavin Turakhia'; 'Registrars Constituency'
> > >>Subject: RE: [registrars] Verisign batch pool advisory
> > >>
> > >>Tim,
> > >>
> > >>Why should we be forced to go with one of their two choices?  The only
> > >>solution to this supposed issue is that Verisign should invest the
> > >>positive revenue they earn from batch pool registrations into
> > >>expanding their capabilities like other businesses do when sales
> > >>increase.  Why should we help pay for registry obligations unless they
> > >>are also willing to help pay for registrar obligations?
> > >>
> > >>It doesn't seem fair that they've been lowering the batch pool
> > >>connections at the same time as launching their own drop name service.
> > >>
> > >>On a related note, did anyone notice the following ICANN announcement
> > >>from 9/21/04 on the "Expired Domain Deletion Policy"?:
> > >>http://www.icann.org/registrars/eddp.htm
> > >>
> > >>The way I read it, except for registrant renewal or extenuating
> > >>circumstances as defined in 3.7.5.1 of the RRA, a registrar must
> > >>cancel a registration at the end of the auto-renew grace period.
> > >>ICANN basically expanded on the original ambiguous policy.  That might
> > >>ruffle a few feathers but it doesn't go into effect until 6/21/05
> > >>though.  Any idea why there's such a long lead time?
> > >>
> > >>Regards,
> > >>~Paul
> > >>
> > >>At 10:22 AM 10/6/2004 -0500, Tim Ruiz wrote:
> > >>>Bhavin,
> > >>>
> > >>>The forgiveness component consists of two criteria:
> > >>>
> > >>>1. Fewer than 350,000 names under management, and
> > >>>
> > >>>2. A ratio of attempted add commands to successful add commands of
> less
> > >>than
> > >>>200 to 1.
> > >>>
> > >>>So at least the top 20 or so registrars will still not qualify for
> > >>>forgiveness.
> > >>>
> > >>>Tim
> > >>>
> > >>>
> > >>>-----Original Message-----
> > >>>From: Bhavin Turakhia [mailto:bhavin.t@xxxxxxxxxxxxxx]
> > >>>Sent: Tuesday, October 05, 2004 10:43 PM
> > >>>To: 'Tim Ruiz'; 'Bhavin Turakhia'; 'Registrars Constituency'
> > >>>Subject: RE: [registrars] Verisign batch pool advisory
> > >>>
> > >>>
> > >>>> So while option 1 may not be ideal either, for now, it will
> > >>>> make the usefulness of the *phantom* registrars pretty much nil.
> > >>>>
> > >>>> Also, with Network Solutions' and Tucows' intention to offer
> > >>>> a secondary market service to registrants with
> > >>>> expiring/deleting names, far less valuable names are going to
> > >>>> actually hit the drop list anyway. So I think the future
> > >>>> value of the batch pool is going to change dramatically.
> > >>>
> > >>>My greater concern is that implementing 1 will result in a
> > situation where
> > >>>icann will not meet its budget sinc everyone will match the
> forgiveness
> > >>>criteria.
> > >>>
> > >>>Im still out on the road all of this week and will only be
> > back in office
> > >>>after 2 weeks ..... And therefore will be a lil quiet :)
> > >>>
> > >>>-B
> >