Hi Warren, Thank you for your helpful feedback, pls see below.
On 4/5/24 22:42, Warren Kumari wrote:
Please SHOUT loudly once you've had a chance to address these, and I'll start IETF LC.
SHOUTING! We've included your feedback in the -08 revision that I just submitted. The below essentially is a commented diff.
Comments / questions: 1: Please be consistent in capitalization of Parent, Child, Registry, Registrar.
Yup, Paul Hoffman also mentioned this, and we changed all to lowercase upon his suggestion. It's now included in the new revision.
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 <http://_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 <http://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"?
Done
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…
Done, in the following way: NEW Once a Child DNS Operator determines that specific Signaling Records have been processed (e.g., by seeing the result in the parent zone), they are advised to remove them. This will reduce the size of the Signaling Zone, and facilitate more efficient bulk processing (such as via zone transfers).
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...)
Done NEW In order to ensure timely DNSSEC bootstrapping of insecure domains, stalemate situations due to mismatch of cached records (Step 4 of Section 4.2) need to be avoided. It is thus RECOMMENDED to perform queries into signaling domains with an (initially) cold resolver cache, or to disable caching for them (e.g., by limiting response TTLs to the interval between scans).
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 <http://example.com/> and it uses ns1.example.net <http://ns1.example.net/>. Later on you discover than example.net <http://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…
Good point! Sometimes, less is more. (Done.)
Nits: 1: s/involes/involves/
Done
2: s/For lack of a comprehensive DNS-innate/Due to the lack of a comprehensive DNS-innate/
Done
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…)
Done
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.
I gave it another shot: NEW Other applications might arise in the future, such as publishing operational metadata or auxiliary information which the DNS operator likes to make known (e.g., API endpoints for third-party interaction).
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).
Done
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)
Done NEW However, the parental agent MUST abort the procedure if an error condition occurs, in particular:
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." ?
Done NEW As in-bailiwick signaling names do not have a chain of trust at bootstrapping time, the parental agent does not consider 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…" ?
Done
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…"?
Done NEW Instead, whenever a list of "bootstrappable domains" is obtained other than directly from the parent, 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.)" ?
Done NEW Fully qualified signaling names must by valid DNS names. Label count and length requirements for DNS names imply that the protocol does not work for unusually long child domain names or NS hostnames.
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 :-) )
No worries, actually I like polishing a near final product -- so thanks a bunch! Best, Peter and Nils _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
