[ga] ICANN | Advisory | 23 August 2001

[Eric Dierker <eric@hi-tek.com>]

Dear All,

Reference: http://www.icann.org/announcements/icann-pr23aug01.htm

Here is a proposition that due to the great privilege bestowed upon
Verisign we should be able to invoke.

Verisign shall make no changes in implementation of the execution of
its' trilateral contract with ICANN and the DoC without first receiving
approval from the GA of the DNSO of  ICANN.

By contract, executive order and DoC regulations this is doable.  Joanna
wrote this back a few months ago and I think it rings true today;


Joanna Lane wrote:

<major snippage>
>
> You're not going to like this but.... tech problems should never drive

> anything related to policy development for social issues. History
teaches us
> that technical difficulties can be overcome and therefore should be a
low
> priority at this point. First we have to clarify the problem in terms
of
> what is, and is not, socially acceptable, and balance this against
technical
> requirements to maintain the stability of the net and in particular
the DNS.
> Once a socially acceptable solution is found, we identify the
technical
> difficulties in achieving the desired solution, then look for the
technical
> solution. If there is no existing technical solution, we have to
develop
> one. To work the other way round on this particular issue, it to put
the
> cart before the horse.
>
> There is also the issue of creating a single point of failure that
> > doesn't exist now.
>
> Agreed, but if there's only one WHOIS server for each TLD, that is
already a
> single point of failure for that TLD isn't it?
>
> >
> > I have a whois client that looks up the TLD and queries the
appropriate
> > host. It then takes the referer reference and re-queries the actual
host
> > that has the data. Note that ripe.net is already under EU dominion
and
> > they've already altered their whois output.
>
> ... and over time the rest will follow as they realize that they have
no
> idea how many EU citizens are already in their database.
Interesting...
>
> Regards,
> Joanna.


Any highschool research assistant can track Versigns' wholly owned
subsidiry gobble up expired names and offer them for resale.  This would
appear to be private profiteering by exploitation of a government
contract forconcessionairing, which would appear to be unethical.

Sincerely,

Eric

Title: ICANN | Advisory | 23 August 2001

Advisory 23 August 2001

---

 

Third Advisory Concerning Equitable Allocation of Shared Registration System Resources

(23 August 2001) As previously reported in advisories dated 16 July 2001 and 10 August 2001, the registry operator and registrars participating in the Shared Registration System (SRS) for .com/.net/.org have been working together to devise a plan to handle expiring names in a manner that is fair and does not interfere with other activities in the SRS.

While all parties will continue to look for a long-term solution, the registry operator announced today that it has developed, and is preparing to implement, a short-term measure that will allow for the resumption of the batch delete process. This short-term measure will allow for the return of deleted names to the "pool" of names available for registration by any registrant, through any registrar, on a first-come/first-served basis. This will alleviate the growing backlog of names in delete-pending status and may provide additional data for use in developing appropriate long-term solutions.

ICANN's Domain Name Supporting Organization has already been advised of the situation and has begun to discuss possible measures for handling expiring names. Members of the community are urged to participate in the DNSO's discussions, so that all viewpoints can be considered in developing measures for fair allocation of expiring names.

---

Subject: [RegistrarsList] Announcement Regarding Suspension of Delete Batch Job and Connection Utilization within the SRS
Date: Thu, 23 Aug 2001 14:56:57 -0400
From: "VeriSign Global Registry Services" <info@verisign-grs.com>
To: <registrars@verisign-grs.com>

To all Registrars:

Summary

On Friday August 10, 2001, VeriSign Global Registry Services (VeriSign GRS) temporarily suspended the batch releases of deleted .com, .net, and .org domain names to ensure continued service quality within the Shared Registration System (SRS). As described in the announcement of the suspension, VeriSign GRS has been working with ICANN and the registrar community to devise an appropriate plan to handle expiring names in a manner that is fair and does not interfere with other activities in the SRS.

VeriSign GRS believes that a long-term solution will require fundamental changes in the way expiring names are handled. Nonetheless, in view of concerns that an ultimate solution might be made more difficult by an accumulation of expiring names during the suspension, VeriSign GRS has been evaluating short-term measures for addressing the issues that caused the suspension. The purpose of this email is to communicate the details of these short-term measures and the schedule for their implementation.

VeriSign GRS will continue to work with the Registrar Constituency, the DNSO, and the Names Council to develop better policies and processes for registrations being returned to the available pool. To the extent that the short-term measures described below provide relevant experience, VeriSign GRS will endeavor to share that information in a manner consistent with the confidentiality it accords to its customers' business information.

Goals

The goals of this new session management process are:

• To re-enable the registry batch release process.
• To ensure each registrar is able to obtain RRP sessions reasonably necessary to support its business practices.
• To support the business practices of each registrar in such a way that the business practices of one would not impact the business practices of another.
• Improve performance and lower system latency during peak processing periods.

Implementation Details

To facilitate the above goals, additional capacity has been added to the SRS and three (3) session pools have been created.

1. Guarantee Pool
2. Overflow Pool
3. Automated Batch Pool

Each of these pools is described in detail below. In summary, we expect the implementation of these three session pools to provide the following advantages:

• A larger and more reasonable number of guaranteed sessions that will better support small to medium registrars that have a traditional business model and that have been experiencing difficulties obtaining sessions.
• Support for registrars whose business model involves more extensive use of automated batch processing, without adversely impacting other registrars.
• Eliminate the need for "session squatting” (acquiring and holding sessions that are not needed or used).

Guarantee Pool

The Guarantee Pool is a session pool in which each registrar is guaranteed 15 sessions. Registrars should continue using the current hostname access (rrp.verisign-grs.com) in order to obtain their guaranteed sessions. There is no change required for registrars to access this pool. Registrars should be aware that due to the load-balancing technology currently employed, it may take multiple connection attempts to obtain these guaranteed sessions. Our data show that over 75% of registrars use 15 or less sessions. Intensive automated batch processing will not be permitted in this pool.

Overflow Pool

The Overflow Pool is a first-come-first-served pool of additional sessions. As with the Guarantee Pool, the Overflow Pool is accessed via the rrp.verisign-grs.com hostname. VeriSign GRS has added sufficient capacity to this pool to accommodate historical registrar session activity, with the movement of intensive batch processing to the Automated Batch Pool described below. Intensive automated batch processing will not be permitted in this pool. We believe the increased capacity coupled with the movement of batch processing to another pool will enable registrars to obtain the sessions they need when they need them, thus eliminating the need for session “hoarding” or “squatting”.

Automated Batch Pool

This pool of sessions has been established specifically to support registrars whose business practices include the execution of intensive automated batch processing. This pool is completely separate from the Guarantee Pool and Overflow Pool, and is accessed only via a separate hostname (rrp-auto.verisign-grs.com). Intensive automated batch processes (such as the daily automated CHECK activity) must be performed in this pool only. Registrars that desire to perform this type of activity in this pool should request access from VeriSign GRS. VeriSign GRS will grant access only to those registrars that request it, and will permit up to 50 sessions to each requesting registrar. This pool is specifically allocated to intensive automated batch processing. The purpose of this pool is to provide an area where intensive automated batch activities can be performed without impacting other activities.

Monitoring

VeriSign GRS closely monitors registrar session activity and will work with registrars to assist them in using the session pool(s) that will best support their business activities. Registrars that perform intensive automated batch processing will be required to modify their systems (i.e., use a different RRP hostname address) so that these activities are performed only in the Automated Batch Pool. VeriSign GRS believes that these measures will permit all registrars to obtain as many sessions as needed to perform business. Thus, there should no longer be a need for registrars to "hoard" or "squat" on sessions unnecessarily. VeriSign GRS is ready to implement technology that will automatically close unused sessions; however, we will only implement this technology if session "hoarding"or "squatting" continues to be a problem.

VeriSign GRS will utilize several monitoring mechanisms to detect inappropriate session utilization. We will inspect for inappropriate utilization if events such as the following occur:

• A sudden change in a registrar’s transaction or session profile
• Activity causing impact to system performance
• Complaints about system response or inability to obtain sessions

Following the occurrence of these types of events, VeriSign GRS will evaluate session activity, looking for the following specific behaviors:

• Loops of repeated transactions (e.g., multiple attempts of the same CHECK or ADD command for the same domain name)
• A high ratio of "unsuccessful" to "successful" SRS responses

If these characteristics exist, this behavior will be determined to be inappropriate for the Guarantee and Overflow Pools and the registrar will be notified and directed to move this activity to the Automated Batch Pool. If you have any additional questions about what constitutes “intensive automated batch processing”, please contact VeriSign GRS Customer Service.

Enforcement

The following enforcement procedures will be employed.

• A 1st offense will result in the registrar having its bandwidth and sessions immediately limited in the Guarantee and Overflow Pools so that the behavior does not impact the system or other registrars. The registrar will receive an email and telephone notification. When the registrar has notified VeriSign GRS of the resolution of the issue (e.g., the activity has been moved to the Automated Batch Pool), these bandwidth and session limitations will be removed.
• A 2nd offense will result in the same action as the 1st, with the added action that the registrar will be notified that subsequent offenses will result in it being blocked entirely from the Guarantee and Overflow Pools.
• A 3rd offense will result in the registrar being blocked from the Guarantee and Overflow Pools for 7 days, requiring that all transactions be performed in the Automated Batch Pool.
• Subsequent offenses will result in the registrar being blocked from the Guarantee and Overflow Pools for 30 days, requiring that all transactions be performed in the Automated Batch Pool.

Enforcement of these procedures will begin with the resumption of batch releases described below.

Implementation Schedule

These three pools are available now. Registrars that do not engage in intensive automated batch processing may continue to access the SRS through rrp.verisign-grs.com as they do now. No system changes are necessary. No intensive automated batch processing is to be performed in the Guarantee Pool or Overflow Pool. Registrars that do engage in intensive batch processing are required to request access to, and move that activity to, the Automated Batch Pool. This will require a minor modification to use the rrp-auto.verisign-grs.com access host.

Resumption of Batch Releases

VeriSign GRS believes that the prompt resumption of registry batch releases is in the best interests of the registrars and the Internet community. Therefore, the batch release process will be resumed at 18:00 UTC (1400 hrs EDT) on Thursday, August 30, 2001. Registrars that anticipate resuming associated intensive automated batch processing must modify their systems to access the Automated Batch Pool via rrp-auto.verisign-grs.com by that time. Registrars that perform this type of activity in the Guarantee or Overflow Pools will be subject to the enforcement procedures noted above. Registrars will not be permitted more than 200 total sessions across all pools. This upper limit is not a guarantee. The plan described here only guarantees 15 sessions. However, if registrars use the Automated Batch Pool for intensive batch processing, and use no more sessions than necessary to perform business (e.g., no session "hoarding"), there should be no shortage of sessions.

Subsequently, all batch releases will be performed daily at 18:00 UTC (1400 hrs EDT). Note this time change. Batch releases are always completed within 15 minutes. Therefore, registrars that utilize intensive batch processing associated with the registry daily batch release have no need to start that processing prior to 17:45 UTC (1345 hrs EDT), or to continue it past 18:30 UTC (1430 hrs EDT).

Assistance

The VeriSign GRS Customer Service and Technical Operations staffs are standing by to assist registrars as needed. We will closely monitor the utilization and activity in each pool. If, at any time, a registrar is unable to obtain a session in the Guarantee or Overflow Pools after repeated attempts, please notify VeriSign GRS Customer Service immediately. Registrars should be aware that the ability to obtain sessions can also be impacted by registrar session management practices and Internet Service Provider issues. Sessions that are broken or otherwise terminated uncleanly may require up to 15 minutes to time-out and reset, and depending on the current number of sessions, may inhibit the creation of new sessions until the broken sessions have timed-out.

We strongly believe that this process will ensure all registrars can acquire the sessions they need when they need them.

VeriSign GRS is committed to ensuring continued SRS service quality, with equitable access to every registrar. As appropriate, this plan may be adjusted in the future to meet that commitment.

Best Regards,

Chris Sheridan
Manager, Customer Service
VeriSign Global Registry Services
www.verisign-grs.com
info@verisign-grs.com

---