[Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-option-06

[Richard Barnes <[e-mail]>]

-----
Draft:  draft-ietf-geopriv-dhcp-lbyr-uri-option-06
Reviewer: Richard Barnes
Review Date: 29 Sep 09

General Comments:

1. This draft is in pretty good shape overall, although there are a few 
critical sections that need to be added.

2. There needs to be tighter wording around allowed URI schemes and how 
the client processes the URIs it receives.  I would suggest using a 
different LUriType for each type of URI (sip/sips/pres vs. http vs. geo 
...) -- this will allow you to (1) save a registry, and (2) have 
multiple dereference schemes available for a URI scheme.  That latter 
feature could be very useful for HTTP URIs, for example.  This also 
avoids the issue of whether HTTP/HELD is included, since the HELD deref 
document can register a new LUriType for itself.

3. This document cannot mandate a policy for the URIs it carries, either 
access-controlled or possession-model.  The approach here should be the 
same as in HELD (they both provide URIs unilaterally, with no way to set 
policy): "Servers SHOULD apply access control policy to URIs; clients 
MUST assume that URI is not access controlled, since it has no way to 
know what the policy is."

4. The document needs to better define the format for LUriValues.  It's 
not clear that it makes sense here to just have UTF-8 strings (as RFC 
4776 does).  Suggest making Valid-For an integer of some fixed 
precision, and LocationUri a UTF-8 string.

5. Can multiple URIs be provided?  If so, how do the Valid-For 
attributes map to them?  Do all the URIs get the same Valid-For, or can 
I define different ones per URI?


Specific Comments:

Section 1, paragraph 2
s/Dereferencing a location URI/Dereferencing a SIP location URI/

Section 1, paragraph 3
s/having a PIDF-LO/having a location object/

Section 1, paragraph 8
Full stop after "given out".  Change latter half to: "In cases where 
multiple client have the same location, the unique URIs assigned to 
these clients can all reference the same location object, relieving the 
LS from maintaining each location individually."

Section 1, paragraph 9
s/vary, and/vary, according to/

Section 2.1 / 2.2
Make the formatting of the IPv4 and IPv6 sections the same.  Choose 
either the "XXX" or "option-" format.  Add an RFC editor note to fill in 
the assigned value for the option code in each case.

Section 2.3
As I mentioned above, this section needs to have a little more 
structure.  Suggest
1. Move Valid-For to LUriType=0
2. Change LUriType=1 to "SIP Presence URI" (sip/sips/pres scheme)
3. Add two sub-sections here, one for each LUriType
4. Move appropriate content under subsections

Section 3, paragraph 1
s/there is zero knowledge by the client/the client doesn't know/

Section 3, example URIs
A more realistic (tempting) example might be something like
    sip:[mac-address]@example.com
s/*this*/the/
Change "The entity= discussion is orthogonal to" to " The identity 
contained in the 'entity' attribute of a PDIF-LO is independent of the 
identification information in a location URI."

Section 3, paragraph starting "The deference..."
This paragraph is false -- the DHCP client needs to know how to handle a 
URI it gets, so this document needs to define (by reference) how such 
URIs are handled.  All that really means is that when you register an 
LUriType, you MUST point to a standards-track document (such as the SIP 
location-conveyance spec) that defines how URIs of that type are handled.

Section 3.1, Bullet 2
This discussion is exactly backwards.  It MUST be assumed that a 
location URI attained using DHCP will NOT operate under an authorization 
model, since the client has no way to know what policy is being applied.

Section 3.3
Delete this section, or move it up to section 2.3.2 (for LUriType=1=Sip 
Presence URI)

Section 4.4
Delete this section; this registry is unnecessary if we use 
LUriType=1=Sip Presence URI

Section 5, paragraph 1
Delete the first part of this sentence: "Where critical decisions might 
be based on the value of this location URI option..."  There's no need 
to qualify a SHOULD.  Remove the following paragraph break.

Section 5, paragraph 2
Change "It is not secure in a practical sense" to "It is secured only at 
layers 1 and 2."  Change "DHCP will be primarily..." to "DHCP is 
often...".  Change "to within a wire" to "to a wire".