ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [registrars] Verisign batch pool advisory

  • To: <registrars@xxxxxxxxxxxxxx>
  • Subject: RE: [registrars] Verisign batch pool advisory
  • From: "Jay Westerdal" <jwesterdal@xxxxxxxxxxxxx>
  • Date: Wed, 6 Oct 2004 15:02:10 -0700
  • In-reply-to: <EBEELHNBILGFEHBGFHIFEEPEDKAA.dwascher@iaregistry.com>
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • Thread-index: AcSr7fduefsGmqolT8uZRkOCz1njbQAASukA

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