Dear Ken,
Thank you for initiating this thoughtful discussion. The proposed topic, “Interpreting RSS Metrics,” is indeed valuable and timely. I fully agree that there is often misinterpretation in how RSS performance metrics are viewed, particularly when emphasis is placed on latency rather than more critical indicators such as availability and correctness.
I believe a focused work party on this subject could bring great clarity to the DNS community, helping stakeholders better understand and apply RSS metrics in meaningful ways. I would be pleased to contribute to further discussions and to the development of a potential Statement of Work.
Regards
Rolla Hassan
From: Erum Welling via rssac-caucus <rssac-caucus@icann.org>
Sent: Thursday, November 13, 2025 4:24 AM
To: Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) <kenneth.d.renard.ctr@army.mil>
Cc: rssac-caucus@icann.org <rssac-caucus@icann.org>
Subject: [RSSAC Caucus] Re: Potential RSSAC caucus work item: Interpreting RSS Metrics
 
Hi Ken, 

I think the key question you pose is: How can the DNS community use these metrics to their advantage?
Can you please provide greater detail on the audience, are they technical, operational...if not, my fear is that what they don't understand will hurt us...negative perception towards the RSS, and potentially "the sky is falling" syndrome. People will always assume the worst, so we need to tread this one carefully -- understanding the audience and how this information may be potentially used and possibly misconstrued will be key. Just a thought.

Thanks,
Erum

On Wed, Nov 12, 2025 at 9:48 AM 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.