Re: [registrars] Afilias Service Level Agreement

["Tim Ruiz" <tim@godaddy.com>]

Thanks Ross. That's my first perference as well. Unfortunately their only
response to date has been that it's our problem not theirs and to resolve
it we need to increase our timeout to 5 minutes.

But given those definitions for monitoring the protocol performance, what's
the point of it then? I don't really care how fast it is to them
internally. I just want better response for my customers and an opportunity
to cross sell INFOs.

Tim

 -------- Original Message --------
   Subject: Re: [registrars] Afilias Service Level Agreement
   From: "Ross Wm. Rader" <ross@tucows.com>
   Date: Tue, April 2, 2002 7:58 am
   To: <tim@godaddy.com>,
         <registrars@dnso.org>

   I can only speak based on my familiarity with the document and not
   from any formal position or association, however I have spent a great
   deal of time with this document so I might be able to help out. So,
   keep in mind that this is my *opinion*, not my employer's or Afilias'
   and that I am not a lawyer ;)

   The service level monitoring implied in Appendix D & E of the .info
   registry agreement are intended to guarantee service times for a
   simulated registrar. However, because real-world conditions vary so
   widely (ie - the performance experienced by a registrar in Ghana is
   going to be drastically different than one in New Jersey), this
   simulated registrar resides within the Afilias network. As such the
   RTT's contemplated by these documents only reflect internal behaviors
   (ie - can we get a packet from the edge router to the core database
   and back in less than the times specified).

   As far as what constitutes an outage, the agreements are reasonably
   precise on that basis - for the EPP protocol interface, and the
   definition of outage is found here -

   "Total duration of Unplanned Outage Time of C1 class services must not
   exceed 30 minutes per Monthly Timeframe. This represents a Service
   Availability percentage of 99.93%. Total duration of Service
   Unavailability of C1 class services must not exceed 60 minutes per
   Monthly Timeframe. This represents a Service Availability percentage
   of 99.86%."


   Unplanned Outage is defined as:

   .18 "Unplanned Outage Time" shall mean all of the following:
   2.18.1 With respect to services other than Whois Service and
   nameserver resolution, the amount of time recorded between a trouble
   ticket first being opened by the Registry Operator in response to a
   Registrar's claim of Service Unavailability for that Registrar through
   the time when the Registrar and Registry Operator agree the Service
   Unavailability has been resolved with a final fix or a temporary work
   around, and the trouble ticket has been closed. This will be
   considered Service Unavailability only for those individual Registrars
   impacted by the outage;
   2.18.2 With respect to services other than Whois Service and
   nameserver resolution, the amount of time recorded between a trouble
   ticket first being opened by the Registry Operator in the event of
   Service Unavailability that affects all Registrars through the time
   when the Registry Operator resolves the problem with a final fix or a
   temporary work around, and the trouble ticket has been closed;
   2.18.3 With respect to all services, the amount of time that Planned
   Outage time exceeds the limits established in Section 2.10 above; or
   2.18.4 With respect to all services, the amount of time that Planned
   Outage time occurs outside the window of time established in Section
   2.10 above.

   Service Unavailability is defined as:

   2.13 "Service Unavailability" means when, as a result of a failure of
   systems within the Registry Operator's control.
   2.13.1 With respect to services other than Whois Service and
   nameservice, Registrar is unable to establish a session with the
   System gateway which shall be defined as:
   2.13.1.1 successfully complete a TCP session start,
   2.13.1.2 successfully complete the SSL authentication handshake, and
   2.13.1.3 successfully complete the Extensible Provisioning Protocol
   ("EPP") <login> command.
   2.13.2 With respect to all services, system monitoring tools register
   three (3) consecutive monitoring failures on any of the components
   listed in Section 3–System Services.

   At the end of the day, it sounds like this is something that can be
   worked out on a commercial basis between supplier and customer
   (perhaps not - but its always my first preference). If you work with
   Afilias and help them understand what the impact of this situation is
   on your business and what the impact on theirs is if you go to a
   selective lookup, then I think that you'll be able to make much
   quicker and more satisfactory headway than if you "get the lawyers
   involved".

   Just my $0.02, and as always, YMMV.

   Take care Tim,

   -rwr

   ----- Original Message -----
   From: "Tim Ruiz" <tim@godaddy.com>
   To: <registrars@dnso.org>
   Cc: "Dan Halloran" <halloran@icann.org>
   Sent: Tuesday, April 02, 2002 9:08 AM
   Subject: [registrars] Afilias Service Level Agreement


   > According to Afilias' SLA, the protocol performance for a
   > single-entity payload should be:
   >
   > Add/Renew/Delete/Update - 800ms
   > Transfer  - 1600ms
   > Check - 400ms
   >
   > Now I realize that this is based on how their system monitoring
   > tools simulates a registrar. But it seems to me that if a
   > significant percentage of real-life registrar transactions are not
   > getting this kind of response that there must be a serious problem
   > with their monitoring tool.
   >
   > We feel we are NOT getting the above response times on any kind of a
   > consistent basis.  We are in the process of documenting the response
   > times ourselves, particularly the Check response. We have complained
   > to Afilias who basically claims that no one is having this problem
   > but us. They actually suggested we increase our timeout on a Check
   > from 30 seconds to 5 minutes!
   >
   > So we'd like to know, has anyone else been experiencing slow
   > performance with Afilias during part of the day? If so, are you
   > willing to document
   your
   > response times and submit same to Afilias and ICANN. At the very
   > least we would like to see Afilias seriously review their monitoring
   > methodology as we believe it may not be truly representative of what
   > the registrars are experiencing.
   >
   > If this cannot be resolved we feel we may have no choice but to stop
   > cross-checking INFO and offer it only when specifically requested.
   >
   > And Dan,  what constitutes an outage? Can they take 5 minutes to
   > respond
   to
   > a Check command (as they seem to suggest) and not call that an
   > outage?
   >
   > Tim Ruiz
   > Go Daddy Software, Inc.