>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.
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?
>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. 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?
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.
>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
