Hi Peter, Thank you for the effort put into this spec.
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. # Make idnits happy Please add the following to the abstract: NEW: This document updates RFC 7344 and RFC 7477. # 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. (2) Any reason why RFC 9364 is not cited here rather than pointing to these individual RFCs? # 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. # 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]. # Configuration knobs/Operational Considerations (Section 3) CURRENT: A retry schedule with exponential back-off is RECOMMENDED (such as after 5, 10, 20, 40, ... minutes). 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. 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. Idem for this one: CURRENT: A schedule with exponential back-off is RECOMMENDED. I guess the schedule should be a configurable parameter. # 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. # 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, <http://dx.doi.org/10.1145/3419394.3423623>. ACM, "Risky BIZness", Proceedings of the 21st ACM Internet Measurement Conference, DOI 10.1145/3487552.3487816, 2 November 2021, <http://dx.doi.org/10.1145/3487552.3487816>. 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, <http://dx.doi.org/10.1145/3419394.3423623>. [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, <http://dx.doi.org/10.1145/3487552.3487816>. Cheers, Med ____________________________________________________________________________________________________________ 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]
