On Sun 2026-03-08 06:13:13-0400 Mohibul wrote:

My understanding from the discussion is that the goal is to keep the scope of this work narrow and focused. The intent is not to rewrite RSSAC001 or make broad editorial changes, but instead to concentrate only on deciding which service expectations should remain, be updated, or be removed. Minor editorial clean‑ups are acceptable, but any material or meaningful changes should be clearly identified, discussed openly, and agreed on by the caucus before moving forward.

Anyone who missed the call and watch the recording (it's only 16 minutes): https://icann.zoom.us/rec/share/I3uN-zh4uuCFed4-aWQ8Tda4eZpFbIWrkpfIwKVL642v... I think your summary is mostly right, except for the minor editorial clean-ups part. Even editorial changes must meet the substancial/material qualification. They also updated the statement of work to specify that the primary audience is the Root Server Operators (RSOs), and directed us to revert back to the original version (RSSAC001v2) and start again. Examples given of acceptable changes were: - E3.1-B removed entirely. 'collective' requirements instead of RSO requirement - E3.2-B adding serving root-servers.net to zones served by RSOs - E3.2-D the acronym RZM was used without expansion - E3.6-A defining a publication period of one year (instead of time to time) All of those were changes but one were to the expectation text itself. The one change to the additional text after an expectation, expanding an acronym, was correcting an oversight. So I think the bar for editorial changes is pretty high. I actually would argue that the RZM change wouldn't qualify, because a RSO would know what RZM meant. So figuring out where the fine line is for editorial changes may be tricky. Regards, Robert USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division

Subject: Quick clarification on expectations vs measurements Hello everyone, Based on the recent work session and follow‑up discussion, I wanted to share a brief clarification to make sure I’m aligned on how measurement and expectations are treated across the RSSAC documents. RSSAC001 (including the v3 work party) remains an expectations document for RSOs, focused on describing good root server service at a high level, rather than defining measurements or enforcement. RSSAC047, as discussed in the metrics session, provides observational measurements to help understand system behavior, but is not a compliance mechanism for RSSAC001. RSSAC002, in turn, defines a common format for publishing raw operational data and does not assess performance. My takeaway was that there was no indication of new or expanded measurement standards being proposed at this time, and that the emphasis remains on keeping RSSAC001 expectation‑focused. Please correct me if I’ve missed any nuance. Best regards, Mohibul On Mon, Mar 9, 2026 at 11:47 PM Wes Hardaker via rssac-caucus < rssac-caucus@icann.org> wrote:

...

I think your summary is mostly right, except for the minor editorial clean-ups part. Even editorial changes must meet the substancial/material qualification.

Thank you Robert, I believe your summary is accurate and captures the points from the meeting.

...

I actually would argue that the RZM change wouldn't qualify, because a RSO would know what RZM meant. So figuring out where the fine line is for editorial changes may be tricky.

I'd consider that a document error, as in general acronyms should always be spelled out. As such I'd say its an error (as opposed to just a clarification), and I'd say it should be included in a future revision. But we can discuss it during a WP meeting of course.

-- Wes Hardaker USC/ISI _______________________________________________ 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] RSSAC001v3 – *Tracking IETF/DNSOP Dependencies* Hello everyone, The clarifications from our recent discussion — particularly the high bar for editorial changes and the focus on RSOs as the primary audience — really helped crystallize the approach for me. Keeping that discipline will be essential to moving the document forward meaningfully without scope creep. On that note, with IETF 125 currently underway in Shenzhen, I wanted to raise a practical question: does the work party have a standing mechanism to track relevant DNSOP discussions that could introduce new BCPs applicable to root server operators? Given our mandate to align v3 expectations with current standards, it seems worth ensuring we have visibility into that work as it develops — even within our narrow scope. Curious whether others have thoughts on how we're handling that dependency. Best regards, Mohibul On Mon, Mar 9, 2026 at 12:33 PM Robert Story via rssac-caucus < rssac-caucus@icann.org> wrote:

On Sun 2026-03-08 06:13:13-0400 Mohibul wrote:

...

My understanding from the discussion is that the goal is to keep the scope of this work narrow and focused. The intent is not to rewrite RSSAC001 or make broad editorial changes, but instead to concentrate only on deciding which service expectations should remain, be updated, or be removed. Minor editorial clean‑ups are acceptable, but any material or meaningful changes should be clearly identified, discussed openly, and agreed on by the caucus before moving forward.

Anyone who missed the call and watch the recording (it's only 16 minutes):

https://icann.zoom.us/rec/share/I3uN-zh4uuCFed4-aWQ8Tda4eZpFbIWrkpfIwKVL642v...

I think your summary is mostly right, except for the minor editorial clean-ups part. Even editorial changes must meet the substancial/material qualification. They also updated the statement of work to specify that the primary audience is the Root Server Operators (RSOs), and directed us to revert back to the original version (RSSAC001v2) and start again.

Examples given of acceptable changes were:

- E3.1-B removed entirely. 'collective' requirements instead of RSO requirement - E3.2-B adding serving root-servers.net to zones served by RSOs - E3.2-D the acronym RZM was used without expansion - E3.6-A defining a publication period of one year (instead of time to time)

All of those were changes but one were to the expectation text itself. The one change to the additional text after an expectation, expanding an acronym, was correcting an oversight.

So I think the bar for editorial changes is pretty high.

I actually would argue that the RZM change wouldn't qualify, because a RSO would know what RZM meant. So figuring out where the fine line is for editorial changes may be tricky.

Regards, Robert

USC Information Sciences Institute <http://www.isi.edu/> 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.

Plenty of us in the Caucus follow the IETF work, and some of us are quite active in that work. Here are my responses to the specific cases you mention:

RFC 3901 bis (IPv6 mandate): The working group is moving toward last call on a draft that would make IPv6 non-optional for authoritative name servers, updating guidance that has been in place since 2004. Should this reach BCP status, it may warrant consideration within the scope of v3 service expectations.

- draft-ietf-dnsop-3901bis is already in the RFC Editor's queue, which means that the technical contents of the draft can be considered final. It is about zones, not about individual authoritative operators for part of the zone. Thus, it is a best current practice that the root zone has some authoritative servers that are available over IPv6, which of course it does. If some RSOs chose not to be available over IPv6, the RSS as a whole would still meet the recommendations in what will become this RFC.

DNSSEC algorithm lifecycle and multiple algorithm rules: Two related presentations addressed the transition of DNSSEC signing algorithms in practice. One point noted in the room is worth highlighting — the root zone context differs from protocols like TLS in that there is no negotiation; signatures are produced in one place and validated everywhere. This has implications for how algorithm transition timelines apply to RSOs specifically.

These drafts affect how IANA signs the root zone. The RSOs simply serve the root zone that IANA produces, so it does not concern RSSAC.

Post-Quantum DNSSEC strategy: A strategy document was presented on transitioning DNSSEC to post-quantum algorithms, with 2030 referenced as a general guidance deadline for post-quantum safety. Given RSOs' direct involvement in root zone signing, this is a development that may be useful to track over time.

Again, RSOs have nothing to do with signing the root zone: they serve the zone as IANA provides them. Further, some of us strongly disagree with the 2030 date as being based on fantasy instead of fact.

Some of these — particularly the IPv6 mandate if it reaches BCP status — may fall directly within our revision scope.

As stated above, I disagree with assertions that how IANA creates the root zone affects any of the RSOs as long as they do what they always have done, which is to serve the root zone as it is given to them by IANA. --Paul Hoffman

Thank you Paul for your detailed assessment of those drafts and clarifying the RSO's role in relation to IANA's output. I wanted to provide a quick update from the IETF 125 DNSOP session of March 16: the ```draft-ietf-dnsop-3901bis``` (IPv6 mandate) has now been confirmed as technically final and is in the RFC Editor's Queue. Source : IETF 125: Domain Name System Operations (DNSOP) 2026-03-16 03:30 https://www.youtube.com/watch?v=w-Bc2LMkVQU While I appreciate that the collective root zone already meets the requirements, the fact that this dependency is now moving from a draft to a near-final BCP status underscores the original question: does the v3 work party have a defined process to formally note and track the status of such IETF dependencies as they reach these final stages? Best regards, Mohibul On Sun, Mar 15, 2026 at 4:07 AM Paul Hoffman <paul.hoffman@icann.org> wrote:

Plenty of us in the Caucus follow the IETF work, and some of us are quite active in that work.

Here are my responses to the specific cases you mention:

...

RFC 3901 bis (IPv6 mandate): The working group is moving toward last call on a draft that would make IPv6 non-optional for authoritative name servers, updating guidance that has been in place since 2004. Should this reach BCP status, it may warrant consideration within the scope of v3 service expectations.

- draft-ietf-dnsop-3901bis is already in the RFC Editor's queue, which means that the technical contents of the draft can be considered final. It is about zones, not about individual authoritative operators for part of the zone. Thus, it is a best current practice that the root zone has some authoritative servers that are available over IPv6, which of course it does. If some RSOs chose not to be available over IPv6, the RSS as a whole would still meet the recommendations in what will become this RFC.

...

DNSSEC algorithm lifecycle and multiple algorithm rules: Two related presentations addressed the transition of DNSSEC signing algorithms in practice. One point noted in the room is worth highlighting — the root zone context differs from protocols like TLS in that there is no negotiation; signatures are produced in one place and validated everywhere. This has implications for how algorithm transition timelines apply to RSOs specifically.

These drafts affect how IANA signs the root zone. The RSOs simply serve the root zone that IANA produces, so it does not concern RSSAC.

...

Post-Quantum DNSSEC strategy: A strategy document was presented on transitioning DNSSEC to post-quantum algorithms, with 2030 referenced as a general guidance deadline for post-quantum safety. Given RSOs' direct involvement in root zone signing, this is a development that may be useful to track over time.

Again, RSOs have nothing to do with signing the root zone: they serve the zone as IANA provides them. Further, some of us strongly disagree with the 2030 date as being based on fantasy instead of fact.

...

Some of these — particularly the IPv6 mandate if it reaches BCP status — may fall directly within our revision scope.

As stated above, I disagree with assertions that how IANA creates the root zone affects any of the RSOs as long as they do what they always have done, which is to serve the root zone as it is given to them by IANA.

--Paul Hoffman

Thank you Wes, that is a helpful reference point. RFC 7720 is a useful anchor. My question was less about whether RSOs are expected to follow DNS development generally, and more about whether the v3 revision process has a defined mechanism for evaluating when IETF developments warrant updates to service expectations — particularly given the high bar for changes the work party has adopted. Looking at the two DNSOP sessions from IETF 124, a few developments seem to touch RFC 7720 territory directly — the IPv6 mandate draft, the DNSSEC algorithm rules discussions, and the post-quantum DNSSEC trajectory, which RFC 7720 does not currently address, at least to my reading. Best regards, Mohibul On Sat, Mar 14, 2026 at 11:03 PM Wes Hardaker <hardaker@isi.edu> wrote:

On that note, with IETF 125 currently underway in Shenzhen, I wanted to

...

raise a practical question: does the work party have a standing mechanism to track relevant DNSOP discussions that could introduce new BCPs applicable to root server operators? Given our mandate to align v3 expectations with current standards, it seems worth ensuring we have visibility into that work as it develops — even within our narrow scope.

Generally, it is expected that RSOs follow DNS development and specifications. The exact requirements of what MUST be followed, technically, are in RFC7720. -- Wes Hardaker USC/ISI