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

[Paul Hoffman <[e-mail]>]

On Aug 15, 2018, at 9:24 AM, Warren Kumari <[e-mail]> wrote:
> ----------------------------------------------------------------------
> 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.

We've now heard this from a bunch of the IETF-wide reviewers. Patrick pointed out earlier that the WG has seen this section as "will be removed" during the later part of the WG process, and that it was not meant to limit future work on DoH. Having said that, making it an appendix with some wording to not limit future work could be nearly harmless. We'll look at that.

> 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.

This was already caught by earlier reviewers. Our working copy now says which cache is being discussed in a more places, including here.

> 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.

Based on an earlier comment, we made it clear that this was about unintentionally serving stale. I agree that "stale" is not really the right word here; RFC 1035 uses "expired", so we can use it here.

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

Yes, definitely.

--Paul Hoffman