[SLE Team] {SPAM/L} RE: SLEWG Meeting | 18:00 UTC | 17 August 2015 - this one!

[Patricio Poblete]

Adam,

Thanks for your explanation. Even though, in general, what you describe
might happen, I believe that the measurement protocol can be designed in
such a way as to exclude this possibility.

What I mean is that a timestamp should be assigned to the exact time when a
communication is sent from IANA to the customer, requesting some action on
their part, and to the time when the reply from the customer comes back.
These timestamps should be the crucial times for computing the duration of
stages.

More precisely, when the IANA receives a communication from the customer
(be it the initial one or the reply to a request), the clock starts running
for IANA *then*, and not some time later when gets around to start
processing it.

This would still leave room for some unaccounted time between to
consecutive stages inside IANA, with no customer intervention. Again, the
design should be such that the end time of one stage and the start time for
the next one should be *exactly* the same. So, the clock never stops, it
just changes from being accounted to some stage to the next.

Patricio

On Tue, Aug 18, 2015 at 11:32 AM, Adam Smith <adam.smith at cdns.net> wrote:

> There is always an “in-between” or queue time between any two processes.
> This is the time at the end of the process and the beginning of the next
> process while the request is still in IANA’s control .  This in-between
> time can occur both between two IANA process steps or between.
>
>
>
> The fundamental issue is that a request could be stalled indefinitely (in
> theory) between process without impacting the SLEs, the dashboards, audit,
> etc. Because the system flow is discrete with well-defined processes, the
> SLEs will only provide accountability for one-half of the entire process.
> So how do you ensure full coverage, and accountability equivalent to an SLE
> for the time in queue?
>
>
>
> Having an overall time is just one approach to the problem.  I would
> contend that it may be the easiest way to solve the problem.  There is not
> a double count, once the step SLE is met,  that time is accounted for in
> the overall time. The issue will be how well IANA manages its flow process,
> and ensures no hold ups of requests.  The SLE times will automatically come
> out with the time stamps during the measurement phase.
>
>
>
> To recap; this is not an overall time issue, but a “queue” time issue.
> The gap that this will leave unresolved is as big as the step processes.
>
>
>
> *From:* dt1-bounces at icann.org [mailto:dt1-bounces at icann.org] *On Behalf
> Of *Patricio Poblete
> *Sent:* Tuesday, August 18, 2015 8:51 AM
> *To:* Kim Davies <kim.davies at icann.org>
> *Cc:* dt1 at icann.org; Paul M Kane <Paul.Kane at icb.co.uk>
> *Subject:* Re: [SLE Team] SLEWG Meeting | 18:00 UTC | 17 August 2015 -
> this one!
>
>
>
> On Mon, Aug 17, 2015 at 6:43 PM, Kim Davies <kim.davies at icann.org> wrote:
>
>
> > ICANN/IANA have argued there is little point in double counting, ie
> capturing the time for each SLE process step, then a for each change
> request adding up each step to have a total overall processing time SLE.
> > From my perspective the two should equate to the same and conducting an
> SLE for the aggregated time is futile as it is almost double counting as
> the total should be the sum of the earlier (measured) component process
> steps.
>
> I believe I am aligned with your thoughts.
>
>
>
> I agree with Paul and Kim on this point.
>
>
>
> Another reason for not using the total aggregated time as a variable is
> that we would not know how to assign an SLE to it, since the possibility of
> multiple repeated technical checks implies that the total time could be
> arbitrarily large.
>
>
>
> There is a mention in Paul's message of the possibility of setting a
> maximum for "in between time". I believe there should be no "in between
> time". Either the ball is with the customer or with IANA, but never in
> limbo. Whenever it is with IANA, it should be accounted for somewhere.
>
>
>
> Patricio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt1/attachments/20150818/3a21764d/attachment-0001.html>