Security and Privacy Considerations for IPv6 Address Generation Mechanisms
draft-ietf-6man-ipv6-address-generation-privacy-08

Thanks for the informative and well-written work.

Nice work on this draft!

A nit, and a compliment in the form of a question for the IESG ...

The nit: The term "low byte" doesn't have a reference on first use in Section 4.2, and doesn't appear in the terminology section. I think I understand the point this text is making:
   
   The extent to which location tracking can be successfully performed
   depends, to a some extent, on the uniqueness of the employed
   Interface ID.  For example, one would expect "low byte" Interface IDs
                                                ^^^^^^^^^^
   to be more widely reused than, for example, Interface IDs where the
   whole 64-bits follow some pattern that is unique to a specific
   organization.  Widely reused Interface IDs will typically lead to
   false positives when performing location tracking.
   
but I'm guessing, and the point seems important enough to justify clarity. Could you add "low byte" to the terminology section, unless it's a term of art all your readers will understand?

The following text was helpful to me in guessing what "low byte" means, 

   On the other hand, some DHCPv6 software leases sequential addresses
   (typically low-byte addresses).  These addresses can be considered to
   be stable addresses.  The drawback of this address generation scheme
   compared to "stable, semantically opaque" addresses is that, since
   they follow specific patterns, they enable IPv6 address scans.

but it didn't appear until Section 4.8. 

Authors and 6man working group, please take what follows as a compliment - no action required on your part, I think. 

For the IESG - I wonder if this document could be published as something more than Informational. It's important, relevant, useful, and clearly written. Maybe it doesn't quite fit being published as a BCP. Maybe it doesn't quite fit being published as an Applicability Statement (https://tools.ietf.org/html/rfc2026#section-3.2). The response to the first question in the shepherd writeup didn't explain why Informational was the proper intended RFC status, so I thought I should ask here.

Maybe it has enough gravitas as is. 

But I'd also ballot Yes for either BCP or AS.

- general: I really like this document but wonder about
how complete it is (or can be). For example, I think
there's very little here on transition mechanism
consequences, and no mention at all of the privacy trade
offs between CGN and IPv6 addressing. I do think it's a
good thing to publish this now though, but it might also
be nice to see if we can get it udpated sometime in
future. (Which'd argue that maybe we should have a
standards track thing like this that recommends what to
do when one cares about privacy in different contexts,
but I'm not asking we go there now.)

- section 1: I'm surprised only A+P gets onto the list
here - aren't there more worthy of mention? I hope you
can extend this list to include the most commonly used
of those.

- section 2: I'd not have thought of a SIP proxy as a
place to which I'd publish addresses - might be nice (no
more) to add a reference that explains that?

- section 2: the definitions are probably ok, but they
don't really specify disjoint sets of things, e.g.  for
the stable vs. temporary IID some things will fit both
definitions, which seems a bit odd. However, I'm not
sure that being much more precise is worthwhile.

- section 3: If an addr with an IID like that is used in
an ACL (e.g. on a router/switch) that can also be bad if
the device moves now and then. (Since anyone can fake
'em.)

- section 3: The ways in which a bad actor can gain
knowledge are worse than stated - if the IID is broadcast
from a handset whilst wandering about, which is what
happens a lot!

- section 3: Would it be a good idea to try scare the
reader a bit via a reference to the Canadian govt story
about tracking everyone going throught Toronto airport?
I'm not sure readers of this will otherwise get the full
import otherwise.

- Table 1: I don't agree with some of your "no"
statements. I think what you mean by "no" is really "not
solely based on wire protocols" or somesuch, e.g. with
DHCP the servers can assist with location tracking based
on client ID or layer 2 information. I think you should
clarify what "no" means here to not give a slightly
wrong impression.

- Table 1: What logic was used to determine how many
rows to include here? Actually all of section 4 seems
overly focused on IIDs. 

- 4.8: I'm surprised there's so little to be said here.

Well constructed document - Thanks!

No action for the authors or shepherd here: so in answer to Barry's question. I think this document is able to stand on its own feet as informational - it doesn't need (in my opinion) to be classified as a BCP to add gravitas. The approach in the document stands as informational but the clear language and coverage of mechanisms and the resulting tradeoffs provide its own weight.