Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. 

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.

- Document: draft-ietf-deleg-06

- Reviewer: Tim Chown

Note the preference from Brian was for reviewers with implementation experience, which I don't have. I've read the draft as someone familiar with DNS and DNS delegation operationally.

- Review Date: 5 Feb 2026

- Intended Status: Standards Track 

## Summary 

The draft defines a new, extensible method for DNS delegation for a domain using DELEG and DELEGI records.

I consider the document to generally be Ready - the direction and general principles and detail seem good - but with Minor Issues / Nits

## General Operational Comments Alignment with RFC 5706bis 

The draft is well written, given its nature, and gives a clear rationale for its need. 

I like the approach taken. It's clean, and is incrementally deployable, with clear 'guards' specified in the text, e.g., against fallback from DELEG to NS for DELEG-aware resolvers.  The signalling method for capability seems reasonable.

I was a little surprised that two of the main benefits of this new approach are not defined in the document, and remain future work, specifically the extensibility (the Metadata keys of 4.1.6) and the use of alternative ports / protocols (as stated in 4.1.5). I don't see that as a reason to hold this draft up, but I would be interested to see more of what's (likely to be) coming in those areas.

The addition of examples is appreciated. 

## Major Issues 

...

## Minor Issues 

There are a few "TODO" sections which I presume are, well, to be done. SOme are just more examples, other seem more important, especially in the Security section.

The order to try servers in a final SLIST, mentioned at the end of 4.1.7, is stated as out of scope. I smell Happy Eyeballs overlap here?

In 4.2.1.1 - "Include the" - do you mean SHOULD or MUST here?  Looks like some words missing.

There's a fair bit of security text in (say) 4.3 (downgrade attacks) and 4.4.3 (referral downgrade protection) - should this be  a pointer to section 5.2 rather than being in two places?

Might be nice to say a bit more about relationship with SVCB, given the stated code reuse.

## Nits 

Section 1.1 - "addition terms" -> "additional terms"

Maybe add a diagram to emphasise the delegation demarcation difference?

The "because of bugs" in 6.1 is a tad worrying.

Tim