Hi there, authors (and WG), Thank you for this document, I found it clear, useful, and an easy read.
I do have a few comments/nits; addressing these now should help the IETF LC and IESG evaluation go more smoothly. Please SHOUT loudly once you've had a chance to address these, and I'll start IETF LC. Comments / questions: 1: Please be consistent in capitalization of Parent, Child, Registry, Registrar. 2: "Signaling Domains SHOULD be delegated as zones of their own, so that the Signaling Zone's apex coincides with the Signaling Domain (such as _signal.ns1.example.net). While it is permissible for the Signaling Domain to be contained in a Signaling Zone of fewer labels (such as example.net), a zone cut ensures that bootstrapping activities do not require modifications of the zone containing the nameserver hostname." Can you please try and reword this? I'm not entirely sure what "Signaling Domains SHOULD be delegated as zones of their own," actually *means*. I think I sort of do, but I don't think I could fully articulate it — perhaps "standalone zones"? 3: "To keep the size of the Signaling Zones minimal and bulk processing efficient (such as via zone transfers), Child DNS Operators SHOULD remove Signaling Records which are found to have been acted upon." This feels fairly hand-wavey (especially because it has a "SHOULD") — how would that child operators know that the signing records have been processed/consumed? (yes, I know, but it seems like some text it needed). Perhaps just rewording the sentence would help - something like: "Once a Child DNS Operator determines that specific Signaling Records have been processed (e.g by seeing the result in the Parent), they are advised to remove the Signaling Record. This will help keep the Signaling Zone smaller, and bulk processing (such as via zone transfers) more efficient."? Something like that… 4: "It is RECOMMENDED to perform queries within Signaling Domains (Section 4.2) with an (initially) cold resolver cache or to limit the TTL of cached records to the interval between scans, as to retrieve the most current information regardless of TTL." This sentence doesn't really work - it says to "limit the TTL of cached records" so you have the most current information regardless of the TTL. Perhaps just adding "regardless of the original TTL" (or "actual TTL" or something...) 5: "(When a batch job is used to attempt bootstrapping for a large number of delegations, the cache does not need to get cleared in between queries pertaining to different Children.)" Is this always true? I'm not sure, but it feels like there could be cases where there are delegations to domain early on in a run, which you later discover later in a run is also being bootstrapped. E.g you start with example.com and it uses ns1.example.net. Later on you discover than example.net is also bootstrapping, but it is already in the cache…. This might be a really uncommon corner case (and I might be completely wrong about this causing an issue!), but it seems like unless we are 100% sure we should just drop this sentence (and implementers can figure out if the optimization is worth potentially stepping on a rake :-P). I'll happily note that I cannot figure out if my concern is valid, but it *feels* like there is something scary here… Nits: 1: s/involes/involves/ 2: s/For lack of a comprehensive DNS-innate/Due to the lack of a comprehensive DNS-innate/ 3: "The Parent can then use this signal to cryptographically validate the CDS/CDNSKEY records found at an insecure Child zone's apex, and upon success secure the delegation." Suggest: "The Parent can then use this signal to cryptographically validate the CDS/CDNSKEY records found at an insecure Child zone's apex and, upon success, secure the delegation." (I generally avoid noting comma-related nits, but this one triggered my OCD, so…) 4: O: "Other applications might arise in the future, such as publication of API endpoints for third-party interaction with the DNS Operator or of other operational metadata which the DNS Operator likes to publish." P: "Other applications might arise in the future, such as publishing API endpoints for third-party interaction with the DNS Operator or other operational metadata that the DNS Operator likes to publish." C: Flow / readability. 5: "To publish a piece of information about the Child zone" s/a piece of// (I think that this works better, without changing the meaning / intent). 6: "If, however, an error condition occurs, in particular: [many many things] the Parental Agent MUST abort the procedure." This seems somewhat tricky to read / parse — by the time you get down to the "the Parental Agent MUST abort the procedure" bit you've forgotten where the sentence starts. I recommend: "If an error occurs in any of the following steps, the Parental Agent MUST the procedure: Step 1:... " (just a suggestion) 7: This seems a little clumsy: "The Parental Agent does not use in-bailiwick Signaling Names during validation because they cannot have a pre-established chain of trust at bootstrapping time, so are not useful for bootstrapping." Perhaps: "In-bailiwick Signaling Names do not have a pre-established chain of trust at bootstrapping time, and so the Parental Agent cannot use them during validation." ? 8: I had to read this multiple times to figure out what it meant: "For example, when discovering Signaling Names by performing an NSEC walk or zone transfer of a Signaling Zone, the Parental Agent MUST NOT assume that the nameserver(s) under whose Signaling Domain(s) a Signaling Name appears is in fact authoritative for the corresponding Child." Perhaps s/appears is in fact authoritative/appears is, in fact, authoritative/ or, perhaps better yet "appears is actually authoritative…" ? 9: "In this case (and in other cases alike where some list of "bootstrappable domains" is retrieved from elsewhere), the Parental Agent MUST" Perhaps: "In this, and other cases where a list of "bootstrappable domains" is retrieved from elsewhere, the Parental Agent MUST…"? 10: "The protocol is further restricted by the fact that the fully qualified Signaling Names fit within the general limits that apply to DNS names (such as their length and label count)." I found this somewhat confusing — it is "In addition, fully qualified Signaling Names must by valid DNS names (e.g length, label count, etc.)" ? Thank you again; I know that making edits to address nits can be annoying, but we are expecting many people to read and review the document, and so having it polished is important and polite (also, once people start commenting on nits, they seem to continue :-) ) W
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
