On Thu, Feb 20, 2025 at 3:17 AM Murray Kucherawy via Datatracker <
nore...@ietf.org> wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-dnsop-compact-denial-of-existence-06: Discuss
>
Thank you for your review, Murray.
----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Kudos to Andy Newton (incoming ART AD) for spotting these issues that need
> either discussion or correction:
>
> (1) This document uses BCP 14 keywords without citing BCP 14. It also uses
> some BCP 14 keywords ("recommended") in all-lowercase form, which might be
> worthy of review.
>
This was already taken care of in response to an earlier review from Gunter
Van de Velde.
> (2) Section 3.1 Paragraph 2:
>
> The Next Domain Name field SHOULD be set to the immediate lexicographic
> successor of the QNAME. The Type Bit Maps field MUST only have the bits
> set
> for the following RR Types: RRSIG, NSEC, and NXNAME. (The immediate
> lexicographic successor is the typical case of the "DNS Name Successor"
> defined in [RFC4471]).
>
> The reference to RFC4471 is informative, but this makes it look like it
> should
> be normative. But that would make it a downward reference, since this is
> seeking Proposed Standard status. How does the WG want to handle this?
>
One possible way to deal with this is to delete the reference to 4471. In my
view, the text in the doc was already self explanatory without it.
I'll defer to others more familiar with IETF/RFC process for other possible
recommendations.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Why the "SHOULD" in Section 3.1? What is the impact if I don't do that?
> Why
> might I legitimately choose not to do that? "SHOULD" implies there are
> answers
> to these questions.
>
I guess because epsilon functions in minimally covering NSEC records don't
necessarily need to be precise. However, I see no compelling reason not to
do so in this case, and all known implementations follow what we propose.
So,
I will change this to "MUST" (barring any objections from the working
group).
>
> Some nits:
>
> * Section 1 varies between single and double quotes; is this intentional?
>
Fixed.
>
> * In Section 3.1, s/immedidate/immediate/
>
Fixed.
>
> * Not at all necessary, but I suggest breaking Section 10 into a
> subsection for
> each action.
>
Pondering, but my quick reaction is that this is small enough that it
doesn't need
subsections.
(Updated text is in the github repo, pending publication of next revision).
Shumon.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
