[Doh] Warren Kumari's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT)

[Warren Kumari <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-doh-dns-over-https-13: No Objection

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-doh-dns-over-https/



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

Thank you -- I've been following this work, and so only have a few minor
comments at this point...

Section 3. Protocol Requirements
I really think that this section should remain - it is helpful to people new to
the technology to understand how and why design decisions were made. If you are
not comfortable with it in the body of the document, perhaps it could be made
an Appendix.

Section 5.1.  The HTTP Request
" In order to maximize cache friendliness, DoH clients using media formats that
include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in
every DNS request." While this should be obvious, as this document is talking
about both DNS and HTTP it would be helpful to clarify **which** cache.

Section 6.1.  Cache Interaction
"This requirement helps assure that none of the RRsets contained in a DNS
response are served stale from an HTTP cache." The wording of this feels a
little "clunky", but I don't really have a suggested fix. I also think that it
would be helpful if the "served stale" term could be changed, but this might
just be because I think of draft-ietf-dnsop-serve-stale when I see that.

General:
You *might* want RFC 8446 instead of 5077, 5246, but I'm not sure.