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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 07 Mar 2022 04:25:59 -0800

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,

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?

   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.

   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.

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.

Regards,
Rob

---

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

> On 7 Mar 2022, at 12:25, Robert Wilton via Datatracker <[email-masked]> wrote:
> 

Hi Rob,

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

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

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

> level, or QUIC packet level.

We’ve updated this to `QUIC packet level`

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