Warren Kumari has entered the following ballot position for draft-ietf-dprive-padding-policy-05: Yes
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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Firstly, thank you for writing this, and also for addressing Joe Clarke's OpsDir notes (and, obviously, thanks to Joe for the review!). I have a clarifying question and some nits: Section 4.2.2: " According to the limited empirical data available, Random Length Padding performs slightly worse than Block Length Padding." Performs slightly worse along what axis? I'm assuming "the server can answer less queries per second", but could also be "uses more RAM", "higher CPU", "explodes randomly", etc. I don't really think that this needs to be addressed, but if you are editing it anyway, and have an easy way to improve it... Oh, Appendix A made me laugh :-) Other than that, some nits: 1: Section 3. General Guidance "EDNS(0) options space: The maximum message length as dictated by protocol limitation limits the space for EDNS(0) options." This flows a little oddly - perhaps "The maximum message length as dictated by the protocol limits the space..." (unless the "limitation limits" entertains you...) 2: Section 4.1: "Note that the recommendation above applies only if DNS transport is encrypted." I suggest "if the DNS transport..." _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
