Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS)

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi  Ben,

Thanks for your review. Please see inline.




-- 4.3.2

The name of an 802.11 access point can imply the users location with a fair bit of precision, making it effectively count as location data. The draft needs  more discussion of the privacy implications of that.


[Sri] I believe this issue is now resolved after discussions with Alissa Cooper and the newly agreed text.



-- 6:
This section seems underspecified. There seems to be a missing discussion about interdependencies among options. For example, For example, network name is meaningless without the technology type. What is the minimum needed to be coherent?


[Sri] Agree. Its mainly the ATT that must be present with certain options. In each of those option section, we will state this explicitly.


I support  Stephen's and Alissa's discusses, and look forward to their resolution.

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


[Sri] This covers all the currently defined access technologies in ATT registry (CDMA, GSM and WLAN based access networks). For new ATT values that are yet to be defined the network name has to be interpreted as defined in the document that introduces those ATT values.



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


[Sri] Its the MAC address one of the interfaces of the access point.

OLD:

      In some deployments, the Access-Point
      Name can be set to the string representation of the Media Access
      Control (MAC) address as specified in [RFC6991] mac-address string
      type of the device or some unique identifier that can be used by
      the policy systems in the operator network to unambiguously
      identify the device.  The encoding MUST be UTF-8 as described in
      [RFC3629].


NEW:

      In some deployments, the Access-Point
      Name can be set to the string representation of the Media Access
      Control (MAC) address as specified in [RFC6991] mac-address string
      type of the device or some unique identifier that can be used by
      the policy systems in the operator network to unambiguously
      identify the device. The MAC address is typically from one of the

      interfaces of the access point.  The encoding MUST be UTF-8 as described in

      [RFC3629].


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


[Sri] Ok




-- 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?)


[Sri] I believe its existing behavior.

RFC 3315 and RFC 2131 ? Bernie ?

   "If DHCPv4 server does not understand the option defined in Section 4
   it MUST ignore the DHCPv4 Access Network Identifier option received; this is as specified in the base documents RFC2131 and RFC3315"



Editorial:

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


[Sri] OK.



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


[Sri] OK



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


[Sri] OK



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

Ok.

OLD:

      An 8-bit field that is unused for now.  The value MUST be
      initialized to 0 by the sender and MUST be ignored by the
      receiver.

NEW:


     An 8-bit field that is unused at the time of writing this draft. The value MUST be
      initialized to 0 by the sender and MUST be ignored by the
      receiver.