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

[Sara Dickinson <[e-mail]>]

> On 10 Mar 2022, at 04:53, Murray Kucherawy via Datatracker <[e-mail]> wrote:
> 
> 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.

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

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

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


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

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. 

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