I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Revision reviewed: draft-ietf-dnsop-child-syncronization-01 Summary: Ready with nits. ID Nits: Clean, other than a ref to a newer version of a draft (RFC Ed can deal with this). Checklist stuff: A.1. Operational Considerations This document does describe how deployment will occur (it's basically built in to the document) and the solution is deployable. It appears to scale well from an operational / management perspective. A.1.5.1 - Will the new protocol significantly increase traffic load on existing networks? In a pathological network it could be noticeable - if you had a nameserver with a *very* large number of *very* unpopular names the CSYNC "polls" could be a significant fraction of traffic. This is very very unlikely to occur in the real world - nameservers like this (if they exist) are probably run by registrars ("Get free DNS when you buy a domain!") who would not need this functionality (they manage things in a different manner). They would also have other domains that get significant traffic, so the CSYNC would get lost in the noise anyway... A.1.8 - Are there fault or threshold conditions that should be reported? Yes, kinda. Inability to process a CSYNC record (for any reason) should be reported. It would be nice to be able to signal that to the child, but there is no realistic way to accomplish this (which the document covers). I think that it would be useful for the document to suggest that failures SHOULD be logged (so that the parent can troubleshoot if they want to). A.3: This document includes an Operation Considerations section (Section 4). It is well written and understandable. Q: Does the proposed protocol have a significant operational impact on the Internet? A: Yup, it sure does -- deployment of this solution will significantly lessen delegation mismatches between parent and child. This will improve the stability / correctness of the DNS, and so the Internet at large. Nits: Section 1 - Introduction: Some resource records (RRs) in a parent zone are typically expected to be in-sync [O: in-sync P: in sync] with the source data in the child's zone. This difficulty is frequently from simple operator laziness [O: This difficulty is frequently from simple operator laziness or because of the complexities of... P: These difficulties may stem from operator laziness, as well as from the complexities of...] This specification was not designed to synchronize DNSSEC security records, such as DS RRsets. For a solution to this problem, see the complimentary [O: complimentary P: complementary] solution [I-D.ietf-dnsop-delegation-trust-maintainance], (I do like the fact that the document is complimentary about I-D.ietf-dnsop-delegation-trust-maintainance :-) Section 4: Where [O: where P: Where] errors for CSYNC processing are published Section 2.1.1.2.1: "Specifically: a parental agent must not copy data blindly; An IETF proposed (or higher) standard specification" I think the 'A' in 'An' does not need to be capitalized. Section 3.2.2: "The A and AAAA type flags indicates that the A and AAAA, respectively, address glue records for in-bailiwick NS records within the child zone should be copied into the parent’s delegation information." I found this sentence difficult to parse (even though I know what it was trying to say). I think that just dropping the "respectively" would make it much clearer (and folk won't get confused). Acknowlegement: Olafur is listed as "Olafur Gu[eth]mundsson" - I believe that he'd prefer: Ólafur Guðmundsson if possible else Olafur Gudmundsson. A thank you also goes out to Ed Lewis, who the author held many conversations with [O: who...with P: with whom ...] about the issues surrounding parent/ child relationships and synchronization. More than Nits: Section 3.1: "If the SOA records from the first and last steps have different serial numbers, then the CSYNC record obtained in the second set MUST NOT be processed. The operation MAY be restarted or retried in the future." I think it might be helpful to explain *why* the SOA might change (otherwise it kinda sounds like the processing of the CSYNC record caused the change). Something like: If the SOA records from the first and last steps have different serial numbers (for example, because the zone was edited during the interval between steps 1 and 4), then ..." 6: IANA Considerations: I think that this document is creating an IANA registry, and will probably need a longer bit of text (basically requesting that the IANA creates the registry). Not sure though.