Subject: [Geopriv] Review of draft-ietf-geopriv-dhcp-lbyr-uri-option-00

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 08 Mar 2008 04:40:41 +0200

Hi James,

thanks for the draft update.

I have a few questions:

* Do you want to use only URLs where possession alone is not sufficient?

The following text give me this impression:

"

   o  Any user attempting to gain access to the information at this URI
      will be challenged by the LIS, not the DHCP server for
"
      credentials and permissions.

If so, wouldn't it be useful to put a description into the document that 
explains how the policies get to the LIS, namely by uploading them using 
the Geolocation Location Policy mechanism.

I think you have to mandate a specific protocol otherwise you have to 
put a BIG applicability statement in front of the 1st page since the 
work will most likely only be useful for enterprise networks.
I believe that the following statement does not really work:

"

   o  Any user control (what Geopriv calls a 'rulemaker') for the
      parameters and profile options a Location-Object will have is out
      of scope of this document, but assumed to take place via an
      external web interface between the user and the LIS (direct or
      indirect).

"

* Do you only envision SIP-based URIs being used? No HTTP/HTTPS URIs?

Why is this?

*

"

There is some
   debate as to whether this Location-URI need be a random alphanumeric
   string or just unique.  If the latter, there is some debate as to
   the how we define unique. Is that through space as time, as RFC 3261 <http://tools.ietf.org/html/rfc3261>
   defines a SIP Call-ID needs to be (meaning: never a duplicate, ever,
   by any device, ever)? Or is it unique to within a specific domain
   for as long as it is actively assigned to a client (plus some
   interval).
"

If you don't plan to use a certain type of URI then this might not be 
required at all.

Ciao
Hannes

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

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 08 Mar 2008 18:44:21 -0600

Hannes

Thanks for the review, but I have some questions and comments about 
your conclusions drawn, as I think you are expecting too much from 
this simple DHCP Option creation/definition document.

>* Do you want to use only URLs where possession alone is not sufficient?

I'm not sure what your question is asking.

Are you asking about "possession=authorization of PIDF-LO dereference"?

This model shouldn't be used with DHCP because there is no 
authorization mechanism within DHCP, therefore each dereference needs 
to be challenged by the LIS (since there wasn't one done within the 
LCP download process of the URI

>the Geolocation Location Policy mechanism.

I disagree.  This is a DHCP extension doc, and shouldn't architect 
other protocols.  I mention *that* a rulemaker sets policies for 
location revelation, I shouldn't have to pick a protocol, then set 
rules around how that protocol (possibly) is extended to do this 
interaction with the user.  That's for another doc to define.

>I think you have to mandate a specific protocol

Since this is a DHCP only draft, and DHCP isn't going to be that 
protocol - I believe it's appropriate to state that a user, as 
rulemaker, sets the location revelation policies at the LIS, all 
without naming a protocol.

>otherwise you have to put a BIG applicability statement in front of 
>the 1st page

what? The applicability for this is clear to everyone, given that 
there are *two*  RFCs produced by this WG that cover DHCP downloading 
location to a client. This doc merely downloads a URI instead of a 
location-value.  Otherwise, all 3 are the same.

Further, RFC 3693 has a beautiful diagram articulating the Target, 
the Location Seeker, the Rulemaker and the Location 
Generator/Server.  DHCP is a simple protocol that realistically 
cannot be expected to do anything about the Target<==>Rulemaker 
communication, therefore that discussion belongs in another document.

This is something Allison and I talked about doing back in Vienna, as 
a Geopriv Framework - which I believe is still needed.

>since the work will most likely only be useful for enterprise networks.

enterprises only? How about useful wherever DHCP is used, which isn't 
limited to enterprises... PacketCable comes to mind as a good example 
of this.  IMS could be another - since both use DHCP.

>       external web interface between the user and the LIS (direct or

why?

I've explained above why I believe this should not be defined in this doc.

>* Do you only envision SIP-based URIs being used? No HTTP/HTTPS URIs?

What document allows HTTP and HTTPS URIs in DHCP?

What protocol is going to use the product of  this DHCP Option?  SIP maybe?

Conveyance only calls out 3 schemes (SIP:, SIPS: & PRES:), why should 
this doc initially offer more?

>    the how we define unique. Is that through space as time, as RFC 
> 3261 <http://tools.ietf.org/html/rfc3261>

fair - but this isn't decided yet, is it?

Random numbers are only be argued for within those that believe in 
the Possession model, which I don't believe applies to DHCP allocated 
URIs (from a LIS).  Within that Possession model argument, no one has 
answered my question about the extent to which this random numbers 
need to remain random.  A number was seemingly arbitrarily picked 
(128), without any discussion, then was doubled (to 256) during the 
discussion - again with no reasoning given for either number.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 09 Mar 2008 20:13:38 +0200

Hi James,

I am looking forward to the meeting already. Comments below:

> LCP download process of the URI
I would spell these assumptions out explicitly.

> interaction with the user.  That's for another doc to define.
Even though this is a DHCP document does not mean that this prevents you 
from explaining how it is supposed to work in a realistic setting. We 
cannot produce solutions that only work in enterprise networks or in 
environments with very specific assumptions.

We will have to consult the working group on this issue, I guess. .

> without naming a protocol.
I very much disagree with you

> Further, RFC 3693 has a beautiful diagram articulating the Target, the 
> Location Seeker, the Rulemaker and the Location Generator/Server.  
> DHCP is a simple protocol that realistically cannot be expected to do 
> anything about the Target<==>Rulemaker communication, therefore that 
> discussion belongs in another document.
>

I believe that this aspect is very much related to the usage of DHCP and 
is not the case for HELD.
Hence, you have to specify it in this document.

> of this.  IMS could be another - since both use DHCP.
You cannot expect that users to write their policies on webpages every 
time when they roam.

> I've explained above why I believe this should not be defined in this 
In a roaming and mobility environment you cannot expect users to 
configure their policies each time they attach to a new network.
Without picking one specific protocol how do you expect this to work.

> this doc initially offer more?

I am not sure what you mean. We have HTTP-based URIs already in HELD; 
Why are these URIs restricted to SIP/SIPS/PRES URIs in DHCP?

> fair - but this isn't decided yet, is it?
Just wanted to understand your reasoning.

>
> Random numbers are only be argued for within those that believe in the 
> Possession model, which I don't believe applies to DHCP allocated URIs 
> (from a LIS).  Within that Possession model argument, no one has 
That's OK.

I personally believe that the DHCP security model is largely 
incompatible with the possession model and hence I would rule it out in 
the document.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 09 Mar 2008 15:18:21 -0500

At 01:13 PM 3/9/2008, Hannes Tschofenig wrote:
>Hi James,
>
>I am looking forward to the meeting already.

yeah... I bet you are. Stop grinning so much (or is that salivation I see)

:-O

comments below

>  Comments below:

I think I state this, but I don't believe this needs to articulated 
to the point of describing an architecture that will be detailed in 
another document.

>from explaining how it is supposed to work in a realistic setting.

RFC 4776 doesn't explain, except in passing - and then only 
minimally, how a DHCP server knows which location to give to a DHCP 
client.  That RFC was not so long ago, yet this burden was not placed 
on that document. Why does this document have to articulate the 
overall architecture that will be detailed in a new document *that 
hasn't been started yet)?

>We

Philosophically, the IETF produces solutions from clear requirements 
for anywhere the Internet Protocol communicates between 
devices.  Some might argue that DHCP is only for enterprises, yet 
there is a whole WG surrounding that effort. Should this document 
move to that WG where this limitation would not be seen as a hindrance?

The fact that DHCP is good enough to have survived the v4 to v6 
mindset, and been included in PacketCable and IMS shows it is a 
valuable protocol that is not so limited.

>I very much disagree with you

Do you propose DHCP be the protocol to set rulemaker policies on the LIS?

>Hence, you have to specify it in this document.

So, everything that is not HELD has to explain itself, and there 
can't be a case in which multiple protocols interwork?

>You cannot expect that users to write their policies on webpages every

I don't know where you are with this comment.  Users, regardless of 
whether they are static or dynamic, and regardless of which type of 
LCP they use, will have the same rulemaker policies. Are you 
suggesting users will be HELD aware?

>Without picking one specific protocol how do you expect this to work.

What about the meta question of a Location Target that can't 
communicate using IP (which is allowed in RFC3693), and moves. How is 
that user supposed to communicate its rulemaker policy with a LIS it 
isn't even aware exists?

That topic is older, therefore needs to be addressed too.  Because 
you've had the time to consider it for so long, what's the answer, Hannes?

>Why are these URIs restricted to SIP/SIPS/PRES URIs in DHCP?

Because DHCP is an LCP just like HELD is, and the two will not 
operate in the same client at the same time.  They're competitive 
solutions accomplishing the same goal.  This is just like SIP and 
H.323 aren't used by you to place the same call from the same device...

I think you're focusing too much on getting HELD everywhere to let 
anything else progress.

>incompatible with the possession model and hence I would rule it out in

I'm glad we agree with this. Richard also agrees with this. So that 
makes 3 of us...

;-)