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 <jcla...@cisco.com> 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/
>

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to