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

[Kim Davies]

All,

Firstly, I have to state up-front I feel quite blindsided by this discussion. As tasked by the Design Team, Adam and I have been working countless hours on co-authoring a mutually agreeable draft between the two of us before sharing it with the wider group to get input on. We have been meeting and converging on something two of us can agree, but we still had a little more work to do to get there, so I am not sure I understand how it came to pass that this has been circulated and is being discussed beyond the two of us.  I also find it hard to comment appropriately as I only see part of the discussion as it is happening in private with only select individuals, rather than openly on the list. Thanks to Adam for copying in the mailing list on his replies.

With that in mind, comments below:

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.

I am surprised by this comment as in our discussions to date we have not even discussed this idea of dividing the technical checks into two different SLE categories in this fashion before. The notion of having two separate measurement points for technical checks like this is something that was only introduced in a revision Adam emailed me in the last 24 hours. I have not had the opportunity to form a view on it. My initial thought is if you perform an identical process twice, that they would be two measurable events of the same type, each subject to the SLE for that specific process.

To be clear,  "Are you saying that you want IANA to capture/publish the time taken for each process step?”, I have always supported this, so it is categorically incorrect to suggest I have pushed back on measuring anything other than all of the processing time, and with that time attributable to who is responsible. The points of potential disagreement are the granularity of the measurements, and in particular the granularity and overlap of potential SLEs (i.e. double counting the same process with two different SLEs set for it).

As an additional clarification, you said “IANA would like…” and “IANA’s reasoning…" It is important to understand the only things I have discussed in producing the document to date is my personal views. Just as Adam’s views he has shared with me in developing the document are his alone, and I wouldn’t ascribe them to being CommunityDNS’s position, my understanding is the drafting has only been between the two of us with Bernie as a facilitator. I have not circulated the draft within ICANN for buy-in or feedback as I understood broader review would come after Adam and I had a meeting of the minds and produced a draft we agreed was ready to share with the Design Team and others.

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?

I have never suggested that we measure a single customer request process time, nor have any of the drafts we’ve produced contemplated it, so it is not clear to me where this thinking is coming from.

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.

This is simply not correct. The measurements in the drafts we have have been discussing measure and report 100% of IANA’s processing time for change requests, and have provision to apply SLEs to 100% of IANA’s processing time for routine change requests and delegations/redelegations. The only place envisaged where times may be reported, but for which SLEs may not apply, is circumstances described in the document as “Category V” where there are unique circumstances that make a request “fall out” of the normal processing flow (e.g. lawsuit,  special processing instructions on file, etc.)

It is true that a routine NS change request could take months and meet all SLEs, but I can only see two ways it could happen. Either (a) the SLEs are set to make that an acceptable target (as we haven’t defined the SLEs, that would come later); or (b) the time taken is customer time or other third party time (e.g. the time it takes them to confirm a request). It is clear it could not happen because there was a portion of IANA processing time that is not being measured and reported.

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.

Not sure I understand what is being suggested here. I don’t see where there is an opportunity for discriminatory behavior, and this is not something that we have talked about in our discussions to date. If IANA performs within the community agreed SLEs, and the SLEs cover IANA’s processing time, where is the concerning opportunity for IANA to unduly detriment a request? Is the suggestion that while meeting the SLEs, IANA could go even quicker for some TLDs it “prefers” while taking longer for others?

thanks,

kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt1/attachments/20150805/8b628524/attachment.html>