Thanks for the review
At 11:48 PM 3/8/2010, Thomson, Martin wrote:
>Hi James,
>
> > I addressed what I believe is the final open issue [...]
>
>Open issues that I'm aware of or have just noticed:
>
>1. The means by which authorization rules are provisioned is not specified.
please provide some suggested text
>...nor is it declared out of scope. Hannes and I have argued the
>point that this cannot be deployed without this missing
>piece. Thus, this cannot be made out of scope just by declaring it
>so. It's not an impossible problem, even though it might be difficult.
>
>This remains my biggest issue with the document. It's been an open
>issue for a while. It might be nice to get WG consensus on this so
>we can stop wasting cycles on it (I think that it's been an open
>issue since the earliest versions of the doc).
>
>2. Has this document been reviewed by the DHC WG?
it will be cross-WGLCd just like the past IDs that involve DHCP,
unless things have changed that I didn't notice.
>I've been subscribed there for a while now and I've not seen any
>emails on this draft. I anticipate a problem relating to the way
>that this option does not use sub-options consistent with existing
>options. Two reasons: the existence of the ver and resv parts
>(which I argue are not necessary [1]), and the length of the
>sub-option code is usually different in DHCPv4 and DHCPv6.
>
>3. Valid-For is independent of the DHCP lease.
>
>I can see why this is necessary, but it introduces an interesting
>deployment problem. One major DHCP implementation I'm aware of (and
>use daily :*( ) does not update individual options independent of
>the lease. The only effective way to update options with this
>implementation is to release the IP address and renew it.
that isn't necessarily true, and I'm not going to propose limiting
this doc to how 1 implementation does things.
If the valid-for is the same as the lease time, then the valid-for
isn't necessary. That's why it's optional. Roger Marshall really
wants this, so I incorporated it, and there might be times where the
lease of an IP address (or other DHCP Options) is different than the
time a location URI is to be considered *not stale*. The two do not
have to be bound to the same timeframes, though sometimes they will
be. I believe it flexibility here.
>Thus, it's going to be hard to get an updated URI if it is valid for
>less time than the lease duration.
>
>4. RAIO (RFC 3046) is mandated with MUST-strength language.
>
>This is not necessary. While this might make sense where relays are
>employed, this is not necessary for successful deployment. In our
>(relatively small) office, we use a flat network that does not
>employ relay agents. This would not be an impediment to us
>deploying this option.
This is a fair observation. I'll change the text to say something like this
"RFC 3046 SHOULD be utilized, however, where relays are not
deployed, the RAIO Option is not necessary."
>Furthermore, the draft talks about movement. RAIO only provides
>information about the point of attachment when the DHCP request is
>made; later requests to the location URI might happen after the
>Target moves from this point. Thus, the LS and LG need to be able
>to handle movement.
a lot of the time, RAIO will be tied to the wiremap database, which
is necessary.
When a device is mobile, the RAIO will indicate which AP the Target
is attached to, so I also think this is necessary.
>5. URI length.
>
>Quoting the draft:
>
> Per [RFC2131], subsequent LuriElement Options, which are
> non-concatenated, overwrite the previous value.
>
>This is OK, though I don't think that 2131 says anything about this at all.
In past drafts, the DHCP WG did in fact correct me about the 255 length.
Their opinion is that if a URI is longer than 255 bytes, "you need to
pick a new URI".
Therefore something like what 3396 proposes should cover us pretty
well for the small number of cases that URIs go a little bit over.
>Even 3396 says nothing about this. Rules for handling sub-options
>are not defined for the general case, so it's good that you define them.
>
>Note that the draft talks about long URIs, which cannot be created
>based on these rules. It might be worth pointing out the 255 octet
>limitation (which could be fewer characters).
>
>6. URI character encoding.
>
>The draft is silent on the way that URI characters are encoded into
>a sequence of octets.
what do you suggest?
>7. (Easy one) the draft uses "Rule Holder" when it means "Rule Maker".
Even simpler -- RFC 3693 says "Rule Holder", so I'm not changing
anything. The idea of a "Rule Maker" might have been made up by me
for all I know, but it has permeated list and meeting discussions --
but it is not what the Geopriv Requirements RFC calls the entity.
Thanks
James
>--Martin
>
>[1] http://trac.tools.ietf.org/wg/geopriv/trac/ticket/26
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
