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

[Sara Dickinson <[e-mail]>]

> On 10 Mar 2022, at 14:25, John Scudder via Datatracker <[e-mail]> wrote:
> 
> John Scudder 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:
> ----------------------------------------------------------------------
> 
> Thanks for this, I found it clear and easy to read. I have just a couple
> comments.

Hi John,

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

> 
> 1. In §5.2, there is
> 
>   Servers MAY defer processing of a query until the STREAM FIN has been
>   indicated on the stream selected by the client.  Servers and clients
>   MAY monitor the number of "dangling" streams for which the expected
>   queries or responses have been received but not the STREAM FIN.
>   Implementations MAY impose a limit on the number of such dangling
>   streams.  If limits are encountered, implementations MAY close the
>   connection.
> 
> Wouldn’t a stream be dangling even if the expected queries and responses hadn’t
> been received? I.e., isn’t the thing that makes a stream “dangling” simply the
> lack of a STREAM FIN?

We’ve updated the text in 5.2 related to dangling streams so please review to see if this clarifies the issue?

> 
> 2. In §5.4,
> 
>                                                      Client and servers
>   that send packets over a connection discarded by their peer MAY
>   receive a stateless reset indication.
> 
> This seems like a misuse of the RFC 2119 MAY. Do you mean "may" or better
> still, "might" or "could"? If you really mean the 2119 keyword, then a rewrite
> seems to be in order to put this in terms of the other party being permitted to
> send the reset.

We’ve changed MAY to might - thanks!

Best regards

Sara.