Subject: Re: [Geopriv] My review of draft-ietf-geopriv-dhcp-lbyr-uri-option-05

From: "James M. Polk" <[email-masked]>
Date: Sun, 26 Jul 2009 11:53:49 -0500

Hannes

Thanks for the review

comments in-line

At 01:26 AM 7/20/2009, Hannes Tschofenig wrote:

>Hi James,
>
>Thanks for the update. I have compiled my comments into the MS word 
>with track changes and turned it into a PDF. <<...>>

thanks for this format

>There are a bunch of editorial suggestions; maybe they are useful.

I'm frustrated by some of the comments and suggestions because - in 
some cases - they hack apart text that's been (unmodified) in the 
document since the individual -00 was submitted way more than 2 years 
ago, and no comments were made until now. Makes me think I 
continually have to hit a moving target...

another frustration is with the "entity= attribute" vs. "device ID 
element" discussion - which several on this list don't seem to want 
to separate - and they are separate topics.  The entity= attribute is 
equivalent to an AOR in SIP (i.e., it is the presentity's URI), but 
the <deviceID> element is equivalent to a MAC address. Both are 
identifiers, but one can change and the other is fixed for the life 
of that device.

When Hannes logs onto two devices, the two devices each have unique 
identifiers (i.e., unique MAC addresses), but Hannes' presentity URI 
is the same for both devices, unless the URI has a host part embedded 
within the URI (analogous to a SIP AOR vs. a Contact Address). The 
user part and the domain part of the URIs are still the same.  The 
two identifiers should never be considered the same - and all the 
discussion about interchanging the meanings of entity= and device 
should never happen.

but it still does...

That said - some comments, however, seem to be fine and I'll modify 
the text accordingly.

>There is only one major comment: It is good that you describe the 
>security model you focus on. It seems that you settled with the 
>authorization model in comparison to the possession model. That's 
>fine with me given the lack of confidentiality protection in DHCP.

ok, glad you think this is ok moving forward...

>Now, in order to get it to work in an interoperable fashion you 
>would have to make Geolocation Policy and XCAP a normative reference 
>(mandatory to implement).

I have Geolocation Policy as informative now (and have had it in 
there for a while), and I can make this normative, but I don't yet 
see how making XCAP explicitly normative is necessary.  If you 
believe it is to get Geolocation Policy to work, then making 
Geolocation Policy normative ought to be enough, don't you think?  If 
not, exactly which piece of text in this ID do I place the XCAP 
reference directly next to?

>I cannot see it would work otherwise.
>
>Ciao
>Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 26 Jul 2009 20:58:32 +0300

Hi James, 

Thanks for the quick response. 

>>with track changes and turned it into a PDF. <<...>>

I could also send you the word document, if that makes things easier. 
It is very difficult to type these editorial suggestions into a mail.

>I'm frustrated by some of the comments and suggestions because 
>- in some cases - they hack apart text that's been 
>(unmodified) in the document since the individual -00 was 
>submitted way more than 2 years ago, and no comments were made 
>until now. Makes me think I continually have to hit a moving target...

If you think that the editorial comments do not help then leave it as is. 

Why do I send editorial comments so late? Well, for me it makes a lot of
sense to provide them with a stable version rather than with an early
version. Early document versions tend to change a lot making any previous
editorial comments irrelevant. 

>
>another frustration is with the "entity= attribute" vs. 
>"device ID element" discussion - which several on this list 
>don't seem to want to separate - and they are separate topics. 
> The entity= attribute is equivalent to an AOR in SIP (i.e., 
>it is the presentity's URI), but the <deviceID> element is 
>equivalent to a MAC address. Both are identifiers, but one can 
>change and the other is fixed for the life of that device.
>
>When Hannes logs onto two devices, the two devices each have 
>unique identifiers (i.e., unique MAC addresses), but Hannes' 
>presentity URI is the same for both devices, unless the URI 
>has a host part embedded within the URI (analogous to a SIP 
>AOR vs. a Contact Address). The user part and the domain part 
>of the URIs are still the same.  The two identifiers should 
>never be considered the same - and all the discussion about 
>interchanging the meanings of entity= and device should never happen.
>
>but it still does...

I didn't see a discussion of 'entity' attribute vs. <deviceID> element in
draft-ietf-geopriv-dhcp-lbyr-uri-option-05.txt. 
 
>
>That said - some comments, however, seem to be fine and I'll 
>modify the text accordingly.
>
>
>see how making XCAP explicitly normative is necessary.

My thinking was the following:
http://www.ietf.org/id/draft-ietf-geopriv-policy-21.txt does not define a
mandatory-to-implement transport to uploading the policy. 

If we do not define one in this document then we end up with the situation
where the end host and the DHCP server understand the same authorization
policy format but the policies cannot be uploaded. 

That's why I was suggesting to add XCAP to the normative references. Maybe
XCAP needs to be normatively referenced in the geolocation policy document?!

I don't know what would be more appropriate. 

> If you 

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 26 Jul 2009 16:20:23 -0500

btw - sorry you are not coming to Stockholm. I hope you get better quickly.

>It is very difficult to type these editorial suggestions into a mail.

I agree, which is why I do this type of review often in WORD with 
Track Changes turned on, so the author can see where I make all my 
small comments, and how I'd rewrite a sentence - like you did here.

>editorial comments irrelevant.

well, it also gives an author a false sense of stability when someone 
brings up one or two suggestions that are big, the author believes 
"if I just satisfy *these*, I'll have this commenter's concerns 
met"... This gives an author a mental note as to ticking off each 
commenter - until there are none, which is when the author believes 
that particular document is fairly stable, and can ask the chairs for 
WGLC believing they have satisfied all comments.

I've asked the chairs for WGLC for several meetings, believing I'm 
nearly at the finish line.  You review makes me think I'm way back 
near the starting line, as you ask me to justify about 15 different 
pieces of text. The ID isn't that long, and 15 things need to be 
adjusted with explanation...  it's frustrating, you know.

it also delays RFC publication by a year or two, if others are 
following this method.

That said - perhaps the chairs ought to WGLC this to get all the 
comments in at once, and I'll only have to rewrite this ID the one 
(long) time   ;-)

>draft-ietf-geopriv-dhcp-lbyr-uri-option-05.txt.

you inserted the word "device" into the paragraph at the bottom of 
page 6 - which is counter to the discussion we've been having about 
entity= attribute vs. <deviceID> element on this list, as well as on 
SIPCORE's list.

I specifically know DHCP isn't going to assign a device's ID (which 
most likely is its MAC address - per RFC 4479).

that coupled with the paragraph you quoted towards me regarding the 
HELD ID (section 6 - which interchanged the meanings of entity= 
attribute and the <deviceID> element), has me sensitive to what you 
understand about this word you insserted. Which is why I wrote the 
two "frustration" paragraphs above in this thread.

>mandatory-to-implement transport to uploading the policy.

and how do you want me to add this into a (what should be simple) 
DHCP extension ID?

Here is where I believe you are getting too into an architecture for this ID.

>XCAP needs to be normatively referenced in the geolocation policy document?!

err, since that doc doesn't "...define a mandatory-to-implement 
transport to uploading the policy." to you your words from above, I'm 
thinking that is where XCAP ought to be defined, and not a DHCP doc, 
which would only cover DHCP -- whereas the geolocation policy 
document needs to cover all policy uploading for Geopriv, right?

>I don't know what would be more appropriate.

I clearly believe our geolocation policy document should contain the 
transport mandates vs. a singular LCP protocol.

  BTW -- using the other logic, that means HELD needs to also define 
this "mandatory-to-implement transport to uploading the policy." -- 
but I doubt it does today.

Instead of putting this into each LCP doc, why don't we put it into 
the Policy doc *once*, taking care of all LCPs at once?

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 26 Jul 2009 18:16:30 -0500

Hi James,

This is a question only, but is something that I have puzzled over now
for a while and it is very unclear to me how you will get the following
to work.

"This Option can be useful in WiMAX connected endpoints or IP 
   cellular endpoints.  The location URI Option can be configured as a 
   client if there is a router, such as a residential home gateway, 
   with the ability to communicate to downstream endpoints as a server.

   How an LS challenges a dereference can vary, and a policy 
   established by a rulemaker [RFC3693] for a Location Target as to 
   what type of challenge(s) is to be used, how strong a challenge is 
   used or how precise the location information is given to a 
   requestor. All of this is outside the scope of this document (since 
   this will not be accomplished using DHCP)."

If I understand what this text is saying, then my DSL modem at home
could be given a location URI by my ISP, and all devices inside my house
would be given the same location URI yes?

In this case I now have multiple targets, not just devices, but targets
being located through the same location URI, and you have explicitly
called out that geopolicy or common policy is going to be used and not
possession model. How, in the case described above can each Target have
its own geopolicy, and how can the LIS distinguish which policy to
invoke given that they all tied to the same location URI?

If I have misunderstood what it is you are saying, then could you
clarify it a bit please. If I haven't, then can we either have a
statement to say don't use this option in this configuration, or provide
a suitable explanation as to how the problem is overcome.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of James M. Polk
> Sent: Monday, 27 July 2009 7:20 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Geopriv] My review ofdraft-ietf-geopriv-dhcp-lbyr-uri-
> option-05
> 
> Here is where I believe you are getting too into an architecture for
this
> ID.
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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: Sun, 26 Jul 2009 18:48:35 -0500

James

in-line below

>would be given the same location URI yes?

they can, yes - but this doesn't mean they MUST in all cases.

>being located through the same location URI,

yes, with you so far...

>and you have explicitly
>possession model.

with you so far...

>How, in the case described above can each Target have
>its own geopolicy

who says each target has to have its own policy. Every target within 
a residence *can* have the same policy, or different policies (the 
latter being an administrative choice by the ruleholder -- i.e., the 
SP that's providing the service.

>, and how can the LIS distinguish which policy to

well, if all the targets are in the same residential address, they 
don't need or require their own policy, necessarily - do they? In 
fact, why would they in that circumstance (if in fact all targets are 
at the same civic address, receiving their location from the same 
residential gateway)?

>a suitable explanation as to how the problem is overcome.

I don't see this as a problem. I believe this is a configuration 
issue, and not a protocol issue. Opeerators could choose to have this 
enabled (i.e., all targets at the same civic address get the same 
location URI), or disabled (all targets get unique location URIs). We 
should NOT be who decides this for every operator on the planet.

I expect customer RFPs to define what they want in a company's 
products about these optional decisions in the protocol.  That's 
where Andrew and Cisco can decide to offer products that do or not do 
what a particular Operator (i.e., customer) wants - on the chance 
that not doing what they want means the other company gets the deal 
(and revenue).

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 26 Jul 2009 18:59:00 -0500

Hi James,

I think your assertions below misunderstand the context of the argument.
The policy is made by a rulemaker, and under the terms of what your
document describes one of the rulemakers is the Target. This means that
each Target has the right to set its own rules, unless the LIS can
distinguish between the Targets, then this becomes mayhem.

Saying that they don't have to is not sufficient, under the rules they
are allowed to, so I fail to see how this can work through a residential
gateway.

This is totally a protocol issue when deployed in the manner described,
and the document indicates, if not encourages, that it can be deployed
in this manner.

I request that the issues be clearly highlighted at a minimum, but
preferably have a statement saying where this mechanism is not
appropriate.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Monday, 27 July 2009 9:49 AM
> To: Winterbottom, James; Hannes Tschofenig
> Cc: [email-masked]
> Subject: RE: [Geopriv] My review ofdraft-ietf-geopriv-dhcp-lbyr-uri-
> option-05
> 
> James
> 
> in-line below
> 
> > > >If you think that the editorial comments do not help then leave
it as
> >is.
> > > >
> > > >
> > > >Why do I send editorial comments so late? Well, for me it makes a
lot
> >of
> > > >That's why I was suggesting to add XCAP to the normative
references.
> > > Maybe
> > > > >Geolocation Policy normative ought to be enough, don't you
think?
> >If
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 26 Jul 2009 20:12:01 -0500

Or to put it another way: "Two targets having the same location is not
the same as two targets having the same policy"

The comment below:

    " if all the targets are in the same residential address, they
      don't need or require their own policy, necessarily - do they?"

conflates these two points I think. It's true to say that two targets
don't necessarily need individual policies. There's no need to bring the
co-location aspect into it. OTOH, two LTE connected users standing next
to each other in the street share the same location - but likely want
their own policies.

I think the thrust of James W's question is how to ensure separate
devices *can* have their own policy with DHCP-delivered URI(s) behind a
residential router. As opposed to the question of whether they would
always need this. And, yes, I can certainly see that two users behind a
residential router may want different policies - depending on where they
are sending the URI(s).

Cheers,
Martin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Winterbottom, James
Sent: Monday, 27 July 2009 9:59 AM
To: James M. Polk; Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Geopriv] My review
ofdraft-ietf-geopriv-dhcp-lbyr-uri-option-05

Hi James,

Cheers
James

it as
lot
references.
think?
--
--

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Jul 2009 03:30:38 -0500

James

we shouldn't ever impose that distinction on an operator when all the 
policies within the same household are the same, for example.

>are allowed to, so I fail to see how this can work through a residential

you are imposing a policy in geopriv work that is in fact acting as 
if you are part rulemaker by doing it this way IMO. I don't think 
that's what we are here for.

An operator that provides location services needs to be able to have 
its own set of rules free from protocol constraints to define it's 
own set of policies per user or per address.

If HELD wants to have a overriding rule that says every target MUST 
get its own URI, fine.  You're SP focused.  We have enterprise 
customers, SMB customers, Commercial customers and residential 
customers who don't share that desire to have each and every target 
create a load on a server when it doesn't have to, yet allow for it 
when a customer does want to. That's flexibility.

>and the document indicates, if not encourages, that it can be deployed

it isn't encouraged, but it allows, certainly. It shouldn't be 
prevented, which is what you want to have happen.

James - you don't ever plan on implementing DHCP, so why exactly are 
you putting constraints on how we who do use DHCP want to code and deploy it?

>preferably have a statement saying where this mechanism is not

firstly, I don't fully understand that this is "an" issue, but I can 
add text to this section if that will make you happy.

I won't unilaterally include text saying it is inappropriate give 
that we have feedback saying at least some want it this way, so it's 
not inappropriate for them.

James

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Jul 2009 04:41:57 -0400

In fact, it might be real common that the access network only allowed one
policy for one subscriber, regardless of how many devices that may be
present.  It tends to treat a residence, for example, as one thing, with one
address, and, therefore, one policy.

Other providers might be more willing to have separate policy for what it
sees as separate ports.

Brian

> Behalf Of James M. Polk
> Sent: Monday, July 27, 2009 4:31 AM
> > > >    cellular endpoints.  The location URI Option can be configured
> as
> >a
> > > >    what type of challenge(s) is to be used, how strong a
> challenge
> >is
> > > > > From: [email-masked] [mailto:geopriv-
> [email-masked]]
> >On
> > > >Behalf
> > > > > Of James M. Polk
> > > > > btw - sorry you are not coming to Stockholm. I hope you get
> better
> > > > > quickly.
> > > > >
> > > > > > >>Thanks for the update. I have compiled my comments into the
> MS
> > > >word
> > > > > >It is very difficult to type these editorial suggestions into
> a
> >mail.
> > > > >
> > > > > >sense to provide them with a stable version rather than with
> an
> >early
> > > > > >version. Early document versions tend to change a lot making
> any
> > > >previous
> > > > > that particular document is fairly stable, and can ask the
> chairs
> >for
> > > > > > >interchanging the meanings of entity= and device should
> never
> > > >happen.
> > > > > > >
> > > > > > >but it still does...
> > > > > >
> > > > > entity= attribute vs. <deviceID> element on this list, as well
> as
> >on
> > > > > SIPCORE's list.
> > > > >
> > > > > > >>There is only one major comment: It is good that you
> describe
> >the
> > > > > > >>fine with me given the lack of confidentiality protection
> in
> >DHCP.
> > > > > > >
> > > > > > >I have Geolocation Policy as informative now (and have had
> it
> >in
> > > > > > >there for a while), and I can make this normative, but I
> don't
> >yet
> > > > > >http://www.ietf.org/id/draft-ietf-geopriv-policy-21.txt does
> not
> > > >define a
> > > > > Here is where I believe you are getting too into an
> architecture
> >for
> > > >this
> > > > > ID.
> > > > >
> > > > >
> > > > > >If we do not define one in this document then we end up with
> the
> > > > > situation
> > > > > >XCAP needs to be normatively referenced in the geolocation
> policy
> > > > > document?!
> > > > >
> > > > > transport to uploading the policy." to you your words from
> above,
> >I'm
> > > > > I clearly believe our geolocation policy document should
> contain
> >the
> > > > > this "mandatory-to-implement transport to uploading the
> policy."
> >--

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Jul 2009 03:43:46 -0500

>the same as two targets having the same policy"

I agree with this, but it isn't always the case that there will be 
two policies for two targets.  This ID allows there to be two for 
one, and two for two.

>to each other in the street share the same location - but likely want

yes - again I agree -- however, your LTE example isn't the only means 
of access connectivity, is it?  It just as easily could be two 
hardwired Ethernet attached phones in the same house, couldn't 
it?  In this latter case, there really is no distinguishing factor 
between the two hardwired phones in that house, so why take the extra 
load in a processor and the memory to have two differnet policies?

I'm not sure how big your house is (as a function of the total number 
of shared phone lines you have, but I have dozens of phone outlet 
jacks in my house, each needing exactly 1 policy, for example - since 
they are all at the same location.

Individual policies are necessary for each cell phone in my house 
(there are 5), but not the hardwired phones.

>residential router.

But I've been saying *CAN* all this time, and James W said explicitly 
this should be either prohibited or not appropriate. I think you two 
don't agree, which is fine, but I'm saying - and the ID says - 'can 
be the same or can be different' which is more towards what you are saying.

>As opposed to the question of whether they would
>always need this.

I'm not saying "always" in the ID, I'm advocating flexibility to have 
local decision making, and James W is not (i.e., see is "not 
appropriate" comment below).

>And, yes, I can certainly see that two users behind a

that's equally possible - and could be mandated by configuration - 
but shouldn't be mandated to comply with an IETF RFC thus leaving out 
the possibility of configuring all targets within a building having 
the same location URI.

james

---

From: Richard Barnes <[email-masked]>
Date: Mon, 27 Jul 2009 10:55:02 +0200

Brian,

I expect that you're right on this, and that's what's scary -- that the 
LS might treat all policy requests from the same IP address as 
equivalent, so that different entities could step on each other.  One 
person could set very restrictive policies and someone else behind the 
same NAT could rewrite those policies to be completely open.

On the other hand, this only creates a problem when multiple entities 
that the ISP considers the same subscriber have different policies.  So 
going back to the text that James W cited ...
"
    This Option can be useful in WiMAX connected endpoints or IP
    cellular endpoints.  The location URI Option can be configured as a
    client if there is a router, such as a residential home gateway,
    with the ability to communicate to downstream endpoints as a server.

"
... it seems like what we should do to avoid this is just note that the 
G/W should *dereference* the URI and provide location by *value* to 
downstream endpoints (or references that it can address distinctly by 
client).

And FWIW, it seems like the same considerations apply to HELD 
distribution of location URIs, but hasn't arisen because HELD doesn't 
have a recommendation like the above.

--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 27 Jul 2009 04:01:05 -0500

Cool. I'm happy - just so long as it *can* be done.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Monday, 27 July 2009 6:44 PM
To: Dawson, Martin; Winterbottom, James; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] My review

But I've been saying *CAN* all this time, and James W said explicitly 
this should be either prohibited or not appropriate. I think you two 
don't agree, which is fine, but I'm saying - and the ID says - 'can 
be the same or can be different' which is more towards what you are
saying.

james

as
better
MS
any
chairs
as
describe
don't
not
the
policy
above,
> > > > this "mandatory-to-implement transport to uploading the policy."
-
-
-------------------------
>this email is prohibited.
-------------------------

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Jul 2009 04:32:53 -0500

At 03:55 AM 7/27/2009, Richard Barnes wrote:
>Brian,
>
>I expect that you're right on this, and that's what's scary -- that 
>the LS might treat all policy requests from the same IP address as 
>equivalent, so that different entities could step on each other.

I mostly agree with you, but that's the game within a single provider 
(say of a voice service from AT&T or Verizon in the US). Not liking 
their policies means you live with them until you change providers. 
Sometimes (usually?) that means changing the type of access you have 
(from wireline to wireless, for example).

>One person could set very restrictive policies and someone else 
>behind the same NAT could rewrite those policies to be completely open.
>
>On the other hand, this only creates a problem when multiple 
>entities that the ISP considers the same subscriber have different 
>policies.  So going back to the text that James W cited ...
>"
>... it seems like what we should do to avoid this is just note that 
>the G/W should *dereference* the URI and provide location by *value* 
>to downstream endpoints (or references that it can address 
>distinctly by client).

I'm all for this happening

>distribution of location URIs, but hasn't arisen because HELD 
>doesn't have a recommendation like the above.
>
>--Richard
>
>
>
>Brian Rosen wrote:

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Jul 2009 04:36:08 -0500

>Cool. I'm happy - just so long as it *can* be done.

the text in the ID says "can".

So, I'm agreeing with you Martin.

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 27 Jul 2009 05:56:43 -0500

All I have asked for is that you explain how it can be done.
The current description does not say how the distinction can be made, and since there is no upstream flow with the DHCP option to distinguish the downstream entities I don't believe as stands that it can be.

I am more than happy for the solution to stand if an reasonable description of how to do it can be provided, otherwise I am not.

Cheers
James

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Mon 7/27/2009 4:36 AM
To: Dawson, Martin; Winterbottom, James; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] My review   ofdraft-ietf-geopriv-dhcp-lbyr-uri-option-05

James