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

From: James M. Polk ^lt;>
Date: Tue May 15 2007 - 00:30:22 EDT

At 06:39 PM 5/14/2007, Winterbottom, James wrote:
>Hi James,
>An interesting draft given some of the debates that we have had in the
>past.. ;)

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.

>That aside, I have several concerns with this draft.

You wouldn't be you without expressing concerns with someone else's ID ;-)

>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. Non-DHCP transactions
between the the DHCP server any any other device are not mentioned
here. This is not an architecture ID. 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.

I probably should have a "It is assumed..." paragraph.

>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.

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.

>This is not talked about at all in the security section and really needs to be

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.

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.

>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.

Others have comments?

> > -----Original Message-----
> > From: James M. Polk []
> > Sent: Tuesday, 15 May 2007 7:56 AM
> > To:
> > Subject: [Geopriv] New ID creating DHCP LbyR URI delivery Option
> >
> > Geopriv WG
> >
> > Here is the announcement of a new and real simple ID that creates and
> > IANA registers a DHCP Option for delivering a Location-by-Reference
> > (LbyR) URI to an endsystem.
> >
> > + I believe we want this LbyR value to be all inclusive, meaning not
> > break up the Option by having separate DHCP fields for each URI
> > parameter and/or header parameter another protocol, such as SIP,
> > might use. This allows for a simple single value Option in DHCP, and
> > only one length field - for the whole option. I believe the
> > characters within the URI will provide any delineation necessary,
> > such as the ' < ', ' > ', and ' ; ' signs used in the ABNF of SIP
> > header structure. Does anyone disagree with this?
> >
> > + What I don't know is if this Option should identify which type of
> > URI is present (sip, sips, pres...). Anyone have thoughts on make
> > this an explicit field in the Option (where the URI will already
> > indicate this)?
> >
> > + I'm also not sure if this Option should identify UTF-16, and
> > therefore also UTF-8, characters as a separate Option field. Any
> > opinions on this? I could add a "Reserved" field of a byte or two
> > just for these types of extensions in the future, whenever they are
> > wanted or needed. Thoughts?
> >
> > + I currently state in this ID that
> >
> > "LbyR URIs SHOULD NOT reveal identity information of the
> > user of the device,
> > since DHCP is a cleartext delivery protocol."
> >
> > Should this "SHOULD NOT" be a "MUST NOT"? I know we don't want
> > identity info in this, but is that need strong enough to be a MUST
> > NOT strength here in DHCP?
> >
> > + Additional comments are appreciated.
> >
> > James
> >
> >
> > >A New Internet-Draft is available from the on-line Internet-Drafts
> > >directories.
> > >
> > > Title : Dynamic Host Configuration Protocol
> > > (DHCP) Option for a Location-by-Reference (LbyR) Uniform Resource
> > > Identifier (URI)
> > > Author(s) : J. Polk
> > > Filename :
> > > Pages : 7
> > > Date : 2007-5-14
> > >
> > > This document creates a Dynamic Host Configuration Protocol
> > > Option for the Location-by-Reference (LbyR) Uniform Resource
> > > Identifier (URI) of an endpoint. For example, an endpoint can be
> > > Session Initiation Protocol (SIP) User Agent Client (UAC), i.e.,
> > > phone. This LbyR URI can be included in a UA's messages to
> > > other nodes of that UA's geographic location, once the URI is
> > > dereferenced by a Location Recipient.
> > >
> > >A URL for this Internet-Draft is:
> > >
> > option-00.txt
> > >
> > >_______________________________________________
> > >I-D-Announce mailing list
> > >
> > >
> >
> > _______________________________________________
> > Geopriv mailing list
> >
> >
>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.

Geopriv mailing list
Received on Mon, 14 May 2007 23:30:22 -0500

This archive was generated by hypermail 2.1.8 : Tue May 15 2007 - 00:30:33 EDT