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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
