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

From: John Scudder via Datatracker <[email-masked]>
Date: Thu, 10 Mar 2022 06:25:50 -0800

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.

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?

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.

---

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

> On 10 Mar 2022, at 14:25, John Scudder via Datatracker <[email-masked]> wrote:
> 

Hi John,

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

> been received? I.e., isn’t the thing that makes a stream “dangling” simply the

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

> seems to be in order to put this in terms of the other party being permitted to

We’ve changed MAY to might - thanks!

Best regards

Sara.

---

From: John Scudder <[email-masked]>
Date: Tue, 22 Mar 2022 13:07:11 +0000

Looks good, thanks.

—John

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

On 10 Mar 2022, at 14:25, John Scudder via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!Wu89gEt6BSBMlrVVVqtPKEgp2gFbSm-kD7hYo_PGJgCh-sP7Sw9WRCqRg5c79Q$
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/__;!!NEt6yMaO-gk!Wu89gEt6BSBMlrVVVqtPKEgp2gFbSm-kD7hYo_PGJgCh-sP7Sw9WRCrpa1JmiQ$

Hi John,

1. In §5.2, there is

2. In §5.4,

Client and servers

Best regards

Sara.