[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