RSSAC001v3 – Question on the Removal of E.3.1-B and BCP 40 Collective Expectation
*Subject :* RSSAC001v3 – Question on the Removal of E.3.1-B and BCP 40 Collective Expectation Hello everyone, 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. 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. So my question is simply: was this intentional, and if so, is there something in v3 that takes its place? I may be missing some context, so please feel free to correct me if I'm overlooking anything. Best regards, Mohibul On Tue, Mar 10, 2026 at 1:12 AM Andrew McConachie via rssac-caucus < rssac-caucus@icann.org> wrote:
Dear RSSAC Caucus Members,
During the RSSAC001v3 call at ICANN 85 a diff document was discussed. This is the document that the RSSAC used to compare RSSAC001v2 and the RSSAC001v3 Working Document. It's attached to this mail as a PDF.
The first page of the document explains more on how it was prepared.
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.
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
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
Hi Mohibul, One thing the work party may wish to discuss is whether the reference to RSSAC026v2 and RFC 9499 in Section 1 of Working Document v1 should be ported over to Working Document v2. If you look at the Diff document that I sent you'll see the reference at the bottom of the Introduction. --Andrew
On 1 Apr 2026, at 17:39, Mohibul Mahmud via rssac-caucus <rssac-caucus@icann.org> wrote:
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 <mailto: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/ [isi.edu] <https://urldefense.com/v3/__http://www.isi.edu/__;!!PtGJab4!99vWBxYzG16Av1K8SWbupAT-aV1CmOzqWH2cqpLsBSzg14m5wWVBR11E9IBSYDk4peK-k6r30Qr1pvRlLGcukXG0hfs1YxM_3ys$>> Networking and Cybersecurity Division
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 Andrew, Thank you for pointing that out. I can see the reference in the Introduction of the diff document: *"Unless otherwise noted, this document uses terminology from RSSAC026v2 and RFC 9499."* This line essentially tells readers which definitions the document relies on. RSSAC026v2 is the RSSAC terminology document that defines key terms like what the Root Server System means as a whole. RFC 9499 is the broader DNS terminology reference from the IETF. Together they form the definitional foundation that the rest of RSSAC001 builds on. This line is present in Working Document v1 — it was added as part of the v1 revision work. However since Working Document v2 starts fresh from RSSAC001v2, and this line was never in RSSAC001v2 to begin with, it did not carry over automatically into v2. This creates a potential confusion. A reader of Working Document v2 would have no indication of which terminology definitions the document relies on. More specifically in the context of the E.3.1-B discussion — without a pointer to RSSAC026v2, a reader would not be able to easily find the RSS definition that Robert referenced to explain why E.3.1-B was removed. They would need to go searching across multiple documents to piece that together. Carrying this line over from v1 into Working Document v2 would solve both issues at once — restoring terminology consistency and making the reasoning behind the E.3.1-B removal traceable for any reader. Best regards, Mohibul On Wed, Apr 1, 2026 at 2:04 PM Andrew McConachie < andrew.mcconachie@icann.org> wrote:
Hi Mohibul,
One thing the work party may wish to discuss is whether the reference to RSSAC026v2 and RFC 9499 in Section 1 of Working Document v1 should be ported over to Working Document v2. If you look at the Diff document that I sent you'll see the reference at the bottom of the Introduction.
--Andrew
On 1 Apr 2026, at 17:39, Mohibul Mahmud via rssac-caucus < rssac-caucus@icann.org> wrote:
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/ [isi.edu] <https://urldefense.com/v3/__http://www.isi.edu/__;!!PtGJab4!99vWBxYzG16Av1K8...>
Networking and Cybersecurity Division
_______________________________________________ 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.
participants (3)
-
Andrew McConachie -
Mohibul Mahmud -
Robert Story