Re: [ga] ICANN | Advisory | 23 August 2001

[Derek Conant <dconant@dnsga.org>]

Now respectfully, you should know better than to waste your time
supporting a position that will never be actualized. 

Do you really believe that the DNSO GA is capable of understanding and
handling the responsibility associated with the proposal you support?  

The DNSO GA's purpose, scope and agenda within the ICANN process is
inherently too narrow to stand in the way of any ICANN contractual
relationship or policy changes.

VeriSign's active role in proposing changes is necessary for a better
DNS.

Derek Conant
DNSGA President and Chairman

Telephone:  (202) 801-0158
Facsimile:  (202) 234-0685
E-mail:  dconant@dnsga.org

Eric Dierker wrote:
> 
> 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
> 
>     ---------------------------------------------------------------
> 
>                                          Advisory
>        [ICANN Logo]
>                                       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
> 
>   ------------------------------------------------------------------
--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html