Skip to main content

Last Call Review of draft-ietf-6man-ipv6-address-generation-privacy-07
review-ietf-6man-ipv6-address-generation-privacy-07-secdir-lc-eastlake-2015-08-06-00

Request Review of draft-ietf-6man-ipv6-address-generation-privacy
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-08-04
Requested 2015-07-02
Authors Alissa Cooper , Fernando Gont , Dave Thaler
I-D last updated 2015-08-06
Completed reviews Secdir Last Call review of -07 by Donald E. Eastlake 3rd (diff)
Opsdir Last Call review of -07 by Qin Wu (diff)
Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Request Last Call review on draft-ietf-6man-ipv6-address-generation-privacy by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 08)
Result Has nits
Completed 2015-08-06
review-ietf-6man-ipv6-address-generation-privacy-07-secdir-lc-eastlake-2015-08-06-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last call
comments.

This draft is ready with nits. It provides a survey of the privacy and security
considerations of a variety of IPv6 address generation mechanisms. As far as I
can tell, it does a thorough job and is a useful document. I have the following
minor comments:

Section 1: Although references and lengthier names are given for all the other
categories of configuration method, the "Manual configuration" method section
is notable for the brevity of its entries and lack of any references
whatsoever. I don't have the faintest idea what "Wordy" is and a couple of the
others convey to me only a vague idea of what is being listed.

Section 2: What does "DHT" stand for? Given that it occurs exactly once in this
document, perhaps it should be spelled out.

Section 3.3: It might also be useful to mention that the group-addressed bit in
the upper 24-bits of a 48 bit MAC will be zero and the global/local bit will
probably be zero also. It would be good to add a reference to RFC 7042.

Section 4, Table 1: Given that there seems to be plenty of space, I would
recommend spelling out "CGA" in the Mechanism column. Also, I see no reason for
the "(s)" on the end of "Mechanism" in the column header.

Section 4.2: "low byte", which occurs here as well as in Section 1, could use a
couple of sentences of explanation.

Section 4.3: The first sentence reads very oddly. Suggest replacing "it" with
"such a mechanism".

Section 5.2: Maybe it is just me but it sounds quite odd to come across a "This
document recommends" exactly once here almost at the end of this Informational
document. It is certainly a reasonable recommendation but there are a number of
previous points in the document where some mechanisms seems so much better,
from the privacy and security point of view, than others that a recommendation
would be equally justified. So I suggest changing "This document recommends
that compliance testing suites be ..." to "Such compliance testing suites
should be ...". (I realize that means about the same thing but somehow it
bothers me a lot less.) Alternatively, state in the introduction that
recommendations are provided and review the document and add appropriate
recommendation language in favor of superior mechanisms.

Thanks,

Donald

=============================

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)

 155 Beaver Street, Milford, MA 01757 USA



d3e3e3 at gmail.com