Subject: [Geopriv] Comments to draft-ietf-geogriv-http-location-delivery-01

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Jul 2007 21:15:11 +0200

I have read the draft and have a few comments.

Terminology
-------------

I strongly suggest not to define new terms in this document. PLEASE!!! 
We have already defined all of them.
If you copy terms from other documents, which I think is not needed 
either, then reference them and copy them without any change.
Redefining terms will cause a lot of confusion.

Use the term "IAP" and "ISP" rather than Access Provider (AP).

If you are not happy with the LCS term then we change it in the other 
LCP Req. document as well.

Don't define a new term for "device" -- use the term Target since we (a) 
used it in the past and (b) the Target term already covers the device

The term "Rule Holder" and "Rule Maker" are not relevant for this document

Overview and Scope
----------------------

"
This document is based on the attribution of the LI to a Device and not 
specifically a person (end user) or Target, based on the premise
that location determination technologies are generally designed to 
locate a device and not a person. It is expected that, for most 
applications, LI for the device can be used as an adequate substitute 
for the end user's LI. Since revealing the location of the device almost 
invariably reveals some information about the location of the user of 
the device, the same level of privacy protection demanded by a user is 
required for the device. This approach may require either some 
additional assurances about the link between device and target, or an 
acceptance of the limitation that unless the device requires active user 
authentication, there is no guarantee that any particular individual is 
using the device at that instant.
"

Delete that stuff. The term "Target" also covers the device -- not only 
person.

The document repeats the following aspect many-many times:
"
This document identifies two methods for acquiring LI. Location may be 
retrieved from a Location Configuration Server (LCS) by-value, that is,
"

I suggest to say it once or only a few times instead of repeating it 
with almost every section.

Protocol Overview
-------------------

"
The policy that describes to whom, and how, LI is granted is outside the 
scope of this document and MAY be specified in separate specifications 
as required.
"

No RFC 2119 language is needed.

I liked the following section. The SIP Location Conveyance draft also 
needs to contain that type of stuff:

"
   The details on the information that may be included in the PIDF-LO
   MUST follow the subset of those rules relating to the construction of
   the "location-info" element in [10].  The PIDF-LO generated by the
   LCS in this case MUST follow the rules in [10].  In addition, the
   default values for <retransmission-allowed> and <retention-expiry> as
   specified in [8] MUST be applied.  A default value of "no" SHALL be
   used for the <retransmission-allowed> element.  A default value of 24
   hours SHALL be used for <retention-expiry> value of any generated
   PIDF-LO documents.  An LCS MAY provide a shorter value for
   <retention-expiry> but MUST NOT provide a value longer than 24 hours.
"

What is missing is information what goes into the entity attribute.

Section 6.1:

Please delete the following text and the references to the listed protocols:

"
Candidate protocols that could be used to address these purposes 
include: TCP [17], TLS [2], SASL [18], HTTP [3], SIP [22], BEEP [21] and 
SOAP [25] [26].
"

Section 6.2:

"
It is anticipated that other Device identities MAY be provided through 
schema extensions.
"

RFC 2119 language not needed.

Section 7.2:

* Why isn't the default value defined for locationType since clients 
will not care about the format in most cases and the network may not be 
able to provide them with many different formats anyway. I suggest to 
have "any" as default. Then, you don't have a mandatory element

* I am not happy with messing location types with a request for an LbyR. 
I strongly believe that there is a need for an attribute, maybe called 
"locationReference" that can either be set to TRUE when a reference is 
requested. When the field is set to FALSE then LbyV is requested. If the 
attribute is absent then the client does not care about it.

* Doesn't a response need to indicate what information was returned. How 
should the client figure out whether it received "postalCivic" or 
"juridictionalCivic" ?

Section 7.2.1:

I don't think that the "exact" attribute is really needed.
I expect the following behavior:

   - I know what I want and I provide indication for it. If that stuff 
is not available then I receive an error.
   - I don't know what I want and then I set locationType to "any".

Section 7.3: What is the "message" parameter good for? What additional 
information would you convey? Does it really need to be there?

Section 7.5.1: Why cannot the client put the expires attribute into the 
request? I would make a lot of sense to allow the client to hint the 
desired lifetime of the LbyR.

Section 11: The examples don't correspond to the schema. For example, 
currently the locationType is mandatory but it is not include in the 
first example.

Section 13: Contributors

I don't think it is useful to list James, Martin and Barbara in the 
contributors section since they are also listed as authors.
I am also curious why Henning is not listed as a contributor since this 
proposal is really close to RELO.

Open Issue
------------

You might need to describe to what an LbyR actually refers to. Sure, it 
refers to a PIDF-LO but does that PIDF-LO that is returned via the 
dereferencing protocol may refer to the location at the time when the 
reference was created or when the dereferencing step is executed. I 
would even go as far as defining this aspect in 
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-context-00.txt.

You might want to include some text about the model you desire to have. 
There are essentially two models:

a) The client may indicate (via the locationType) to what the reference 
should apply to. The dereferencing protocol then just returns what was 
indicated.
b) Alternatively, you could just return a reference without indicating 
what is behind it exactly. The dereferencing protocol would then 
indicate what exactly it wants.

Realistically, you need to go for (a) anyway given that the 
dereferencing protocol my not provide any parameters and the "default" 
needs to be returned.
Model (a) has the advantage that the client is more in control of what 
is provided.

This aspect refers also the question of who converts location. Is it the 
LR or the LCS? In model (b) it seems to be the LCS and in model (a) it 
seems to be the LR.

Ciao
Hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jul 2007 18:49:25 -0500

Hi Hannes,

Thanks for your review and comments.  Responses and a couple questions
embedded below [MB].

Mary

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Saturday, July 21, 2007 2:15 PM
To: GEOPRIV
Subject: [Geopriv] Comments to
draft-ietf-geogriv-http-location-delivery-01

Terminology
-------------

I strongly suggest not to define new terms in this document. PLEASE!!! 
We have already defined all of them.
If you copy terms from other documents, which I think is not needed 
either, then reference them and copy them without any change.
Redefining terms will cause a lot of confusion.
[MB] Per responses to Barbara and Shida, the goal would be to delete the
duplicate definitions and only if necessary define new terms. Per the
text in section  the only new terms I'm aware of defined in this
document are Civic Location/Address, Geodetic Location and LI.  If folks
are aware of their definition in other GEOPRIV documents, let me know. I
should clarify though that the text that describes the source
definitions for the terms is still needed (e.g., LO is defined in both
RFC 3693 and RFC 4110 (differently)).  [/MB]

Use the term "IAP" and "ISP" rather than Access Provider (AP).
[MB] Is your suggestion considering Barbara's suggestion to replace the
use of the terms AP and Access Network Provider with the more generic
Access Network?  I think that approach works well for the current
content of the document and only impacts the introductory material.
[/MB]

If you are not happy with the LCS term then we change it in the other 
LCP Req. document as well.
[MB] The LCS terms was defined in the -00 when there was none explicitly
defined in the L7 LCP Req document, so I added one since it's an
important concept.  I did update (and modified slightly for readibility
only) the definition in the -01 to match the addition of that term to
the L7 LCP Requirements document. Per the response above and in other
emails, I'll remove the term in this document. [/MB]

used it in the past and (b) the Target term already covers the device
[MB] That term "device" is the same definition as exists in RFC 3693 (in
section 5.4).  I'll remove the definition per the comments above, but I
think the concept is still relevant.  Ditto for the term "Target" [/MB] 

The term "Rule Holder" and "Rule Maker" are not relevant for this
document
[MB] I agree they're not directly relevant, but they do make Figure 1
pretty and complete. I don't think it hurts to leave them in the figure
and they are consistent with the definition in RFC 3693.[/MB]

Overview and Scope
----------------------

"

Delete that stuff. The term "Target" also covers the device -- not only 
person.
[MB] Per my comment above, the terms "target" and "device" are
distinguished in RFC 3693. [/MB] 

I suggest to say it once or only a few times instead of repeating it 
with almost every section.
[MB] I'll try to minimize the repetitiveness (some of that is a result
of large chunks of text having been deleted, so it is now much more
repetitive).  [/MB]

Protocol Overview
-------------------

"

[MB] Agreed.

"

What is missing is information what goes into the entity attribute.
[MB] Alright.  I'll add some text to address that. [/MB]

Section 6.1:

Please delete the following text and the references to the listed
protocols:

"

SOAP [25] [26].
"
[MB] Agreed. 

Section 6.2:

"

[MB] Agreed.

Section 7.2:

[MB] Interesting idea.  Any other opinions from other folks on this one?

attribute is absent then the client does not care about it.
[MB] I don't have a strong opinion on this and I don't think it makes a
big difference in terms of implementations. Any other opinions from
other folks on this one? 

Section 7.2.1:

   - I know what I want and I provide indication for it. If that stuff 
is not available then I receive an error.
   - I don't know what I want and then I set locationType to "any".
[MB] This is somewhat related to the proposal to have the response
indicate exactly what you did get. [/MB]

Section 7.3: What is the "message" parameter good for? What additional 
information would you convey? Does it really need to be there?
[MB] It's optional, additional "human-readable" text.  I can't see that
it hurts to have that. It does seem like it's a nicety rather than a
necessity.  If others are strongly against it, we could remove. [/MB]

Section 7.5.1: Why cannot the client put the expires attribute into the 
request? I would make a lot of sense to allow the client to hint the 
desired lifetime of the LbyR.
[MB] But what would be the knowledge basis for knowing the lifetime.
That seems like that's something an application can do that wouldn't
need to be part of the protocol OR are you envisioning an LCS has
multiple LbyRs available with various expiry times and the client gets
one that is most suited? [/MB]

Section 11: The examples don't correspond to the schema. For example, 
currently the locationType is mandatory but it is not include in the 
first example.
[MB] Yep. That needs to be fixed. [/MB]

Section 13: Contributors

I don't think it is useful to list James, Martin and Barbara in the 
contributors section since they are also listed as authors.
I am also curious why Henning is not listed as a contributor since this 
proposal is really close to RELO.
[MB] James, Martin and Barbara aren't listed in the author's section
(i.e., on the title page). I did a funky thing with the authors list to
force this "Contributors" section in the document. But, there wasn't a
way around getting their addresses in the Authors' address section.
However, there is a note in the contributor's section that their
addresses are in the Author's section.
If someone is aware that this capability is available on the XML2RFC
toolset, please let me know.  [/MB] 

Open Issue
------------

http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-context
-00.txt.

[MB] It seems your suggesting changes to the above document and not
explicit text changes to this document at this time.  Is that correct?
[/MB]

Ciao
Hannes

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 24 Jul 2007 13:14:15 -0500

I just noticed that there was an error in one of my responses, so I've
snipped the rest below. 

Section 7.2:

* Why isn't the default value defined for locationType since clients 
will not care about the format in most cases and the network may not be 
able to provide them with many different formats anyway. I suggest to 
have "any" as default. Then, you don't have a mandatory element
[MB] "any" is already the default per the text in 7.2.  I wasn't paying
attention here as there was already a comment that there is an error in
Table 1 in that the locationType is listed as mandatory, but per the
text in 7.2, it should be optional.