Hi Robert, Thank you for the clear explanation — that makes sense. The connection to the RSSAC026 definition clarifies the reasoning behind the removal. One small follow-up if I may — since the collective coverage logic now flows through the RSSAC026 definition rather than being stated explicitly in RSSAC001 itself, would it be worth adding a brief note in v3 to make that reasoning visible to readers? Someone reading RSSAC001 in isolation might not immediately see how individual RSO compliance under E.3.2-A collectively satisfies the system-level expectation without the cross-reference to RSSAC026. Happy to leave this to the work party's judgment — just wanted to flag it as a potential clarity improvement. Best regards, Mohibul On Wed, Apr 1, 2026 at 11:32 AM Robert Story <rstory@ant.isi.edu> wrote:
On Fri 2026-03-20 04:12:22-0400 Mohibul wrote:
I was going through the v2-to-v3 diff and noticed that E.3.1-B has been removed in v3. In v2, this expectation read:
"The RSOs are collectively expected to deliver the service in conformance to IETF standards and requirements as described in BCP 40."
I wanted to ask about this deletion, as it seems like a substantive change rather than simply an editorial one.
As I understand it, BCP 40 is what ties the RSS (Root Server System) together from a collective protocol compliance standpoint. If E.3.1-B is removed, v3 doesn't seem to have anything that covers this at the system level anymore. E.3.2-A still covers protocol implementation, but that applies to each RSO individually — not to the RSS as a whole.
Hi Mohibul,
This was removed because it redundant. The definition of the RSS in RSSAC 026 is: "The root server system is the set of root servers that collectively implements the root service".
So if E.3.2-A covers each RSO, by definition the RSS is covered.
This seems particularly relevant in light of the recent discussion around draft-ietf-dnsop-3901bis, which is now in the RFC Editor queue. If BCP 40 is updated or complemented by additional BCP guidance over time, the absence of E.3.1-B may leave RSSAC001 without a clear collective point of reference for those developments.
If BCP40 is updated or additional documents with guidance are published, possible new expectations can be considered in the next revision of RSSAC001.
Regards, Robert
USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division