[SLE Team] Names SLEs follow-up call (DT-A only) - Meeting Notes (01Aug16)

Nathalie Vergnolle nathalie.vergnolle at icann.org
Mon Aug 1 23:55:27 UTC 2016


Dear members of the Names SLEs work group,

Please see below the meeting notes and chat history from today's DT-A call. The presentation material and AC room recordings are now posted at https://www.icann.org/stewardship-implementation under "Meetings & Work Sessions" section.


*** Meeting Notes ***

Names SLEs Call (DT-A only)
01 August 2016 @ 20:00 UTC

Notes:

*        R1: no objections

*        R2: group proposes 1 business day. The system doesn't support the distinction between business vs calendar days. To be further discussed

*        R3: group agrees to 50 min for all cat

*        R4: no objections

*        R5: no objections

*        R6: no objections

*        R7: IANA now proposes 60 d (100%). Group agrees to 60 d (100%).

*        R9: Cat III - group agreed to align Cat III and IV to 5 min. Cat I stays at 60s.

*        R10: IANA proposal reflects the RZMA. Working group agrees to 72 hrs, suggests it be reconsidered by the CSC after the transition, with a proposal of 24 hr.

*        R11: No objections

*        Accuracy 1: (line item 72) cat II should be 100%, not n/a

*        Accuracy 2: (line item 80) cat II should be 100%, not n/a

*        On-line Services: no objections

Action items:

*        ICANN to update table with today's reviews, and circulate for approval to DT-A.

*        IANA to review R2 & R7 proposals.

Categories:

*        Category I (Routine updates impacting Root Zone File)-Routine change requests that alter the technical data published in the DNS root zone (e.g.changes to NS records, DS records and glue records) . For these changes the process requires IANA, both pre-and post-transition, to engage third parties to implement, publish and distribute changes in the root zone file.

*        Category II (Routine updates not impacting Root Zone File)-Routine change requests that do not alter the DNS root zone file (e.g.contact data and metadata). These changes do not engage third parties as part of implementation, and therefore will have a materially different processing timeframe.

*        Category III (Creating or Transferring a gTLD)-Requests to create ("delegate") or transfer ("redelegate" or "assign") a generic top-level domain. These changes require additional processing by IANA to ensure policy and contractual requirements are met associated with a change of control for the TLD. While the key processing is performed elsewhere within ICANN, the IANA processing is significant and therefore distinguishes this type of request from a routine change request.

*        Category IV (Creating or Transferring a ccTLD)-Requests to create or transfer a country-code top-level domain. These changes require additional processing by IANA to ensure policy requirements are met. This processing is performed by IANA staff, and includes performing additional analysis on the change request, producing a report, and having that report reviewed (including verification that all existing registration data has been successfully transferred from the old to new Registry operator). This processing is significant, and is normally substantially longer than a routine change request, and therefore should be distinguished.

*        Category V (Other change requests)-Other non-routine change requests. IANA is required to process change requests that may have special handling requirements, or require additional documentary evidence or additional clarifications from the customer or third parties, that do not afford them the ability to automate. These scenarios include, but are not necessarily limited to:
i.Customers that require requests to be handled outside the online self-service platform, such as those lodging change requests through the exchange of postal mail;
ii.Customers that have placed special handling instructions on file with IANA, or have otherwise asked for special handling for a request that deviates from the normal process, that must be executed manually by IANA staff;
iii.Unique legal or regulatory encumbrances that must be satisfied that require additional processing;
v.Changes that relate to the operation of the root zone itself, including changing the Root Key Signing Key, altering theset of authoritative name servers for the root zone (i.e. the "root servers"), and changes to the "root hints" file

Chat:
Jay Daley: Jeffrey Eckhaus sends his apologies

Elise Gerich: correct

Elise Gerich: the agreement is between ICANN and Verisign

Trang Nguyen: The RZMA provides for a change control mechanism for ICANN/Verisign to change SLAs.

Jay Daley: agreed

Patricio Poblete: Can R10 be considered part of the SLE for IANA?

Patricio Poblete: or is it for verisign?

Jay Daley: IIRC the report fromKim -  IANA says that 72 hours is only reflective ot current

performance because of deliberately delayed changes.

Jay Daley: Sorry messed up typing

Jay Daley: Kim - IIRC the report from IANA says that 72 hours is only reflective ot current

performance because of deliberately delayed changes

Elise Gerich: Jay - it is difficult to hear you

Elise Gerich: how is this measure noted in the proposal from CWG?

Patricio Poblete: Sorry, I got disconnected briefly. I believe that Accuracy of root zone

information is not applicable for Cat II updates, as they do not impact the root zone, by

definition. But if IANA is OK with 100%, then OK

Elise Gerich: the proposal for different measures for scheduled and unscheduled downtime seems

practical

Jay Daley: Sorry Pal can I go back to availability

Kim Davies: @patricio: there are two categories, root zone file and root zoen database. for root

zone file it is n/a because there are never any in that category, for root zone database it is

100%.

Nathalie Vergnolle: Category I (Routine updates impacting Root Zone File)-Routine change requests

that alter the technical data published in the DNS root zone (e.g.changes to NS records, DS

records and glue records) . For these changes the process requires IANA, both pre-and post-

transition, to engage third parties to implement, publish and distribute changes in the root zone

file.Category II (Routine updates not impacting Root Zone File)-Routine change requests that do

not alter the DNS root zone file (e.g.contact data and metadata). These changes do not engage

third parties as part of implementation, and therefore will have a materially different

processing timeframe.Category III (Creating or Transferring a gTLD)-Requests to create

("delegate") or transfer ("redelegate" or "assign") a generic top-level domain. These changes

require additional processing by IANA to ensure policy and contractual requirements are met

associated with a change of control for the TLD. While the key processing is performed elsewhere

Patricio Poblete: @kim The notes say Accuracy 1 is 100%, not n/a

Elaine Pruis - Donuts: using that thinking, couldn't it be 1 business day then?

Elaine Pruis - Donuts: 36 hours from reciept then.

Elaine Pruis - Donuts: 3 days is too long

Trang Nguyen: With so few of this type of requests, setting a too tight of an SLA is not optimal.

If there's only one request for the month and it happens to come in on a Friday evening, the SLA

would not be met.

David Conrad: this is just submissions by email, right?

Kim Davies: as a practical measure, the vast majority of our customers use our self-service

interface, as evidenced by the fact we received none of these enquiries in the 3.5 month data

collection period

Patricio Poblete: How often are requests submitted by email?

Jay Daley: correct

Jay Daley: I can accept 60d @ 100%

Elise Gerich: thank you, Jay

Kim Davies: the discussion on the last call was regardng the thresholds being set at +3sd for 90%

Kim Davies: we agree +2sd for 90%

Trang Nguyen: Thank you, everyone!

****************

Thanks,
Nathalie.

Direct line: +1-310-578-8957
Mobile: +1-310-938-1037
Skype: nathalie.vergnolle.icann
Jabber: nathalie.vergnolle at jabber.icann.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt1/attachments/20160801/a4b90186/attachment-0001.html>


More information about the dt1 mailing list