On Feb 15, 2010, at 5:36 AM, Thomson, Martin wrote:
>> 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.
I think it would make more sense to say "This contract must
include" (lower case) rather than "This contract includes . . .."
Otherwise it sounds like a statement of fact.
>> 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.
It seems a bit odd to place a normative requirement on something that
happened in the past ("MUST have been"). It's not clear that you need
to be normative at all since you're talking about an authorization
check that already happened. Here's a suggestion:
> 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 be treated
> 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.
+1
Alissa
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
