Hi, I am sorry for the late reply due to seasonal vacation. I asked my colleague Angela Dall'Ara, Policy Officer at RIPE NCC, to review the document. She participated in the ASO/RSSAC session at the Istanbul ICANN meeting where the document was discussed. Her remarks and thoughts are below. Feel free to incorporate as you see fit. -hph ---------- Forwarded message --------- From: Angela Dall'Ara <adallara@ripe.net> Date: Mon, 6 Jan 2025 at 09:01 Subject: Re: Fwd: [RSSAC Caucus] FOR REVIEW: RSSAC Caucus Guidelines for Changing IP Addresses To: Hans Petter Holen <hph@ripe.net> Hi Hans Petter, Happy New Year to you too! Thank you for sharing the document, I send you here below my comments as I don't think my name is supposed to appear in the google doc. I find the document a clear and exhaustive guideline, I only have a couple of observations: - In the “Preface” : 1) the last sentence of the first paragraph appears to be incomplete: *In this Advisory, the RSSAC ...* 2) the second sentence of the second paragraph is very long and I think it would be clearer if written as a list: *This includes - communicating on matters relating to the operation of the root servers and their multiple instances with the technical and ICANN community, - gathering and articulating requirements to offer to for those engaged in technical revisions of the protocols and best common practices related to the operation of DNS servers, - engaging in ongoing threat assessment and risk analysis of the root server system and recommend any necessary audit activity to assess the current status of root servers and root zone. * - In “2. Definitions”: Service Address mentions RSI, which I assume is Route Server Identifier, but I did not find the acronym in RSSAC026v2 - In “3.1 Selecting a Future Service Address” we read *RSOs are expected to ensure that a future service address does not have a negative reputation in well-known address reputation databases.* I note that RIPE NCC can now allocate via waiting list only returned IPv4 addresses for which routability cannot be guaranteed. It is then up to the RSO to “clean up” the past reputation records. - In “3.4 After Decommissioning the Former Service Address” I would highlight the fact that different operations (transfers, returns,...) are allowed by the different policies accepted by the community and implemented by the different RIRs, I would change the first sentence in the second paragraph to: *The RSO should remain in control of the former service address indefinitely, or for as long as allowed by the policies implemented by the responsible RIR.* - Additionally, it would be handy to provide the link to the referenced documents in the notes, but as I'm not familiar with the format of RSSAC documentation, I don't know if this is usually done. A more detailed explanation of the risks of reusing the addresses previously assigned to route servers would be beneficial if a policy proposal would be submitted for discussion. I’m happy to assist if this is still in the planning. Kind regards, Angela On Thu, 2 Jan 2025 at 16:37, Ray Bellis via rssac-caucus < rssac-caucus@icann.org> wrote:

On 12/12/2024 16:02, Andrew McConachie via rssac-caucus wrote:

...

Dear RSSAC Caucus Members,

Duane, Ray and myself met today to discuss the RSSAC Caucus Guidelines for Changing IP Addresses Work Party.

We are requesting the full RSSAC Caucus review this publication from now until January 8th, 2025.

https://docs.google.com/document/ d/1ad1aaymsaDkBdBfXYPj19_PbNeIVnu6dQ2lb2L4Asso/

The document is mostly stable. We modified the final two sentences of Section 3.4 and marked them as modified text. Otherwise we only merged text from our last call.

We are cancelling next week's meeting on December 19th, 2024. The work party's next call will be on January 9th, 2025. On that call the work party will review comments received in this full Caucus review cycle. Here is a reminder that we're still looking for comments on this document in advance of next Thursday's call.

Ray

_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-- -hph

On Feb 2, 2025, at 06:47, Andrew McConachie via rssac-caucus <rssac-caucus@icann.org> wrote:

Dear RSSAC Caucus Members,

Duane, Ray, Ozan, and myself met on Thursday and merged all outstanding suggestions in the document.

https://docs.google.com/document/d/1ad1aaymsaDkBdBfXYPj19_PbNeIVnu6dQ2lb2L4A...

This starts a week review of this document. Please review it by Sunday February 9th.

If there are no significant suggestions this document will be sent to the RSSAC for a vote and eventual publication.

Sorry for late review. Good document. Minor suggestions (fine to just ignore them as they may not be appropriate or already discussed): - "Root hints data should be retrieved …” It seems to me that it would be useful to add a link to where the source of this data is. That way it becomes clear what we are talking about. (Root hints could I think be interpreted in various ways). - "“root hints” are a set of addresses which can be used by applications”. While it is theoretically possible that a generic/user/ application may have that data, it is essentially in resolvers. Resolvers are “applications” per se, but I think it is a bit misleading for a normal reader that would see “applications” as any application. I understand that the next sentence talks about the resolvers, but the rest of the paragraph is back to “applications”. I wonder if more specific text should be used such as s/application/name resolving application/ or similar. - "RSOs are expected to ensure that a future service address does not have a negative reputation in well-known address reputation databases.”. I understand the idea, but wonder how this is very practical and in fact really useful, as reputation databases are highly dynamic and are based on various heuristics that may lead to false reputation. More over what are the “well-known address reputation databases”: one may identify one where another may identify another. Finally I’m not even sure the community has agreement on what exactly negative reputation means and if the criteria are clear and based on consensus (if yes, then a link could be added as reference to the definition/criteria of reputation). If people really care about saying something like that, then at least make it way less assertive. Ex: s/ensure/review/. s/does not have/is not tainted with/. s/in well-known address reputation databases//. Regards, Marc.

Thanks, Andrew

...

On 12 Dec 2024, at 17:02, Andrew McConachie <andrew.mcconachie@icann.org> wrote:

Dear RSSAC Caucus Members,

Duane, Ray and myself met today to discuss the RSSAC Caucus Guidelines for Changing IP Addresses Work Party.

We are requesting the full RSSAC Caucus review this publication from now until January 8th, 2025.

https://docs.google.com/document/d/1ad1aaymsaDkBdBfXYPj19_PbNeIVnu6dQ2lb2L4A...

The document is mostly stable. We modified the final two sentences of Section 3.4 and marked them as modified text. Otherwise we only merged text from our last call.

We are cancelling next week's meeting on December 19th, 2024. The work party's next call will be on January 9th, 2025. On that call the work party will review comments received in this full Caucus review cycle.

Depending on the comments received between now and January 8th, and the outcome of the call on January 9th, we may have a second full Caucus review. It really depends on how many comments we receive between now and January 9th. Staff will send a reminder on January 2nd, 2025 to remind everyone to review the document in the new year.

Thanks, Andrew

_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

Hi, I sincerely apologize for the delayed review. Below, you will find my comments. While the majority are minor observations, there are a few that I believe may necessitate further elaboration. Feel free to ignore them. Yours, Daniel Introduction The term "root name server" is not specified in the Lexicon RSSAC026, as of the version dated March 12, 2020, nor is it mentioned in RSSAC030. It appears that "root name server" can be considered synonymous with "root server." Additionally, "DNS root sources" is not defined in either RSSAC026 or RSSAC030, except for its inclusion in the title of RSSAC030. This may be an aspect that warrants inclusion in a future revision of RSSAC026. section 1.2 """Parties that need to include up-to-date root hints in their applications have the responsibility to periodically check the DNS root sources for updates and incorporate them as necessary. [3]""" It is somewhat ambiguous to me why RSSAC030 is referenced, as I do not perceive a necessity for updating the root hints in RSSAC30. My interpretation of RSSAC30 indicates that it outlines the existence of the DNS root sources. Furthermore, the statement appears to imply that if an individual requires an updated file, they must ensure its update, which seems somewhat tautological to me. Additionally, it suggests that there may be valid reasons for operating with an outdated hints file; however, while all information may be present, I am uncertain about the need to take this into account. I believe the intention of the text is to convey that RSO should consistently update the root hints. It is my belief that we can articulate this more clearly. """Root hints data should be retrieved over a secure channel or verified with cryptographic signatures. """ It is my belief that the term "root hints" can also be referred to as root hints data. Unless there is a necessity to use an alternative designation, it would be prudent to maintain a consistent terminology. The section could also clarify the relationship between the two mechanisms involved when a root server changes its IP address. Priming, in theory, seems to guarantee that an application receives the most current list of IP addresses, provided that its root hints include at least one valid IP address. This mechanism offers resilience against changes in the IP address of a root server. Conversely, in terms of IP management, this leads to previous IP addresses still receiving traffic. It would be beneficial to articulate the positioning and interrelation of these mechanisms within that section. This explanation would elucidate why outdated IP addresses persist and how changes in IP addresses may not impact applications, thereby resulting in root hints remaining unchanged. section 1.3 """Despite their infrequency, these changes are well-managed and pose minimal risk when proper protocols are followed.""" My reading of the sentence is that infrequency increases the risks, which I do see contradicts that we have protocols to handle such change of IP address. I think the term protocol is ambiguous to me as it is unclear if it designates mechanisms (or protocols) handled by applications to overcome such changes or if it designates the protocol put in place by the RSO to proceed to the change of IP. I understood the later at first, but I think the text is willing to say the first interpretation. This might be good to clarify this. I contend that priming is a mechanism that warrants inclusion in the bullet points and should be explicitly noted. """RSOs are expected to continue responding to queries on former service addresses for at least six months. (See Section 3.3.1).""" Extending the period by an additional six months does not, in my view, mitigate the risk; rather, it merely postpones the issue, unless proactive measures are taken during that timeframe. I believe that this six-month extension allows for the opportunity to update the root hint file. Therefore, I contend that the critical point of this bullet is the delay, which facilitates the applications' capacity to update the necessary root hint file, and this should be emphasized. section 3.1 """If requesting a new allocation for a future service address,""" It seems prudent to consult the RIR even in the absence of a new allocation requirement. Should this not be the case, we can provide an explanation as to why such consultation may not be advisable. I perceive reputation as being associated with spammers or illicit traffic; however, it may also that the IP address has some level of traffic or carries significant risks of attracting traffic. If the IP address is sourced from another root server, it is likely to be acceptable, as the transition would probably be seamless for that specific IP address. Nevertheless, consider an IP that has been utilized to host a widely-used service, which has been frequently accessed by outdated devices. I believe the recommendations should be articulated more clearly, with specific issues highlighted, as the current guidance is rather ambiguous. section 3.2.2 """The future service address should be fully functional prior to the RSO taking any actions in this section.""" It appears that the issue pertains not to the future service address itself, but to the service associated with that future service address. It may not be essential, but the date should be articulated clearly to ensure that individuals in different time zones can unequivocally identify that specific moment. Even when the time zone is indicated, it is advisable to consider the potential impact of daylight saving time on certain days. """Note that schedules and dates may be subject to change. """ This statement conveys at least two key messages: firstly, it is not essential to adhere strictly to the planned schedule. I believe it is important to clarify that deviations from the plan are not anticipated and should only occur under exceptional circumstances. Furthermore, the intended message emphasizes that if such deviations do occur, individuals must be informed through clear communication. In my view, the community should be kept updated regarding both the maintenance and alteration of dates. This necessitates ongoing communication to ensure that everyone is aware of the current situation. I would probably propose to change the following two sentences """Note that schedules and dates may be subject to change. An RSO should keep the community informed when dates change significantly. """ by: """An RSO should ensure that the community remains informed by providing regular updates concerning any planning changes or planned operations.""" """In exceptional circumstances it may be necessary for an RSO to make a change with less than six months advance notice.""" In my opinion, this sentence is not necessary and covered by the first sentence: """An RSO is expected to provide advance notification to the Internet community not less than six months prior to the change of service address.""" I believe this sentence can be removed. section 3. 3 I believe the section should add a community engagement and a sunset IP mechanisms sub section. Section 3.3.1 suggests that services on both the old and new IP addresses should operate concurrently to facilitate the updating of "root hints" by the software. While updating the "root hints" is one approach, it would be beneficial for the RSO to maintain communication with the community during this transition, informing them of the IP address change and confirming that all traffic has been successfully redirected to the new RSOs and address—though this remains a theoretical consideration. The intent of ongoing communication with the community is to reach those who may have overlooked the initial notifications. This aspect appears to be absent from the document and should perhaps be incorporated into a dedicated subsection. Furthermore, it may be prudent to recognize that there is no compelling reason for a client performing priming to necessarily update the root hints, which underscores the importance of community engagement. It is my observation that many systems tend to investigate issues primarily when errors occur. After a period of parallel operation for both services, it may be advisable for the RSO to gradually begin advertising SERVFAIL or another suitable error message. This approach could provide the RSO with the opportunity to alert systems still utilizing the old IP address prior to its complete removal. This suggestion appears to conflict with the current wording of section 3.3.2. It is essential to reference such mechanisms in the document in some capacity. If there is a belief that these mechanisms are detrimental, this should also be clearly stated. section 3.3.1 There exists an architectural concern regarding the continuous use of a specific IP address, even when it is not included in the Root Server System (RSS). It is possible that an application developer has hardcoded all IP addresses from the root hint file to guarantee a response from the RSS. My interpretation of RSSAC 030 and RSSAC 026 indicates that the RSS consists of root server instances linked to a Root Server Operator (RSO) and derived from the DNS root sources. With the implementation of priming mechanisms, the potential for all 13 IP addresses to change may have been deemed an acceptable risk. When a previous IP address responds on behalf of the RSS, despite not being part of it, this can be perceived as an impersonation of the RSS's identity. Consequently, when the application queries the RSS, it receives a response from an identifier that no longer belongs to the RSS and as such by something else than the RSS. The problem could be less important if DNSSEC is being used, but suppose that communication to the root servers uses TLS. Would we expect the authentication to succeed ? I believe this matter warrants attention, and additional efforts should be made to effectively phase out these IP addresses. It does not appear prudent for former instances of the RSS to continue responding as if they were still part of the RSS. section 3.3.4 """The RSO may choose to identify instances responding on former service addresses via alternate NSID or hostname.bind strings. This may not be feasible if the same instance responds on both the former and current service addresses.""" It is peculiar to note that an RSO (the subject of the advisory) might select an option that ultimately becomes unfeasible. Furthermore, the text is somewhat convoluted and, in my view, requires clarification. section 3.4 """Despite application developers’ efforts to maintain up-to-date root hints, and the widespread implementation of priming queries, it is well known that some DNS clients continue to send queries to former service addresses. If the former service address were to change hands, this would present a risk to such clients (See Section 1.3).""" Fundamentally, the issue from the client is that these clients do not use DNSSEC. I think that should be mentioned in the text. It also make the IP address hardly re-usable. I think the text should focus on the goal which is that while traffic remains to be observed, the IP address should not be associated to any service other than the root server system. I am wondering why the such management cannot be implemented by RIRs which remains the entity responsible to manage IP addresses in my opinion. Preface: These remarks do not primarily pertain to the Work Party; rather, they appear to be directed towards the ICANN staff. It is possible that there are English syntax conventions with which I am not familiar, but I am eager to learn. For instance, I would refer to the Root Server System (RSS), yet I am curious if there exists a guideline stipulating whether we should write it as Root Server System (RSS) or root server system (RSS). The term "Advisory" seems unusual to me, as I do not recall it being utilized as a specific term - even though it is mentioned this way in many prefaces. However, I understand that it originates from the Advisory Committee (AC). Regarding the phrase "ICANN community and Board," I find the use of uppercase for "Board" and lowercase for "community" somewhat surprising. Since both terms denote specific entities, it may be more appropriate to capitalize "community" as well. In the instance of "Internet's root server system," I believe we could refer to it as the Root Server System (RSS). On Mon, Feb 3, 2025 at 1:14 PM Wessels, Duane via rssac-caucus < rssac-caucus@icann.org> wrote:

Hi Marc,

My comments are inline below.

...

On Feb 2, 2025, at 6:31 AM, Marc Blanchet via rssac-caucus < rssac-caucus@icann.org> wrote:

...

On Feb 2, 2025, at 06:47, Andrew McConachie via rssac-caucus < rssac-caucus@icann.org> wrote:

Dear RSSAC Caucus Members,

Duane, Ray, Ozan, and myself met on Thursday and merged all outstanding suggestions in the document.

https://secure-web.cisco.com/1xUsEtMLvtrEdXz3xvuTJ_78yFFn1ST8lb7R_727rTA8G-_...

...

This starts a week review of this document. Please review it by Sunday

February 9th.

...

If there are no significant suggestions this document will be sent to

the RSSAC for a vote and eventual publication.

Sorry for late review. Good document. Minor suggestions (fine to just ignore them as they may not be appropriate or already discussed):

Indeed I feel the time for some of these comments is now past as the work party had many meetings where the text around these topics were discussed and debated. This is already the second “last call”. However if other caucus members feel the need to reopen these for discussion please speak up.

...

- "Root hints data should be retrieved …” It seems to me that it would be useful to add a link to where the source of this data is. That way it becomes clear what we are talking about. (Root hints could I think be interpreted in various ways).

As a matter of style the document doesn’t have links in the body text. We do have a footnote just before that which references RSSAC030, which in turn has the URL for the root hints file.

...

- "“root hints” are a set of addresses which can be used by applications”. While it is theoretically possible that a generic/user/ application may have that data, it is essentially in resolvers. Resolvers are “applications” per se, but I think it is a bit misleading for a normal reader that would see “applications” as any application. I understand that the next sentence talks about the resolvers, but the rest of the paragraph is back to “applications”. I wonder if more specific text should be used such as s/application/name resolving application/ or similar.

As someone who contributed text to this section, I can explain why I think applications is appropriate. It is true that root hints are essential for resolvers, those are not the ones I think need to hear this message. I think resolver developers and operating system maintainers are well-aware of the need to maintain up-to-date hints. I want to make sure we also reach developers of other applications who may be less aware of this need. An example that came up within RSSAC itself was the initial implementation of the RSSAC047 metrics, which had hard-coded root server addresses.

...

- "RSOs are expected to ensure that a future service address does not have a negative reputation in well-known address reputation databases.”. I understand the idea, but wonder how this is very practical and in fact really useful, as reputation databases are highly dynamic and are based on various heuristics that may lead to false reputation. More over what are the “well-known address reputation databases”: one may identify one where another may identify another. Finally I’m not even sure the community has agreement on what exactly negative reputation means and if the criteria are clear and based on consensus (if yes, then a link could be added as reference to the definition/criteria of reputation). If people really care about saying something like that, then at least make it way less assertive. Ex: s/ensure/review/. s/does not have/is not tainted with/. s/in well-known address reputation databases//.

As I see it, the point of this text is to inform the reader that address reputation is the RSOs responsibility, and is a part of the process for changing an address. Whether it says “ensure” or “review” matters less (to me at least).

DW

_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-- Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160

Hi, You have the option to disregard the review if you choose. That said, I may not have all the information, but the rationale dismissing the review as late and substantial appears to conflict with the call for review dated February 2, which I was addressing. From that communication, it was my understanding that the deadline was set for February 9, and I submitted my review on February 7. Moving forward, I believe it would be beneficial for the call for review to provide clearer expectations. In this particular instance, it seems no review was anticipated. The February 2 email "FOR REVIEW: RSSAC Caucus Guidelines for Changing IP Addresses" """ Dear RSSAC Caucus Members, Duane, Ray, Ozan, and myself met on Thursday and merged all outstanding suggestions in the document. https://docs.google.com/document/d/1ad1aaymsaDkBdBfXYPj19_PbNeIVnu6dQ2lb2L4A... This starts a week review of this document. Please review it by Sunday February 9th. If there are no significant suggestions this document will be sent to the RSSAC for a vote and eventual publication. """ Yours, Daniel On Fri, Feb 14, 2025 at 5:01 AM Andrew McConachie < andrew.mcconachie@icann.org> wrote:

Dear Daniel,

The work party chairs, staff and the RSSAC Admin committee discussed your suggestions this week. Given how substantial they are and how late they were received, and after the work party had already reached consensus in its scheduled meetings, we have decided to not accept them. Such significant changes are more easily handled in the first review period or at least prior to the last day of the second/final review.

Thanks for your understanding.

Sincerely, Duane, Ray, Andrew and RSSAC Admin Commitee

On 7 Feb 2025, at 19:08, Daniel Migault via rssac-caucus < rssac-caucus@icann.org> wrote:

Hi,

I sincerely apologize for the delayed review. Below, you will find my comments. While the majority are minor observations, there are a few that I believe may necessitate further elaboration. Feel free to ignore them.

Yours, Daniel

Introduction

The term "root name server" is not specified in the Lexicon RSSAC026, as of the version dated March 12, 2020, nor is it mentioned in RSSAC030. It appears that "root name server" can be considered synonymous with "root server." Additionally, "DNS root sources" is not defined in either RSSAC026 or RSSAC030, except for its inclusion in the title of RSSAC030. This may be an aspect that warrants inclusion in a future revision of RSSAC026.

section 1.2

"""Parties that need to include up-to-date root hints in their applications have the responsibility to periodically check the DNS root sources for updates and incorporate them as necessary. [3]"""

It is somewhat ambiguous to me why RSSAC030 is referenced, as I do not perceive a necessity for updating the root hints in RSSAC30. My interpretation of RSSAC30 indicates that it outlines the existence of the DNS root sources. Furthermore, the statement appears to imply that if an individual requires an updated file, they must ensure its update, which seems somewhat tautological to me. Additionally, it suggests that there may be valid reasons for operating with an outdated hints file; however, while all information may be present, I am uncertain about the need to take this into account. I believe the intention of the text is to convey that RSO should consistently update the root hints. It is my belief that we can articulate this more clearly.

"""Root hints data should be retrieved over a secure channel or verified with cryptographic signatures. """

It is my belief that the term "root hints" can also be referred to as root hints data. Unless there is a necessity to use an alternative designation, it would be prudent to maintain a consistent terminology.

The section could also clarify the relationship between the two mechanisms involved when a root server changes its IP address. Priming, in theory, seems to guarantee that an application receives the most current list of IP addresses, provided that its root hints include at least one valid IP address. This mechanism offers resilience against changes in the IP address of a root server. Conversely, in terms of IP management, this leads to previous IP addresses still receiving traffic. It would be beneficial to articulate the positioning and interrelation of these mechanisms within that section. This explanation would elucidate why outdated IP addresses persist and how changes in IP addresses may not impact applications, thereby resulting in root hints remaining unchanged.

section 1.3

"""Despite their infrequency, these changes are well-managed and pose minimal risk when proper protocols are followed."""

My reading of the sentence is that infrequency increases the risks, which I do see contradicts that we have protocols to handle such change of IP address. I think the term protocol is ambiguous to me as it is unclear if it designates mechanisms (or protocols) handled by applications to overcome such changes or if it designates the protocol put in place by the RSO to proceed to the change of IP. I understood the later at first, but I think the text is willing to say the first interpretation. This might be good to clarify this.

I contend that priming is a mechanism that warrants inclusion in the bullet points and should be explicitly noted.

"""RSOs are expected to continue responding to queries on former service addresses for at least six months. (See Section 3.3.1)."""

Extending the period by an additional six months does not, in my view, mitigate the risk; rather, it merely postpones the issue, unless proactive measures are taken during that timeframe. I believe that this six-month extension allows for the opportunity to update the root hint file. Therefore, I contend that the critical point of this bullet is the delay, which facilitates the applications' capacity to update the necessary root hint file, and this should be emphasized.

section 3.1

"""If requesting a new allocation for a future service address,"""

It seems prudent to consult the RIR even in the absence of a new allocation requirement. Should this not be the case, we can provide an explanation as to why such consultation may not be advisable.

I perceive reputation as being associated with spammers or illicit traffic; however, it may also that the IP address has some level of traffic or carries significant risks of attracting traffic. If the IP address is sourced from another root server, it is likely to be acceptable, as the transition would probably be seamless for that specific IP address. Nevertheless, consider an IP that has been utilized to host a widely-used service, which has been frequently accessed by outdated devices. I believe the recommendations should be articulated more clearly, with specific issues highlighted, as the current guidance is rather ambiguous.

section 3.2.2

"""The future service address should be fully functional prior to the RSO taking any actions in this section."""

It appears that the issue pertains not to the future service address itself, but to the service associated with that future service address.

It may not be essential, but the date should be articulated clearly to ensure that individuals in different time zones can unequivocally identify that specific moment. Even when the time zone is indicated, it is advisable to consider the potential impact of daylight saving time on certain days.

"""Note that schedules and dates may be subject to change. """

This statement conveys at least two key messages: firstly, it is not essential to adhere strictly to the planned schedule. I believe it is important to clarify that deviations from the plan are not anticipated and should only occur under exceptional circumstances. Furthermore, the intended message emphasizes that if such deviations do occur, individuals must be informed through clear communication. In my view, the community should be kept updated regarding both the maintenance and alteration of dates. This necessitates ongoing communication to ensure that everyone is aware of the current situation.

I would probably propose to change the following two sentences

"""Note that schedules and dates may be subject to change. An RSO should keep the community informed when dates change significantly. """

by:

"""An RSO should ensure that the community remains informed by providing regular updates concerning any planning changes or planned operations."""

"""In exceptional circumstances it may be necessary for an RSO to make a change with less than six months advance notice."""

In my opinion, this sentence is not necessary and covered by the first sentence: """An RSO is expected to provide advance notification to the Internet community not less than six months prior to the change of service address."""

I believe this sentence can be removed.

section 3. 3

I believe the section should add a community engagement and a sunset IP mechanisms sub section.

Section 3.3.1 suggests that services on both the old and new IP addresses should operate concurrently to facilitate the updating of "root hints" by the software. While updating the "root hints" is one approach, it would be beneficial for the RSO to maintain communication with the community during this transition, informing them of the IP address change and confirming that all traffic has been successfully redirected to the new RSOs and address—though this remains a theoretical consideration. The intent of ongoing communication with the community is to reach those who may have overlooked the initial notifications. This aspect appears to be absent from the document and should perhaps be incorporated into a dedicated subsection.

Furthermore, it may be prudent to recognize that there is no compelling reason for a client performing priming to necessarily update the root hints, which underscores the importance of community engagement.

It is my observation that many systems tend to investigate issues primarily when errors occur. After a period of parallel operation for both services, it may be advisable for the RSO to gradually begin advertising SERVFAIL or another suitable error message. This approach could provide the RSO with the opportunity to alert systems still utilizing the old IP address prior to its complete removal. This suggestion appears to conflict with the current wording of section 3.3.2. It is essential to reference such mechanisms in the document in some capacity. If there is a belief that these mechanisms are detrimental, this should also be clearly stated.

section 3.3.1

There exists an architectural concern regarding the continuous use of a specific IP address, even when it is not included in the Root Server System (RSS). It is possible that an application developer has hardcoded all IP addresses from the root hint file to guarantee a response from the RSS. My interpretation of RSSAC 030 and RSSAC 026 indicates that the RSS consists of root server instances linked to a Root Server Operator (RSO) and derived from the DNS root sources. With the implementation of priming mechanisms, the potential for all 13 IP addresses to change may have been deemed an acceptable risk. When a previous IP address responds on behalf of the RSS, despite not being part of it, this can be perceived as an impersonation of the RSS's identity. Consequently, when the application queries the RSS, it receives a response from an identifier that no longer belongs to the RSS and as such by something else than the RSS.

The problem could be less important if DNSSEC is being used, but suppose that communication to the root servers uses TLS. Would we expect the authentication to succeed ?

I believe this matter warrants attention, and additional efforts should be made to effectively phase out these IP addresses. It does not appear prudent for former instances of the RSS to continue responding as if they were still part of the RSS.

section 3.3.4

"""The RSO may choose to identify instances responding on former service addresses via alternate NSID or hostname.bind strings. This may not be feasible if the same instance responds on both the former and current service addresses."""

It is peculiar to note that an RSO (the subject of the advisory) might select an option that ultimately becomes unfeasible. Furthermore, the text is somewhat convoluted and, in my view, requires clarification.

section 3.4

"""Despite application developers’ efforts to maintain up-to-date root hints, and the widespread implementation of priming queries, it is well known that some DNS clients continue to send queries to former service addresses. If the former service address were to change hands, this would present a risk to such clients (See Section 1.3)."""

Fundamentally, the issue from the client is that these clients do not use DNSSEC. I think that should be mentioned in the text. It also make the IP address hardly re-usable. I think the text should focus on the goal which is that while traffic remains to be observed, the IP address should not be associated to any service other than the root server system. I am wondering why the such management cannot be implemented by RIRs which remains the entity responsible to manage IP addresses in my opinion.

Preface:

These remarks do not primarily pertain to the Work Party; rather, they appear to be directed towards the ICANN staff. It is possible that there are English syntax conventions with which I am not familiar, but I am eager to learn. For instance, I would refer to the Root Server System (RSS), yet I am curious if there exists a guideline stipulating whether we should write it as Root Server System (RSS) or root server system (RSS).

The term "Advisory" seems unusual to me, as I do not recall it being utilized as a specific term - even though it is mentioned this way in many prefaces. However, I understand that it originates from the Advisory Committee (AC).

Regarding the phrase "ICANN community and Board," I find the use of uppercase for "Board" and lowercase for "community" somewhat surprising. Since both terms denote specific entities, it may be more appropriate to capitalize "community" as well.

In the instance of "Internet's root server system," I believe we could refer to it as the Root Server System (RSS).

On Mon, Feb 3, 2025 at 1:14 PM Wessels, Duane via rssac-caucus < rssac-caucus@icann.org> wrote:

...

Hi Marc,

My comments are inline below.

...

On Feb 2, 2025, at 6:31 AM, Marc Blanchet via rssac-caucus < rssac-caucus@icann.org> wrote:

...

On Feb 2, 2025, at 06:47, Andrew McConachie via rssac-caucus < rssac-caucus@icann.org> wrote:

Dear RSSAC Caucus Members,

Duane, Ray, Ozan, and myself met on Thursday and merged all outstanding suggestions in the document.

https://secure-web.cisco.com/1xUsEtMLvtrEdXz3xvuTJ_78yFFn1ST8lb7R_727rTA8G-_... [secure-web.cisco.com] <https://urldefense.com/v3/__https://secure-web.cisco.com/1xUsEtMLvtrEdXz3xvu...>

This starts a week review of this document. Please review it by Sunday February 9th.

If there are no significant suggestions this document will be sent to the RSSAC for a vote and eventual publication.

Sorry for late review. Good document. Minor suggestions (fine to just ignore them as they may not be appropriate or already discussed):

Indeed I feel the time for some of these comments is now past as the work party had many meetings where the text around these topics were discussed and debated. This is already the second “last call”. However if other caucus members feel the need to reopen these for discussion please speak up.

...

- "Root hints data should be retrieved …” It seems to me that it would be useful to add a link to where the source of this data is. That way it becomes clear what we are talking about. (Root hints could I think be interpreted in various ways).

As a matter of style the document doesn’t have links in the body text. We do have a footnote just before that which references RSSAC030, which in turn has the URL for the root hints file.

...

- "“root hints” are a set of addresses which can be used by applications”. While it is theoretically possible that a generic/user/ application may have that data, it is essentially in resolvers. Resolvers are “applications” per se, but I think it is a bit misleading for a normal reader that would see “applications” as any application. I understand that the next sentence talks about the resolvers, but the rest of the paragraph is back to “applications”. I wonder if more specific text should be used such as s/application/name resolving application/ or similar.

As someone who contributed text to this section, I can explain why I think applications is appropriate. It is true that root hints are essential for resolvers, those are not the ones I think need to hear this message. I think resolver developers and operating system maintainers are well-aware of the need to maintain up-to-date hints. I want to make sure we also reach developers of other applications who may be less aware of this need. An example that came up within RSSAC itself was the initial implementation of the RSSAC047 metrics, which had hard-coded root server addresses.

...

- "RSOs are expected to ensure that a future service address does not have a negative reputation in well-known address reputation databases.”. I understand the idea, but wonder how this is very practical and in fact really useful, as reputation databases are highly dynamic and are based on various heuristics that may lead to false reputation. More over what are the “well-known address reputation databases”: one may identify one where another may identify another. Finally I’m not even sure the community has agreement on what exactly negative reputation means and if the criteria are clear and based on consensus (if yes, then a link could be added as reference to the definition/criteria of reputation). If people really care about saying something like that, then at least make it way less assertive. Ex: s/ensure/review/. s/does not have/is not tainted with/. s/in well-known address reputation databases//.

As I see it, the point of this text is to inform the reader that address reputation is the RSOs responsibility, and is a part of the process for changing an address. Whether it says “ensure” or “review” matters less (to me at least).

DW

_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-- Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada

Phone: +1 514-452-2160

_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-- Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160