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

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Wed, 09 Mar 2022 03:35:37 -0800

Zaheduzzaman Sarker 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 a lot for working on this specification. Thanks to Brian Trammell  for
the TSVART review.

I have following comments and I think addressing them will improve this
documentation-

   * Section 5.3.3 - should also list the protocol error case related to 
   session resumption and 0-RTT, and put a reference to section 5.5 for further
   details.

   * Section 5.2 says -

     "Implementations MAY impose a limit on the number of such dangling
     streams. If limits are encountered, implementations MAY close the
     connection."

     However, I have  not notices any indication  of how this limits can be
     set. I would be great if we can say how the implementer can enforce the
     normative "MAY".

---

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

> On 9 Mar 2022, at 11:35, Zaheduzzaman Sarker 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.

>   session resumption and 0-RTT, and put a reference to section 5.5 for further

We’ve added a bullet point:
“   *  receiving a "replayable" transaction in O-RTT data (for servers
         not willing to handle this case - see section Section 5.5)”
 
>     set. I would be great if we can say how the implementer can enforce the

We’ve updated the text in section 5.2 based on other comments we have to more clearly specify when streams are ’dangling' so please review.

Best regards

Sara.

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Tue, 22 Mar 2022 10:47:22 +0000

Thanks for addressing my comments. I have checked -11 version and it looks good to me for my comments.

//Zahed

> On 22 Mar 2022, at 10:38, Sara Dickinson <[email-masked]> wrote:
> 
> 
>