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-lbyr-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).
Comment[TH2]: The term "dereferencer" does not exist.
- changed to "...dereferencing entity..."
Comment[TH3]: To what does the "defined in" refer to?
- whether or not the dereferencing entity has permission to
attain the Target's location.
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
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.
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.
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.
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..."
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.
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.
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).
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.
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.
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.
Comment[TH16]: How does this SHOULD fit to the MUST NOT from above.
- it doesn't. I corrected it.
Comment[TH17]: Not sure what this means.
- removed the paragraph
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
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).
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.
Comment[TH21]: Delete this sentence. It does not make a sense.
- done
Comment[TH22]: I am not sure what this means.
- I took this out too
Comment[TH23]: Why do you repeat it again?
- removed paragraph
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...
James
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
