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).
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.
Recommend rewording:
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.
In cases where privacy for the Device or Target is legally mandated,
regulated, or otherwise important, it is critical that these issues be
resolved before permitting a third-party request. A pre-arranged
contract between the third-party, a Rule Maker and the LIS operator may
be necessary to guarantee appropriate privacy is provided when device
identifiers are used in this fashion. It is recommended that such a
contract 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.
Automated mechanisms to ensure privacy constraints are also 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.
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."
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.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
