ICANN/DNSO
DNSO Mailling lists archives

[registrars]


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

Re: [registrars] Fw: [council] Policies Concerning Allocation of Expiring Names in .com/.net/.org


I think it would be useful to attempt to acquire some data on the situation
first.

For instance, it is theoretically possible that the problems could actually
existing at a registrar level and not a registry level (although likely it
will be a combination of both). If the registry could somehow provide us
with data that would indicate a) popularity of the expiry with the
"namesnatching" crowd and b) the old registrar of record for the domains, we
could then start to look for patterns in the data and choose a course of
action that would most appropriately deal with the problem.

Do we have any channels at our disposal through which we can request data of
this nature from ICANN or VRSN?

-rwr



Tucows Inc.
t. 416.538.5492
----- Original Message -----
From: "erica" <erica.roberts@bigpond.com>
To: "Registrars@Dnso.Org" <registrars@dnso.org>
Sent: Wednesday, July 18, 2001 12:47 AM
Subject: [registrars] Fw: [council] Policies Concerning Allocation of
Expiring Names in .com/.net/.org


> In the message below, Louis is suggsting that the DNSO consider
formulating
> policy for handling expiring domain names.  This is clearly of
significance
> to Reistrars and it would be v useful if the constituency as a whole could
> determine its position on the issue.
>
> reards,
> erica
> ----- Original Message -----
> From: "Louis Touton" <touton@icann.org>
> To: <council@dnso.org>
> Cc: "Danny Younger" <webmaster@babybows.com>
> Sent: Tuesday, July 17, 2001 11:19 AM
> Subject: [council] Policies Concerning Allocation of Expiring Names in
> .com/.net/.org
>
>
> > To the Names Council:
> >
> > In recent weeks, some registrars have reported difficulty in accessing
> > the .com/.net/.org Shared Registration System during the hours in which
> > expiring names are deleted. Upon investigation, it appears that a
> > significant portion of the available bandwith and connections is being
> > consumed during these hours by a few registrars making very large
> > numbers of queries for the names expected to expire.
> >
> > Under VeriSign's Registry Agreements with ICANN, it is obligated to
> > provide all accredited registrars "with equivalent access to its
> > Registry Services, including to its shared registration system."
> > VeriSign Registry proposed that, as an interim measure, it would place a
> > uniform limitation of 250 simultaneous connections and 256k bandwidth
> > applied to each accredited registrar. ICANN has advised VeriSign
> > Registry that these limitations appear consistent with its Registry
> > Agreements. These limitations will apply beginning tomorrow, Tuesday,
> > 17 July 2001. See the message copied below.
> >
> > This interim measure will not guarantee that all registrars will have
> > access to the registry in all circumstances. To foster a fairer and more
> > orderly process, the DNSO may wish to begin consideration of possible
> > development of a policy for handling expiring names.
> >
> > Louis Touton
> >
> > ----- Original Message -----
> > From: VeriSign Global Registry Services
> > To: registrars@verisign-grs.com
> > Sent: Friday, July 13, 2001 4:49 PM
> > Subject: [RegistrarsList] Registry Advisory: Bandwidth and Session
> > Limits to be Deployed within the SRS
> >
> > To All Registrars:
> >
> > VeriSign Global Registry Services is responsible for ensuring equivalent
> > access to the Shared Registration System (SRS) by all registrars.
> > Recently, the deletion and subsequent availability of large numbers of
> > domain names have caused a domain "land rush" during certain hours of
> > the day. During these daily "land rushes" some registrars acquire
> > unnecessarily large numbers of RRP sessions, making it difficult for
> > other registrars to acquire the minimal number needed to conduct normal
> > business. Whether this is due to inefficient registrar systems, or a
> > conscious desire to block competition by monopolizing RRP connections,
> > it is a behavior that cannot be supported or condoned. VeriSign GRS has
> > been working with ICANN to determine an access policy that will address
> > this abusive behavior while protecting the equivalent access
> > requirements of the COM, NET and ORG Registry Agreements. Our goal is to
> > protect the equivalent access of each registrar without impacting
> > legitimate business operations.
> >
> > The first step in this process will be to limit the total bandwidth any
> > single registrar can consume, along with the total number of RRP
> > sessions any single registrar can simultaneously open. Beginning Tuesday
> > July 17, each ICANN accredited registrar will be limited to 256K in
> > bandwidth and 250 simultaneous RRP connections.
> >
> > As always, we recommend each registrar evaluate the efficiency of their
> > systems. VeriSign GRS will share with each registrar their bandwidth
> > utilization and RRP connection trends, in addition to efficiency (i.e.,
> > number of transactions per connection).
> >
> > RRP bandwidth and connections will always be a finite commodity. The
> > recent "land rush" events indicate that the informal measures we have
> > relied on in the past will not ensure that all registrars have fair
> > access to this commodity. VeriSign GRS recognizes that, although they
> > should be helpful in the short term, the bandwidth and connection
> > limitations described above will not ensure access in all load
> > circumstances and are only a partial solution. We will therefore be
> > working with registrars and ICANN to develop fair and effective
> > longer-term means of providing every registrar appropriate access to the
> > SRS.
> >
> > If you require additional information, please contact VeriSign Global
> > Registry Services at info@verisign-grs.com or +1 703-925-6999.
> >
> > Best Regards,
> >
> > Chris Sheridan
> > Manager, Customer Service
> > VeriSign Global Registry Services
> > www.verisign-grs.com
> > info@verisign-grs.com
> >
>



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