Authors and list
I have a couple questions and a few comments about the current
geopriv-reqs-02 ID:
1. Under what circumstances is LI optional within a valid LO (there are
*no* LI fields) - section 3.1.2?
2. Why is the focus only on non-publicly available Location Information
(Section 3.1.1)?
This should be available to all forms of geodetic and civil location
transfers - including transporting what could be found in a Yellow Pages
listing.
3. Stated in the Abstract:
"This document focuses on the authorization, integrity and privacy
requirements for such location-dependent services. Specifically, it
describes the requirements for the geopriv Location Object (used to
securely transfer location data and other privacy-enabling
information) and for the protocols that use this Location Object."
But this doesn't state anything to the effect of '... this document with
define Location Information...' or '... this document will define how
location information will be specified in a uniform manner...'. Why has
this topic area been omitted?
4. From the Intro section
"A key goal of the protocols described in this
document is to facilitate the protection of privacy pursuant to
privacy policies set by the "user" (or, more precisely in the
terminology of this document defined in Section 3 below, the "Rule
Maker")."
This doesn't account for the possibility of any domain based policies (and
mechanisms) that might override a user's policies.
5. From the Intro:
"The ability to derive or compute a Device's location, and access to
the derived or computed location, are key elements of the location-
based services privacy equation. Central to a Target's privacy are
(a) the identity of entities that have access to raw location data,
derive or compute location, and/or have access to derived or
computed location information, and (b) whether those entities can be
trusted to know and follow the privacy policy of the user."
"The ability to derive or compute a Device's location..." is outside the
scope of the IETF, but it's stated more than once here. I believe a server
could "gather" the Location Information with or without IP involved, then
transmit it in IP (at which time this could be done with a Geopriv Protocol).
6. In the Intro section:
"The main principles guiding the requirements described in this
document are:"
which lists 5 parts to Geopriv's Requirements - without listing anything
about Location Information...
As it is, this document could be renamed as "Geopriv Privacy Requirements"
7. From Conventions section:
"Note that the requirements discussed here are requirements on the
generic Location Object and on the using protocols for location
services. Thus the requirements discussed in this document mostly
refer to the capabilities that are mandatory-to-implement."
So this document should cover all that is mandatory to implement, right?
8. From section 3.1.1. Location Information (LI) and Sighting:
"The focus of the geopriv working group is on information about a
Target's location that is NOT based on generally or publicly
available sources, but instead on private information provided or
created by a Target, a Target's Device, or a Target's network or
service provider:
Location Information (LI):
A relatively specific way of describing where a Device is
located and that is (a) derived or computed from information
generally not available to the general public (such as
information mainly available to a network or service
provider), (b) determined by a Device that may be not
generally publicly addressable or accessible, or (c) input or
otherwise provided by a Target."
Again states the purpose of the Geopriv WG, including the deriving of a
Target's location. Should state providing, transferring, and/or generating
Location by some means outside the scope of the IETF. Seems to leave out
the possibility of a configuration protocol sending the Location
Information to the Target at boot time (or some other time).
Is one of the requirements of LI to state in which way the LI was
determined? It seems to have been written this way.
Doesn't seem like we should care how the LI was determined, just that it is
a format Geopriv can use. And if we don't care (due to it being out of
scope for us to manage or authenticate), we should refer to it other than
the transport of it. This transportation could be in raw form, as such a
Geopriv aware device is needed to generate the LI in a Geopriv format
(which should be referenced).
9. From section 3.1.1. Location Information (LI) and Sighting:
"Within any given location-based transaction, the INITIAL
determination of location (and thus the initial creation of Location
Information) is termed a Sighting:
Sighting:
The initial determination of location based on non-public
information (as discussed in the definition of Location
Information), and the initial creation of Location
Information."
The creation of Location Information is outside the scope of Geopriv, yet
it is mentioned here explicitly.
Sighting is referring to something similar to a military sighter usage
(from the artillery term) in which someone calculates or uses instruments
to determine where something else is, generally what is to be shot at.
While this might have some similarity in meaning to the mobile or cellular
examples proved, it doesn't apply to any manual entries directly, and
doesn't seem appropriate for situations where another IP-based Protocol(s)
delivers the location information (say from a wire-map database described
in the DHCP LO Option ID, or via some RPC).
A more appropriate term for Location Sighter would seem to be Location
Generator - as something that generates or creates, in some IP protocol
syntax, location reference information field or fields (for example -
converts raw GPS coordinates into a Lat/Long/Alt coordinates that this WG
appears to prefer).
10. From section 3.1.1. Location Information (LI) and Sighting:
"In this case, Identifier-1 may be Pseudonym, and Location-1 may have
less accuracy or granularity than the original value."
This is the first use of the terms "accuracy" and "Granularity", yet in
Atlanta, the WG seemed to agree that "accuracy" isn't the correct term we
mean to convey, "Resolution" is (and "precision" along with it).
Resolution isn't mentioned anywhere within this document.
Further, in 9.3. Specifying Desired Accuracy in a Request:
"If the LO is used to request location information (leaving some
fields empty), it is not clear how to specify the requested
accuracy. Are the data types "country/state/city" and
"country/state" different data types or the same data type with
different "accuracy" or "granularity"?"
This section gives the most concrete definition of Accuracy, yet it is in
fact loosely defining the term 'resolution'. Accuracy defines something
that is within x number of measurement units from a specific point on a
referencable map.
Resolution is defined as being within a specific border or set of borders
on a referencable map.
Within a "country/state/city" seems to fit the definition of Resolution,
and not accuracy.
Granularity isn't defined within this document.
11. From 3.1.2. The Location Object"
"A main goal of the geopriv working group is to define a Location
Object (LO), to be used to convey both Location Information and
basic privacy-protecting instructions:
Location Object (LO): This data contains the Location Information
of the Target, and other fields including an identity or
pseudonym of the Target, time information, core privacy
policies, authenticators, etc. Most of the fields are
optional, including the Location Information itself."
This last line is troubling, and not explained. Why would LI be optional?
This section is a further reminder of how little is defined in the LI
section (3.1.1) about LI and what fields are mandatory (apparently none),
and which are optional, or even which are available to chose from (other
than a time field - but is that time field the time when the Target was
last queried for its location, or when the storing Server received the
location, or when the Server responded to the Location Request?). Section
9.5 mentions that this time field doesn't have a default format.
Somewhere, some device knows exactly where a Target is. What isn't stated
explicitly in this ID is that from that precise and complete LI field
group, policy can and will make the Target's location reply less precise -
perhaps (and likely) based on who asked for the information. There should
be cases where maximum resolution is provided (emergencies or just by
policy configuration for certain requesters). This isn't mentioned as being
available.
There is also no mention of the ability for the Location Seeker (another
hard term to use) to request an optional field be returned to it. For
instance, if distance and vector are optional LI fields, is the Target the
sole decision maker that it will include this information in the Location
Reply? What if the Location Seeker doesn't want this information? This has
a direct impact on the size of the Geopriv message (which is later stated
in the ID to be a concern).
12. From 3.1.3. Location Object vs. Using Protocol:
"The "using protocol" is the protocol that uses (creates, reads or
modifies) the Location Object. A protocol that just transports the
LO as a string of bits, without looking at them (like an IP storage
protocol could do), is not a using protocol, but only a transport
protocol."
This shouldn't be the definition of a using vs. transport protocol.
"...without looking at them..." is an unusual phrase in defining a
protocol's usage. Shouldn't this be defined as "transporting unmodified"
(the LI/LO) is a transportation protocol.
If this definition remains as is, doesn't that mean that SIP, for example,
could use LI fields unmodified in reference to any target device the UA
knows without any related Policy or Security information accompanying those
LI fields?
13. Further from this section: 3.1.3. Location Object vs. Using Protocol
"...Nevertheless, the entity or protocol that caused the
transport protocol to move the LO is responsible of the correct
distribution, protection, usage, retention, and storage of the LO."
Should read "...is responsible for the..."
And, what is meant by the term "...correct..." in this context. Is this not
based uniformly on the Policy and Security information contained within the
LO itself. If so, it should be stated here.
14. Further from this section: 3.1.3. Location Object vs. Using Protocol
"...are of two types: First, the Location Object definition MUST
include (optional) fields or mechanisms used to secure the LO as
such. The LO MAY be secured, for example, using cryptographic..."
What is meant by "...MUST include (optional) fields..."?
Fields are either optional, or mandatory, and so far in this document, no
fields are mandatory; therefore nothing is a MUST.
15. Further from this section: 3.1.3. Location Object vs. Using Protocol
"The security mechanisms of the Location Object itself are to be
preferred."
This last sentence seems out of place. Shouldn't the security mechanism
clearly stated within the Security Information fields of the LO be the
minimum level achieved when a Using Protocol includes the LI of a Target?
16. From 3.1.4. Trusted vs. Non-trusted Data Flows:
"The following terms distinguish
between the two basic types of data flows:
Trusted Data Flow:
A data flow that is governed by a pre-existing contractual
relationship that addresses location privacy.
Non-trusted Data Flow:
The data flow is not governed by a pre-existing contractual
relationship that addresses location privacy."
This doesn't seem to cover the case of non-contracted, but Security
Association configured "trusted" data flows. For example, not all employees
of the same company will necessarily have a contract in place when
exchanging LI. Me and my wife might not either. Yet if the devices are
configured to transfer LI between themselves in a secure manner (perhaps
matching or exceeding Geopriv's minimums), that should be considered
"trusted". PGP is an example of trusted data flows, yet there is no
contract between parties that should not be expected between some Geopriv
parties.
17. From 3.2.1. Primary Geopriv Entities:
Here is another location (aside from the Terminology section 3.0 & 3.1)
within the ID for terms and definitions. This should be in one place within
the ID.
18. From 3.2.1. Primary Geopriv Entities:
"Device" seem redundant and not necessary. Is it a Target? It seems as if
"A Target" qualifies and fulfills the role of "A Device". The term/phrase
"The Target" means a specific "Target" whose location is sought. Both are
nouns (1st and 3rd person) and can easily be used either way - therefore
reducing the number of terms used.
19. From 3.2.1. Primary Geopriv Entities:
"Rule Maker:
The individual or entity that has the authorization to set the
applicable privacy policies and rules."
This definition explicitly states that there is "one" controller of rules
or policies. A user should have control over their target(s), yet there
could easily be a situation where a domain (perhaps a company's internal
policy) might also have overriding control over part of the LI (perhaps
overriding the maximum resolution a Target gives in a Location Request).
20. More from 3.2.1. Primary Geopriv Entities:
"Location Seeker (LSeek):
An individual or entity who seeks to receive location data
about a Target.
A Location Seeker may act in one or more of the following more
specialized roles: as the Location Sighter, a Location Server, or as
an Ultimate Location Recipient:
Location Sighter (LoSi), or Location Data-Source
The original source of the sighting of a Target in a given
transaction.
Location Server (LServ), or Intermediate Location Recipient: "
Seems like the acronyms are hard at best to remember.
Seems like the Seeker can be a Ultimate Location Recipient. Why does this
need 2 terms? It imitates a Client/Server type relationship - and gives
multiple names for the Client and Server. How about a single name for each
- while defining each can have multiple roles? This is especially true when
reading that there is another term (Intermediate Location Recipient) possible.
21. More from 3.2.1. Primary Geopriv Entities:
"Ultimate Location Recipient (ULR):
An individual or entity who receives location data about a
Target and does not transmit the location information or
information based on the Target's location (such as driving
directions to or from the Target) to any party OTHER than the
Target or the Rule Maker."
Is the ULR (another hard acronym) still a ULR if the LI comes under the
control of a Using Protocol? If so, this seems like a "Geopriv Location
Seeker" endpoint (could be defined as one of its many roles); if not,
Geopriv shouldn't define the ULR for another Protocol that optionally
manipulates part of or all of the LO (including Policy and Security
Information Fields and requirements).
22. From 3.2.2. Secondary Geopriv Entities
"Data Transporter:
An entity or network that receives and forwards data without
processing or altering it."
Why does this term need to be defined? This involves the previously defined
"transport protocol" (from section 3.1.3) and has nothing to do with
Geopriv or its operations, does it?
23. More from 3.2.2. Secondary Geopriv Entities
"Initial Access Provider (IAP):
The entity that provides the initial network access or other
data communications services essential for the operation of
communications functions of the Device or computer equipment
in which the Device operates. Often, the IAP -- which will be
a wireless carrier, an Internet Service Provider, or an
internal corporate network -- will be identical to the LoSi.
In other cases the IAP has a "dumb" LoSi, one that transmits
geopriv data but does not implement or use any part of the
geopriv Location Object. Other cases may involve no IAP at
all or the IAP is only a Data Transporter. "
By any other name, this is the Internet and is an ISP, which is a defined
term within the IETF - as such, is not needed here.
How can a Network be a "Location Sighter"? Cell Towers might be used to
gather enough information to a collection server to generate LI worthy of
insertion into a LO for a Target. A satellite system (GPS) could also be
used for this operation. Neither is IP based, therefore shouldn't be
defined here, but can be mentioned.
24. From 3.2.3. Geopriv Data Storage Functions
"The existence and data storage practices of Location Storage is
crucial to privacy considerations, because this may influence what
Location Information could eventually be revealed (through later
distribution, technical breach, or legal processes)."
This paragraph should necessitate a requirement for storage policy being
included within the Policy Information of the LO for a Target.
25. From 3.3. Privacy Policies and Rules
"..."my location can only be disclosed to
the owner of such credentials and in such accuracy"..."
This is a misuse of the word "accuracy" and its meaning. Resolution and
(more likely only) precision are the coupled meanings that should be here
in the quote.
26. From 3.4. Identifiers, Authentication and Authorization
"...Unlinkability ensures that a user may make multiple
uses of resources or services without others being able to link
these uses together. Unlinkability requires that entities are
unable to determine whether the same user caused certain specific
operations in the system."
If "unlinkability" ensures the privacy of a Target, in essence, then how is
it to be used to bind a Location Seeker's unlinkable ID to authenticate a
Location Request to, and be successful?
If you don't know that it is me requesting your location, because of this
unlinkability, then how would you bind a rule or policy to my pseudonym and
grant me the ability you would have given me (had you known it was me
asking)? This is further called into question during the "id-B" example in
the next paragraph.
27. More from 3.4. Identifiers, Authentication and Authorization
"Authorization
The act of determining if a particular right, such as access
to some resource, can be granted to the presenter of a
particular credential."
This doesn't seem to allow for the concept of varying authorization, and
make the LI less precise based on who asked for it. This is a key piece of
most discussions within the WG form it's beginning.
28. From 4. Scenarios and Explanatory Discussion
There an example of GPS, of Cell Towers, and Mobile Communities and
Location-Based Services. There is no mention of a wired scenario (such as
Broadband Cable or DSL access, or Ethernet connectivity). This further
makes this ID appear to be a mobile/Cellular centric ID. Geopriv should not
be limited to wireless mind sets.
Additionally, any GPS communications is logical and shouldn't be mentioned
as a Geopriv scenario (there's no IP involved). Cell Towers aren't IP
based, therefore they too aren't under Geopriv's charter.
Once some Server that has gathered enough information about these cellular
devices, that Server might use Geopriv to communicate to other Location
Servers (this scenario could fall under Geopriv, or SOAP).
29. From SCENARIO 3: Mobile Communities and Location-Based Services
"...including Data Types and Accuracy."
This is the first mention of "Data Types". What are they? This is loosely
referenced, but not defined in Requirement 2.6.
30. More From SCENARIO 3: Mobile Communities and Location-Based Services
"1: Registration:
The Rule Maker registers himself and the Target with the
Location Server. This registration process is outside of the
scope of our discussion..."
Why is Registration of Geopriv Targets, Geopriv Servers and Geopriv Rule
Makers *not* part of Geopriv?
Further, it would seem that the Target would be doing the Registration to a
Location Service, and within that Registration would be a pointer to an
existing Rule Maker (the Target and Rule Maker should be the owners of the
policy for that Target) and an existing Rule Maker Policy Profile for that
Target. The text here has this process turned around.
If the Target is new to a Location Services Provider, then they should be
prompted to create a Profile (perhaps a resident file within the Target
waiting for upload - and also part of Geopriv). There shouldn't be any
location communications until the LSP has verified that it will grant this
Target access to its network, and the network will follow the Policy
Information and Security Information rules (kinda like a contract).
31. From 5.1. Location Object
"Req. 1. (Location Object generalities)
1.1) Geopriv MUST define one Location Object (LO) -- both in
syntax and semantics -- that must be supported by all geopriv
entities.
1.2) Some fields of the Location Object MAY be optional. This
means that an instance of a Location Object MAY contain the
fields or not."
Should be rewritten as follows (with new numbering that's not included here):
1.1) Geopriv MUST define a 'mandatory to implement' set of Location
Object fields to be understood by all Geopriv entities.
1.1a) Any Geopriv entity that transmits a maximum precision LO, provide
a mandatory to implement minimum set of Location Information fields in that
Location Reply (this should be similar to what is in the DHCP LO Option ID.
1.1b) A Location Sighter (term needs to change to Generator) MUST
include a mandatory minimum set of LI fields in its communication to the
Location Server.
1.2) Some fields within the Location Object MAY be present, or MAY not.
1.2a) All Geopriv entities MUST not fail a transaction if one or more
fields are not present, or not understood, if the Geopriv message is
acceptable under the Policy and Security rules for that Target.
32. From Requirement 2.5 Location Field.
"Each Location Field may contain one or more Location
Representations, which can be also in different formats."
This text seems to indicate the necessity of another ID defining all the
potential Location Information Fields (to ensure interoperability). Why was
this left so open?
33. From Requirement 2.7 Motion and direction vectors
This text should be under Req 2.5 - or this separate ID defining the LO, or
at least the LI and its mandatory and optional fields
34. From Requirement 3.2
"3.2) The Location Object SHOULD define two Location Data Types:
one for latitude / longitude / altitude coordinates and one for
civil locations (City, Street, Number) supported by all geopriv
receivers (entities that receive LOs)."
Civil addressing isn't understood throughout the world (as in there isn't
one way of expressing civil addresses). This should be an defined optional
LI Field which should be included if the Location Seeker asks for it.
35. From Requirement 3.3
"3.3) The latitude / longitude / altitude Data Type SHOULD also
support a delta format in addition to an absolute one, used for
the purpose of reducing the size of the packages or the security
and confidentiality needs."
In text format, as Geopriv is, this won't save any space in the Geopriv
message - therefore this doesn't make much sense to be a requirement.
36. From Requirement 3.4
"3.4) The Location Object definition SHOULD agree on further
Location Data Types supported by some geopriv entities and
defined by other organizations."
What is this requirement referring to? There are no examples, and nothing
comes to mind that could explain this requirement.
37. From Requirement 5.2. The Using Protocol
"Req. 4. The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the
corresponding Policy Rules regarding the transmission and storage
of the LO."
This is written as a MUST, where other text in other parts of the ID state
this is optional or preferred only;
From 3.1.3:
"First, the Location Object definition MUST
include (optional) fields or mechanisms used to secure the LO as
such."
And then:
"Second, the using
protocol may also provide security mechanisms to securely transport
the Location Object."
And then:
"The security mechanisms of the Location Object itself are to be
preferred."
38. From Requirement 15.3)
"The protocol SHOULD allow a bypass if authentication
fails in an emergency call.
The issue addressed in the last point is that an emergency call in
some very unfavorable situations my not be completed if the minimal
authentication fails. "
This requirement should be bound to a maximum precision of the LI fields
within that LO transmitted during these emergency situations - but that
text isn't present in this ID.
39. Section 6.3 refers to the emergency situation requirement 14.3, but
it's actually Requirement 15.3
40. From Emergency Case
"- "If the emergency server does not authenticate itself,
nevertheless send the location", or
- "If the emergency server does not authenticate itself, let the
call fail". "
Although this seems like a good configuration plan, but doesn't solve the
innocent bystander (a friend/colleague of the Target's owner) who might not
want this configuration when they place the emergency call.
41. From 9.4. Truth Flag
"Geopriv should not provide an attribute in object saying "I'm not
telling you the whole truth." "
This should be a requirement in this document - as it would give away too
much information to include it when the target is reducing the precision of
their location purposely.
42. From 9.5. Timing Information Format
"The format of timing information is out of the scope of this
document."
This will breed incompatibilities if there is no default specified, and
maybe even violate rules/policies that are based on the local or global
timing of the location request.
I'd like to cover these topics/questions/concerns.
cheers,
James
*************************************
"People generally demand more respect for their own rights than
they are willing to allow for others"
Received on Fri Jan 31 19:32:55 2003
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST