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

From: Warren Kumari <[email-masked]>
Date: Wed, 15 Aug 2018 09:24:46 -0700

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.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Aug 2018 16:47:15 +0000

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.

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

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

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

Yes, definitely.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 15 Aug 2018 12:54:27 -0400

Woot.

Thanks,
W

On Wed, Aug 15, 2018 at 12:47 PM Paul Hoffman <[email-masked]>
wrote:

> 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.
>
> This was already caught by earlier reviewers. Our working copy now says
> which cache is being discussed in a more places, including here.
>
> 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:

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Thu, 16 Aug 2018 09:14:07 +0200

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

I recommend to use "RFC 8446", too.

Renne