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

Kim Davies kim.davies at icann.org
Tue Aug 18 15:05:58 UTC 2015

Hi Adam, Hi all,

On Aug 18, 2015, at 7:32 AM, Adam.Smith at cdns.net<mailto: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.

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.

As it currently stands, we derive current performance measures by recording timestamps of state changes through the life cycle of a ticket.

To give a simplified example that perhaps illuminates our approach. Let’s take these hypothetical timestamps that get recorded by our system:

+0:00:00 — Pending creation
+0:00:00 — Pending technical check
+0:00:05 — Pending contact confirmation
+0:04:32 — Pending IANA review
+0:13:06 — Pending NTIA authorisation
+1:02:15 — Pending Root Zone implementation
+2:06:10 — Pending Root Database implementation
+2:06:12 — Completed

We would then use these timestamps to deduce the time periods it was in each state for the purposes of identify performance, i.e.

Pending creation — 0m
Pending technical check (IANA time) — 5m
Pending contact confirmation (customer time) — 4h27m
Pending IANA review (IANA time) — 8h34m
Pending NTIA Authorisation — 14h9m
Pending Root Zone implementation (RZM time) — 1d3h55m
Pending Root Database implementation (IANA time) — 2m

We could then sum the “owner” of each time period to attribute time based on responsibility:

IANA time = 0m + 5m + 8h34m + 2m = 8h41m
Customer time = 4h27m
RZM time = 1d3h55m
NTIA time = 14h9m

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.

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

More information about the dt1 mailing list