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

[Paul M Kane - CWG]

Thanks Kim.

I feel we are very close to having an acceptable document - just a little
confusion which can removed by addressing any ambiguity in the document. 

I suggest that Kim, Bernie and Adam have a call this week to finalise/clarify
the areas of agreement and suggest (in the unlikely event)should there be any
areas of specific disagreement  they are highlighted and discussed within DTA.

Well done to all... we are on the final lap..... and very close to the finish.... 

Best

Paul 


Quoting Kim Davies <kim.davies at icann.org>:

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