Skip to main content

Last Call Review of draft-ietf-dhc-dhcpv6-privacy-03
review-ietf-dhc-dhcpv6-privacy-03-genart-lc-sparks-2016-02-02-00

Request Review of draft-ietf-dhc-dhcpv6-privacy
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-02-04
Requested 2016-01-21
Authors Suresh Krishnan , Tomek Mrugalski , Sheng Jiang
Draft last updated 2016-02-02
Completed reviews Genart Last Call review of -03 by Robert Sparks (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-dhc-dhcpv6-privacy-03-genart-lc-sparks-2016-02-02
Reviewed revision 03 (document currently at 05)
Result Ready with Nits
Completed 2016-02-02
review-ietf-dhc-dhcpv6-privacy-03-genart-lc-sparks-2016-02-02-00
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.)