Barbara
> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: Monday, February 15, 2010 12:36 AM
> To: STARK, BARBARA H (ATTLABS); geopriv@ietf.org
> Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-identity-extensions
>
> Hi Barbara,
>
> 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
