Subject: [Geopriv] Comments on HELD -04

From: Richard Barnes <[email-masked]>
Date: Wed, 30 Jan 2008 19:56:33 -0500

After a review of HELD -04, I think the document is substantially 
complete.  That said, I do have some comments in addition to those that 
have already been expressed  I've discussed a series of nits and 
editorial changes with the authors, and I would like to bring the 
following questions to the list.

--Richard

1. HELD URI
The specification of a HELD URI scheme in the current draft seems 
incomplete, in that it doesn't fully specify a dereference scheme. 
However, specifying a dereference scheme would essentially make 
draft-winterbottom-geopriv-deref-protocol a part of the HELD 
specification.  That is, if the HELD URI were completely specified, the 
base HELD spec would specify not only an LCP usage of HELD but also a 
location-by-reference usage.

On the other hand, I haven't heard a compelling reason that a HELD URI 
is necessary if the only supported use case is an LCP.  In that case, it 
seems sufficient for the endpoint simply to acquire a DNS name or IP 
address for the LIS, so that it can send a HELD/HTTP request to port 80 
on that interface (the Request-URI could be fixed in the standard, e.g., 
"/").  So if we only want the current draft to support the usage of HELD 
as an LCP, the HELD URI can be removed altogether.

So I think there are two alternatives:
a. Completely specify the HELD URI, including dereference by 3rd parties
b. Remove the HELD URI from the draft and only support the LCP usage
My personal preference is for the former, but I don't have any strong 
objections to either option.  However, we should decide on one of these 
two courses.

2. Document structure
Throughout most of the document, HELD is discussed as a single, 
integrated protocol, the notable exceptions being Section 5.1 and 
Section 8.  On the other hand, there are clearly two separate components 
to the protocol: The XML syntax, the transport/binding protocol.

The current draft needs to describe better the functions played by these 
parts individually as well as together.  This is crucial because as HELD 
is extended, these two parts will be used with different parts; 
different XML (e.g., adding identitifierss or measurements) over HTTP, 
or the same XML messages over other bindings (e.g., raw TLS, BEEP). 
(Obviously the first case is more likely!)  It will be easier to to make 
extensions secure and interoperable if the roles of the XML syntax and 
the binding are clearly articulated.  In addition, I think this will 
make the current draft easier to understand.

Consider target identifiers: It isn't clear from the current draft (at 
least to me) that the XML has nothing to do with the identifier used for 
the target; instead, the identifier is provided by the transport layer. 
    If you're implementing a LIS, this tells you to get the identifier 
from the whatever transport component you're using.  If you're writing 
an extension that runs over a new transport, it tells you that you need 
to specify an identifier to use.  If you're writing 
draft-winterbottom-geopriv-held-identity-extensions, it tells you that 
you need to explain how your XML identifiers interact with the 
identifiers the transport layer provides.

I don't mean to propose a radical re-writing of the document; I think 
most of the text is already there.  I'd just like to see it organized 
differently:
a. Syntax/semantics included in the XML
b. Syntax/semantics included in the binding
c. How the HTTP binding works in particular

3. Identifying information in location URIs
Section 6.5 (Location URIs) says that "A location URI MUST NOT contain 
any information that could be used to identify the Device or Target."  I 
certainly agree with the intent of this statement, but it's hard to say 
something concrete because (1) the security objective here is unclear, 
and (2) the LIS is inherently incapable of determining what "identifies 
the Device/Target".  For instance, a LIS operator might think that it's 
good enough to use a hash of an IP address instead of the IP address 
itself.  That would prevent guessing the IP from the URI, but would 
still allow the URI to be correlated with a known address, and would 
allow URIs to be guessed.  I would suggest that we add some more 
thorough discussion of this to the Security Considerations (I'll write 
up some text), and replace this statement with a pointer to that.

4. Response time parameter
Are people comfortable with the current level of specificity in the 
description of the responseTime parameter (Section 6.1)?  I have a 
little bit of concern over the inherent inability of the LIS to 
determine whether it has met the response time, but given that the 
language is non-normative, I'm not sure this requires a change to the text.

5. Caching
Section 8 says that "the "expires" and cache control headers are used to 
control the caching of any PIDF-LO document or Location URIs."  Should 
this say instead that the HTTP header for a locationResponse should 
disable caching?  I would vote in favor of this, since I don't really 
see a need for caching at the HTTP layer, given that the LIS and the 
endpoint should be pretty close to each other.  The LIS might cache 
location results, however.

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

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 31 Jan 2008 15:07:42 -0600

5. Caching

[MB] I guess I'm not seeing the advantage of what you propose. I'll
await other responses and hopefully those will clarify things.  [/MB]

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

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 31 Jan 2008 15:04:20 -0600

language is non-normative, I'm not sure this requires a change to the
text.

[MB] We've spent a good bit of time tweaking the text that is there
(take a look at the diffs for the last 3 versions).  I don't think there
is perfect text for that section given that we can't mandate LIS
behavior. So, unless someone has strong concerns, I'd rather leave that
text as it is.[/MB]

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 31 Jan 2008 14:58:26 -0600

3. Identifying information in location URIs Section 6.5 (Location URIs)
says that "A location URI MUST NOT contain any information that could be
used to identify the Device or Target."  I certainly agree with the
intent of this statement, but it's hard to say something concrete
because (1) the security objective here is unclear, and (2) the LIS is
inherently incapable of determining what "identifies the Device/Target".
For instance, a LIS operator might think that it's good enough to use a
hash of an IP address instead of the IP address itself.  That would
prevent guessing the IP from the URI, but would still allow the URI to
be correlated with a known address, and would allow URIs to be guessed.
I would suggest that we add some more thorough discussion of this to the
Security Considerations (I'll write up some text), and replace this
statement with a pointer to that.

[MB] That statement has been in the document since the WG -00. I think
we can handle the clarification either way - either adding text here or
the security section.  It's not uncommon to have security requirements
inline in a document and have the security section be a summary that
points back to the main document - this avoids a lot of redundancy in
trying to establish the context in the security sections. I think your
point is that this can only be SHOULD NOT - is that correct? In which
case, we should explain scenarios that might lead to the cases where it
might contain information that could be used to identify the device or
target. 
[/MB]