<div dir="ltr">Kim,<div><br></div><div>This is exactly what I was trying to say. You explained it much better :-)</div><div><br></div><div>Patricio</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 18, 2015 at 12:05 PM, Kim Davies <span dir="ltr"><<a href="mailto:kim.davies@icann.org" target="_blank">kim.davies@icann.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
Hi Adam, Hi all,
<div><br>
<div><span class="">
<blockquote type="cite">
<div>On Aug 18, 2015, at 7:32 AM, <a href="mailto:Adam.Smith@cdns.net" target="_blank">
Adam.Smith@cdns.net</a> wrote:</div>
<br>
<div>
<div style="font-family:SourceSansPro-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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. </span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>I don’t agree that is an inherent principle, it is entirely dependent on how the system was built and designed. I can tell you that the current RZMS system does not have any “in-between” states and we have no intention of implementing them.</div>
<div><br>
</div>
<div>As it currently stands, we derive current performance measures by recording timestamps of state changes through the life cycle of a ticket.</div>
<div><br>
</div>
<div>To give a simplified example that perhaps illuminates our approach. Let’s take these hypothetical timestamps that get recorded by our system:</div>
<div><br>
</div>
<div>+0:00:00 — Pending creation</div>
<div>+0:00:00 — Pending technical check</div>
<div>+0:00:05 — Pending contact confirmation</div>
<div>+0:04:32 — Pending IANA review</div>
<div>+0:13:06 — Pending NTIA authorisation</div>
<div>+1:02:15 — Pending Root Zone implementation</div>
<div>+2:06:10 — Pending Root Database implementation</div>
<div>+2:06:12 — Completed</div>
<div><br>
</div>
<div>We would then use these timestamps to deduce the time periods it was in each state for the purposes of identify performance, i.e.</div>
<div><br>
</div>
<div>Pending creation — 0m</div>
<div>Pending technical check (IANA time) — 5m</div>
<div>Pending contact confirmation (customer time) — 4h27m</div>
<div>Pending IANA review (IANA time) — 8h34m</div>
<div>Pending NTIA Authorisation — 14h9m</div>
<div>Pending Root Zone implementation (RZM time) — 1d3h55m</div>
<div>Pending Root Database implementation (IANA time) — 2m</div>
<div><br>
</div>
<div>We could then sum the “owner” of each time period to attribute time based on responsibility:</div>
<div><br>
</div>
<div>IANA time = 0m + 5m + 8h34m + 2m = 8h41m</div>
<div>Customer time = 4h27m</div>
<div>RZM time = 1d3h55m</div>
<div>NTIA time = 14h9m</div>
<div><br>
</div>
<div>That is our current method of doing stats collection. Obviously we need to implement many more states and increase the complexity of the current system to account for all the new measurements in the current draft. However I don’t think the underlying principle
has to change to introduce a way to allow “in-between” states.</div><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
</font></span></div><span class="HOEnZb"><font color="#888888">
kim</font></span></div>
</div>
</blockquote></div><br></div>