[DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-refuse-any-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am balloting YES, because it is good to have these techniques available, but
I also have some comments that I would like to see addressed or rebutted.

The Shepherd writeup does not say why 1034/1035 are not mentioned in the
Abstract.  Also, the phrase "updates [103x] by" does not appear in the
Introduction, leaving just section 7 to describe the changes.

The document doesn't really make it clear whether the "[t]he operator [...]
might choose not to respond to such queries" is restating an existing
specification from some other document or making a new statement.

Section 1.1

As Mirja notes, draft-ietf-dnsop-terminology-bis is likely to replace 7719
by the time this document's publication process finishes.

Section 2

It seems like the intended takeaway here is that there's a balance or
tradeoff to had between the "good" uses (efficiency of getting all desired
data at once) and "bad" ones (amplification), with mining for zone data
being a "dual-use technology".  The text doesn't really help the reader
reach that conclusion, though -- a few extra words at the start of each
paragraph might help, like the "legitmiately used" in the very first one,
or "On the other hand, ANY queries are frequently abused to [...]" might
help set the intended tone.

Section 4

Should "return a conventional ANY response" be listed or mentioned here?

Section 4.2

   [...] The
   specific value used is hence a familiar balance when choosing TTL for
   any RR in any zone, and be specified according to local policy.

nit: Is there a missing word or three before "be"?

   DATA described in this seection to distinguish between synthesised
   and non-synthesised HINFO RRSets.

nit: "section"

I'm a little surprised to see a "SHOULD NOT" for relying the RDATA 'CPU'
contents of "RFCXXXX" for the final RFC number, since I can't come up with
an other reason why that CPU value would be used.  But I do not object to it.

Section 4.4

Why are we enumerating transports instead of talking about the properties
they provide?  We've got multiple new transports in the works, and it would
be a shame to ignore them out of the gate.