IANA Naming Functions: Service Level Agreements
Last updated 2 July 2020
These Service Level Agreements describe the expected level of performance of the IANA Naming Functions, as required by Annex A, Section 2(c) of the IANA Naming Function Contract. Changes to these SLAs are performed using the SLA change process.
Definitions for the fields for the SLAs
Service Level Agreement Change Process
I. Service Level Agreements
Process Category |
Metric |
Threshold |
Type |
Compliance |
Period |
Category I — Routine updates impacting Root Zone File (NS, DS and glue records) |
Submission |
||||
Time for ticket confirmation to be sent to requester following receipt of change request via automated submission interface |
≤ 60 secs |
Max |
95% |
Month |
|
Time for lodgment of change request into RZMS by Contractor on behalf of request sent by email |
≤ 3 days |
Max |
95% |
Month |
|
Technical Checks |
|||||
Time to return results for technical checks following submission of request via automated submission interface |
≤ 50 mins |
Max |
95% |
Month |
|
Time to return results for subsequent performance of technical checks during retesting due to earlier failed tests |
≤ 10 mins |
Max |
95% |
Month |
|
Contact Confirmation |
|||||
Time for authorization contacts to be asked to approve change request after completing previous process phase |
≤ 60 secs |
Max |
95% |
Month |
|
Time for response to be affirmed by Contractor |
≤ 60 secs |
Max |
95% |
Month |
|
Contractor Review and Processing |
|||||
Time to complete all other validations and reviews by Contractor and release request for implementation |
≤ 5 days |
Max |
90% |
Month |
|
Supplemental Technical Checks |
|||||
≤ 10 min |
Max |
95% |
Month |
||
Implementation of Changes |
|||||
Time for root zone changes to be published following completion of validations and reviews by Contractor |
≤ 72 hrs |
Max |
99% |
Month |
|
Time to notify requester of change completion following publication of requested changes |
≤ 60 secs |
Max |
95% |
Month |
|
Category II — Routine updates not impacting Root Zone File (Contact details and metadata) |
Submission |
||||
Time for ticket confirmation to be sent to requester following receipt of change request via automated submission interface |
≤ 60 secs |
Max |
95% |
Month |
|
Time for lodgment of change request into RZMS by Contractor on behalf of request sent by email |
≤ 3 days |
Max |
95% |
Month |
|
Technical Checks |
|||||
Time to return results for technical checks following submission of request via automated submission interface |
No Technical Checks Undertaken |
Not Applicable |
Not Applicable |
Not Applicable |
|
Time to return results for subsequent performance of technical checks during retesting due to earlier failed tests |
No Technical Checks Undertaken |
Not Applicable |
Not Applicable |
Not Applicable |
|
Contact Confirmation |
|||||
Time for authorization contacts to be asked to approve change request after completing previous process phase |
≤ 60 secs |
Max |
95% |
Month |
|
Time for response to be affirmed by Contractor |
≤ 60 secs |
Max |
95% |
Month |
|
Contractor Review and Processing |
|||||
Time to complete all other validations and reviews by Contractor and release request for implementation |
≤ 5 days |
Max |
90% |
Month |
|
Supplemental Technical Checks |
|||||
Time to return results for performance of technical checks during Supplemental |
No Technical Checks Undertaken |
Not Applicable |
Not Applicable |
Not Applicable |
|
Technical Check phase |
|||||
Implementation of Changes |
|||||
Time for root zone changes to be published following completion of validations and reviews by Contractor |
No Technical Checks Undertaken |
Not Applicable |
Not Applicable |
Not Applicable |
|
Time to notify requester of change completion following publication of requested changes |
≤ 60 secs |
Max |
95% |
Month |
|
Category III — Creating or Transferring a gTLD |
Submission |
||||
Time for ticket confirmation to be sent to requester following receipt of change request via automated submission interface |
≤ 60 secs |
Max |
95% |
Month |
|
Time for lodgment of change request into RZMS by Contractor on behalf of request sent by email |
≤ 3 days |
Max |
95% |
Month |
|
Technical Checks |
|||||
Time to return results for technical checks following submission of request via automated submission interface |
≤ 50 mins |
Max |
95% |
Month |
|
Time to return results for subsequent performance of technical checks during retesting due to earlier failed tests |
≤ 10 mins |
Max |
95% |
Month |
|
Contact Confirmation |
|||||
Time for authorization contacts to be asked to approve change request after completing previous process phase |
≤ 60 secs |
Max |
95% |
Month |
|
Time for response to be affirmed by Contractor |
≤ 60 secs |
Max |
95% |
Month |
|
Contractor Review and Processing |
|||||
Time to complete all other validations and reviews by Contractor and release request for implementation |
≤ 10 days |
Max |
90% |
Month |
|
Supplemental Technical Checks |
|||||
Time to return results for performance of technical checks during Supplemental Technical Check phase |
≤ 10 mins |
Max |
95% |
Month |
|
Implementation of Changes |
|||||
Time for root zone changes to be published following completion of validations and reviews by Contractor |
≤ 72 hrs |
Max |
99% |
Month |
|
Time to notify requester of change completion following publication of requested changes |
≤ 60 secs |
Max |
95% |
Month |
|
Category IV — Creating or Transferring a ccTLD |
Submission |
||||
Time for ticket confirmation to be sent to requester following receipt of change request via automated submission interface |
≤ 60 secs |
Max |
95% |
Month |
|
Time for lodgment of change request into RZMS by Contractor on behalf of request sent by email |
≤ 3 days |
Max |
95% |
Month |
|
Technical Checks |
|||||
Time to return results for technical checks following submission of request via automated submission interface |
≤ 50 mins |
Max |
95% |
Month |
|
Time to return results for subsequent performance of technical checks during retesting due to earlier failed tests |
≤ 10 mins |
Max |
95% |
Month |
|
Contact Confirmation |
|||||
Time for authorization contacts to be asked to approve change request after completing previous process phase |
≤ 60 secs |
Max |
95% |
Month |
|
Time for response to be affirmed by Contractor |
≤ 60 secs |
Max |
95% |
Month |
|
Contractor Review and Processing |
|||||
| Time to complete validation and reviews after each submission | ≤ 14 days |
Max |
100% |
Month |
|
Time for third-party review of request (e.g. by ICANN Board of Directors, PTI Board or other relevant verification parties) |
(Where Applicable) ≤ 60 days (subject to review) |
Intentionally Left Blank |
Intentionally Left Blank |
Intentionally Left Blank |
|
Supplemental Technical Checks |
|||||
Time to return results for performance of technical checks during Supplemental Technical Check phase |
≤ 10 mins |
Max |
95% |
Month |
|
Implementation of Changes |
|||||
| Time to complete final delegation or transfer report | ≤ 21 days | Max | 100% | Month | |
Time for root zone changes to be published following completion of validations and reviews by Contractor |
≤ 72 hrs |
Max |
99% |
Month |
|
Time to notify requester of change completion following publication of requested changes |
≤ 60 secs |
Max |
95% |
Month |
|
| Number of interactions or clarifications with customer | N/A | N/A | N/A | Month | |
Category V — Other change requests (i.e. non-routine change requests) |
Submission |
||||
Time for ticket confirmation to be sent to requester following receipt of change request via automated submission interface |
≤ 60 secs |
Max |
95% |
Month |
|
Time for lodgment of change request into RZMS by Contractor on behalf of request sent by email |
≤ 3 days |
Max |
95% |
Month |
|
Technical Checks |
|||||
Time to return results for technical checks following submission of request via automated submission interface |
≤ 50 mins |
Max |
95% |
Month |
|
Time to return results for subsequent performance of technical checks during retesting due to earlier failed tests |
≤ 10 mins |
Max |
95% |
Month |
|
Contact Confirmation |
|||||
Time for authorization contacts to be asked to approve change request after completing previous process phase |
≤ 60 secs |
Max |
95% |
Month |
|
Time for response to be affirmed by Contractor |
≤ 60 secs |
Max |
95% |
Month |
|
Contractor Review and Processing |
|||||
Time to complete all other validations and reviews by Contractor and release request for implementation |
No Validations Undertaken |
Not Applicable |
Not Applicable |
Not Applicable |
|
Supplemental Technical Checks |
|||||
Time to return results for performance of technical checks during Supplemental Technical Check phase |
≤ 10 mins |
Max |
95% |
Month |
|
Implementation of Changes |
|||||
Time for root zone changes to be published following completion of validations and reviews by Contractor |
≤ 72 hrs |
Max |
99% |
Month |
|
Time to notify requester of change completion following publication of requested changes |
≤ 60 secs |
Max |
95% |
Month |
|
| Label Generation Rulesets | |||||
| Validation and Reviews: Time to confirm that a submission is well-formed or send it back for remediation. | ≤ 5 days |
Max | 90% | Month | |
| Implementation: Time from when the request is ready for implementation until the request completion. | ≤ 7 days |
Max | 90% | Month | |
-
Accuracy
Metric
Measurement
Threshold
Type
Compliance
Period
Root zone file data published in the root zone matches that provided in the change request
Accuracy
100%
Min
<100%
Root zone database is correctly updated in accordance with change requests (does not include impact of normalization and other processing standardization - which in any event shall never detrimentally impact the update)
Accuracy
100%
Min
<100%
-
Online Services Availability and Enquiry Processing
Metric
Threshold
Type
Compliance
Period
RZMS availability — availability of an online interactive web service for credentialed customers to submit change requests to their root zone database entries.
≥ 99.0%
Min
< 99%
Month
Website availability — availability of root zone management related documentation (i.e. on http://www.iana.org)
≥ 99.0%
Min
< 99%
Month
Directory service availability — availability of the authoritative database of TLDs
≥ 99.0%
Min
< 99%
Month
Credential recovery — time to dispatch confirmation email of forgotten username or password
≤ 60 secs
Max
95%
Month
Credential change — time to implement new password within the system
≤ 5 min
Max
95%
Month
Dashboard update frequency — average time to update the dashboard to ensure up-to-date reporting
≤ 30 min
Max
100%
Month
Dashboard accuracy — the data presented on the dashboard is accurate
100%
Min
<100%
Month
Dashboard availability — availability of the dashboard online
≥ 99%
Min
<99%
Month
SLE report production — time to produce reports following the conclusion of the reporting period
Monthly
SLE report availability — availability of the SLE reports and associated data online
<10 days after month end
Max
>10 days
Month
SLE report publication — schedule of reporting periods
Monthly
Time to send acknowledge of enquiry — time taken to send initial acknowledgement of receipt of a general enquiry pertaining to root zone management (but not pertaining to interactions in a change request context)
≤ 60 secs
Max
95%
Month
Time to send initial response to enquiry — time taken for staff to respond to enquiry, either in part or in whole
≤ 5 days
Max
90%
Month
II. Definitions for the fields for the SLAs are as follows:
- Process. The business process that Contractor is requested to perform.
- Metric. The individual metric that will be measured as part of the completion of the business process.
- Threshold. The specified target for each individual change request.
- Type. Whether the threshold specified is a minimum target (compliance must not be less than the target) or a maximum target (compliance must not be more than the target).
- Compliance. The percentage that the target goal in aggregate must be met or exceeded within the specified time period for all requests in the specified category.
- Period. The time over which compliance is measured. (The period of collecting measurements to meet the Service Level Agreement (SLA)).