[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 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.