 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Comments regarding the draft, http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-03.
Note: This is a partial review, for the first half of the document - throught section 4 only. Additionally, most of the comments suggest minor, (yet IMO important), rewording changes - except, maybe for the last two, C17, C18 - which lead to bigger issues.
-roger marshall.
----
C1. Abstract, Clarify text,
Change from:
"...The protocol includes options for retrieving
location information either by-value or by-reference."
Change to:
"...The protocol includes options for acquiring
location information to an end device, either by-value or by-reference (or both)."
Reason: It could be misread to suggest that it may be possible to retrieve location "by-value" through some dereference step, instead of receiving location in a "by value" form as part of a Configuration Protocol.
C2. Introduction, Clarify text,
Change from:
"...mobile networks and wireless access networks."
Change to:
"...mobile networks."
Reason: Both mobile networks and wireless access networks share common characteristics. Is there a clear deliniation between the two? Maybe we could just say "mobile networks".
C3. Intro, pp2., s1. Change wording,
change from:
"...two methods for acquiring LI."
change to:
"...two methods for receiving the acquired LI."
Reason: Problem here is that HELD (in this draft) shouldn't equate an LI to a location URI (see comment C9, below) - wording needs to be clearer.
C4. Intro, pp2., Clarify wording:
"Both of these methods are compatible..."
Reason: Question is, compatible with what? Need to say something like, compatible [with each other for a single request/response, or <???>].
C5. Section 3, Overview and Scope, pp1., s2., Change wording
Change from:
"The LIS is present within the same administrative domain as the Device (the access network).
Change to:
"For this document, we make the assumption that the LIS is present within the same administrative domain as the Device (the access network)."
Reason: Same domain assumption needs spelled out, since it is possible for LIS elements to exist in core network domains also.
C6. Section 3, pp1., s3. Change wording.
Change from:
"An Access Provider (AP) operates the LIS so that Devices (and Targets) can
retrieve LI."
Change to:
"For this document, it is assumed that an Access Provider (AP) operates the LIS so that Devices (and Targets) can
retrieve LI."
Reason: same "state the assumption" comment needed as above.
C7. Section 3, pp1., s4. Change wording.
Change from:
"The LIS exists because not all Devices are capable of
determining LI, and because, even if a device is able to determine
its own LI, it may be more efficient with assistance."
Change to:
"The LIS exists because not all Devices are capable of
determining LI, and because, even if a device is able to determine
its own LI, it may be more efficient with assistance, and finally, because it may be desired that external requests for a target location be cached in a LIS in order to alleviate load from the target device."
Reason: The reason given as to why a LIS exists needs to be expanded to cover the idea of "storing location".
C8. Section 3, pp1., s5., change wording, since there are more ways to come up with a location than just by derivation methods.
Change from:
"This document does not specify how LI is derived."
Change to:
"This document does not specify how LI is determined (i.e., provisioned, measured, or derived)."
C9. Section 4, pp1., s1., Clarify wording,
Change from:
"The HELD protocol facilitates retrieval of LI either by-value, as a PIDF-LO document, or by-reference..."
Change to:
"The HELD protocol facilitates the acquisition to the device, either of an LI directly via by-value, as a PIDF-LO document, or that of acquiring LI indirectly, via by-reference..."
Reason: Here, the "LI" term seems to be equated to either an LbyV LO or an LbyR location URI, whereas in the text following, (Section 4, pp3., s3.), it equates the LI to the object that a Location URI points to (LI should not be equated to a location URI, but to the LI which the location URI points to),
"A Location URI is a URI [21] of any scheme, which a Location Recipient (LR) can use to retrieve LI."
C10. Section 4.1, pp2., s1., Change wording for completeness,
Change from:
"This is not always the case."
Change to:
"Though this may occur, this is not always the case."
Reason: This makes the wording flow together, rather than sounding like two differing opinions from the same author.
C11. Section 4.1, pp2., s2., Clarify the following text to make the topology more understandable,
"For example, a NAT used in a
residential Local Area Network (LAN) is typically not a problem. The
external IP address used on the Wide Area Network (WAN) side of the
NAT is an acceptable identifier for all of the devices in the
residence since the covered geographical area is small.
Reason: It's not clear whether the intention is to differentiate between two separate topologies, one with a LAN and the other with a WAN, or only one topology that is a hybrid including both a LAN and a WAN portion.
C12. Section 4.1, pp3., Clarify wording (2x).
Change from: "address"
Change to: "IP address"
C13. Section 4.1.1, pp1., Change wording.
Change from:
"To minimize the impact of VPNs, Devices..."
Change to:
"To minimize the potential negating impact of VPNs, devices..."
C14. Section 4.1.1, pp2., Change wording,
Change from:
"Devices that establish VPN connections for use by other devices
inside a LAN or other closed network MAY act as a HELD LIS for those
other devices."
Change to:
"Devices that establish VPN connections for use by other devices
inside a LAN or other closed network MAY act as a LIS Proxy that implements the HELD protocol for those
other devices."
Reason: It is not clear what a "HELD LIS" is. The implication here is that of a proxy to get location on-behalf-of another device - which implies a LIS-to-LIS protocol (not mentioned).
C15. Section 4.1.1, pp3, Clarify terminology, what is meant by the following phrase, "act as a LIS"? (taken from following statement:
"VPN devices that act as a LIS MAY acquire
their own location using HELD."
Something that acts like a LIS is either (probably) really a LIS, or something like a "LIS Proxy". Could be clearer.
C16. Section 4.1.2, pp1., s1., Change wording,
Change from:
"A LIS MUST NOT provide location information to a Device if it cannot
provide accurate information."
Change from:
"It is the general expectation that a LIS not provide location information to a Device which is accurate information."
Reason: There seems to be a recurring mismatch between the description of what a protocol (HELD) interface is to a LIS - and that of the requirements for a LIS itself throughout this section, misplaced for what should be considered a black box to the interface.
C17. Section 4.1.2, pp1., s1., General Comment, How can the original statement be resolved in light of location hiding, which is a purposeful attempt to make a location "inaccurate" (depending on how the term is defined).
C18. General Comment - along the lines of comment C17: This draft advertises itself as a protocol spec, not a set of LIS requirements. The document needs to describe the in and the out of the HELD protocol interface, and should not intermingle other requirements, assumptions, and expectations of what a LIS (viewed as a black box) should do.
---
CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________ Geopriv mailing list Geopriv at ietf.org https://www1.ietf.org/mailman/listinfo/geopriv