[Gen-art] Gen-ART LC review of draft-ietf-geopriv-http-location-delivery-07

[Ben Campbell <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-geopriv-http-location-delivery-07
Reviewer: Ben Campbell
Review Date:  2008-05-06
IETF LC End Date: 2008-05-07
IESG Telechat date: (if known)

Summary:

This document is almost ready for publication as a proposed standard.  
I have a few questions and comments that should be considered prior to  
publication.

Comments:

-- Substantive comments:

-- I am a little bit confused by the scope of applicability of this  
draft. Section 3, paragraph 1 says "This document assumes that the LIS  
is present within the same administrative domain as the Device (e.g.,  
the access network)." However, section A.3. claims compliance to a  
requirement to the effect of "The design of the L7 LCP MUST NOT assume  
a business or trust relationship between the Application Service  
Provider (ASP) and the Access Network Provider." (It is possibly I am  
misunderstanding what ASP means in this context?)

Furthermore, certain aspects of HELD seem to require fairly tight  
coupling between the LIS and the access network. For example, the NIS  
needs to know about any range of addresses for which it is likely to  
have erroneous location info due to VPNs and NATs. The security  
considerations indicate that the network needs to be properly  
configured to avoid ip spoofing attacks, which would seem to indicate  
at least an administrative coupling between the access network  
provider. It goes on to make a normative statement that network  
configuration SHOULD be considered.

A paragraph or two describing the expected network architecture might  
clear this up. Maybe this is covered sufficiently in some of the  
referenced documents?

-- I would like to see a little more analysis on the safety of using  
the source IP address as the device identifier. My instinct says that  
reverse routeability may keep this from being a problem--but the  
security considerations do indicate source address spoofing could  
cause LI to be compromised, and add a list of approaches, "one or  
more" of which is recommended to limit the exposure. If there are in  
fact risks of compromise, I think the draft needs some more exhaustive  
and explicit statements of what I must do to avoid such attacks.

-- The lbyr requirements draft includes a SHOULD level requirement  
that a client should be able to cancel location references. HELD does  
not seem to allow for that capability. I know it was only a SHOULD,  
but was there a particular reason to leave it out?

-- Section 4.2: I understand that the authz mechanisms for  
dereferencing location URLs constitute a bit of an "elephant in the  
room". But do we really think it is useful to punt entirely on that?  
The referenced doc does not seem all that helpful on the matter. Even  
an example of a potentially useful approach might be helpful. (I  
realize this is not a HELD problem per se, but without some mechanism  
for it, I question the usefulness of location by reference in HELD.)  
(If we can point to a location dereference protocol and claim that  
spec solves this, then no problem.)

Section 4.3.1: Should there be normative advice in this section?


Section 6.2 and 6.2.1: I don't see an obvious way to say I only want  
to get location by value. Is that intentional?

Section 6.3, error code unsupportedMessage:

Wasn't there a normative statement ealier that the LIS MUST ignore  
anything in a request that it does not understand? If so, when would  
this get used?

6.5.2: Can you give any guidance about useful value ranges for  
"expires"? I assume very short expirations would not be useful.

6.6, last paragraph:

"Note that the presence parameter is not explicitly shown in the XML
    schema Section 7 for a location response message due to XML schema
    constraints."

Is that not a problem, since section 7 is the formal definition of the  
protocol syntax?

Section 8:

I'm a little confused by the fact that a HELD URI can show up both in  
a HELD response, and in LIS discovery. Does this use of a HELD URI  
imply the use of the HELD protocol? If so, how would a HELD URI in a  
locationReponse message be used? Since HELD uses the source IP address  
for the identifier, it is not useful to transmit the URI to another  
device, right?



-- Nits and Editorial Comments:

S1: Expand LIS on first use. (You do so later in paragraph.)

Section 4:

Paragraph 1

I realized at this point I had not yet seen an expansion of "HELD",  
nor a statement that HELD is the protocol being defined in this  
document outside of the document title. Maybe an official "naming"  
sentence in the last paragraph of the intro would help.

Also, this paragraph could use explicit references for pidf-lo and  
location URIs.

Section 4.3, paragraph 3: Please expand VPN on first use.

Table 1: Can you add a legend for o and m? I know it seems obvious,  
but better to be explicit. Also, listing locationUriSet and presence  
both as optional for responses does not quite capture the normative  
statement that one or the other MUST exist.

Section 5.2: Should there be normative language around the inclusion  
of locationType? (There is for the other parameters)


Section 6.2. "any" value: The normative statement that the LIS SHOULD  
return all available forms seems to mildly conflict with some of the  
further normative statements in the paragraph.

Section 12.5: URI Scheme Syntax says "See section" with no section  
number.






_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art