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:jmpolk@cisco.com]
Sent: Mon 7/27/2009 4:36 AM
To: Dawson, Martin; Winterbottom, James; Hannes Tschofenig
Cc: geopriv@ietf.org
Subject: RE: [Geopriv] My review ofdraft-ietf-geopriv-dhcp-lbyr-uri-option-05
At 04:01 AM 7/27/2009, Dawson, Martin wrote:
>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
>Cheers,
>Martin
>
>-----Original Message-----
>From: James M. Polk [mailto:jmpolk@cisco.com]
>Sent: Monday, 27 July 2009 6:44 PM
>To: Dawson, Martin; Winterbottom, James; Hannes Tschofenig
>Cc: geopriv@ietf.org
>Subject: RE: [Geopriv] My review
>ofdraft-ietf-geopriv-dhcp-lbyr-uri-option-05
>
>At 08:12 PM 7/26/2009, Dawson, Martin wrote:
> >Or to put it another way: "Two targets having the same location is not
> >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.
>
>
> >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.
>
>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.
>
>
> >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.
>
>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
> >residential router may want different policies - depending on where
>they
> >are sending the URI(s).
>
>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
>
>
> >Cheers,
> >Martin
> >-----Original Message-----
> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> >Behalf Of Winterbottom, James
> >Sent: Monday, 27 July 2009 9:59 AM
> >To: James M. Polk; Hannes Tschofenig
> >Cc: geopriv@ietf.org
> >Subject: Re: [Geopriv] My review
> >ofdraft-ietf-geopriv-dhcp-lbyr-uri-option-05
> >
> >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
> >
> >
> > > -----Original Message-----
> > > From: James M. Polk [mailto:jmpolk@cisco.com]
> > > Sent: Monday, 27 July 2009 9:49 AM
> > > To: Winterbottom, James; Hannes Tschofenig
> > > Cc: geopriv@ietf.org
> > > Subject: RE: [Geopriv] My review ofdraft-ietf-geopriv-dhcp-lbyr-uri-
> > > option-05
> > >
> > > James
> > >
> > > in-line below
> > >
> > > At 06:16 PM 7/26/2009, Winterbottom, James wrote:
> > > >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?
> > >
> > > they can, yes - but this doesn't mean they MUST in all cases.
> > >
> > >
> > > >In this case I now have multiple targets, not just devices, but
> >targets
> > > >being located through the same location URI,
> > >
> > > yes, with you so far...
> > >
> > > >and you have explicitly
> > > >called out that geopolicy or common policy is going to be used and
> >not
> > > >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
> > > >invoke given that they all tied to the same location URI?
> > >
> > > 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)?
> > >
> > >
> > > >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.
> > >
> > > 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
> > >
> > >
> > >
> > > >Cheers
> > > >James
> > > >
> > > > > -----Original Message-----
> > > > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
> >On
> > > >Behalf
> > > > > Of James M. Polk
> > > > > Sent: Monday, 27 July 2009 7:20 AM
> > > > > To: Hannes Tschofenig
> > > > > Cc: geopriv@ietf.org
> > > > > Subject: Re: [Geopriv] My review
> >ofdraft-ietf-geopriv-dhcp-lbyr-uri-
> > > > > option-05
> > > > >
> > > > > btw - sorry you are not coming to Stockholm. I hope you get
>better
> > > > > quickly.
> > > > >
> > > > > At 12:58 PM 7/26/2009, Hannes Tschofenig wrote:
> > > > > >Hi James,
> > > > > >
> > > > > >Thanks for the quick response.
> > > > > >
> > > > > > >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
> > > > > >
> > > > > >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 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.
> > > > >
> > > > >
> > > > > > >
> > > > > > >
> > > > > > >>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...
> > > > > >
> > > > > >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.
> > > > >
> > > > > 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 ;-)
> > > > >
> > > > >
> > > > >
> > > > > > >
> > > > > > >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.
> > > > >
> > > > > 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.
> > > > >
> > > > > >
> > > > > > >
> > > > > > >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.
> > > > > >
> > > > > >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.
> > > > >
> > > > > 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.
> > > > >
> > > > >
> > > > > >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?!
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > > > > 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?
> > > > > > >
> > > > > >
> > > > > >Ciao
> > > > > >Hannes
> > > > > >
> > > > > > >>I cannot see it would work otherwise.
> > > > > > >>
> > > > > > >>Ciao
> > > > > > >>Hannes
> > > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > Geopriv@ietf.org
> > > > > 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]
> > >
> >
> >-----------------------------------------------------------------------
>-
> >------------------------
> >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
> >Geopriv@ietf.org
> >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]
>
>
>------------------------------------------------------------------------------------------------
>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]
------------------------------------------------------------------------------------------------
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
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
