saradickinson
commented
2 years ago To answer comment no.1 - we did include various references to recursive-auth work in earlier versions to ongoing work but as the churn was so high we agreed with a previous reviewer to remove them. That is still the case.
huitema
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
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?
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.