Subject: RE: Questions and comments regarding geopriv-reqs-02

From: Cuellar Jorge <[email-masked]>
Date: Mon, 10 Feb 2003 19:20:51 +0100

Hello James,

thank you for your comments.  Here my replies:

> 1. Under what circumstances is LI optional within a valid LO (there are 
> *no* LI fields) - section 3.1.2?

We use the word "LI" (location information) in a more general form than 
"Location Field" (Req 2, part 2.5). "Location Field" is the method to
convey Location Information in a Location Object.  Thus I think, what you
ask is:  Under what circumstances is a Location Field optional within a
valid LO (there are *no* Location fields).

The answer is: always.  When do you want to send a LO without Location
Field?  Well, for instance, you may use a Location Object to *request*
location information.  In this request you usually have no Location Field,
only the requested location data type. A Location Sighter may (in some
scenario) tell a Location server that he has spotted some target X, without
giving further details on the location.  This may be useful already ("user A
is in France") or the Location Sighter may be sending this information as
part of a query ("do you need information for this target? At which rate or
on demand?").

> 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.

Sure, we want also the LO to be used for publicly available Location
Information, the comment is only to stress that the draft concentrates on
privacy requirements and not on general requirements on the LO format.

> 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?

Yes, Allison responded already to the question in the same way I see it:
the geopriv requirements document has emphasis on the
privacy requirements for the protocol - and its scope doesn't
include the structure of the location information.

This is what we have to do next ;)

> 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.

This is (almost) true. One thing that may be considered is the possibility
for the use to write "meta-policies" delegating part of his policy-making
to a domain.  But how this can be done in a secure and private way is still
a research topic.  On the other hand two things:

- there may be "emergency case policies" or "legal interception policies"
that in fact will override the users policies, no matter what we do in
geopriv.

- how exactly the authorization is given to "policy maker A" for writing
the policies of a user (sometimes also A, sometimes the parent of the child
or the owner of the tracked car or whatever) is not specified by the
protocol.  This seems to be more a matter of "registration" of a new device
or user into a system.

> 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).

True.

> 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"

Yes, the focus of the document is on privacy.

> 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?

No, the document does not cover "all that is mandatory" to implement.  There
are still many points open.  What the document want is to clarify what are
the privacy requirement, so that we can make further progress with other
parts of the specification.

> 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).

You are right: the possibility of a configuration protocol sending the
Location  Information to the Target at boot time (or some other time)
should be included, of course.  But how this information was entered into
the system is still out of scope for us.

> Is one of the requirements of LI to state in which way the LI was 
> determined? It seems to have been written this way.

No. We will add a remark. Also the emphasis on private information is
misleading at this point (Location Information may be as you have said,
public).

> Doesn't seem like we should care how the LI was determined, just that it
is 
> a format Geopriv can use.

True.

> 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).

I am not sure I understand...

> 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.

Yes.

> 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).

Yes, Location Generator has been proposed some time ago, and I would
support it.

> 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).

Could you define "Resolution" and "precision"?  I have no problem in using
them.  And what is the difference to "accuracy" and "granularity"?

> 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.

Thus, I read this as saying the accuracy is a particular form of resolution.
(Because accuracy defines something that is within a specific circle on a 
referencable map).  Yes, we are using accuracy in a quite general abstract
form.  Resolution is probably better.

> Within a "country/state/city" seems to fit the definition of Resolution, 
> and not accuracy.

> Granularity isn't defined within this document.

In San Diego we agreed on granularity...  But resolution seems still better.

> 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?

To use the LO for requests, as explained before.

> 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.

Not yet, this will be important, of course, but we wanted to concentrate on
the privacy stuff.

> 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.

A particular case of filtering is using no filter, or a particular case of 
sending "in general a less precise or a computed version of the information
is being delivered" is sending full resolution. This will be made clear in
the text.

> 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).

This is a difficult question. But we have not decided yet, how location
requests will really look like.  Perhaps it is at least partly a matter of
the "using protocol".

> 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.

No, or classification is not base on only modifying the LO, but on reading
it, or "using" it.  If you read the LO to get the identity of someone or
whatever, you are using the geopriv object.

> 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?

SIP would be using the LO.

> 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..."

Yes.

> 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.

It is base on the policies applicable to the LO, which are given in the LO
or referenced by it or were known by other means by the entity or
protocol that caused the transport protocol to move the LO.  The point is:
I only send (if I am geopriv compliant) the LO to someone who knows how to
use it.  If he uses some low-level ip storage transport protocol to move the
object
into some SCSI ip device, he is still responsible for the data, not the 
scsi ips protocol.

> 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..."?

The definition MUST include the fields.
The field themselves are optional.

> 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?

The point is: the LO may say "this LO has to be encrypted".  Or it may be
partly encrypted, and in the Security Information fields information about
which encryption methods or which keys ("security associations") were used.
We prefer the second choice.

> 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.

This whole world if trust is very subtle.  I could give you more cases.
In this part of the document, the authors want just to point out the case
where there is no pre-existing contractual relationship, which is more
problematic than the other one.  The one you mention lies in between two
extremes (the Non-trusted and the trusted and secured one). 

> 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.

Yes, we'll review this.

> 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.

Yes, we have discussed this many times.  And I agree: The term "Device"
seem redundant and not necessary.  But if the target is for instance a
person, then there is some value of talking about how the location
information of one or several devices (which may be lost or stolen or used
by several people) are used as "proxies" for the target.

> 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).

Actually I do agree.  But there has to be some proof the user agrees
too on that.

> 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? 

Because the seeker may pass this information further (he may be also a
Location Server)

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.

We do not want to distinguish the entities or roles from the point of view
of one protocol run, but from the point of view of  privacy considerations
and requirements.  The ultimate location recipient has very different needs
than an Intermediate Location Recipient form that point of view.

> 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).

The question is here not manipulating or using the LO, but passing it
further.

> 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?

Yes, from a purely protocol perspective, it is outside of the operation of
geopriv. I *may* be different from a "transport protocol" (from section
3.1.3) in the sense that it can be used *before* geopriv comes in place. In
any case, the point is that we have to make sure that such Data Transporters
do not introduce more privacy or security leaks.  The purpose of the
definition is just to introduce an entity, so we can talk about it later,
when we need 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.

The IAP can also be a WLAN provider (not necessarily the internet provider)
or a corporate network, or something else.

> How can a Network be a "Location Sighter"? 

This text is misleading. The LoSi can be *part* of that network or IAP. 

> 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.

It is mentioned, because there are privacy concerns here.

> 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.

Yes, I see something like "this data must be kept secret (or even
encrypted) as part of the policy. But we have not reached consensus
here. All those questions have been moved to the "core-policies" draft.

> 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.

Fine.

> 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?

Depending on the context, sometimes I want pure unlinkability (Say: "there
is one customer on the line A", or "there are 27 vehicles on this part of
the road") without that any identifiable information is disclosed.  In other
cases I want that some people may have the information linked, other not.
For instance if I ask twice where you are, I may link the 2 pieces of
information. But perhaps the system is generating 2 unlinkable requests
("where is xyz001" and "where is abc789") and a privacy friendly technology
is able to resolve the queries correctly.

> 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.

Of course it must be known that the requestor is authorized, but this in not
done via identification.

> 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, 

Sure, authorization may vary (over time), why not?

> 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.

Sure you may have authorization for a given resolution, other people for
another resolution : in the 2 cases, the system has to filter the
information differently.

> 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.

True.

> 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).

Yes.

> 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.

Civil vs. lat/long for instance. You may also think that
"country/state/city" is
a different data type than "country/state/city/street/number" (or that they
are 2 resolutions of the same data type).

> 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?

Registration is the process of making the contracts with the ISPs or Mobile
Carriers or geopriv service providers.  At this point you, the user or rule
maker, have to show that you are entitled to "make the policies" for this
device under these or those conditions, or using a particular password, etc.

> 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.

Say, the target is a car of an infant.  The owner of the car or the parent
of the child, the rule maker, would be doing the Registration, not the
target. I do not think the text is reversed.

> 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).

The LSP may have no network at all, so I do not understand "until the LSP
has verified that it will grant this Target access to its network".

> 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.

Perhaps: "receivers". Senders-only do not have to understands all.

>     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.

I don't understand the requirement.

>     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.

This seems to be requirements on a using protocol (or in a very determined
scenario).  I do not see why this is needed.

>     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.

I don't understand the requirement.  But if the Geopriv message is not
acceptable under the Policy and Security rules for that Target, then it
should not use it.

> 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?

We have to make sure that in the draft that defines the LO the 
obligatory formats for Location Information Fields are defined.  And a
method for expanding the LO formats.

> 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.

Yes.

> 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.

I do not think. Large numbers (even in text) require more space than small
numbers.

> 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;

No this is a MUST.  In other part it is said: there are many ways of
securing a LO.  We prefer the LO-security itself, not just transporting
the LO securely.  This is like preferring IPsec to TLS or preferring
xml-security than securing SOAP with TLS.

But I understand what is causing your confusion, this has to be clearer on
the draft.

>               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."

Yes.  The LO should offer LO-"intrinsic" security (if it is xml then
xml signatures, etc).  The using protocol may take care to use
further security (like IPsec or TLS).  We prefer the "intrinsic" one.

> 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.

I am not sure what you mean "should be bound to a maximum precision". The 
information must be sent in full resolution, yes. There is no need for
authentication here.

> 39. Section 6.3 refers to the emergency situation requirement 14.3, but 
> it's actually Requirement 15.3

Thanks.

> 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.

How would you solve the case?

> 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.

I do agree, but it has raised much debate. The problem is: if you ask for
resolution X and you get resolution Y, is this because the server is not
telling you the whole truth?  If you send information in Lat/long, should it
be evident which resolution you are sending? This is for later
consideration.

> 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.

This must be done soon, but we wanted to concentrate on other type of
questions first.

----------------

Best regards,

Jorge

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 13 Feb 2003 16:34:29 -0600

Jorge (and list)

I've decided to break up this reply to cover the list of questions and 
comments - and Jorge's replies - in groups of 10 because this email is 
already so large. This hopefully will get others to comment on specific 
points they are interested in.

At 07:20 PM 2/10/2003 +0100, Cuellar Jorge wrote:
>location information.

I am going to send you my LO Policy Information and Security Information 
when requesting your LO?

I see a Location Request as just that, a Location Request. I don't believe 
my LO has anything to do with your LO. So I'm not understanding what you 
intend yet.

>In this request you usually have no Location Field,

I believe in your example, you are providing an example of me including my 
LI in my Location Request to you (your device). I believe the LRQ 
packet/message is orthogonal to my LO, therefore I wouldn't include even my 
partial LO. I believe there should be a negotiation/request mechanism 
within the Location Request message where I request a single or set of LI 
fields that aren't what is determined to be default for all replies (for 
example, your outside temperature, or vector - both of these will likely 
not be in Geopriv's default LI Field Group.

>privacy requirements and not on general requirements on the LO format.

I agree this comment should be there, but I believe we should have text 
stating anything location-based can be included regardless of how well its 
known.

>This is what we have to do next ;)

But in order to determine this structure, we should have a requirements doc 
just for that structure (of the LI fields) to have a meaningful discussion 
that has a reference. Do you agree with this?

>protocol.  This seems to be more a matter of "registration" of a new device

I can see a clear case where an enterprise/government provider does NOT 
want devices providing too precise a location, and having a set policy to 
configure all Target and Location Servers to this mandatory maximum precision.

>Yes, the focus of the document is on privacy.

Privacy yes, but the amount of privacy could change (be more or less) based 
on the amount of LI given. This is the foundation for the Resolution 
Fields; in other words, if device X gives location precision that is down 
to the millimeter, that Geopriv message should be considered for higher 
privacy controls than if device X merely gave the location precision of 
1/6th that of the Earth (for where it is). Then there might not be very 
much (or no) privacy controls.

I believe this varying in precision should directly affect the level of 
privacy applied to an LO for any device.

>parts of the specification.

The text should be modified to state

>should be included, of course.

Thank you

>But how this information was entered into

agreed

>No. We will add a remark.

good

>Also the emphasis on private information is

I think this is important

> > a format Geopriv can use.

good

>I am not sure I understand...

I'm referring to the transmission of non-IP or non-Geopriv information 
elements that can be gathered by a Geopriv aware device. This Geopriv aware 
device is the first device this WG should have scope over (and define 
'stuff' regarding it).

> > it is mentioned here explicitly.

I would prefer to call this "generation".

Location Generation:
    The gathering of Location Information, perhaps from multiple sources,
    at an IP-based server which communicates with other Geopriv Entities
    (or Geopriv devices or something along these lines)

>Yes, Location Generator has been proposed some time ago, and I would

See above for a rough definition of it

>them.  And what is the difference to "accuracy" and "granularity"?

It's an issue of perspective. Accuracy is a perspective from the Target 
outward (i.e. I'm X number of measurement units[feet, meters, miles, etc] 
from this point Y. This places a burden on the Target to know how to make 
this Location Information less granular.

Definitions:

Accuracy: The ability of a measurement to match the actual value of the 
quantity being measured

         This states that the measurement could be incorrect, which should 
be a flaw in our choice of its use.

Resolution: The fineness of detail that can be distinguished in measured area.
    Geopriv applied: The fineness of area within provided, and closed, 
borders (ex. Latitude and Longitude boundaries)

Precision: 1. The state or quality of being precise; exactness; 2. The 
ability of a measurement to be consistently reproduced; 3. The number of 
significant digits to which a value has been reliably measured.

Geopriv should give a truthful reply to Location requests with the use of 
both Resolution and Precision. We SHALL state the defined borders a Target 
is within, yet the Target SHOULD control the precision (or exactness) of 
how large an area is provided in that reply.

>form.  Resolution is probably better.

Thank you

>In San Diego we agreed on granularity...  But resolution seems still better.

cheers,
James

               *************************************
"People generally demand more respect for their own rights than
                          they are willing to allow for others"

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 17 Feb 2003 12:52:41 -0600

>Hello James,

Here are my responses to questions and comments 11-20 for list review

>To use the LO for requests, as explained before.

I am still somewhat confused and might be missing something. Are you 
stating that the LO should be utilized for a Location Request?

This seems to my to be unnecessary. Should Geopriv merely define separate 
packet formats for "Location Request" for when a device wants the location 
of a Geopriv Target?

In this same vein, there needs to be something to satisfy one of John 
Morris's suggestions - that is to have a packet format to "notify" a Target 
(if it's Geopriv aware) that it's Location has been requested (to keep the 
Target in the loop, so to speak). This "Notify" message doesn't need a LO 
within it, especially since there should be a Security Association between 
the Location Server and the Target already in place.

I believe we will end up with several message formats that don't require 
the LO be present. Including the LO in these packets will make the overall 
message long, cumbersome, and contain not-necessary information (which we 
should avoid, IMO).

>Not yet, this will be important, of course, but we wanted to concentrate on

This, too, suggests that there ought to be a separate LI Reqs ID for 
pointed, open discussion on what should be in this LI portion of the LO

Thank you

>requests will really look like.  Perhaps it is at least partly a matter of

I believe we should make it a requirement that there be some form of 
negotiation capability within the Geopriv Location Request  message. Within 
this LRQ message, the Location Seeker could include which LI fields it 
wants returned to it (of course, other than those that are deemed mandatory 
- if this occurs).

Maybe I'm thinking down the road about having these multiple packet formats 
too much within my questions when I refer to asking why LI would be 
optional. If there is only ever one Geopriv packet format, the LI will be 
optional. I'd like to hope that we create a few packet formats/messages 
(Location Request, Location Reply, Location Reject, Notify, Location 
Update, etc)

>whatever, you are using the geopriv object.

OK. I believe the text should explain this more so as to relieve potential 
confusion in the future. I have a feeling the Distinction of a Using 
Protocol vs. a Transport Protocol will become a bigger "thing" as LI starts 
getting incorporated into other Protocols. Defining it here more, will help 
this WG.

>SIP would be using the LO.

With your added paragraph above, I understand. I didn't before.

>into some SCSI ip device, he is still responsible for the data, not the

OK

>The field themselves are optional.

I don't understand. If Geopriv were a binary protocol, this would make 
sense to keep the correct format of the packet or payload. Since Geopriv is 
Text-based, it will rely on Headers. Are you suggesting that all Headers 
possible be present even if the Header-Field is blank? I hope not. I hope 
that the Geopriv Protocol includes those LI Headers that have compliant 
values within their respective fields, and *not* include blank headers. 
This is a waste of data that serves no purpose that I can see.

>We prefer the second choice.

Interesting

>extremes (the Non-trusted and the trusted and secured one).

I would still prefer there to be one piece of text (one sentence) stating 
something to the effect that two or more Geopriv aware endpoints can 
exchange LI if each trusts each other through some manual key/token 
exchange (like PGP or something similar).

> > within the ID for terms and definitions. This should be in one place

OK

>by several people) are used as "proxies" for the target.

I agree that we've discussed this many times. I read the ID's text to state 
that a Target is the Geopriv Device who's location is be sought after and 
that moment; and that any device *can* be a target (just not currently 
elevated to that level within this text).

>Actually I do agree.  But there has to be some proof the user agrees

I agree with your comment as well. This can be done within an employment or 
service contract, for example.

>Because the seeker may pass this information further (he may be also a

At that point, the Seeker is a Proxy (acting on behalf of other devices for 
Requests and Replies - it's still a Proxy). We might define a Location 
Server to be able to act as a Proxy, then use the term as a verb and not a 
noun. I'd be OK with that, but interchanging causes confusion.

>than an Intermediate Location Recipient form that point of view.

I think that distinction should be made when the protocol is built, and 
left at a higher level (not defined as much) within the Reqs ID. So I guess 
I questioning the reason for defining a ULR this early

cheers,
James

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 17 Feb 2003 13:47:23 -0600

>Hello James,

Here are my responses to questions and comments 21-30 for list review

>The question is here not manipulating or using the LO, but passing it

But at that point, it's outside the scope of Geopriv. It might not even be 
IP at that point. I believe the ULR is the end of the line of Geopriv aware 
devices and we shouldn't necessarily go farther in definitions.

>definition is just to introduce an entity, so we can talk about it later,

Later...?   OK, I'll let this one rest

>or a corporate network, or something else.

Then any or all IP networks can be IAP. This seems like a hard group to 
define and I don't understand the purpose of this except for when lawyers 
get involved (no offense John).

>This text is misleading. The LoSi can be *part* of that network or IAP.

fair

>It is mentioned, because there are privacy concerns here.

I'm not sure how privacy concerns here are in scope of the IETF if they are 
not IP based

>here. All those questions have been moved to the "core-policies" draft.

Then maybe that ID should be referenced here?

> > (more likely only) precision are the coupled meanings that should be here

Thanks

>Of course it must be known that the requestor is authorized, but this in not

But identification is how you create your rules that allow certain people 
(or devices certain people own) to get/receive more precise - or any - 
information in the first place. I currently don't see this being a 
requirement we can fulfill without limited the ability of our devices to 
allow appropriate replies. This seems like a loop that can't be satisfied 
when coupling the two requirements.

>Sure, authorization may vary (over time), why not?

This seems binary to me (you have authorization or you don't). And without 
authorization, your Location Request fails. Remember, we want to categorize 
Location Requests into levels of precision too. If authorization is binary, 
we can't. This is what I mean by varying levels.

Or do you believe this is a multi-step process in which authorization 
determines that your request can be granted, then who you are determines 
what the reply will be?

If you answer yes, then I think you fail to resolve my comments to Question 
#26 above (lacking identify of the requester through the use of pseudonyms)

>another resolution : in the 2 cases, the system has to filter the

But how do you determine who is who if pseudonyms are used?

> > be limited to wireless mind sets.

Thank you - can there be a small piece of text to this within the ID?

>are 2 resolutions of the same data type).

wow, that could get quite complicated once you add up all the potential 
variations of this.

Henning and I did this exercise for his work office, and determined that he 
had (if memory serves) 11 Header fields involved just to get to him. That's 
a lot of unique Data Types to be registered when we get into the way 
various countries use postal or civil addressing

>device under these or those conditions, or using a particular password, etc.

What about when a mobile device becomes mobile outside of its home domain 
network? The way you explain it above, it would lose contact with its core 
LSP and the IAP wouldn't recognize it. Shouldn't there be something like a 
roaming registration of cellular systems in our architecture? This would 
likely involve some form of registration with the new Service Provider, I 
would think.

>target. I do not think the text is reversed.

Once that car of the infant crosses jurisdictional boundaries (county, 
province, state, country, etc) and leaves its home Location Service 
Provider's network, how does that car communicate via Geopriv in any 
direction? How does any Location Request get an appropriate response 
(remember - there would be no Sighter in this "other" jurisdiction)? The 
new LSP won't recognize it because there is no contract. It can't sent out 
a Location Update or determine where it is... nothing.

>has verified that it will grant this Target access to its network".

Say your cell phone is Geopriv compliant, and you have a contract with an 
LSP in your country. you travel to this country. Even though this country 
has a Geopriv Service Provider (I know, wishful thinking - just like cell 
coverage's "promise") you would lose contact until you returned home.

I don't believe we want Geopriv to be this limiting. We want there to be a 
solution for roaming (via some registration type process that perhaps 
checks the validity with your home domain and then chooses whether to honor 
it of not - under your policy/privacy rules)

cheers,
James

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 17 Feb 2003 14:58:27 -0600

>Hello James,

Here are my responses to questions and comments 31-42 for list review

>Perhaps: "receivers". Senders-only do not have to understands all.

Fair correction. But shouldn't senders-only have to provide some mandatory 
to implement set of fields for interoperability reasons?

>I don't understand the requirement.

This is for emergency cases - and I think we agree that this is a special 
case that requires a separate definition.

>scenario).  I do not see why this is needed.

The Sighter or Generator doesn't have policy contained within it, so it 
should be mandatory to have that device send the complete, most precise LI 
for all potential Geopriv Targets it is the Sighter for. The LS then 
applies the Policy to all inbound requests.

>acceptable under the Policy and Security rules for that Target, then it

I'm stating the opposite, and agree with your comment (2nd sentence above). 
If a Location Seeker doesn't understand a particular field that is included 
within the reply, it shouldn't fail the transaction. If a Location Server 
doesn't understand a Location field, it shouldn't fail the transaction. 
This requirement is for the cases of extensibility when one side of the 
Geopriv process in any direction provides more information than the 
receiver understands.

>method for expanding the LO formats.

Do you mean Location Fields or Data Formats?

> > LI Field which should be included if the Location Seeker asks for it.

Ah, then you believe some notion of a Location Request containing the LI 
Fields it wants to receive? I think this is necessary, and we don't need 
much detail, but a little text should be added to this ID mentioning this 
(it is a FW ID as well).

>I do not think. Large numbers (even in text) require more space than small

OK... hmmmm

How do you represent a ~10ft change in position over some interval of time, 
moving 287 degrees from True North - and have that number of headers added 
(much less the difference in total byte count) to the original reply equal 
less than just giving new Lat/Long/Alt?

This also places the burden of this change on the Target - which might 
support the Fields involved, but not support the processing power to keep up.

I think this is a good idea that should fall under the "Optional LI Fields" 
area (meaning MAY not SHOULD).

>further security (like IPsec or TLS).  We prefer the "intrinsic" one.

All of my question #37 was pointing out inconsistency in the text. I agree 
that it should be a MUST

>information must be sent in full resolution, yes. There is no need for

I believe the text should state "full resolution" (as you stated with your 
reply).

> > it's actually Requirement 15.3

Glad to help  ;-)

>How would you solve the case?

I think the default should be limited to "send the LI". If the user of the 
device changes the configuration to "MUST authenticate (even a emergency 
response center) or the call fails", then the innocent bystander has the 
owner of the device to direct any action (legal) towards, and not the 
device manufacturer - which is always an expensive uphill battle with a 
manufacturer's legal resources.

>be evident which resolution you are sending? This is for later

That's why I brought it up here on the list, to have more discussion about it.

OK

cheers,
James