>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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
