RE: [Geopriv] New ID creating DHCP LbyR URI delivery Option

From: Winterbottom, James ^lt;>
Date: Tue May 15 2007 - 01:02:58 EDT

Hi James, I shall snippet at various sections to make sure that the points I am addressing are clear. > > the WG agreed they wanted a lower layer delivery protocol getting the > LbyR to the client/endsystem. This is how I see the DHCP part of > that request being done. My point is that the hum and subsequent agreement was about getting the Target a subscription URI so that they can get their own location (an indirect LCP), not about getting a reference to a Target to distribute to third-parties. Indeed the hum went against this latter proposal, the former being indirect, and the latter being direct. > >That aside, I have several concerns with this draft. > > You wouldn't be you without expressing concerns with someone else's ID > ;-) Touché!! > > >The first is that this does not seem to me to be talking about a > >reference for LCP, but rather a generic LbyR mechanism, that is it is > >providing a reference for third parties to dereference. It is unclear to > >me, what the relationship is between the DHCP server, and thing that is > >providing location, is the DHCP server being opened up to the general > >Internet for querying, or is the DHCP server being turned into an > >application server of some kind? A formal specification describing how > >the DHCP gets this information, and what it sets in the LIS needs to be > >defined, for much the same reasons that DHCP updates DNS records. > > This is a DHCP mechanism ID, without the non-DHCP parts intertwined > in the discussion. This makes for a short ID. Maybe, but it also makes the solution extremely incomplete, without the other being specified somewhere, this solution is not workable. Non-DHCP transactions > between the the DHCP server any any other device are not mentioned > here. This is not an architecture ID. So what is the architecture in which this solution slides? Without it, the solution makes little sense. Though I can quickly mention > something like "Non-DHCP information exchange is out of scope within > this document" and "what information gets populated at the LbyR URI > is out of scope of this document". I will add either/each if the WG > wants it/them. > Something needs to happen, and I think it needs to be a lot more than just pushing stuff out of scope. The document needs a strong reference to a document that does describe the architectural space in which this solution fits. > I probably should have a "It is assumed..." paragraph. > Assumptions are always dangerous.. ;) > > >My next concern, is that there is no support or mechanism of any kind > >for the end-point to specify to the LIS (or whatever the DHCP is > >getting/setting its information in) what options to set in the resulting > >PIDF-LO, or indeed who is allowed to access the information. > > That's not a DHCP transaction, therefore not in this ID. This is the problem I have, you can't half do this stuff, this is why DHCP is not appropriate for providing a location URI for distribution to third-parties. Quite simply it is not capable of providing the privacy sureties from the Target to the location server. > > Plus, this level of granularity (what options are set in a PIDF-LO) > is not appropriate within DHCP either. DHCP is not a deliverer of > rules from a user's client to a DHCP server. This is envisioned to > have to happen outside of DHCP, say via a web interface. I am sorry, this makes no sense to me at all. You are saying that the end-point has to learn about a webpage in the access network so that they can externally set their location preferences. This webserver is then connected (somehow) to a DHCP server, which retrieves a location URI and sends it to the Target? Why would I bother? If I can use DHCP like this, I can provide a URI to the HELD-based LIS and I am done, no extra interfaces required at all. > >This is not talked about at all in the security section and really needs > to be > >discussed. > > firstly, I don't view your point in the above (starting with "My next > concern, is ..." paragraph) as a security concern, warranting text in > the security considerations section. So having a reference that anyone can use, and that yields a PIDF-LO that describes my location and doesn't have my usage-rule settings in it isn't a security concern? I do beg to differ on this point, I see this as a major security concern and it needs clear discussion. > This ID describes DHCP as a transport of a URI, much like how Geo and > Civic locations are transported to the client/endsystem. What is in > the URI is not really germane to the transport mechanism, is it? I > agree it needs to be discussed somewhere, but isn't that more of what > goes in an architecture doc? If true, this isn't such a doc. It is a > mechanism doc. Security concerns are about the transport of the > info, its safety, integrity, any crypto options, etc... I state what > DHCP has defined to date in this area in the security considerations > section. > I guess that I don't believe that DHCP is suitable for conveying references or location in this fashion because it does not provide sufficient security measures. This becomes even more prevalent in wireless environments where data is potentially more accessible to third-parties. > > >My final first cut concern is that there is no reference made to the > >location by reference requirements document, or discussion on how this > >proposal meets those requirements. > > Perhaps this is a fair point. I'll look at that doc, and see what > applies to a protocol at this type of lower layer, and see about > incorporating what is appropriate from the requirements doc. > > BTW - is the LbyR reqs ID a WG item yet? I really have an aversion > to referencing to an individual ID, if I can help it. > It isn't currently a WG item but I think that the LbyR requirements document needs to become a WG item, or there is little point in building solutions. Cheers James ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]

Geopriv mailing list
Received on Tue, 15 May 2007 00:02:58 -0500

This archive was generated by hypermail 2.1.8 : Tue May 15 2007 - 01:03:07 EDT