Hi Éric, Thank you for your comments. Associated changes will be included in revision -10, and can be previewed at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/16/commits/1111e7bece2158440c5ed5b221fd8a312ac8f171.
On 5/16/24 15:52, Éric Vyncke via Datatracker wrote:
# COMMENTS (non-blocking) I am sympathetic to Paul Wouter's comments about 'bailiwick' and the use of "_signal". The latter is probably to late to be changed.
This has been "arbitrated" by Warren, see https://mailarchive.ietf.org/arch/msg/dnsop/ju-pAWR-QD6BvqDU7qMjIsgBdPA/.
## Section 2 Two normative "SHOULD" but no reason/suggestion on when the SHOULD can be bypassed.
This paragraph will be reworked as a result of yesterday's telechat.
## Section 4.1.1 "example.co.uk" is not a IANA/IETF reserved domain name. Suggest to use an actual reserved domain name.
The example is trying to illustrate that bootstrapping is not limited to 2nd-level domains, but also applies elsewhere in the tree. We could use subdomain.example.com, but that's confusing because "example.com" is not commonly considered a registry (unlike "co.uk"). Other options would be "child.under.example" and things like that. The example would then have to names like _dsboot.child.under.example._signal.ns1.example.net, parsing of which requires more thinking and is thus less instructive. The authors therefore prefer to keep this example as is, assuming that there's no requirement to use a reserved name. (If there is, apologies for the ignorance, and we'll fix it!)
Suggest to also add the RR type in the example.
added "as CDS/CDNSKEY RRsets"
Perhaps explain `Publication of signaling records under the in-bailiwick domain _signal.ns3.example.co.uk is not required`.
It's explained in the beginning of the section. As others felt the draft is "more verbose and repetitive than it needs to be", we'd rather not add to that :-)
## Section 7 Like Erik Kline, I wonder whether the IANA considerations should include a request for _dsboot. The use of _dsboot is only briefly mentioned in section 1.1, which is rather weak for a proposed standard document (I was close to open a DISCUSS on this topic).
The authors are not sure under which conditions such registries should or should not be erected, and thus can't contribute to this discussion. Any guidance / opinions from others would be appreciated. (FWIW, it is the authors' impression that adding such a registry seems to add about 2 pages of text, while its added value may be limited at this time. That may change once other prefixes get specified, and one might want to consider erecting a registry at such a later time. Other considerations can be found at https://mailarchive.ietf.org/arch/msg/dnsop/PSmBgLTZDB-j8fA_9n4B4WWdLDc/.) Best, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
