> On 12 Apr 2018, at 09:50, Shane Kerr <[email protected]> wrote:
>
> Alex,
>
> I think that the new way probably makes slightly more sense.
>
> So I prefer the NEW order.
+1 for the NEW order although I might suggest calling Section 4.2 something
like “Other Strategies Evaluated"
Sara.
>
> 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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
