Thank you for the helpful review, Murray! On 2025-02-23 12:35, Shumon Huque wrote:
On Thu, Feb 20, 2025 at 3:17 AM Murray Kucherawy via Datatracker <nore...@ietf.org <mailto: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 todo 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).
I disagree that this should be "MUST" as that would prevent an authoritative nameserver to respond with a wider namespace than potentially "just" the owner name and the immediate lexicographical successor. This could for instance be desirable in response to a random prefix attack. This with the caveat that there exist no names in the covered namespace. Changing "SHOULD" to "MUST" would prevent an implementer from having that option. For normal operations it is more natural, and simpler, to use the immediate lexicographic successor but it should not be a hard requirement in my opinion.
/Christian _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
