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