Hi Peter/David, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Peter Thomassen <[email protected]> > Envoyé : mardi 4 novembre 2025 08:41 > À : David Blacka <[email protected]>; [email protected] > Cc : [email protected]; [email protected]; BOUCADAIR Mohamed > INNOV/NET <[email protected]> > Objet : Re: [DNSOP] draft-ietf-dnsop-cds-consistency-09 ietf last > call Dnsdir review > > > Hi David, > > Thanks a lot for your review! > > On 10/23/25 22:50, David Blacka via Datatracker wrote: > > On August 30, 2023, I did an early review of > > draft-ietf-dnsop-cds-consistency-03. > > > > My primary concerns in that review were that the draft should > define > > the "multi-provider" (or whatever) term, or don't mention it at > all; > > the interaction with CSYNC records wasn't fully clear; and, > handling > > non-responsive nameservers wasn't clear. > > > > These have all been addressed. "Multi-provider setup" is > defined > > (along with "multi-signer setup"); use with CSYNC has been made > clear; > > and there is some advice on dealing with non-responsive > nameservers. > > That's good to hear! > > > I have a few minor nits and editorial advice. > > > > In the Abstract: > > > > This document specifies that when performing such queries, > > parent-side entities has to ensure that updates triggered > via > > CDS/CDNSKEY and CSYNC records are consistent across the > child's > > authoritative nameservers, before taking any action based > on > > these records > > > > s/has/have -- The subject of that sentence is "entities", which > is > > plural, so we need "have" instead of "has" here. > > Thank you. As this may be the only change (pending the below > issue), I prefer to take this up with the RFC Editor instead of > going through resubmission and triggering a bunch of notification > emails to various groups. > > > In Section 3: > > > > To accommodate transient inconsistencies (e.g., replication > > delays), implementations MAY be configurable to undertake a > > retry of the full process, repeating all queries (suggested > > default: enabled). A schedule with exponential back-off is > > RECOMMENDED. > > > > I wonder if we should talk about making a configuration or just > talk > > about what we thing the implementations should actually do? > > > > Perhaps: > > > > Implementations SHOULD/MAY retry the full process when > > encountering inconsistencies to account for transient > > inconsistencies (e.g., replication delays.) > > Your proposed text is almost identical to text we had previously, > which was then changed upon a suggestion by Med (see [1] and the > subsequent thread unfolding). > [Med] I have a preference for the CURRENT wording as the intended behavior is more clear (let alone that it exposes to the operator a knob to control the behavior). The suggested MAY for example leave it to the implem how/when to decide to do the retry. > I'll be happy to change the text back if this is where consensus > falls. Perhaps Med (or others) can comment; I've cc'ed him. > > Best, > Peter > > > [1]: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2FMdbnX7ic59kDf5- > eqqJ5uqEI- > bE%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C301f09d4410c > 4f65d96e08de1ba7cd8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > 638978604670826687%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=dxzNo1lEMFPFypdCRWAkQQ0HGC1kdcV5%2BfBO19eSU > VM%3D&reserved=0 and search for "whether this is retried or not > should be controlled using a knob" ____________________________________________________________________________________________________________ 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]
