> 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.
...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?
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.
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.
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.
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. 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.
7. (Easy one) the draft uses "Rule Holder" when it means "Rule Maker".
--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
