<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] Verisign batch pool advisory
- To: "'Paul Stahura'" <stahura@xxxxxxxx>, "'Jay Westerdal'" <jwesterdal@xxxxxxxxxxxxx>, <registrars@xxxxxxxxxxxxxx>
- Subject: RE: [registrars] Verisign batch pool advisory
- From: "Donny Simonton" <donny@xxxxxxxxxxxxxxx>
- Date: Wed, 6 Oct 2004 17:23:17 -0500
- In-reply-to: <DA6F8AFB015C544AB4385B5DEBDE1FBB0C2482@mail.enom.com>
- Sender: owner-registrars@xxxxxxxxxxxxxx
- Thread-index: AcSr8BSj11H77gpgQuaKUG3Kj56sfwAAkS3w
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
> >
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|