[SLE Team] {SPAM/L} RE: FW: SLEs - Working Draft

Wed Aug 5 03:22:20 UTC 2015

Elaine,

Thank you for reviewing the document and providing the feedback.  Please see answers in-line.

Best,

Adam

From: Elaine Pruis [mailto:elaine at donuts.email] 
Sent: Tuesday, August 4, 2015 5:25 PM
To: Paul M Kane <Paul.Kane at cdns.net>
Cc: Adam Smith <adam.smith at cdns.net>; Jay Daley <jay at nzrs.net.nz>; Jeffrey Eckhaus <jeff at rightside.co>; Jeff Neuman <jeff.neuman at valideus.com>; Patricio Poblete <ppoblete at nic.cl>
Subject: Re: FW: SLEs - Working Draft

Thanks very much for your work on this Adam, excellent job.

Attached is a draft with track changes on for grammatical edits, and here are my comments / questions.

Apologies for the lengthy email. 

1. In Assumptions, Section E, Add "email requests" to the change request submission types, along with metrics and reporting.

Background:

 Donuts (along with our backend operator, as well as our DNS provider) recently transitioned and migrated a live new gTLD from another registry operator, which had contracted with a different backend operator and DNS provider (Category III in the SLE doc). The legacy operator had an RZM credential but our arrangement was for Donuts to handle the migration with very little involvement from the legacy operator. (This same scenario could exist in the case of an EBERO migration). Because the legacy operator had the RZM credential, but Donuts performed all of the migration work, change requests to IANA were not submitted via the RZM portal. Rather, they were submitted via an email request to rzm at iana.org <mailto:rzm at iana.org> .  Obviously the review of the email request, confirmation of receipt, and follow up communication was not part of the automated system and did not occur via the RZM portal. In addition, the TLD did not "appear" in the Donuts RZM portal until well after the sponsoring organization AND DNS change requests were processed and completed.  We were in a sticky spot because contractually we were the registry operator but had no ability via the RZM to self-manage the TLD. 

This example of service via email communication is timely and the same issue will soon be repeated in another TLD transition. In an era of TLDs changing hands as rapidly as they are being delegated or launched, there is a strong case to include in Assumptions, Section E, email submission as a means for change requests, with response time metrics, as well as inclusion of the metrics in reporting.

Agreed, I will make the necessary changes.

2. In Assumptions, Section K, categorization of change requests, it appears as if each category will have a different SLE.  Please add "IANA notice to customer of category type" as a requirement.   If IANA informs a customer of the type of request they are processing, the registry operator can better plan timelines for things like DNSkey changes, NS updates, etc. According to the chart, the first four categories will have metrics a customer can refer to and possibly depend on, but the Cat 5s will not. In this case it is essential that the registry operator be aware of the uncertainty of the turn around time.

I agree with your assumption.  If there is uncertainty in the time period, the operator should be made aware in advance.

3. In Assumptions, Section L, please confirm that the X in the box indicates a defined SLE is to be determined as part of our work. If not, what does the X mean? Yes the X in the box indicates that the step is applicable to the process and will have a defined SLE.

4. In Service Level Expectation, page 11, add a Service Area "Email Communication" "Response to sponsoring organizations that do not yet have RZM credentials for the TLD" 

Ok.

5. In Reporting Mechanisms, page 12, I assume the Status Tracker is part of the RZM interactive service. The same information should be made available to registry operators that are transitioning a TLD, that do not yet have access to the TLD via their RZM account. (This issue would go away if IANA provided access to the TLD via the RZM immediately upon the sponsoring organization being updated). – Yes, the Status Tracker is available to the TLDs only.

6. In Informational Measurement and Reporting, (VERY pleased with the additions you've made),  B1 says "Time from submission to customer action required — average time between submissions of a change request via RZMS to when customer is asked to provide contact confirmations on a request.' Please add a separate metric "Time from submission to customer action required — average time between submissions of a change request via EMAIL to when customer is asked to provide contact confirmations on a request."

I will add this…

7. Question, in Process Performance on Page 15, please clarify, how is this chart different than the chart on page 8 (with the X's), or why is it included here? – The document is actually broken into parts, an Introductory section (background, assumptions, etc.) and the SLE itself (starting on page 11).  I started with the process flow and the chart in the Introductory section to provide an overview of IANA’s process and how the process maps to the different requests (categories).  The table on Page 15 will have the SLE times itself.  I intentionally laid out the table so each different type of request had its steps laid out with the associated times.  This way the processes, steps, and time can be easily mapped to IANA’s process flow.

Thanks again Adam for your hard work. – Thank you Elaine, and I will collect all the changes and apply it to the document and recirculate.

On Tue, Aug 4, 2015 at 11:04 AM, Paul M Kane <Paul.Kane at cdns.net <mailto:Paul.Kane at cdns.net> > wrote:

Adam

Thanks for your email but I am a little confused. This should be a standard process flow SLA.

I am struggling to identify the impasse from your email?

Are you saying that you want IANA to capture/publish the time taken for each process step and IANA don't want to do that?

If so, could you tell us what is their reasoning for just having a single customer request process time rather than both the time taken for each specific process step as well as the cumulative transaction time?

Please explain what is meant by "opportunity for discriminatory behavior."?

I will take a look at your proposed SLE document tonight/tomorrow (and BTW thanks for all your effort on this).

I think it would be good for the DTA members to have a call to discuss and give guidance to you once we have greater clarity of the impasse.

I have a CWG call on Thursday and I've been asked to "explain the delay" in having the SLE published.... so keep up the good work. We want this finished asap!

Best

Paul

Adam Smith wrote:

All,

I wanted to provide the latest update on the SLE document and process, as well, seek guidance from the DTA/SLE subcommittee on further direction due to an impasse. Attached is a copy of my latest draft of the SLE document that deviates from IANA’s last draft.

As a quick background, my goal was to identify a process, set SLA points in the process, and setup mechanisms for transparency, i.e. automated dashboards, deviation reports, etc. To fast forward, IANA delivered a process flow diagram last Thursday as well as their latest copy. Here are the deviations/impasse:

·During the development of the SLE, IANA had identified processes with limited number of steps in the process flow. After receiving the new process flowchart. It is apparent there is more detail in the process then initially conveyed, and the new version of the SLE reflects those changes. The importance of capturing and measuring the actual process vs. combining process is the ability to find weak points in the flow for both future optimization and failure analysis.

·It is important to measure each step, as well as the cumulative time in the system. The issue here is that one can meet the SLE for each step while still having an unreasonable amount of time in the implementation of the request. This could provide the opportunity for discriminatory behavior.

The other areas that I would like feedback on the document is the granularity of the process steps, does it provide enough transparency, and the direction we would like to go.

I look forward to our discussion as well as your feedback.

All the best,

Adam

-- 

 <http://www.donuts.domains> 

Elaine Pruis, Vice President, Operations
 <http://www.donuts.domains> Donuts Inc.
10500 NE 8th Street, Suite 350, Bellevue Washington, 98004, U.S.A. | Telephone: 509.899.3161
 <https://twitter.com/DonutsInc>  <https://www.facebook.com/donutstlds>  <http://www.linkedin.com/company/donuts-inc-> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt1/attachments/20150804/116f34da/attachment-0001.html>