> On 7 Mar 2022, at 12:25, Robert Wilton via Datatracker <[email protected]> > 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. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
