Subject: [dns-privacy] Warren Kumari's Yes on draft-ietf-dprive-padding-policy-05: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Mon, 18 Jun 2018 13:28:42 -0700

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..."