Subject: [DNSOP] Re: Éric Vyncke's No Objection on draft-ietf-dnsop-ds-automation-08: (with COMMENT)
From: Peter Thomassen <[email-masked]>
To: Éric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 20 May 2026 13:40:54 +0200
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>

Hi Éric,

Thank you for your review!

On 5/20/26 09:18, Éric Vyncke via Datatracker wrote:
> ## COMMENTS (non-blocking)
> 
> ### Andy's DISCUSS
> 
> I second Andy Newton's DISCUSS point about the use of `SHOULD` vs. `MUST`. The
> sentence in section 3 is not enough IMHO `However, not following any
> requirements designated with the "SHOULD" key word will generally lead to
> undesirable effects of ambiguity and interoperability issues.`

Andy has proposed improved wording: https://mailarchive.ietf.org/arch/msg/dnsop/X2bmBcl8Bx6sBRts8fc_U5mKxdE/ Unless I hear back, I'll assume you're OK with that.

> The use of BCP14 is also questionable as it is not really about interoperation.
> E.g., section 4.2.2 contains `The reduction should be in effect at least for a
> couple of days` still providing guidance to the operators without the use of
> BCP14. Same for section 5.2, which has no BCP14 and still useful.

The reason for this is as follows: Sections *.1 are the recommendations sections and sections *.2 contain analysis and rationale. Sections *.1 are compiled verbatim into Appendix A so you can find all the recommendations relevant for DS automation interoperability by just look at the Appendix, as a handy implementation reference.

The recommendations sections therefore contain the distilled core of the recommendations. The particular case you quote ("The reduction should be in effect at least for a couple of days") is a very qualitative statement, and in my view not an interoperability statement that would really add to what the corresponding recommendation 4.1.2 says; it rather provides additional context.

In case this doesn't clarify the issue, feel free to re-raise and we can see together what to do about it.

> See also next issue.
> 
> ### BCP status
> 
> Linked to Andy's DISCUSS, whether this document is BCP or 'informational' is
> also another question. Some BCP-like RFC (e.g., RFC 9099) are informational and
> do not rely on BCP14, only plain English "should".

I don't see Andy raising a question about the document status.

Roman was concerned; we've attempted to address that (pending his feedback) by ensuring that defining recommendations are MUST, not SHOULD (which indeed was an error).

For extra context on the BCP status, please see the shepherd write-up.

Thanks,
Peter