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

["Ben Campbell" <[e-mail]>]

Hi, thanks for the response. More comments inline. I removed sections 
that don't seem to need further discussion.

Thanks!

Ben.

On 8 Dec 2015, at 16:34, Sri Gundavelli (sgundave) wrote:

> Hi  Ben,
> -- 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.
>

I saw proposed text clarifying the scope and making some of the security 
guidance normative. I support that in general, but I don't think it 
solves the specific privacy issue around 802.11 access point names. Did 
that discussion involve text describing the privacy implications of  
that? If so, I missed it. In any case, it would be helpful to see the 
new text in the context of a draft update.

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

That will probably address this issue. Do you have proposed text (or a 
revised I-D)?


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

Did I miss guidance to the expert reviewer for that registry that these 
things need to be defined? Does RFC 5213 have such guidance? That is, if 
someone registers a new ATT value for use with RFC 5213, would they know 
they need to define how to interpret the network name?

[...]
>
> -- 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"

I suggest dropping the 2119 MUST. For example:

"RFCs 2131 and 3315 require that the DHCPv4 server ignore the DHCPv4 
Access Network Identifier option if it does not understand the option 
defined in Section 4"

[...]