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

[Sara Dickinson <[e-mail]>]

> On 7 Mar 2022, at 12:25, Robert Wilton via Datatracker <[e-mail]> wrote:
> 
> Robert Wilton 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:
> ----------------------------------------------------------------------

Hi Rob,

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

> 
> Hi,
> 
> Thanks for this doc.  It looks like DNS and QUIC could be a good fit.  Just a
> few minor comments/questions.
> 
>   In QUIC, sending STOP_SENDING requests that a peer cease transmission
>   on a stream.  If a DoQ client wishes to cancel an outstanding
>   request, it MUST issue a QUIC STOP_SENDING with error code
>   DOQ_REQUEST_CANCELLED.  This may be sent at any time but will be
>   ignored if the server response has already been acknowledged.  The
>   corresponding DNS transaction MUST be abandoned.
> 
> I presume that there is no requirement that the DNS transaction be immediately
> abandoned.  E.g., if a server already has a reply queued for sending, then it
> is still reasonable to send that response?

We’ve added text here to clarify: 
“ Servers SHOULD NOT continue processing a DNS
   transaction if they receive a STOP_SENDING."

> 
>   Because new error codes can be defined without negotiation, use of an
>   error code in an unexpected context or receipt of an unknown error
>   code MUST be treated as equivalent to DOQ_NO_ERROR.
> 
> I find DOQ_NO_ERROR to be a strange name for an error code because I would
> naturally assume that DOQ_NO_ERROR is equivalent to "success", but that doesn't
> seem to be the intention here.  In particular, I find it strange to treat an
> unknown error equivalently to DOQ_NO_ERROR.  I'm not saying that the behaviour
> is wrong, only that the naming is slightly strange/confusing.

It’s a good point - we’ve added a new error code DOQ_UNSPECIFIED_ERROR to be used specifically for the case you picked out (instead of the DOQ_NO_ERROR) to avoid this confusion.

> 
>   In theory, padding at the QUIC level could result in better
>   performance for the equivalent protection
> 
> As a nit, I didn't find "QUIC level" to be particularly clear, and hence I was
> wondering whether this could be clarified.  E.g., is this at the QUIC protocol
> level, or QUIC packet level.

We’ve updated this to `QUIC packet level`

> 
> 10.4.  DNS over QUIC Error Codes Registry
>   Registrations in this registry MUST include the following fields:
> 
> This lists various fields that MUST be included, but doesn't specify values for
> the initially assigned values in the table.

Thanks for picking this up! The changes in -11 re-work that section so it is now hopefully consistent.

Best regards

Sara.