Reviewer: Scott Rose Review result: Ready with Issues Review of dnssec-bootstrapping
The draft is likely OK to proceed as there are only a few nits that do not change the overall contents. I am confused about if it adds to methods in RFC 8078 or replaces methods in RFC 8078. 1. Abstract: The Abstract says that this draft deprecates the DS enrollment methods in RFC 8078, which implies this draft will replace that text. However the Security Considerations section implies that this draft only adds a new method and removes none of the existing ones (possible just phrasing issue?). If this draft intends to only add a new secure method, the abstract could be changed to say “This document adds the new DS enrollment method to the list of methods described in Section 3 of [RFC8078].” If this is to replace the CDS/CDNSKEY based methods in RFC 8078, then perhaps the first sentence in the Security Considerations section should be updated to say “This draft document replaces the methods described in RFC 8078 Section 3 with a method that adds authentication. Its security level is therefore…” To make it explicit that this draft replaces that section rather than just add another method while retaining the methods previously described in RFC 8078. That is the only potentially confusing issue. The rest are nits: 2. Section 1.1 Terminology: “Parent” and “Child” are defined the same way in the most recent version of the DNS Terminology RFC 8499, so a reference could be used instead of repeating the definition. Also, “Signaling Name” sounds confusing compared to the Signaling Domain. Would it be easier to write it as: “Signaling Name The owner name of comprised of a prefix, the Child zone name and the Signaling domain name. Used by the Parental Agent to identify and retrieve the Signaling Type used by the Child zone (See Section 2.2). “ To stress it is a name in the Signaling Domain, but contains the child zone name. 3. Section 2.1 Strictly speaking, would the Signaling Zone really need a secure delegation? I could even be an island but the Parental Agent has the Signaling Zone’s SEP key (KSK or ZSK) as an installed trust anchor. If the Parental Agent really only needs to be able to validate RRSIGs in the Signaling Zone, the zone doesn’t necessarily need to have a secure delegation, as it is up to the Parental Agent to validate signatures. Not saying that is easier (it has other problems), just possible so the MUST may be unnecessarily strict. 4. Section 4.2 Parental Agent: Last sentence in paragraph ends “…the cache does not need to get cleared in between.)”. Might be expanded to “…cache does not need be be cleared in between queries to unique Child Zone names.)” for clarity. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
