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