Subject: Stephen Farrell's Yes on draft-ietf-6man-ipv6-address-generation-privacy-07: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 05 Aug 2015 09:02:50 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-6man-ipv6-address-generation-privacy-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-address-generation-privacy/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 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.