Compact Denial of Existence in DNSSEC
draft-ietf-dnsop-compact-denial-of-existence-07

Just a few comments:

        Since NODATA responses are generated for non-existent names

Should this not also say "not covered by a wildcard" ? I guess it depends on whether you consider "non-existent names" to mean "not covered by a wildcard". I think it wouldn't hurt to make this explicit in the text.


        proves the delegation is unsigned by the absense of the DS bit.

The absence is of the DS RRtype, signified by a bit in the Type Bitmaps field. This brings the writing more in line with earlier mentions of the Type Bitmaps content. (also absense -> absence ?)


Last, the Appendix A and B look very similar to what we normally call Implementation Status (RFC 7942). Those sections are usually removed from the document before publication (to avoid them being used sort of as advertisement, and for quickly becoming outdated). I'm a bit on the fence here on whether it would align more with RFC 7942 to remove these from the final document.

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-compact-denial-of-existence-06
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Suzanne Woolf for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request), and I have read Shumon's reply:
https://datatracker.ietf.org/doc/review-ietf-dnsop-compact-denial-of-existence-06-intdir-telechat-fressancourt-2025-02-10/ 

Other thanks to Patrick Mevzek , the DNS directorate reviewer, and I have read Shumon's reply:
https://datatracker.ietf.org/doc/review-ietf-dnsop-compact-denial-of-existence-06-dnsdir-telechat-mevzek-2025-02-02/

I hope that this review helps to improve the document,

Regards,

-éric


## COMMENTS (non-blocking)

### Section 3.5

Please expand `EDE` at first use.

### Section 4

Should there be a normative reference to base32 ?

### Section 5.1

A nice and smart trick ;-)

### Section 6

This section is about the drawback of the proposed system... While the section is clear and the technique appears to work fine in real life, I cannot refrain from wondering what will happen when DNSSEC is more widespread and with HAPPY WG probably requesting first SVCB, then AAAA, and finally A (i.e., 3 RR in a row). 

### Section 8

Section 1 includes  `The use of minimally covering NSEC or NSEC3 records also prevents adversaries from enumerating the entire contents of DNS zones by walking the NSEC chain,`, this is really important in IPv6 world as enumerating DNS is faster than enumerating a /64. I.e., suggest adding this positive consideration in the security section.

### Appendix B

While this appendix helps the reader to assert the feasibility, it lacks references, i.e., how can the authors/WG/IETF assert this statement?