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. On Mon, Oct 18, 2021 at 7:48 AM Sara Dickinson <[email protected]> wrote: > > > > On 15 Oct 2021, at 01:47, Christian Huitema <[email protected]> wrote: > > > > > > On 10/14/2021 12:06 PM, Martin Duke wrote: > >> 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. > >>> > <snip> > > > > Do you want to suggest a better text? > > > >>> 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? > > I will let Sara answer this specific question. > > Thanks for pointing this out - the text does need updating one way or > there other. > > We’ve had no feedback to date on this question, so on the basis that > no-one has objected to sending a NOTIFY in 0-RTT data, I’ve opened a PR to > update the text to allow this: > https://github.com/huitema/dnsoquic/pull/114 > > Regards > > Sara. > > > > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
