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

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 May 2007 16:55:43 -0500

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        : draft-polk-geopriv-dhcp-lbyr-uri-option-00.txt
>         Pages           : 7
>         Date            : 2007-5-14
>
>    This document creates a Dynamic Host Configuration Protocol (DHCP)
>    Option for the Location-by-Reference (LbyR) Uniform Resource
>    Identifier (URI) of an endpoint.  For example, an endpoint can be a
>    Session Initiation Protocol (SIP) User Agent Client (UAC), i.e., a
>    phone.  This LbyR URI can be included in a UA's messages to inform
>    other nodes of that UA's geographic location, once the URI is
>    dereferenced by a Location Recipient.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhcp-lbyr-uri-option-00.txt
>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 14 May 2007 18:39:44 -0500

Hi James,

An interesting draft given some of the debates that we have had in the
past.. ;)

That aside, I have several concerns with this draft.

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.

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. This is not
talked about at all in the security section and really needs to be
discussed.

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.

Cheers
James

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, 15 May 2007 7:56 AM
> To: [email-masked]
> Subject: [Geopriv] New ID creating DHCP LbyR URI delivery Option
> 
> Geopriv WG
> 
> >         Filename        :
draft-polk-geopriv-dhcp-lbyr-uri-option-00.txt
> >http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhcp-lbyr-uri-

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 May 2007 23:30:22 -0500

>An interesting draft given some of the debates that we have had in the

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   ;-)

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

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

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.

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 15 May 2007 00:02:58 -0500

Hi James,

I shall snippet at various sections to make sure that the points I am addressing are clear.

> LbyR to the client/endsystem.  This is how I see the DHCP part of

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.

> You wouldn't be you without expressing concerns with someone else's ID

Touché!!

> 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
> 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
> is out of scope of this document".  I will add either/each if the WG

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

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

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

> DHCP has defined to date in this area in the security considerations

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 15 May 2007 02:34:21 -0500

Per my previous email; I had enough trouble seeing how DHCP could be
reliably used to deliver a literal location value from the access
network to my device. How does the DHCP server running in my house get
the location from the access provider in the first place? That was hard
enough.

Using DHCP to deliver a unique URI for subsequent dereferencing raises
the practical difficulties by another order of magnitude. How is my DHCP
server going to get hold of this temporary unique URI and where does it
point? By leaving these questions out of scope we haven't actually
progressed to a solution at all. We've just swapped the end client for
the DHCP server - we're still stuck with all the location delivery
problems to solve.

I take your point, James, that your brief (as you've accepted it) is
just to define a new option which is a location URI. Not your problem as
to how it gets in there or how it's used. I'm just asking the practical
question of why are we doing this at all?

I'd prefer to see energy spent on using DHCP to deliver the URI for the
LIS. This, at least, provides a local fallback for LIS discovery if the
network based SRV techniques are not available in a given access. And,
you know, it's more like the kind of thing DHCP was created for.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Tuesday, 15 May 2007 2:30 PM
To: Winterbottom, James; [email-masked]
Subject: RE: [Geopriv] New ID creating DHCP LbyR URI delivery Option

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

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

DHCP has defined to date in this area in the security considerations
section.

Others have comments?

> > >    Identifier (URI) of an endpoint.  For example, an endpoint can
be
>a
> > >    Session Initiation Protocol (SIP) User Agent Client (UAC),
i.e.,
>a