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

[Sara Dickinson <[e-mail]>]

> On 9 Mar 2022, at 23:11, Francesca Palombini via Datatracker <[e-mail]> wrote:
> 
> 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.

Hi Francesca,

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

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

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.

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

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.