Subject: Re: [RSSAC Caucus] RSSAC001v3 – Tracking IETF/DNSOP Dependencies
Hello everyone,
To make my earlier question more concrete, I wanted to share a few observations from both DNSOP sessions at IETF 124 in Montreal (November 3rd and 7th), which may be relevant to our work on RSSAC001v3.
IETF 124: Domain Name System Operations (DNSOP) 2025-11-03 14:30
From <https://www.youtube.com/watch?v=aDZU8XThpnk>
IETF 124: Domain Name System Operations (DNSOP) 2025-11-07 16:30
From <https://www.youtube.com/watch?v=7eGNuHmvbXA&t=98s>
Several items across the two sessions appear to have bearing on RSO service expectations:
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.
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.
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.
Some of these — particularly the IPv6 mandate if it reaches BCP status — may fall directly within our revision scope. Others, like the post-quantum DNSSEC trajectory, may not require action in v3 but could be worth having visibility into as we work through what stays, what gets updated, and what gets removed from RSSAC001v2.
Best regards,
Mohibul
[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-aWQ8Tda4eZpFbIWrkpfIwKVL642vl5g6Ll7EYktW7nbWHfvv.hMOYXTP0Kh3zPopR?startTime=1772962314000
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.