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
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of James M. Polk
> Sent: Monday, July 27, 2009 4:31 AM
> To: Winterbottom, James; Hannes Tschofenig
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] My review ofdraft-ietf-geopriv-dhcp-lbyr-uri-
> option-05
>
> At 06:59 PM 7/26/2009, Winterbottom, James wrote:
> >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.
>
> James
>
> we shouldn't ever impose that distinction on an operator when all the
> policies within the same household are the same, for example.
>
>
> >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.
>
> 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.
>
>
> >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.
>
> 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?
>
>
> >I request that the issues be clearly highlighted at a minimum, but
> >preferably have a statement saying where this mechanism is not
> >appropriate.
>
> 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
>
>
> >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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
