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
