Public Comment

Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.

Контент доступен только на следующих языках

  • English

Name: Registries Stakeholder Group (RySG)
Date: 17 Nov 2022
Other Comments

The Registries Stakeholder Group (RySG) appreciates the opportunity to provide comments on the Proposed Amendment to the SLA for the IANA Numbering Services.


Providing feedback on this proposal is challenging because the Proposed Amendment is presented with extraordinarily limited context and background (i.e. only two paragraphs on the Proceedings page).


Key recommendations

While we provide detailed comments below, we provide the following summary and key recommendations for adjustments to the Proposed Amendment:

1. Adjust the SLA for the provisioning API (4.3.2(f)d) to be more reasonable given the interface’s relative operational and economic importance; we suggest 98% as a maximum, the standard for gTLD registries which have ICANN-accredited registrars as clients and considerable economic pressure on the registry-registrar interface;

2. Phase in the requirements for nameserver geographic distribution and diversity so as to not adversely impact the budget and operational load at PTI.


There are further recommendations contained in the list of “Material Items” below and additional points for review in the list of “Minor Items” that follow.


Material items

1. Amendment III: Stringent API SLA for reverse DNS zone maintenance.  We note that the proposed 4.3.2 (f)drequires that the API for RIRs to “automate the changes and updates they need to make to records in the in-addr.arpa and ip6.arpa zones” would have an “API uptime of at least 99.9% excluding scheduled maintenance activity.”    This amounts to approximately 45 minutes of unscheduled downtime per month.  We note that this SLA is more stringent than the 99% SLAs for DNS resolution (4.3.2 (i)) and DNS zone transfer (4.3.2 (h)).   The higher SLA would be expected to introduce greater operational cost and lower operational flexibility for IANA.  Such a high SLA should be justified.  (See Recommendation #1 for an alternate proposal.)

2. There is an inconsistency in the structure of the SLAs for DNS queries (4.3.2(i)) and the API (4.2.3(f)) in which the query SLA has a “best efforts” standard and the API SLA has a “must ensure” standard.  Given the lesser importance of the management API, relative to DNS queries, the API SLA should also have a “best efforts” standard.

3. Regarding a “post mortem report” described in 4.3.2(k), what will be the confidentiality status of such a document?  We do not have a specific recommendation here, other than the confidentiality be determined in advance.



Minor items

-   Amendment II:  Perhaps a lack of definitional clarity in Amendment II, related to the sentences: “The operation of the zones relevant to the reverse resolution process.  This includes… “.  Since the term “reverse resolution process” lacks a referenced definition, the scope of the list of zones in the subsequent sentence (which currently has 4 zones) does not appear to have a strict limit.  That is, there could be ambiguity if other zones are included in this list.


- Amendment II:  Includes the capitalized term “Reverse DNS Distribution Servers” which does not appear in the current SLA document (https://www.nro.net/wp-content/uploads/ICANN-RIR-SLA-signature25May16.pdf). 


- Regarding the requirement described in 4.3.2(c)b to “Have an (sic) heterogeneous configuration across the aggregate”, the standard for “heterogeneous” is not described.  It is implicitly referenced in Amendment V in the context of “undesirable homogeneity”, but without definition.  Given that reasonable technicians can disagree on a topic like this, we recommend that the standard for heterogeneity be memorialized for future reference if a question of contractual compliance arises.


The above recommendations are motivated by the following questions, the answers to which were not readily available in the information provided as part of the Public Comment Proceeding:

- What has been the operating history of the Reverse DNS Resolution Services? That is, have there been prior operational disruptions to the resolution capability that would have breached the described SLAs?  If so, what were these disruptions, what were the impacts, and what was the aftermath?

Note the above recommendations do not include any suggested change to the SLAs for the Reverse DNS Resolution Services.  This is based largely on the assumption that they have been operating nominally within the SLAs described in the document and therefore the proposed SLAs are not expected to be difficult to achieve.


- What is the quantity, frequency, and time-criticality of RIR changes/updates to the in-addr.arpa and ip6.arpa zones?  What is the current performance level of these transactions via the API?

Similarly, the above recommendations do not include any suggested change to the SLA for visibility (4.3.2(j)).  This is based largely on the assumption that IANA would have been operating nominally within the SLAs described in the document and therefore the proposed SLAs are not expected to be difficult to achieve.


- What new work or additional infrastructure will be required of PTI to comfortably achieve the performance and reliability service levels required in the Proposed Amendment?  Is that work budgeted?  How will this work be scheduled so as to not unfavorably impact other PTI projects?


- What new work will be required of PTI in order to monitor and report on the requirements of the Proposed Amendment?  Is that work budgeted?  How will this work be scheduled so as to not unfavorably impact other PTI projects?  For example:

To what extent does the current Reverse DNS Resolution Service:

   Achieve the described functionality?

        Achieve the described performance?

        Achieve the described reliability?

Regarding the software interface:  How many clients are using it, what is the transaction load, and to what extent does the current API:

        Achieve the described functionality?

        Achieve the described performance?

        Achieve the described reliability?

Summary of Submission

The RySG provides the following summary and key recommendations for adjustments to the Proposed Amendment:

1. Adjust the SLA for the provisioning API (4.3.2(f)d) to be more reasonable given the interface’s relative operational and economic importance; we suggest 98% as a maximum, the standard for gTLD registries which have ICANN-accredited registrars as clients and considerable economic pressure on the registry-registrar interface;

2. Phase in the requirements for nameserver geographic distribution and diversity so as to not adversely impact the budget and operational load at PTI.

There are further recommendations contained in the comment’s list of “Material Items” and additional points for review in the list of “Minor Items”.