Peter Thanks for the prompt reply and some explanations. I appreciate that you took time to reply to a non-blocking ballot 😉
If you are at RIPE-92, then let's shake hand. Else, see below for EV> Regards -éric From: Peter Thomassen <[email protected]> Date: Wednesday, 20 May 2026 at 12:41 To: Eric Vyncke (evyncke) <[email protected]>; The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-ds-automation-08: (with COMMENT) 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. EV> I will indeed trust Andy's text > 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. EV> thanks for the explanation, and, BTW, my point was more about removing BCP14 from S 1.* and not to add BCP14 in section 2.* ;-) 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. EV> Andy didn't indeed, I was simply linking this point to the previous one 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). EV> this will be a big improvement For extra context on the BCP status, please see the shepherd write-up. EV> this is the part were we disagree, this set of useful recommendations would better fit an informational RFC. Anyway, this was not blocking. Thanks, Peter
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
