Access-Network-Identifier Option in DHCP
draft-ietf-dhc-access-network-identifier-13

I do support Alissa's and Stephen's Discusses.

Thanks for handling my DISCUSS.

Thanks for addressing my discuss point. I've cleared the discuss.
--------------


-- 4.3.1:
This mentions how to interpret the network name for 802.11, 3GPP, and 3GPP2 networks. Is the use of this sub-option limited to those technology types? How should it be interpreted for other types?

-4.3.2, Access-Point Name
The paragraph refers to the MAC address of a device. Which device is it talking about? (e.g. end-device, base station, DHCP relay)

-- 4.4.1:
[SMI] probably needs to be a normative reference.

-- 7, first sentence:
This seems to be making a MUST level requirement for servers that do not implement this draft. Is this a new MUST, or is already specified elsewhere? (If the latter, then citation?)

Editorial:

-- 1, paragraph 2, First sentence: 
Missing article for DHCP relay agent
s/add/adds/

-- 2, 2nd paragraph:
Lots of missing articles for MAG.

-- 3, SSID definition:
s/the IEEE/an IEEE/
s/one network to the other/ one network from another/

-- 5.1, reserved:
The reader’s “now” may be years from the authors' “now” :-) I suggest something to the effect of "At the time of this writing"

Thanks for solving my DISCUSS

Thanks for addressing the questions raised int he SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05811.html

There was mention of IPsec use when relaying this information and then a question from Stephen if this was actually used.  I'm guessing the answer is no since the protection is not mentioned in the draft, but wanted to confirm as that wasn't clear to me from the email thread.

Additionally, is there any advice given (possibly in other related specs, but I suspect having it here for the new values could be helpful) to assign obscure names to several of the values like the Access Point Identity (Name, BSSID) and Operator Id/Realm?  Obscuring only helps a little, but having names that don't necessarily advertise the usage of the associated network might be helpful.  Thanks.

I look forward to the planned discussion to see if we can further improve
the privacy and security properties of DHCP. Thanks for being willing
to have that discussion.

OLD DISCUSS TEXT BELOW:

(Sent mail 2016-01-10, checking on change vs. discuss)

(1) Did the DHC working group consider how this information,
when sent without adequate protection between relay and dhcp
server, could help in pervasive monitoring? If so, what was the
conclusion reached? We have seen http header field information
sent between infrastructure nodes being intercepted for that
purpose, so this has to be similarly at risk.  If the answer is
that this is only to be used within a single network operator's
setup (or a roaming arrangement) then that needs to be
justified (as practical) and, if it can be justified (I'm not
sure tbh), also made explicit. 

(2) I had a DISCUSS on the draft that became rfc 6757 about
protection of this kind of data. In that context I think I was
assured that everything (in PMIPv6) was IPsec protected so it
was fine.  Why, in what we now know is a more threated
environment, is it ok to now have weaker protection when I was
assured then that IPsec was in fact quite usable in PMIPv6? I
think you maybe need to put in a MUST use IPsec requirement for
this to be as safe. 

(3) section 7: MAY store - this is possibly sensitive
information so you ought say that it SHOULD NOT be stored
unless needed, and if stored, SHOULD be deleted as soon as
possible. Storing sensitive information when not needed just
shouldn't be considered acceptable anymore I think - is that
reasonable?

OLD COMMENT TEXT BELOW

- I (strongly) support Alissa's DISCUSS and will be interested
in watching how that is resolved. Some of my DISCUSS points do
overlap though so from my POV feel free to mix'n'match the
discussions. Or to process first one then the other, whatever
you think is best.

- RFC6757 defines exactly this for PMIPv6. That implies that
PMIPv6 should not be used to illustrate or motivate this, as
that problem is solved. Perhaps you would be better off if you
limited the scope of this to be used for networks that are some
kind of extension to PMIPv6 only? (You'd need to define what
kind I think.)