[DNSOP] AD Review of: draft-ietf-dnsop-dnssec-bootstrapping

[Warren Kumari <[e-mail]>]

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