Hi Peter, Thanks for the follow-up.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Peter Thomassen <[email protected]> > Envoyé : mardi 14 octobre 2025 17:27 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : DNSOP Working Group <[email protected]> > Objet : Re: [DNSOP] AD Review of draft-ietf-dnsop-cds-consistency > > > Hi Med, > > Thank you very much for your detailed feedback. > > On 10/1/25 17:50, [email protected] wrote: > > Both the issue and proposed approach are well explained. I only > have few minor comments. I sent you a PR with some nits: > https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/pull/5/files> > > Thanks, merged. > [Med] Thanks. > > # Make idnits happy > > > > Please add the following to the abstract: > > > > NEW: > > > > This document updates RFC 7344 and RFC 7477. > > Done (via your PR). [Med] ACK > > > # Background reading > > > > CURRENT: > > > > Readers are expected to be familiar with DNSSEC, including > [RFC4033], > > [RFC4034], [RFC4035], [RFC6781], [RFC7344], [RFC7477], and > [RFC8901]. > > > > (1) This smells like a normative dependency on all these specs, > but there RFC6781 and RFC8901 are provided as informative. > > To fully understand the document (including its justifying > arguments), familiarity with these last two documents is needed, > but they are not normatively relevant for the specification. So I > think the current wording is correct. > [Med] Your explanation falls under "references specify documents that must be read to understand .." part of https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/. However, I re-read the draft and I think that, given how this is used, you can reword as follows: 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. > > (2) Any reason why RFC 9364 is not cited here rather than > pointing to these individual RFCs? > > Yes, because one only needs to be familiar with the aspects of > DNSSEC mentioned above, but for example not with RFC 7646 or RFC > 9276, which both are listed in 9364. That said, I don't feel > strongly at all and will be happy to change it if you prefer. [Med] OK > > > # Restating an existing behavior, not defining a new one > > > > In Section 1: > > > > OLD: > > > > At the same > > time, applying an automated delegation update "MUST NOT > break the > > current delegation" ([RFC7344], Section 4.1), i.e., it MUST > NOT > > hamper availability or validatability of the Child's > resolution. > > > > NEW: > > > > At the same > > time, applying an automated delegation update "MUST NOT > break the > > current delegation" ([RFC7344], Section 4.1), i.e., it must > not > > hamper availability or validatability of the Child's > resolution. > > > > Also, same in Section 3.1 > > > > OLD: > > > > In other words, CDS/CDNSKEY records at the Child zone apex > MUST be > > fetched directly from each (reachable) authoritative server > as > > determined by the delegation's NS record set. > > > > NEW: > > > > In other words, CDS/CDNSKEY records at the Child zone apex > must be > > fetched directly from each (reachable) authoritative server > as > > determined by the delegation's NS record set. > > Agree, and also done (via your PR). > [Med] ACK > Reading this I realize that the case of CDS/CDNSKEY "delete" > signals (RFC 8078 Section 6) is covered ("Specifically, it MUST > NOT delete" in Section 3), but I think it should also be covered > explicitly in Section 3.1. So I've added: > > OLD > Parent, and ensure that each key referenced in any of the > received > answers is also referenced in all other received responses. > > NEW > Parent, and ensure that each key referenced in any of the > received > answers is also referenced in all other received responses, or > that > responses consistently indicate a request for removal of the > entire > DS RRset ([RFC8078], Section 6). > > ... and in the next paragraph (which you quoted above), I changed > at the end: > > OLD > considered inconsistent. > > NEW > considered inconsistent. Similarly, the state MUST be > considered > inconsistent if there is a CDS or CDNSKEY response that > indicates a > removal request for the DS RRset whereas another response > indicates > no change (NODATA) or a DS update. > > This is a no-op clarification, so I'll assume it is fine unless I > hear otherwise. [Med] OK. > > > # Update to RFC 7344 > > > > The spec extends the acceptance rule list, but does not change > any other part of 7344. I suggest to make that explicit: > > > > OLD: > > > > This list is extended with the consistency requirements > defined in > > this document. > > > > NEW: > > > > This list is extended with the consistency requirements > defined in > > this document. This document does not modify any other part > of [RFC7344]. > > Done (via your PR). [Med] ACK > > > # Configuration knobs/Operational Considerations (Section 3) > > > > CURRENT: > > > > A retry schedule with exponential > > back-off is RECOMMENDED (such as after 5, 10, 20, 40, ... > minutes). > > In your PR, you changed this to "e.g., after 5, 10, 20, or 40 > minutes". I accepted the "e.g.,", but disagree with the "or", as > this is an example of a sequence of retries retries with > exponential back-off, and not a list of alternatives of intervals. > > > I guess this should be a configurable parameter. Can say so. > This would be aligned with the similar provisions in the > Operational Considerations of RFC7477. > > All kinds of things can be configurable, and we usually don't say > that, so I'd rather not say it here. However, if you prefer, would > it would for your if we added "(configurable)" before "retry > schedule"? [Med] "s/retry schedule/configurable retry schedule" would be sufficient here. Thanks. > > > Also, > > > > CURRENT: > > > > To accommodate transient inconsistencies (e.g. replication > delays), > > the Parental Agent MAY retry the full process > > > > whether this is retried or not should be controlled using a > knob. Indicating whether the retry is enabled or disabled by > default may be worth to mention. > > I feel the same here about configuration statements as above. > Also, how can it be that it should be done a certain way when it > is MAY? > > However, if you really want this, how about the following: > > 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. > > Idem for this one: > > > > CURRENT: > > > > A schedule with exponential back-off is RECOMMENDED. > > > > I guess the schedule should be a configurable parameter. > > True, although I don't think we need to repeat that here if we say > it above when we first talk about exponential back-off. Do you > think? [Med] The change you made above is sufficient. > > > # 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. 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. > > > # References > > > > Please use the exact titles of these references: > > > > OLD > > > > [LAME1] Akiwate, G., Jonker, M., Sommese, R., Foster, I., > Voelker, > > G. M., Savage, S., Claffy, K., and ACM, > "Unresolved > > Issues", Proceedings of the ACM Internet > Measurement > > Conference, DOI 10.1145/3419394.3423623, 27 > October 2020, > > <https://fra01.safelinks.protection.outlook.com/? > url=http%3A%2F%2Fdx.doi.org%2F10.1145%2F3419394.3423623&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7Ceda8fdc2d81c4380d1d708de0b36 > 2319%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389605242974541 > 30%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=xY%2F40bamh4VL%2BpnxLFTZU5QTJ%2FM%2BYPl%2FUNLsNfEVWbM%3D&re > served=0>. > > > > ACM, "Risky BIZness", Proceedings of the 21st ACM > Internet > > Measurement Conference, DOI > 10.1145/3487552.3487816, 2 > > November 2021, > > <https://fra01.safelinks.protection.outlook.com/? > url=http%3A%2F%2Fdx.doi.org%2F10.1145%2F3487552.3487816&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7Ceda8fdc2d81c4380d1d708de0b36 > 2319%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389605242974693 > 20%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=tzTtoriKW6wY8gWvaXZaElFZYKMO%2BziJULdch7jLiQ4%3D&reserved=0 > >. > > > > NEW: > > > > [LAME1] Akiwate, G., Jonker, M., Sommese, R., Foster, I., > Voelker, > > G. M., Savage, S., Claffy, K., and ACM, > "Unresolved Issues: Prevalence, Persistence, and Perils of Lame > Delegations", Proceedings of the ACM Internet Measurement > > Conference, DOI 10.1145/3419394.3423623, 27 > October 2020, > > <https://fra01.safelinks.protection.outlook.com/? > url=http%3A%2F%2Fdx.doi.org%2F10.1145%2F3419394.3423623&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7Ceda8fdc2d81c4380d1d708de0b36 > 2319%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389605242974854 > 32%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=MWabqDREJEysUJuCe7PH1Zmcj6A7u0a%2BYINAB1XVFp8%3D&reserved=0 > >. > > > > [LAME2] Akiwate, G., Savage, S., Voelker, G. M., Claffy, > K C, and > > ACM, "Risky BIZness: risks derived from registrar > name management", Proceedings of the 21st ACM Internet > > Measurement Conference, DOI > 10.1145/3487552.3487816, 2 > > November 2021, > > <https://fra01.safelinks.protection.outlook.com/? > url=http%3A%2F%2Fdx.doi.org%2F10.1145%2F3487552.3487816&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7Ceda8fdc2d81c4380d1d708de0b36 > 2319%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389605242974997 > 74%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=vTbnYqjXFXLr01Rh7Ymzr%2B6t2GE6qDODGNRKYqh%2BYOU%3D&reserved > =0>. > > Done. [Med] Thanks. > > I'll await your response before I submit a new revision. > Meanwhile, you can look at the combined above changes using this > diff: > https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-dnsop-cds-consistency-08&url_2=https://raw.githubusercontent.com/peterthomassen/draft-ietf-dnsop-cds-consistency/refs/heads/main/draft-ietf-dnsop-cds-consistency-09.txt > > Best, > 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]
