[secdir] SECDIR review of draft-ietf-6man-ipv6-address-generation-privacy-07

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]