Hi Éric, On 5/20/26 13:59, Eric Vyncke (evyncke) wrote:
Thanks for the prompt reply and some explanations. I appreciate that you took time to reply to a non-blocking ballot 😉
I would hope that's the normal way of things!
If you are at RIPE-92, then let's shake hand.
Unfortunately, I'm not (was there only at OARC + Monday). Hand shooken virtually!
Else, see below for EV>
Thanks. I understand that no further action is required based on your response; pls yell otherwise. Best, Peter
*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/ <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]
-- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
