> On 6 Dec 2021, at 19:55, Martin Duke <[email protected]> wrote: > > Thank you for the changes in draft-07. > > from Christian's response: > > >> 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. > > RFC 9000 is pretty much silent on that point. There is no mention of > STOP_SENDING in section 3.1 of RFC 9000. Everything in RFC 9000 looks > like "it would be nice if you stop sending asap", without making that a > hard decision. Yes, we might mention acknowledgements, but this is a > QUIC level issue. QUIC stack APIs may or may not inform the application > about how much data on a stream has been acknowledged, and in this > particular case data might well be acknowledged at the QUIC layer and > discarded at the application layer. > > Do you want to suggest a better text? > > As the current text says, Sec 3.5 of RFC 9000 is the correct reference. I > would recommend > > s/if the server has already sent the response/if the server response has > already been acknowledged > > <snip> > >> 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. > > As the text says, no deployment of RFC8904 currently exists to our > knowledge. The reliance on section 17.2 of RFC 9000 is really an > assurance against a very unlikely eventuality, and I cannot see how it > would impact future versions of QUIC. > > RFC8999 does not guarantee that future versions of QUIC will preserve the > QUIC bit, which allows demultiplex of DTLS with QUIC. DTLS has no invariants > at all. I share your skepticism that this will end up mattering; however, > there ought to be a little text, that says, e.g., > > Deployments that serve DNS over DTLS [RFC8904] and DNS over QUIC version 1 on > the same port will be able to demultiplex the two due to the second most > significant bit in each UDP payload. Such deployments ought to check the > signatures of future versions or extensions (e.g. > [?I-D.ietf-quic-bit-grease]) of QUIC and DTLS before deploying them to serve > DNS on the same port.
Hi Martin, Many thanks for this suggested text - I’ve created https://github.com/huitema/dnsoquic/pull/133 to incorporate this which I hope addresses these two comments. Best regards Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
