Subject: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-dnsoquic-10: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 09 Mar 2022 20:53:43 -0800

Murray Kucherawy has entered the following ballot position for
draft-ietf-dprive-dnsoquic-10: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

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

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

Now THAT is a well done shepherd writeup.

Thanks for this work, which was an interesting read.  It's great to see this so
quickly on the heels of QUIC itself.

Just a couple of BCP 14 things to point out.  In Section 5.4, we have this:

   Clients SHOULD monitor the idle time incurred on their connection to
   the server, defined by the time spent since the last packet from the
   server has been received.  When a client prepares to send a new DNS
   query to the server, it will check whether the idle time is
   sufficiently lower than the idle timer.  If it is, the client will
   send the DNS query over the existing connection.  If not, the client
   will establish a new connection and send the query over that
   connection.

There's a blanket SHOULD, followed by two "will"s.  I read those as normative
requirements, even though they don't use BCP 14 language.  But that means they
conflict with the SHOULD.  IMHO, this needs to be resolved.

In Section 5.5:

   Clients SHOULD consider potential privacy issues associated with
   session resumption before deciding to use this mechanism.  [...]

I find "SHOULD consider" to be far too vague for this to be meaningful.  If
I've thought about it, have I met my burden here?

Thank you for including Section 7.

And now, some nits.

Abstract:

* "... similar properties to that provided by ..." -- s/that/those/

Section 1:

* "DNS over QUIC is referred here as ..." -- s/referred/referenced/ or
s/referred/referred to/

Section 5.2:

* The second-last paragraph is missing a closing parenthesis.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 22 Mar 2022 09:40:52 +0000

> On 10 Mar 2022, at 04:53, Murray Kucherawy via Datatracker <[email-masked]> wrote:
> 

Many thanks for the comments - please see the updates in version -11 which was just published, which we hope address your comments.

> conflict with the SHOULD.  IMHO, this needs to be resolved.

Agreed - we’ve updated the following ‘wills' to SHOULDs.

> I've thought about it, have I met my burden here?

There are several things to evaluate here - we’ve updated this text to:
“Clients SHOULD consider
 potential privacy issues associated with session resumption before deciding to use
 this mechanism and specifically evaluate the trade-offs presented in the various sections of this document. The privacy issues are detailed…"

Does that address your concern or can you suggest text?

All nits fixed - thanks!

Sara.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 Mar 2022 09:51:28 -0700

Hi Sara,

On Tue, Mar 22, 2022 at 2:40 AM Sara Dickinson <[email-masked]> wrote:

>  this mechanism and specifically evaluate the trade-offs presented in the
> various sections of this document. The privacy issues are detailed…"
>

I'd be fine with either the original or proposed text if you make it a
lowercase "should".

I guess for me this comes down to: Why is this a "SHOULD" and not a
"should"?  What specific normative obligation are you imposing with this
sentence that affects interoperability of the protocol?

If after considering potential privacy issues, it's really the case that
there are specific protocol things I need to do, then I would enumerate
those explicitly and make them SHOULDs.  But a general "You SHOULD think
about this" doesn't feel to me like correct use of BCP 14 keywords.

-MSK