Go back

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

SLA Archive

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
  1. 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%

  2. 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:

  1. Process. The business process that Contractor is requested to perform.
  2. Metric. The individual metric that will be measured as part of the completion of the business process.
  3. Threshold. The specified target for each individual change request.
  4. 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).
  5. 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.
  6. Period. The time over which compliance is measured. (The period of collecting measurements to meet the Service Level Agreement (SLA)).
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."