>At 02:12 AM 9/18/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>Hi James,
>>
>>Thanks for the update.
>
>thanks for the feedback
>
>>One important aspect upfront: During the virtual interim meeting you
>>said that Common Policy and Geolocation Policy are now normative
>>references.
>
>I only said Geolocation Policy was referenced, and admitted in
>a note just after the call that I said this was Normative in
>-06, and intended to move this up to Normative (but didn't
>remember to do this), and in -06 it remained in the
>Informative references section. I know why I put it there in
>-05, because that doc hadn't progressed very much within the
>IESG (for a long time with them), and I didn't want this URI
>doc to be bound on waiting for the Geolocation Policy to become an RFC.
Good point; I have sent a separate mail about the status to the list.
>
>I've already started an -07 of this URI doc, and I've already
>moved Geolocation Policy to the Normative section. That said -
>I do not have RFC 4745 in the references currently. Do you
>believe Common Policy and Geolocation Policy should be
>referenced within the same bullet of text (i.e., Section 3.1),
>or somewhere else?
I would reference it in the same section.
>
>>However, when I looked at
>>http://www.ietf.org/id/draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt
>>and I could not find Common Policy reference at all, nor the
>>geolocation draft as a normative reference. Finally, I guess
>you have
>>to reference XCAP as well since you need to have a way to "transport"
>>(or upload) the policies.
>
>Geolocation Policy doesn't have a transport/upload mechanism.
Correct.
>Do you really want this DHCP URI document to set the example
>of how Geolocation Policies get uploaded for all future
>Geopriv docs? Doesn't that mean all future IDs/RFCs that
>reference Geolocation Policy will have to Normatively
>reference this DHCP URI doc because it was the *one* doc to
>specify that XCAP is to be used to upload/transport policies?
But if you don't specify a mechanism for how to get the policies to the
LIS then you cannot accomplish interoperability either.
>
>I thought you and I talked about that and agreed to add that (i.e.,
>XCAP) into the Geolocation Policy doc. Am I wrong here? This
>seems to me to be the (waaay) obvious way to go, thereby
>covering all Geopriv docs that require uploading policies to a LS.
http://tools.ietf.org/html/draft-ietf-geopriv-policy-21#section-10 only
defines the technical content to allow XCAP to be used to upload these
policies (btw, we don't have the same for Common Policy...) but the
document format itself can utilize a number of different transports.
Ciao
Hannes
>
>
>>Please find my comments below.
>
>comments back at you...
>
>I don't think you and I are that far apart any longer on this
>doc. I do have a couple of questions below and ask for your
>opinion on which direction to go on some other points.
>
>James
>
>--Original Message-----
>> >From: geopriv-bounces@ietf.org
>> >[mailto:geopriv-bounces@ietf.org] On Behalf Of ext James M. Polk
>> >Sent: 15 September, 2009 04:37
>> >To: geopriv@ietf.org
>> >Subject: [Geopriv] New DHCP Location URI version submitted
>> >
>> >Geopriv
>> >
>> > Title : Dynamic Host Configuration Protocol
>> >(DHCP) IPv4
>> >and IPv6 Option for a Location Uniform Resource Identifier (URI)
>> > Author(s) : J. Polk
>> > Filename :
>draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt
>> > Pages : 13
>> > Date : 2009-09-14
>> >
>> > This document creates a Dynamic Host Configuration Protocol
>> >(DHCP)
>> > Option for transmitting a client's geolocation
>Uniform Resource
>> > Identifier (URI) of a client, which can be dereferenced in a
>> > separate transaction by the client or an entity the
>client sends
>> > this URI to.
>> >
>> >A URL for this Internet-Draft is:
>> >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lby
>> >r-uri-option-06.txt
>> >
>> >I am including a detailed response to Hannes' PDF below,
>which had 23
>> >"comments" throughout the PDF, as well as a LOT of little edits. I
>> >incorporated most of the edits, though I didn't agree with
>every one
>> >of them.
>> >
>> >Below is my response to each of the "comments" made within that
>> >review. I kept Hannes' numbering in case anyone wants to track them.
>> >He sent this PDF to the list on July 20th, so I won't include that
>> >attachment here.
>> >
>> >Comments to this set of responses is encouraged.
>> >
>> >Comment[TH1]: This is not true. First, it depends on the URI scheme
>> >what specification has to be used. Second, [ID-SIP-LOC] does not
>> >describe how dereferencing works. It only describes how to
>convey the
>> >reference (or a value).
>> >
>> > - see Section 4.5 of conveyance for this. The
>mechanism is the
>> >same for location-by-reference (where the LR needs to request the
>> >Target's location from an LS), and the LR just asking for a
>Target's
>> >location without receiving the location URI in the preceding
>> >transaction (i.e., not via conveyance) -- as long as SIP is used,
>> >that is. There's nothing in the SUBSCRIBE that's different
>(i.e., the
>> >same SIP headers are used). The same is true for the NOTIFY. The
>> >only possible difference is if the SUBSCRIBE includes some presence
>> >filters that ask for a list of fields to be in the NOTIFY, or if
>> >location tracking is requested (i.e., periodic or triggered
>NOTIFYs).
>> >These additional indications are not necessary for an LR to
>receive a
>> >Target's PIDF-LO -- they just change what can be in the PIDF-LO and
>> >how often the LR receives the PIDF-LO (if that part of the
>> >subscription is granted).
>>
>>SIP Location Conveyance does not exactly add a lot of new information
>>to the dererefence of SIP URIs other than what is know already from
>>other specs. Hence, it is not really relevant to this document.
>
>It is not blazing a new trail with whatt be covered within
>Conveyance, because you and I both know someone will ask "gee,
>how does an LR get location when it was only sent a location URI?"
>
>Because I was asked that several times before this section was
>writt(example) en ieyce, I had to put it into the doc.
>Conveyanceing to resist removing it now, among the reasons is
>that it does no harm there.
>
>
>
>> >
>> >Comment[TH2]: The term "dereferencer" does not exist.
>> >
>> > - changed to "...dereferencing entity..."
>>
>>Good.
>>
>> >
>> >Comment[TH3]: To what does the "defined in" refer to?
>> >
>> > - whether or not the dereferencing entity has permission to
>> >attain the Target's location.
>>
>>I think you better expand the description a bit or remove the
>reference.
>>It is hard to capture the idea of the sentence.
>
>I'll work on it
>
>
>> >
>> >Comment[TH4]: This is a use case for the SIP Location Conveyance
>> >document. Do you think it fits in here?
>> >
>> > - I agree, so I removed this in -06
>>
>>OK.
>>
>> >
>> >Comment[TH5]: Why would you want to hand out the same reference to
>> >different entities?
>> >
>> > - Why would all Targets (i.e., phones, ATAs, PDAs, TIVOs,
>> >iPods, etc) within the same residence need separate location URIs?
>> >Most will never be outside of the same residence. Take
>this out to a
>> >SP level of scaling of (from a few to many (dozens?) URIs per
>> >household vs. 1 URI per household). What's the impact on
>the backend
>> >systems? I believe the same is true for all the Cisco
>phones within
>> >the same building at any campus throughout the company. They won't
>> >ever move without getting a new DHCPDISCOVER download (meaning
>> >they've had to reboot - because nearly all are PoE-based now). This
>> >applies to a lot of cases, not just the outlier cases. Mobile
>> >environments are different, but most devices aren't mobile, so the
>> >option is stated here for either.
>>
>>Understood.
>
>cool - I think this one was important to understand.
>
>
>> >
>> >Comment[TH6]: As mentioned by someone in the group this
>term does not
>> >exist in our vocabulary.
>> >
>> > - This was pointed out at the mike by Martin, and is actually
>> >not true at all. RFC 3693, section 5.1 (titled "
>> >Location Information and Sighting") defines and describes
>the act of
>> >"Sighting". Here is the text:
>> >
>> > "Within any given location-based transaction, the INITIAL
>> > determination of location (and thus the initial creation of
>> >Location
>> > Information) is termed a Sighting:
>> >
>> > Sighting:
>> > The initial determination of location based on non-public
>> > information (as discussed in the definition of Location
>> > Information), and the initial creation of Location
>> > Information."
>> >
>> >
>> > To call out something as a Sighter fits the definition, and
>> >isn't out of place - regardless of how it has been portrayed as
>> >inappropriate at any microphone discussion.
>>
>>Sighter does not exist as a role in the architecture. You could say
>>that the LIS does sighting, if you think that this will give
>you a lot
>>of additional value when people have to lookup that term in RFC 3693.
>
>Personally, this term has clear meaning to me. I've always
>said - over the years - that I didn't understand why others
>didn't understand the term. When 3693 was being written, this
>term was used frequently, a lot by Jorge (the editor of 3693),
>so it was an integral part of Geopriv's vernacular.
>
>I'll work on this point...
>
>
>
>> >
>> >Comment[TH7]: I am not sure what is configured here?
>> >
>> > - residential gateways are often DHCP servers to all home
>> >clients, where the gateway appears to the operator as a single
>> >end-system. This is analogous to that - where the gateway hands out
>> >the same location URI to each client that was given to it by the
>> >operator. In WiMAX, this usage can be expanded to include
>> >connectivity such as MiFi scenarios, for example.
>> >
>>
>>The sentence sounds somewhat strange if you read it:
>>"
>>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.
>>"
>>
>>You can configure a DHCP server to do something but the
>Location URI is
>>just a string and that string gets dumped into another container in
>>DHCP.
>
>I'll rework the above sentence to make this point clearer, ok?
>
>> >Comment[TH8]: A right term might be "Location Recipient"
>> >
>> > - fair point, but I'm going to go with "dereference request"
>> >instead of just dereference or LR, because at the beginning
>it's the
>> >request that's being challenged, not the potential LR
>(given that it
>> >hasn't received any location yet). Here's the new first part of the
>> >sentence (changing the word "challenges" too):
>> >
>> > "How an LS responds to a dereference request can vary..."
>> >
>>
>>The LS (which is actually a LIS, btw) will run a security protocol to
>>authenticate the LR to then figure out whether the authorization
>>policies match to the identity of the LR and so on. Changing the
>>sentence in the way you suggested is good.
>>
>>
>>
>> >Comment[TH9]: We don't provide this information in the Geolocation
>> >policy.
>> >
>> > - right, but that doesn't mean it can't exist outside of the
>> >Geolocation Policy ID. It could be a case of the operator
>configuring
>> >all this without a target's involvement, or it could be a
>judge that
>> >sets the rules. In other words, this would be done outside of any
>> >protocol transactions. Also note, I don't reference [ID-GEO-POL],
>> >which is the Geolocation Policy ID that is reference
>elsewhere in the
>> >ID.
>>
>>That's correct. It could be a proprietary mechanism. Since you make
>>references to the geolocation policy document it might be good to say
>>that this functionality goes beyond of what is provided today. Just a
>>thought.
>
>interesting. Do you want me to open up that possibility
>("...that this functionality goes beyond of what is provided today")?
>
>
>> >
>> >Comment[TH10]: Location Recipient
>> >
>> > - thanks, changed
>> >
>> >Comment[TH11]: Not true since you will not arrive at an
>> >interoperable implementation.
>> >
>> > - The comment you made to this last sentence is focused
>> >on DHCP, which will have zero to do with however this could be
>> >done in IP, therefore this sentence is written appropriately.
>>
>>There are things that are outside the scope of DHCP but still relevant
>>for this document. The most recent example is the authorization policy
>>mechanism.
>>
>>So, making this generic statement is not correct.
>
>but I don't understand how this will become non-interoperable?
>
>
>> >
>> >Comment[TH12]: Why don't you call it LbyR?
>> >
>> > - There is disagreement what the difference is between
>> >an LbyR and a Location URI, therefore I've scrubbed the ID of
>> >"LbyR" (except for the filename (that won't exist whenever
>> >this doc becomes an RFC).
>>
>>I have not heard about this disagreement.
>
>It was made by Martin - and he was adamant about it, seeming that I
>was clueless for not knowing this basic fact (going so far as to say
>I basically didn't deserve to talk about location at all, so why was
>I bothering to continue writing anything at the IETF about it). Like
>I told him, I didn't get that memo, nor did I see the
>discussion about it.
>
>I still don't understand the difference, but I didn't forget his
>berating of me (oh, how I love being attacked like that -- not!) - so
>I'm on a mission to never use the acronym LbyR again (after this
>time, or course) because I'm obviously clueless about what it means.
>
>> >
>> >Comment[TH13]: Wouldn't it start with sending the URI?
>> >
>> > - no, because the DHCP Server is not tracking the timer
>> >for each of its clients. It's the clients that are
>> >individually keeping track of the timers, and there is no way
>> >for the clients to know how long it took to receive the
>> >message from the Server. This is a pretty small difference
>> >either way we look at this.
>>
>>Then, the server who maintains these references is assumed to
>store them
>>for the indicated period of time. Right?
>
>interesting... I'd have to say yes to this then. I guess that isn't
>covered at all, and should be.
>
>Given that DHCP responses aren't delayed that long in transit (from
>server to client), how long would you think a default time to retain
>the URI on the server should be (beyond server determined
>'valid-for' value)?
>
>Along those lines, should I add anything about keeping a URI for a
>specific client's MAC address? This would be something like my iPhone
>(connecting to my home WLAN network) always giving out the same
>location URI (when I am there) even though the 'valid-for' times out
>when periodically when I'm on trips?
>
>This doesn't say anything about the location URI returning my PIDF-LO
>all the time (i.e., even when I'm not at home). Is this something
>that ought to be addressed one way or the other?
>
>
>
>> >
>> >Comment[TH14]: What is the lifetime of the location URI if
>> >this parameter is not included.
>> >
>> > - the lifetime of the IP address lease, which is a
>> >little vague in the previous paragraph, so I firmed up this
>> >and the next 2 paragraphs to be clear on the point.
>>
>>Thanks.
>>
>> >
>> >Comment[TH15]: To what does this correspond in
>> >http://bgp.potaroo.net/ietf/idref/rfc5226/?
>> >
>> > - from the bottom of Section 3.1 of RFC 5226, there is this:
>> >
>> > "In many cases, some review of prospective allocations is
>> > appropriate, and the question becomes who should
>perform the review
>> > and what is the purpose of the review."
>> >
>> > This gets into that "some review is often desirable".
>> >Couple the previous paragraph with the next paragraph:
>> >
>> > "One way to ensure community review of prospective
>assignments is to
>> > have the requester submit a document for publication as an RFC.
>> > Such an action helps ensure that the specification is
>publicly and
>> > permanently available, and it allows some review of the
>> > specification prior to publication and assignment of
>the requested
>> > code points. This is the preferred way of ensuring
>review, and is
>> > particularly important if any potential
>interoperability issues can
>> > arise."
>> >
>> > And you should see that stating an RFC is necessary to
>> >extend this doc just fine with RFC 5226.
>>
>>To make the life of IANA easier (and those who read the document) I
>>would suggest to just use one of the terms from RFC 5226.
>>
>>So, maybe you want "Expert Review"?
>
>If I'm to choose one, I'd like to go the other way, and choose
>publish an RFC, because this should mean that the Geopriv WG (if
>still active) will get a chance to read the proposal, instead of one
>day looking at IANA and discovering things in IANA that either we
>didn't know about, or that don't make sense, or are conflicting with
>a new proposal, or are just wrong.
>
>While Expert Review sounds good, sometimes the review isn't the best.
>Having an RFC means the community has a chance to read a proposal for
>new IANA registrations (though I'll admit we all have to pay
>attention for any LCs on this).
>
>
>
>> >
>> >Comment[TH16]: How does this SHOULD fit to the MUST NOT from above.
>> >
>> > - it doesn't. I corrected it.
>>
>>OK.
>>
>> >
>> >Comment[TH17]: Not sure what this means.
>> >
>> > - removed the paragraph
>>
>>OK.
>>
>> >
>> >Comment[TH18]: This paragraph does not fit to the previous and
>> >to the next one. Additionally, it is not clear how these
>> >things would work in such a setting.
>> >
>> > - I agree, therefore I've removed the paragraph
>>
>>Ok.
>>
>> >
>> >Comment[TH19]: I believe that your idea of focusing on the
>> >authorization model does not work.
>> >
>> > - you said that you were ok with my picking the
>> >authorization model in the email you sent me this PDF, now you
>> >say the authorization model doesn't work - and don't tell me
>> >why. I cannot work from this comment. This document doesn't
>> >assume possession of the Location URI equals authorization to
>> >see a target's location. How else can I say that? The next
>> >bullet (after this comment) pretty clearly says "this is for
>> >authorization model deployments" - but this is merely an
>> >assumption (from the section title), and can be used in the
>> >possession model).
>>
>>We discussed this comment during the virtual interim meeting.
>>
>> >
>> >Comment[TH20]: I am not sure why you need to use 2 terms,
>> >namely rulemaker and ruleholder.
>> >
>> > - fixed this, I got caught up in the WG also using
>> >Rulemaker, when in fact that term is not defined in RFC3693
>> >(which only defines "Ruleholder"). I have replaced all
>> >references to the rulemaker with Ruleholder.
>>
>>Ok
>>
>> >
>> >Comment[TH21]: Delete this sentence. It does not make a sense.
>> >
>> > - done
>>
>>Ok
>>
>> >
>> >Comment[TH22]: I am not sure what this means.
>> >
>> > - I took this out too
>>
>>Ok
>>
>> >
>> >Comment[TH23]: Why do you repeat it again?
>> >
>> > - removed paragraph
>>
>>
>>Ok
>>
>> >
>> >Comment[TH24]: Don't capture debates in this document. I don't
>> >think it is good writing style.
>> >
>> > - part of the intent here is to prompt questions during
>> >review, as this discussion has never been resolved that I know
>> >of, regardless how long we debated the topic.
>> >
>> > I'll remove the paragraph anyway...
>>
>>
>>Ok
>>
>>
>>Ciao
>>Hannes
>>
>> >
>> >James
>> >
>> >_______________________________________________
>> >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
