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

Adam Smith adam.smith at cdns.net
Wed Aug 5 02:20:44 UTC 2015

Thanks Paul,


Please see answers in-line.






-----Original Message-----
From: Paul M Kane [mailto:Paul.Kane at CDNS.net] 
Sent: Tuesday, August 4, 2015 2:05 PM
To: Adam Smith <adam.smith at CDNS.net>
Cc: jay at nzrs.net.nz; jeff at rightside.co; jeff.neuman at valideus.com;
elaine at donuts.email; ppoblete at nic.cl
Subject: Re: FW: SLEs - Working Draft




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?


Yes - IANA would like to combine the steps into larger buckets and measure
the combined point.  For example, there are two separate technical checks
done during the process.  Even though, the steps are the same for both
checks, they are done at completely different points, and could have
different variations in time, etc.  IANA would like to combine the two
sub-process into a single Technical check category.  My only assumption is
that there is more effort in setting up and maintaining multiple measurement
points, and if technical process for each time is the same, then there is no
harm in combining them.  


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?


IANA's reasoning is that it is duplicative to measure both the process steps
and cumulative transaction time.  If the all the step's SLE times are
maintained then their process meets the SLE.  Unfortunately, this opens up
an opportunity where, even though, the individual steps are efficiently
maintained, there still could be delays in the "queues" between steps.  So
for example, if you were to have a simple change request for NS records go
through, the overall process could still take a months, but the SLEs of each
step still could be in-line with the requirements and the transaction
considered a success.



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


By no way am I implying anything. Based upon my scenario above there is an
opportunity for a "most favored nation" status which could allow  for
preference in the amount of time a request spends in the "queue".  Queue
jumping may occur and preferences given to certain registries to the
detriment of others. So although the step SLE time is similar for two
different requests, the overall implementation time could be different.


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!






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


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

More information about the dt1 mailing list