Re: [registrars] Afilias Service Level Agreement

["Ross Wm. Rader" <ross@tucows.com>]

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.
>
>
>
>