Thanks for the feedback. I've made the minor corrections that you've requested.
I've responded inline to each below.
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of STARK, BARBARA H (ATTLABS)
> Sent: Saturday, 13 February 2010 3:08 AM
> To: geopriv@ietf.org
> Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-identity-extensions
>
> I've sent the authors my editorial nits (misspellings and grammatical
> errors).
>
> I have the following 5 comments, but if others don't want changes from
> these comments, I'm willing to withdraw any or all of them. My comments
> don't impact the requirements for the protocol or the LIS, and I'd like
> to see this document move forward.
> Barbara
> -----------------------------------------------------------------------
> 1. Section 1.1 (under the Introduction)
> "Due to the risk that an identifier might be spoofed by a Device,
> identifiers MUST NOT be used unless specific information is
> provided for that identifier describing how the identifier is
> used
> and what measures are used to prevent spoofing."
>
> Comment: The use of normative language in this introductory section is
> awkward. Given that the same requirement effectively exists in Section
> 5.1, I would prefer that it not be duplicated here. Make this "must
> not"
> (lower case letters).
You are quite right in pointing out that it's not necessary to use normative language, especially in the introduction.
In response to Bernard's review, this paragraph is already different. I'll take your suggestion and change "MUST NOT" to lowercase. The new text becomes:
Section 1.1, CHANGED:
Due to the risk that an identifier might be spoofed by a Device, identifiers must not be used unless specific measures are taken to prevent spoofing.
> 2. Section 1.1
> "This document does not describe how a third party acquires an
> identifier for a Device, or how that third-party is authenticated
> by a LIS. These issues MUST be resolved before permitting a
> third-party request. A pre-arranged contract between the third-
> party, a Rule Maker and the LIS operator is necessary to use
> device identifiers in this fashion. This contract MUST include
> how the request is authenticated and the set of identifiers (and
> types of identifiers) that the third-party is authorized to use
> in
> requests.
>
> Note that this is not intended to preclude the definition of
> mechanisms that replace this requirement with automated means of
> establishing these constraints."
>
> Comment: This use of normative language to attempt to mandate legally
> binding contracts for access to location information of wheelchairs in
> hospitals, cattle on farms, and all other possible uses of this
> protocol
> is, IMO, unacceptable. Especially here in this introductory section.
> This is trying to mandate policy that is not only external to the
> protocol, but is also external to the LIS that operates the protocol.
> As
> such, it has no business being normative.
I've discussed the implications of this in more detail below. The inviolate rights of cattle notwithstanding, the role of Rule Maker in this case can be trivially assumed by the farmer, who indicates his grant of authorization by installing a tracking device on the animal; or the person who installs the LIS, who assumes this role when they turn the LIS on.
I've removed the normative language, which didn't really add anything in this case, as you can see. I've also taken your text for the final statement, but I don't believe that the conditional language is necessary.
Section 1.1, CHANGED:
This document does not describe how a third party acquires an identifier for a Device, nor how that third-party is authenticated by a LIS. It is critical that these issues are resolved before permitting a third-party request. A pre-arranged contract between the third-party, a Rule Maker and the LIS operator is necessary to use Device identifiers in this fashion. This contract includes how the request is authenticated and the set of identifiers (and types of identifiers) that the third-party is authorized to use in requests.
Automated mechanisms to ensure privacy constraints are respected are possible.
> 3. Section 4.4.1 [editorial comment]
> "After receiving a location request that includes an NAI, the LIS
> sends a "Location-Requestor-Authentication-Protocol" access request
> message to the Authentication, Authorization and Accounting (AAA)
> server."
>
> Comment: Please provide a reference here as to where the
> Location-Requestor-Authentication-Protocol is defined.
This reference is already provided in the first paragraph of the section (as you guessed), but it's probably not clear enough that the WiMAX Forum reference applies to the whole section.
Section 4.4.1, OLD:
In a WiMAX network, an IP address is not sufficient information for a LIS to locate a Device. The procedure in [WiMAX-T33-110-R015v01-B] relies on an NAI to identify the Device.
NEW:
In a WiMAX network, an IP address is not sufficient information for a LIS to locate a Device. The following procedure, described in more detail in [WiMAX-T33-110-R015v01-B], relies on an NAI to identify the Device.
> 4. Section 4.4.1
> "The AAA server consults network policy and if the request is
> permitted, the response includes the IP address that is currently
> assigned to the Device. If this IP address matches the source IP
> address of the HELD location request, the location request is
> permitted; otherwise, the request is rejected."
>
> Comment: Per the 2nd paragraph in this section, the restrictions in the
> 2nd sentence are only true if the request is being treated as a
> location
> configuration request, and not if the request is already authenticated
> as a third-party request. Recommend rewording the 2nd sentence to "If
> this is an unauthenticated request that is being treated as a location
> configuration request, then the location request is permitted if and
> only if this IP address matches the source IP address of the HELD
> location request."
Bernard had a similar comment, but I couldn't think of the right response. I think that the right thing to say here is:
Section 4.4.1, OLD:
If this IP address matches the source IP address of the HELD location request, the location request is permitted; otherwise, the request is rejected.
NEW:
If this IP address matches the source IP address of the HELD location request, the location request can be authorized under the LCP policy (see Section 5.1); otherwise, the request MUST have been authorized as a third-party request.
> 5. Section 5.2
> "An organization that provides a LIS that allows third party
> requests
> must provide a means for a Rule Maker to specify authorization
> policies as part of the LIS implementation (e.g, in the form of
> access control lists). Authorization must be established before
> allowing third party requests for the location of any Target.
> Until
> an authorization policy is established, the LIS MUST reject requests
> by third parties (that is, the default policy is "deny all")."
>
> Comment: Organizations must only do this if they are legally bound to
> do
> this. Not because the IETF says so. Such organizational policy is
> external to the protocol and the LIS. The "musts" in these sentences
> are
> non-normative (which is good), but I think there needs to be some
> additional disclaimers. I recommend "In cases where privacy is mandated
> for legal, regulatory, or other reasons, an organization that provides
> a
> LIS..." and then the 2nd sentence is "In such cases, authorization must
> be established..." The last sentence is good, as a default LIS policy.
I'm sure that organizations could find reasons other than legal ones to protect privacy.
But the main point is that this doesn't prevent anything. The process of gaining authorization can be a simple one. And the role of Rule Maker is an easy one to assume. Given that the LIS operator chooses who to recognize as Rule Maker, if there are no applicable regulations, the LIS operator can assume the role and set any rule they want.
The intent here is not to set a rule, but to identify "harm" to privacy and highlight the role that is taken on when the "send" button is pressed. I'm pretty sure that we're not trying to say prevent this on the strength of "the IETF said so".
I'd prefer not to make these statements conditional.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
