 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Hi Roger, Thanks for putting in the time. Iâve
put some responses inline. Some of these might need a little more thought, but
Iâve put down my opinions. Cheers, Martin From: Roger Marshall
[mailto:RMarshall at telecomsys.com] 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
----
C1.
Abstract, Clarify text, 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. [MT] I see your point, but donât like âacquiring
â toâ. It doesnât read very well. Your comment (as with a similar later one)
relates to whether we consider a location URI as âlocation informationâ. In
the abstract, I donât think that we need to address it â brevity being a virtue
in this context. C2.
Introduction, Clarify text, 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". [MT] Iâd suggest instead that the statement
read: ââ scenarios in which the Device might rely on its access network to
provide location information. The LIS service applies to access networks
employing both wired technology (e.g. DSL, Cable) and wireless technology (e.g.
WiMAX) with varying degrees of Device mobility.â C3.
Intro, pp2., s1. Change wording, 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. [MT] The LI isnât acquired until it is
received. C4.
Intro, pp2., Clarify wording: Reason: Question is, compatible with what? Need to say
something like, compatible [with each other for a single request/response, or
<???>]. [MT] I think that the rest of the sentence
provides adequate clarification: ââboth can be provided concurrently from the
same LISââ C5. Section 3, Overview and Scope, pp1., s2., Change wording
Reason: Same domain assumption needs spelled out, since it is
possible for LIS elements to exist in core network domains also. [MT] This is merely stating the definition of
what a LIS is. This isnât an assumption. As far as a LIS that exists in the âcore
networkâ goes, that is entirely possible, but it remains in the same âadministrativeâ
domain. The access network administration is still providing the service, even
if the actual LIS is physically connected to another part of the Internet. ÂIf
you think that a definition is necessary, then we can discuss where it belongs. C6. Section 3, pp1., s3. Change wording. Reason: same "state the assumption" comment needed as
above. [MT] Same response as above. C7. Section 3, pp1., s4. Change wording. Reason: The reason given as to why a LIS exists needs to be
expanded to cover the idea of "storing location". [MT] The list wasnât intended to be
exhaustive. This is the second time that the word âcacheâ or âcachingâ has
arisen lately. Can I suggest that we leave the opening of that particular can
of worms until another day? 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: [MT] Agreed. The parenthesized definition of âdeterminedâ
isnât necessary though. C9. Section 4, pp1., s1., Clarify wording, 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." [MT] I see the problem. The question is: what
is the thing that a location URI and a location object are both instances of?Â
I donât know the answer to that question. Besides, I canât swallow your use of
âacquisition toâ. âAcquisitionâ is a âpullâ word, whereas âtoâ is a âpushâ
word. C10. Section 4.1, pp2., s1., Change wording for completeness,
Reason: This makes the wording flow together, rather than
sounding like two differing opinions from the same author. [MT] Using âthisâ on the start of the paragraph
is bad form too. Suggest: âIn some cases, LI provided by the LIS to a Device on
the remote side of a NAT or VPN device could be sufficiently accurate. The LIS
MAY provide LI in this case. For example, ââ C11. Section 4.1, pp2., s2., Clarify the following text to make
the topology more understandable, "For example, a NAT used in a 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. [MT] This case is covered in some detail in the
problem statement. Iâm not sure what your concern is. It is perhaps better to
use âInternetâ instead of Wide Area Network (WAN)â, would that work? C12. Section 4.1, pp3., Clarify wording (2x). [MT] Good. C13. Section 4.1.1, pp1., Change wording. [MT] âpotentially negativeâ. And please donât
down case Devices where it applies to the client of the LIS. C14. Section 4.1.1, pp2., Change wording, 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). [MT] Anything acting as a LIS *is* a LIS. There is no LIS Proxy *waves hand*. 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 Something that acts like a LIS is either (probably) really a
LIS, or something like a "LIS Proxy". Could be clearer.
[MT] As above, so below. C16. Section 4.1.2, pp1., s1., Change wording, 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. [MT] This requirement relates to the protocol
in that a Device implementing the protocol can be assured of the veracity of
any response provided by a LIS. Without a strong requirement (as you suggest)
the Device is unable to rely on the contents of the message. ÂAnything that can
appear on the wire is fair game and the location information provided by the
LIS falls into that category. It is not unreasonable to demand that it be
correct. 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). [MT] Location hiding shouldnât have any impact
on this document. The term âaccurateâ is used in a manner conforming with draft-thomson-geopriv-uncertainty
â that is, as a qualitative term. Location information can be accurate without
necessarily being particularly useful. Case in point, the statement: âYou are
here.â 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. [MT] See above statement. ---
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