On Mon, Dec 30, 2024 at 7:16 PM Elwyn Davies via Datatracker < nore...@ietf.org> 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.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
