Alex,

I think that the new way probably makes slightly more sense.

So I prefer the NEW order.

Cheers,

--
Shane

Alexander Mayrhofer:
> 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
> 

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

Reply via email to