[Gen-art] Gen-Art review: draft-ietf-dhc-dhcpv6-privacy-04

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dhc-dhcpv6-privacy-04
Reviewer: Robert Sparks
Review Date: 16Feb2015
IETF LC End Date: past
IESG Telechat date: 18Feb2015

Summary: Ready for publication as an Informational RFC

All of the nits from my LC review have been addressed. Thanks!

RjS

On 2/2/16 10:38 AM, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-dhc-dhcpv6-privacy-03
> Reviewer: Robert Sparks
> Review Date: 2Feb2015
> IETF LC End Date:4Feb2015
> IESG Telechat date: Not yet scheduled
>
> Summary: Ready with nits that should be addressed before publication
>
> The reference to ietf-6man-ivp6-address-generation-privacy should be 
> normative, and when this document is pointing to it because it is 
> discussing a field carrying a generated address, it should be more 
> explicit about why it's making the reference.
>
> In section 4.3 the paragraph on Hash allocation should note that even 
> a well implemented hash does not mitigate the threat of correlation 
> over time.
>
> In section 4.3, the paragraph on Random allocation comments on the 
> poor performance of a specific simplistic implementation of random 
> selection. More efficient algorithms exist. But the discussion is 
> mostly irrelevant to the document. Please simplify this paragraph to 
> focus on the benefits of random allocation.
>
> Should section 5.3 also call out mapping IP addresses into geolocation?
>
> Why doesn't section 5.5 also talk about things like MAC addresses?
>
> Section 5.6 could probably borrow words from RFC7258 - it should at 
> least reference it (currently there is only a reference from the 
> introduction.)
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art