Re-, The diff looks good to me.
Please proceed with the submission of this version. Thanks Peter. Cheers, Med > -----Message d'origine----- > De : Peter Thomassen <[email protected]> > Envoyé : mercredi 15 octobre 2025 10:46 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : DNSOP Working Group <[email protected]> > Objet : Re: [DNSOP] Re: AD Review of draft-ietf-dnsop-cds- > consistency > > > Hi Med, > > On 10/15/25 07:38, [email protected] wrote: > > NEW: > > Readers are expected to be familiar with DNSSEC, including > [RFC4033], > > [RFC4034], [RFC4035], [RFC7344], and [RFC7477]. Readers may > refer to [RFC6781] > > and [RFC8901] for an overview of DNSSEC operational > practices. > > Done (connect with ", and" instead of repeating "Readers"). > > > [Med] "s/retry schedule/configurable retry schedule" would be > sufficient here. Thanks. > > Done. > > >> OLD > >> To accommodate transient inconsistencies (e.g., > replication > >> delays), > >> the Parental Agent MAY retry the full process, repeating > all > >> queries. > >> A schedule with exponential back-off is RECOMMENDED. > >> > >> NEW > >> To accommodate transient inconsistencies (e.g., > replication > >> delays), > >> implementations MAY be configurable to undertake a retry > the > >> full > >> process, repeating all queries (suggested default: > enabled). > >> A schedule withexponential back-off is RECOMMENDED. > >> > > > > [Med] I like this. Thanks. > > Done. > > >>> # Not an absolute requirement > >>> > >>> OLD: > >>> > >>> Existing requirements for ensuring integrity remain in > >> effect. In > >>> particular, DNSSEC signatures MUST be requested and > >> validated for all > >>> queries unless otherwise noted. > >>> > >>> NEW: > >>> > >>> Existing requirements for ensuring integrity remain in > >> effect. In > >>> particular, DNSSEC signatures SHOULD be requested and > >> validated for all > >>> queries unless otherwise noted. > >> > >> No, it is an absolute requirement for the queries talked about > in > >> this document, which are: > >> > >> - CSYNC: RFC 7477 Section 2 (last paragraph) prescribes > validation > >> > >> - CDS/CDNSKEY: > >> * for updates: RFC 7344 Section 6.2 says "MUST check the > >> publication rules from Section 4.1", which says that these > RRsets > >> "MUST be signed with a key that is represented in both the > current > >> DNSKEY and DS RRsets", so this is a validation requirement > >> * for bootstrapping: RFC 9615 Section 4.2 requires > validation > >> > >> The above quote does not affect any other queries (the first > >> paragraph of that containing section says that these are > >> "requirements that apply equally to CDS/CDNSKEY and CSYNC", not > to > >> anything else). > > > > [Med] .. but we say "unless otherwise noted" in the text, which > is an exception. > > Yes, and in fact it is otherwise noted in the last paragraph of > Section 3.1, which says: > > During initial DS provisioning (DNSSEC bootstrapping), > conventional > DNSSEC validation for CDS/CDNSKEY responses is not (yet) > available; > in this case, authenticated bootstrapping ([RFC9615]) should > be used. > > > As a reminder, 2119 says: > > > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean > that the > > definition is an absolute requirement of the specification. > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there > > may exist valid reasons in particular circumstances to > ignore a > > particular item, but the full implications must be > understood and > > carefully weighed before choosing a different course. > > There are no SHOULD-style valid reasons for implementations to > deviate from the validation requirement. > > I believe the issue is that you're reading > > DNSSEC signatures <MUST be requested and validated for all > queries> unless otherwise noted > > while what's meant is > > DNSSEC signatures MUST be <requested and validated for all > queries unless otherwise noted> > > So the "unless" is not an exception from the MUST; rather, it > qualifies what exactly implementations MUST do. > > Making up another example, this is comparable to "clients MUST use > TLS 1.3 unless not supported by the server", where the "unless" is > not a SHOULD-style exception. "clients SHOULD use TLS 1.3" means > something else. > > I recognize however that the wording apparently is unclear. I'm > not sure how to clarify; do you have a suggestion? > > FYI, the diff page linked in my previous message also contains the > changes confirmed in this message. > > Thanks, > Peter ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
