+1

I am in favor of the proposed work item. I recall suggesting a highly similar work item in a previous RSSAC annual survey, titled “Operationalizing RSSAC metrics,” where I outlined the motivations and specific goals in high-level terms.

Dessalegn

On Wed, Nov 12, 2025 at 3:48 PM Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:

I want to spark discussion among the RSSAC caucus regarding a potential work item introduced at recent caucus meetings.  If there is enough interest in the topic, we could pursue a Statement of Work (SoW) to propose such a work item to the RSSAC.

                        

"Interpreting RSS Metrics"                                               

      

There are many open measurements of the Root Server System (RSS) which can be used to monitor and assess RSS performance.  Interpretation of these measurements can sometimes be misleading.

1. Studies often focus on latency, which is a relatively unimportant metric (considering the number of queries actually made to the RSS).  Availability and correctness seem to be more important with respect to the RSS.
2. Another focus is on the number and geographic distribution of the root server instances.  While this distribution can be important, there are often other considerations (such as peering/routing) that can have bigger impacts.
3. Connectivity or platform errors in the measurement system can affect results which are sometimes tough to account for.
4. Are there other metrics that could help inform a [resolver operator, network engineer, <who else>] ?

        

What do caucus members think of a work party on "Interpreting RSS Metrics" (working title, open to discussion)?  The purpose is to inform the DNS community on how to best interpret and use RSS metrics (again, open to discussion).  How can we refine the topics listed above?  What other topics/measurements would be good to include?  How can the DNS community use these metrics to their advantage?  How do we keep a potential work party from getting too deep into problem solving (for example: trying to fix peering issues)?  

-Ken

_______________________________________________
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.

_______________________________________________
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.