Early Review of draft-ietf-deleg-06
review-ietf-deleg-06-opsdir-early-chown-2026-02-05-00

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