Duane, It isn’t so much that I find the report lacking, rather in my mind, it raises the question of whether the goal of RSSAC-001 E.3.6-A to "assure the community that the RSOs take implementation diversity seriously and provide a collective view of implementation choices within the root server system” is realistic/feasible given the current structure of the RSS. In a quick search related to RSSAC-001, I see https://root-servers.org/rssac001/ has had four reports, two by Verisign, one by Netnod and ICANN respectively (maybe there are others not on that site?), posted since RSSAC-001 came out in Dec 2015 (ICANN’s says theirs is a living document, but it doesn’t have a change log so it’s difficult to determine how frequently it has been updated). While having a periodically published aggregated report is likely preferable to (in theory) twelve different reports, (IMHO) none of those reports or the report you just published provides sufficient detail (Netnod’s, explicitly so) to derive any (additional) assurance related to diversity of implementation — in fact, it might raise more questions/concerns than it answers. I suspect I’m aware of (some of) the perhaps intractable challenges in implementation of E.3-6-A. While I appreciate the intent and effort, without information related to (at least) distribution of technology diversity, this feels a bit like a box checking exercise. But perhaps that’s just me. Regards, -drc
On Apr 16, 2025, at 5:16 PM, Wessels, Duane <dwessels@verisign.com> wrote:
Hi David,
Thanks for the feedback.
As you probably know already, technical diversity is something the RSOs have long discussed internally, but this is the first time providing a public report. In going through the process the group discussed the right level of detail to provide and ended up settling on a high-level and simple approach that everyone could agree to for the first report.
I understand from your message that you find it lacking. I am happy to take that feedback to the group as input to the next technical diversity report that comes out.
DW
On Apr 15, 2025, at 11:41 AM, David Conrad <david.conrad@layer9.tech <mailto:david.conrad@layer9.tech>> wrote:
Duane,
Thanks for this. In that document, I note the following:
"Information presented here is a result of that analysis and has been aggregated across all RSOs with no attempt to convey the relative distribution of each technology."
Given this, I’m unsure of the value of this report or how exactly it helps "assure the community that the RSOs take implementation diversity seriously” (from RSSAC-001v2). Without any knowledge of the distribution of the various components mentioned, how is the community to derive any assurance that (to take absurd scenarios) all RSOs but one isn’t running (say) NetBSD, the vast majority of DNS queries aren't handled by (say) Atlas, the majority of all root server traffic isn't routed through (say) CVE-2025-21590 vulnerable JunOS, etc.
Thanks, -drc
On Apr 11, 2025, at 12:17 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
Expectation E.3.6-A of RSSAC001v2 says: The RSOs are expected to collectively publish aggregated implementation diversity reports from time-to-time.
I’m pleased to say that this has been done and you can read the report at https://secure-web.cisco.com/1kF-clvN23gJEwalfliUqIprJYpYKqLxZq4GcS1184XFE6I...
DW
_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> To unsubscribe send an email to rssac-caucus-leave@icann.org <mailto: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://secure-web.cisco.com/1-puFXaQ-M64Mow3LWDf7CwO-bcieZ94Wfgb0Mt_LEKPJuS...) and the website Terms of Service (https://secure-web.cisco.com/1-cMWIU8lt_xBpSjjc7WLocnAkBE8sleNAmtnbh2WpWIKm5...). 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.