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

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Wed, 09 Mar 2022 15:11:39 -0800

Francesca Palombini 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:
----------------------------------------------------------------------

Thank you for the work on this document, I only have two comments below.

Francesca

1. -----

   443 is less likely to be blocked than other ports.  Several
   mechanisms for stubs to discover recursives offering encrypted
   transports, including the use of custom ports, are the subject of
   ongoing work.

and

   For the recursive resolver to authoritative nameserver scenario,
   authentication requirements are unspecified at the time of writing
   and are the subject on ongoing work in the DPRIVE WG.

FP: Are there (informative) references you can point the reader to?

2. ----

   If a peer encounters such an error condition it is considered a fatal
   error.  It SHOULD forcibly abort the connection using QUIC's
   CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code
   DOQ_PROTOCOL_ERROR.

FP: Just seeing now that Alvaro has the same comment here - it would make sense
to state why the first SHOULD is not a MUST. What is the exception where it
would make sense that the peer does not abort the connection? Or is it the
CONNECTION_CLOSE mechanism that can be skipped in some cases, so the "SHOULD"
apply only to that mechanism and not to the abort? Some more text here would be
useful.

---

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

> On 9 Mar 2022, at 23:11, Francesca Palombini via Datatracker <[email-masked]> wrote:
> 

Hi Francesca,

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

> FP: Are there (informative) references you can point the reader to?

For the first, we’ve simply updated the text to:
“ since port 443 is used by many services using QUIC and HTTP-3 and thus less
   likely to be blocked than other ports. “

For the second, we did include various references to ongoing recursive-auth work in earlier versions but as the churn was so high we agreed with previous reviewers to remove them. It is still the case that that work in in flux so I’m very hesitant to add anything back in.

> apply only to that mechanism and not to the abort? Some more text here would be

Yes - same comment from Alvaro. We updated to:

"In some cases, it MAY
 instead silently abandon the connection, which uses fewer of the local resources
 but makes debugging at the offending node more difficult.”

Best regards

Sara.