On Mon, Dec 30, 2024 at 7:16 PM Elwyn Davies via Datatracker <noreply@xxxxxxxx> wrote:
Document: draft-ietf-dnsop-compact-denial-of-existence-05
Reviewer: Elwyn Davies
Review Date: 2024-12-30
IETF LC End Date: 2024-12-23
IESG Telechat date: Not scheduled for a telechat
Summary: Ready with some minor nits. I am not sufficiently involved in
(secure) DNS to validate the technical proposal, but the draft is clear and
makes good sense to me, Sorrry the review is a little late... Christmas caught
up with me!
Thank you for your review Elwyn ...
I am unsure whether the updates for RFC 4035 in Section 6.2 imply that there is
an erratum applying to RFC 4035: The added text is
.....This concern only
applies to implementations of DNSSEC that employ pre-computed
signatures. There is an exception to this rule for online signing
implementations of DNSSEC (e.g Minimally Covering NSEC, and
Compact Denial of Existence (RFC TBD), where dynamically generated
NSEC records can be produced for owner names that don't exist or
are empty non-terminals.
This update appears to apply retrospectively to the approved version of RFC
4035 as well as if the current RFC is approved. I haven't checked if this is
already covered by an erratum.
In my view, this is not an erratum, which would imply there was an error in
RFC4035. That RFC was focussed on the originally envisioned mode of
DNSSEC, using pre-computed signatures, and did not take into account
online signatures which came later. The "Update" proposed in this draft
relaxes a technical requirement so that it is compatible with Online signing.
Major issues: None
Minor issues: None
Nits/editorial comments:
Globally: s/e.g. /e.g., / and s/i.e. /i.e., /
Ok.
s1, para 1: It might be worth pointing explicitly to RFC 4470 when epsilon
functions are mentioned (OK, RFC 4470 is mentioned on the previous line but for
those not in the know...)
Yes, RFC4470 is mentioned in the same sentence as "epsilon" functions, so I'm not sure any additional elaboration is needed. But if you have any specific clarifying text to propose, please do so.
s1, end of para 1: s/at the name/for the name/ possibly.
I think "at the name" is the more typical usage by DNS protocol engineers.
s7: This section should be marked for removal by the RFC Editor on publication
as it is not future proof.
Yes, I agree. (We did want to preserve some of the historical details somewhere though, so maybe we can move this to the appendix and rename it to "Historical Implementation Notes".)
s10: This section should be redrafted to remove the distinction between done
and to be done items. The notes about what has been pre-allocated should be in
an RFC editor note to be removed on publication.
Ok. I assumed the RFC Editor and IANA would work on updating that section before publication.
Shumon.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
