<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [registrars] Delete Issue Update #1
Rick,
This is good to see all proposals on the table for comparison.
Some general comments:
Some of my clients have stated that the back log of domains is closer to 9
million names for .com .net and .org. This information is derived from the
continued checking of the root zone files for the last 5 years. Not only
does a new release process need to be established but a systematic way of
release sing the back log of names has to be addressed.
The market itself was created before the registrars were created using the
NSI email templates. The registrars provided a cheaper real time system then
sending in emails to NSI.
Not all registrars were in this business because of various reasons, which
in turn did limit the amount of exposure for these domains. Now with the new
exposure and emphases on distributing the expired list on a global scale,
the possible request for a single name has just increased 100 fold.
I support the creation of a parallel release system geared to handle the
overhead in the releasing of expired domains in a controlled environment.
This independent system should continue to help promote competition.
Thanks,
David W.
IARegistry
-----Original Message-----
From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
Behalf Of Rick H Wesson
Sent: Friday, August 17, 2001 7:48 PM
To: NSI Registrar List; Registrars List
Subject: [registrars] Delete Issue Update #1
Problem Statement
The procedure implemented by the VeriSign Registry to batch delete
domains is being gamed by a few registrars that have created a market
for domain names due to be deleted. I the registrars attempt to
re-register these deleted domains they have been consuming more than
normal system resources at the registry thus preventing other
registrar from performing normal business during the "landrush" for
the deleted domains.
The registry has implemented a short term policy of not deleting
domains until a new procedure has been developed to allievate the
contention for connections and lower the load of check requests to a
normal level. Until this situation is resolved all deleted domains
will be on "Delete Pending."
Below are several proposals from registrars, one from the GA, and one
from an ICANN Board member, on how to resolve the problem. I encourage
everyone to review these and post their thoughts or additional
proposals to the registrars list. I'll maintain a list of the ideas
and any other information I can gather from the registry.
We should be working on evaluation these proposals next week and have
chosen a single one for recommendation by the 29th of August.
Some guidelines for evaluating proposals:
o The proposal MUST be fair to all ICANN Accredited Registrars
o The proposal SHOULD work within the current RRP 1.1.0 protocol.
o the proposal SHOULD NOT encourage the use of the CHECK DOMAIN
command to find out available names in the pool of names to
be deleted.
o The proposal SHOULD NOT give a greater benefit to a registrar
that uses more RRP Connections over a registrar with a single
RRP Connection.
I'm sure that there are more requirements, the above were just off the
top of my head.
Since my last post on this topic the VeriSign registry has released
the list of domains to be deleted. The files are available under
password protection at ftp://ftp.verisign-grs.com/pub/
I counted over unique 64,000 names to be deleted, queued over the
first 4 days. I have not yet performed any analysis to determine the
registrars that the names belong to.
-rick
Karl Auerbach <karl@cavebear.com>
Create an announcement mechanism in which notices of expiring
domains are sent to interested parties. These notices would be
sent out some period in advance of expiration and would contain
the name that will be expired and the date/time-of-day of the
forthcoming expiration.
Then there would simply be a rush at the tick of the clock to
register the name. (There may be methods of managing the rush, but
here I'm mainly concerned with the means of announcing the
expiration.)
I figure that amortized over a year the average bit rate for this
for a 30,000,000 TLD like .com would be about 800 bits/second
before compression.
Two methods strike me as appropriate - IP multicast and netnews.
IP multicast is easy, cheap (potentially free), and effective.
IP-over-IP tunnels allow it to be extended across non-multicast
enabled ISP's and through firewalls.
In addition, IP multicast allows any person, not just registrars to
listen into the announcements - which is an important aspect of
fairness.
Netnews is kind of a fallback, but it's easy. It has the drawback
that the traffic would have a higher degree of overhead than IP
multicast.
Larry Erlich <erlich@domainregistry.com>
As has been mentioned, why not an auction where Registrars take
bids for desirable names from customers?
1) The REGISTRY gets a fee per name for developing and implementing
the systems to allow registrars to submit bids on behalf of
customers.
2) The REGISTRARS get a fee for accepting the bids from potential
customers.
3) The registrar who is RELEASING (has deleted or about to delete)
the name gets a % of the name sale to insure that it is in their
best interest to release the name, and not sell it or retain it
themselves. This would take care of names that are within the 5
and 45 day windows that don't even go on registry hold (by
providing an incentive to the registrars of those names to have
them handled in the same way). It would also take care of
registrars monitoring expiration dates of those names trying to
grab them by engineering abusive systems.
3a) The other % gets split among ICANN and other ICANN accredited
registrars according to some formula that would have to be
developed.
4) Bids can be submitted for any name, even if it is not
expired. That way customers don't have to constantly monitor the
process. The bids will remain private, only being known by the
registrar who collects the bid and the registry. We get many cases
of people who would like names that haven't even expired yet, and
I'm sure they would pay a nominal fee to be able to bid for the
name if it ever was available.
IANAL, but with the auction approach (unlike the "application"
process) it's legal since the winner is not picked randomly.
And, it is fair for consumers, since one small fee, paid to the
registrar of your choice, covers your bid for a given name. With
applications, you have to submit multiple applications with no
guarantee even if you submit the most applications, only a better
chance. And you lose all the application money. (And as we know
the legality of that system is currently being questioned.)
One final thought. People wanting to register expired names will
complain about the fact that they have to bid on expiring
names. But let's face it. They don't stand a chance of getting the
desirable names right now, unless they buy them from the person who
knows how to work the current system.
A proposal from the GA by Russ Smith
The solution is rather straighforward. You isolate the "grabbing"
system from the rest of registry system so normal business is not
affected. Then you implement a landrush system similar to what is
being used for some of the new TLD's. Of course it would have been
much cheaper to implement this at the start of the shared registry
system. To go back and try to fix it now will be much more
expensive.
Among most of the average domain buyers I believe a "consensus"
existed years ago that the system should be corrected. However, the
people at Verisign are only concerned with the "consensus" of their
shareholders. Since there was no profit motive for doing this it
never was done.
Kevin C. Ranck <kcr@addresscreation.com>
One possible implementation:
On Sunday, Verisign GRS would randomize the pool of expired names
from the previous week and distribute a list to each accredited
registrar (number of names registrar would receive = pool
total/accredited registrars).
The registrar has until the following Saturday to claim (and pay
for) those domains they want. All unclaimed names go into a 'Once
rejected' pool. Those names are then returned to the pool to be
redistributed on Sunday. Once a name is rejected two times it is
deemed not be valuable and is simply released according to the drop
procedures that are in place now.
Chris Moore [mailto:seymour@itsyourdomain.com]
1. Offer a 'grab bag' (for lack a better term) for the expiring
domains. The registry should publish the list of domains to be
released. Then the registrars should put in requests based upon
their client's desires. The names should then be randomly handed
out amongst the registrars who put in requests.
2. Maintain the ability to have all registrars hitting the registry
full-force with the maximum number of connections simultaneously.
3. Offer an isolated rrp server that only offers registration of
expired domains (which stay taken in the regular registry until an
hour or so after drop time).
Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au>
There is a relatively simple solution to this, and that is to
separate out the market for expired domains from the normal market
for new domains.
This can be done in a similar manner to that for ".biz" and ".info"
to handle landrush.
(1) Registry queue up expired domains for a period (e.g 1
month) and advertise a list of expired domains available
(2) Registry accepts pre-registrations for these expired domains
for a period (e.g 1 week)
(3) Registry executes a random selection from the pre-registrations
(4) Repeat cycle for ever
There definitely needs to be a fairer system for allocating expired
domains.
Rob Hall <rob@momentous.ca>
Most of the discussion so far has been how to fix HOW the "drops"
are implemented. I haven't seen any discussion on WHY there are
these "drops". Any fix should take into the account the reason for
these drops.
"Drops" occur when domains are put on REGISTRY-DELETE-NOTIFY status
by the Registry. Domains changed to this status are removed from
the root zone files and are scheduled to be batch deleted after a 5
calendar day waiting period.
Domains are only changed to this status if a Registrar deletes a
domain name outside of the 5 and 45 day grace periods. The 5 day
grace period applies to new, transferred and explicitly renewed
registrations and the 45 day grace period applies to auto-renewed
registrations.
For most Registrars, expired domains never go to
REGISTRY-DELETE-NOTIFY status. We want to make sure that we don't
lose an extra $6 to VeriSign, so we delete an expired domain name
within the 45 day grace period. When this occurs, the domain is
available IMMEDIATELY for re-registration. These names are not
part of the "land rush" that occurs at 6:30 Eastern US time.
Now the vast majority of the expiring domains reside in the legacy
Registrar -- Network Solutions -- which as we know is part of
VeriSign. For reasons unique to Network Solutions, they as a
Registrar have decided not to delete unpaid domains within 45 days
of expiration. Hence the "land rush".
My suggestion is that we eliminate the "land rush" by asking
Network Solutions to play by the rules that the rest of us
Registrars are financially constrained to follow. If 45 days is
not a large enough grace period for Network Solutions to delete
expired domains from their database, I (personally as I do not
speak for the employer) would be willing to support a request for
VeriSign to extend the 45 day grace for all Registrars.
Tucows Inc. Memo
08/10/2001
Re: Verisign Registry Performance, Connection Limits and Domain
Expiration Policy Recommendations
To: General Distribution
Status: Public
Recent events have made it clear that Accredited CNO Registrars and
Verisign Global Registry Services must modify their procedures and
policies in order to more effectively deal with the expiration and
release of domain names.
A determined examination of not only the root problems, but also
the existing policy must be undertaken in order to properly resolve
the service issues that the community faces. This can only be
achieved through concerted cooperation and discourse between the
registry and the registrars.
VGRS has a number of options at their disposal that would
streamline their processes and allow them to operate more
efficiently. This would not only benefit their operations, but also
accredited Registrars and their users.
Executive Summary
-----------------
The General Proposals allow Registrars to explore new ways to
streamline their operation and provide additional offerings and
enhanced customer service to their clientele. It also provides the
Registry with a number of effective mechanisms for managing the
resource and load allocation issues internal to their systems.
The Domain Expiration and Release Improvement Proposals allow
Registrars and the Registry to more effectively manage the deletion
and re-registration process while ensuring that this valuable
resource is appropriately exploited.
General Registry Improvement Proposals
--------------------------------------
1. Replicate key Registry data to Registrar systems. This solution
has the merit of carrying a broad range of benefits for the
Registry and Registrars and closely plays into the points presented
further in this memo. Replicating key data will not only distribute
the load to individual Registrar systems, but also put the
Registrar in a position to determine their own resource allocation
policies rather than relying on the current system of centralized
control and enforcement.
The number of changes to this data are minimal in comparison to the
number of records in the database. Appropriate replication
mechanisms will ensure that the Registry is not overly burdened
with data transport overhead and completely minimize the current
problem of check commands, connection grabbing and the other
symptoms displayed by the rush to grab expired domains.
2. Provide Registrars access to data associated with the STATUS
command via the RRP. Currently Registrars can only retrieve
information on domain names that the Registrar owns. While this
information is freely available out-of-band via the CRSNIC whois
data output, VGRS restricts the availability of this information
via the RRP. The reason for this restriction is not documented.
If Registrars had access to this data in bulk format, it would be a
trivial exercise for them to populate a database local to the
Registrar with the data and use it as a semi-authoritative source
for lookups. Updates to this dataset could be retrieved via the
RRP to ensure reasonable synchronization with the Registry
data. Going forward, as domains are checked that are not in the
Registrars local database, the Registrar could perform a status
command to determine when the Registrar might need to check the
domain name record again base on the expiration date of the record.
This arrangement also has the collateral benefit of minimizing the
number of whois lookups that a registrar is required to undertake
during inter-registrar domain transfers and other administrative
processes.
This is a very important recommendation. There should be no reason
why a Registrar should have to lookup domain names against the
Registry on a regular basis if the Registrar is provided with the
basic data required to know when a domain name is expiring. Under
the current system, if a Registrar receives 10,000 lookup requests
from potential Registrant concerning a domain name, the Registrar
is forced to undertake 10,000 unique lookup requests on the name
because its actual status is unknown to the Registrar.
3. Publish ON HOLD data. According to our estimates, there are at
least 1 million domain names that are currently on hold. It is not
currently possible to authoritatively determine which names are on
hold unless the registry is queried directly via the RRP. This
generates a great deal of unecessary traffic at the protocol level
that could easily be handled through other out-of-band means. For
instance, ON HOLD status could be distributed within the Zone Files
themselves, either as a standalone file, or as comments within the
operational zone file.
4. Separate the 'check' and 'status' commands from those which
actually make changes (like add or modify) into separate databases
and/or servers. Registrars should connect to one system for checks
and one for action items which modify the database. System
modifications to Registrar systems would be trivial and isolate the
impact of any abuse that may occur through either of these systems.
Domain Expiration and Release Improvement Proposals
---------------------------------------------------
There are a number of areas that the Registry need seriously
examine in order to better serve the needs of their Registrar
clientele. The Registry needs to consider these, and all other
serious proposals, very carefully to ensure that the long-term
solution and the ramifications of that solution are beneficial to
the DNS community.
1. Schedule and publish the domain name expiration and deletion
schedules. Various entities have implemented a variety of bizarre
and questionable processes to determine which domains are scheduled
to be released and when. The system-wide overhead (including
Registrar and Registry systems) is excessive.
If expirations were scheduled and published, the "expiration
land-rush" could effectively be managed to occur at times deemed
appropriate by the registry instead of occurring over a 12 to 14
hour period currently determined by speculators. Further, if the
Registry included domain name registration and expiry data as the
response to a "check" and "add" commannd, it would be trivial for a
Registrar to determine that a deleted name had been re-registered
and stop checking the status of the domain or attempting to
register it. Currently the behavior is such that speculators will
continue issuing check commands until they feel that the window for
the expiration and release of the domain has reasonably passed and
assume that domain has been registered by someone else. Only at
this point will they cease their efforts to procure the domain
name.
2. Create a separate subsystem within the Registry to specifically
handle re-registration requests. Even if the association processes
did not change, segregating re-registration requests from standard
registration requests would eliminate the resource constraints and
arbitrary restrictions currently experienced by Registrars.
3. Create a randomized landrush queue for re-registration requests.
Queuing the re-registration requests for specific domains from
Registrars (one request per domain name per Registrar) in a
randomized round-robin queue will completely eliminate the
re-registration rush as we know it. Any names that are not
re-registered by a Registrar could easily go back into the general
pool of available names with limited/non-existant impact to the
Registry at a later date.
Summary
-------
A balanced approach that includes improvements to operational and
technical processes at both the registry and the various registrars
will provide a reasonable and efficient solution to the problems
currently faced by VGRS and CNO Registrars. Specifically dealing
solely with the technical hurdles posed by the "drop-landrush" will
not conclusively deal with the root problems that the community is
now facing. Open and responsible dialog combined with decisive and
measured application of revised policy will be key to ensuring that
the Registry resources are appropriately and responsibly utilized.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|