Update: Rui Paulo points out that https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis-01 is the best reference for QUIC demultiplexing.
On Thu, Oct 14, 2021 at 11:59 AM Martin Duke <[email protected]> wrote: > Note: I review this as a QUIC enthusiast, but at best a novice with DNS. > > I support this work and would like it to move forward. However, I have a > few minor concerns. > > 1. In the introduction, it would be helpful to describe the benefits of > DoQ with respect to DoHTTP/3. The latter obviously is also over QUIC, gets > many of its protocol benefits, and can also leverage the existing DoH > design. So why DoQ? > > 2. (Sec 5.3.1) It doesn't quite sit right that STOP_SENDING can be ignored > if all data has been "sent". If some all has been sent but only some > acknowledged, the receiver of STOP_SENDING should stop trying to retransmit > any unacknowledged data. > > 3. (Sec 5.5) I don't understand the status of this NOTIFY analysis. Will > the document hold until the analysis is complete, or is this an independent > process and you are planning to publish with the statement as-is? > > 4. (Sec 5.5) Is there not a role for intermediaries in this architecture? > I'm thinking of the HTTP header field that notifies the server that the > request arrived in early data, even though on the last downstream > connection was 0RTT. Is the intent that all the termini in the chain will > reject QUERY if early data, as described here? > > 5. (Sec 9.1) It might be worthwhile to point out that 0RTT requests are > not forward secure. > > 6. (Sec 10.2) Section 17.2 in [RFC9000] doesn't say anything explicit > about demultiplexing with DTLS or any other protocol. A danger in reusing > Port 853 is that it implicitly limits use of DoQ with future versions of > QUIC. At the very least, it would be useful to explicity write down the > requirements for DoQ over future versions of QUIC. > > Thanks, > Martin > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
