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".
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
