Subject: [dhcwg] Alternative GEOPRIV perspective on draft-ietf-geopriv-dhcp-lbyr-uri-option

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 10 Oct 2011 12:22:41 +0800

This is response to the discussion here: <http://www.ietf.org/mail-archive/web/dhcwg/current/msg11958.html>.  I haven't been subscribed to the DHC WG, so I hope that you'll excuse the starting of a new thread.

It appears that the discussion is getting tangled up in the issue of expiration.  We DID have a discussion in GEOPRIV, but there wasn't a satisfactory conclusion, from what I can tell: <http://www.ietf.org/mail-archive/web/geopriv/current/msg08362.html>.  We sort of spiraled off on other topics.  More on this below.

There are other aspects to the draft that I've had my own concerns about.  In particular, the need to provide different URIs to different clients, as discussed here <http://www.ietf.org/mail-archive/web/dhcwg/current/msg11972.html>.  This is a big concern when client-controlled authorization policies are used for different URIs [RFC5808].  In that case, a different URI MUST be provided to each different client, or a different URI for every request.

I might disagree with Ted about the ability of DHCP to do this.  A DHCP server _could_ provide a different URI in response to every request and satisfy the requirement.  However, if the point was that no DHCP server in existence would be able to do this without extensive (and probably incompatible or destructive) modification:) ..then this truly isn't viable.  The draft does imply that authorization by possession must be assumed; it should probably go further than that if this is a hard constraint.

(This is a bigger problem with <http://tools.ietf.org/html/draft-ietf-geopriv-policy-uri>, which attempts to add client-controlled authorization policies.)

--
On expiration, there's an alternative perspective that could be used to alleviate the "valid-for" concerns.  Though this might not make a jot of difference to already expressed opinions if it were implemented in the draft...

Movement of a mobile host does not invalidate the URI.  When we do location by value (c.f. 4776, 6225), the value becomes invalid as the host moves.  The entire point of adding the layer of indirection is to allow for movement without invalidating the information that DHCP provides.

In an ideal implementation, the URI would be cool [1].  That is, the URI  is unchanging, though the resource that it identifies might change (as the host moves), or be removed (as the host leaves the network, or when a certain time elapses).  In practice, there might be reasons for the URI to be less than cool.

The "valid-for" applies not to the URI, but the resource that it refers to.  There is no inherent reason, other than convenience, for the resource to have a lifetime that is tied to a DHC lease.  A shorter duration would probably be bad because it's hard to justify a lease renewal for the purposes of acquiring an updated parameter, but longer is probably OK.

--Martin

[1] <http://www.w3.org/Provider/Style/URI.html>