Thank you, Sara. Looking forward to the revised I-D before proceeding to IETF Last Call ;-)
Regards -éric On 07/01/2022, 12:56, "Sara Dickinson" <[email protected]> wrote: > On 7 Jan 2022, at 07:38, Eric Vyncke (evyncke) <[email protected]> wrote: > > Hi Sara > > Thank you for your reply and the PRs. > > Some more comments below, look for EV> <snip> >> >> Section 6.4: same comment as above and also in other places. > > 6.4 is proposed to change to a MUST for the use of padding in PR https://github.com/huitema/dnsoquic/pull/132. The main reason I can see for not using a QUIC padding API if it existed would be code complexity e.g. the implementation may choose to re-use padding logic already implemented in the DNS layer for DoT/DoH. I can add text about this if you think it is useful? > > EV> adding some text about this would be helpful IMHO but not mandatory Fair enough - text added in PR https://github.com/huitema/dnsoquic/pull/132/files <snip> > >> Also in " it performs well compared" does it mean "better" or "similar" ? > > Adguard haven’t published exact data yet but did say in a presentation “it seems that…. it does provide advantage over DoH in cellular data networks, as expected” and their user feedback "ranges from very positive to neutral”. I’m reluctant to declare it ‘better’ without more raw data…. > > EV> in this case "better" would be wrong indeed but doesn't "well" imply 'good' ? I.e., "similar" could be better ? On this one, you are the native English speaker so I let you decide ;-) I’ve switched to ‘similarly (and possibly better)’ to reflect the qualitative nature of Adguards findings. (I also just noticed this is in the ‘Implementation Status’ section which will be removed anyway…) Regards Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
