Subject: Re: Opsdir last call review of draft-ietf-dprive-padding-policy-04

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 12 Apr 2018 10:11:34 +0200

All,

the OPSDIR review from Joe Clarke suggests a re-ordering of the
document flow in order to better appeal to folks with operational
background. I'm considering changing the structure of the document,
but i would appreciate yes/no indications from the group before i
proceed. This would not induce any protocol-level change, but would
still be a change that i consider significant enough for the WG to
discuss.

My suggestion to change the structure would be as follows:

CURRENT:

   1.  Introduction  . . . . . . . . . .
   2.  Terminology . . . . . . . . . .
   3.  General Guidance  . . . . .
   4.  Padding Strategies  . . . . . .
     4.1.  Block Length Padding  . . . . . . . .
     4.2.  Maximal Length Padding ('The Full Monty') . . .
     4.3.  Random Length Padding . . . . . . . . . . . . .
     4.4.  Random Block Length Padding . . . . . . . .
   5.  Recommended Strategy  . . . . . . . . . . . . . . .
   6.  Acknowledgements  . . . . . . . . . . . . . . .
   7.  IANA Considerations . . . . . . . . . . .
   8. Security Considerations . . . . . . . . .

NEW:

   1.  Introduction  . . . . . . . . . .
   2.  Terminology . . . . . . . . . .
   3.  General Guidance  . . . . .

   4.  Padding Strategies  . . . . . .
     4.1.  Recommended Strategy (Block Length Padding)
     4.2.  Other Potential Strategies
     4.2.1.  Maximal Length Padding ..............
     4.2.2.  Random Length Padding . . . . . . . . . . . . .
     4.2.3.  Random Block Length Padding . . . . . . . .
   5.  Acknowledgements  . . . . . . . . . . . . . . .
   6.  IANA Considerations . . . . . . . . . . .
   7. Security Considerations . . . . . . . . .

I think it totally depends on the viewpoint (operational vs.
"research-oriented"). Please share your preferred option - keep with
CURRENT or restructure for NEW.

thanks,
Alex

On Mon, Mar 26, 2018 at 6:45 PM, Joe Clarke <[email-masked]> wrote:
> Reviewer: Joe Clarke
> Review result: Has Nits
>
> I have been asked to review this document on behalf of the ops directorate.
> This document is intended for experimental status, and describes a number of
> strategies to take when performing EDNS(0) padding.  It recommends one
> (experimental) option to use based on empirical data.  Overall, I think this
> document is close to be ready.  In general, coming at it from an operator
> standpoint, I thought the layout was a bit odd.  The recommended option is
> spelled out first, but then the document goes into sub-optimal approaches
> before it actually describes the full recommended solution (both from a query
> and response stance).  It might flow better to discuss the recommended approach
> in detail while leaving all of the sub-optimal approaches for appendices.  At
> the very least, the Maximal Length Padding approach feels somewhat non-sensible
> and should be pushed to the appendix.
>
> Nit-wise, I found the following:
>
> Section 3:
>
> s/signifcantly/significantly/
>
> s/octects/octets/
>
> ===
>
> Section 4.1
>
> You refer to Maximum Length Padding here, but Section 4.2 calls it "Maximal
> Length Padding".
>
> ===
>
> Section 4.2
>
> Is referencing "The Full Monty" needed here?
>
> ===
>
> Section 4.3
>
> You expand (pseudo) to (pseudo) random number in Section 4.1.  I think the same
> should be done here for clarity.
>
> ===
>
> Section 4.4
>
> s/transction/transaction/
>
> ===
>
> Section 5
>
> When you talk about a multiple of 468 bytes used for response padding, I think
> you should include a "see below".
>
> ===
>
> Section 5
>
> s/octects/octets/
>
> ===
>
> Section 5
>
> Where you have "Note that the recommendation above does apply only..." I think
> it reads better to say, "Note that the recommendation above applies only..."
>
> ===
>
> Section 8
>
> s/inffective/ineffective/
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 12 Apr 2018 20:18:14 -0400

> CURRENT or restructure for NEW.

I prefer NEW (i like having the recommendation up front) but would not
be sad if we stuck with CURRENT either.

   --dkg