From: Roger
Marshall [mailto:RMarshall at telecomsys.com]
Sent: Thursday, 6 December 2007 7:17
PM
To:
geopriv at ietf.org
Subject:
[GeoPriv]: Review comments on HELD
draft:http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-03
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.
[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.
[rm] How about, "...The protocol
includes options for a Device to acquire location information either by-value
or by-reference form (or both)."
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".
[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.”
[rm] I'd say, not quite -
but would quote a scholar, "brevity being a virtue in this
context".
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.
[MT] The LI isn’t
acquired until it is received.
[rm] yeah, I agree, not good
enough. Need to make it clear, something like "...two methods for
associating location...either directly, (i.e., an embedded form of location,
a PIDF-LO), or indirectly, (i.e., a location URI, or pointer to
location)..."
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
<???>].
[MT] I think that
the rest of the sentence provides adequate clarification: “…both can be
provided concurrently from the same LIS…”
[rm] no real contest here (just
seemed improper to introduce the phrase "these methods" without reference
to what they were first).
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.
[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.
[rm] granted, the domain is
different, but is still consistent between Device and LIS. New
suggestion then to make the wording not so exclusive sounding, change "(the
access network)" to "(e.g., the access
network)".
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.
[MT] Same response
as above.
[rm] no contest here, given my
suggested prior change.
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".
[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?
[rm] statements such as, "The LIS
exists...", when left unqualified, do seem to be all-inclusive. I will
defer to separate thread - the "caching" or "location
storing" discussion.
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)."
[MT] Agreed.
The parenthesized definition of “determined” isn’t necessary though.
[rm]
agree.
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."
[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.
[rm] I'll grant you my
mis-use of "acquisition... to". To your question (an because the
word 'reference' would be redundant), both these methods are 'associations' of
location information. I cite the suggested from C3, "...two methods for associating
location...either directly, (i.e., an embedded form of location,
a PIDF-LO), or indirectly, (i.e., a location URI, or pointer to
location)..."
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.
[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, …”
[rm]
agree.
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.
[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?
[rm] Use of the term "Internet"
would be better, if that's what this is talking about (my original
confusion was around the picture in my mind of, LAN---WAN; WAN---LAN; or
WAN---LAN---WAN, etc.)
C12. Section 4.1, pp3.,
Clarify wording (2x).
Change from:
"address"
Change to: "IP address"
[MT]
Good.
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..."
[MT] “potentially
negative”. And please don’t down case Devices where it applies to the
client of the LIS.
[rm] yes, and point
taken. Thanks.
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).
[MT] Anything
acting as a LIS *is* a
LIS. There is no LIS Proxy *waves
hand*.
[rm] agree that anything that
acts as a LIS *is* a LIS, let's clear up any wrong notion that a LIS can't
exist unless it supports the HELD protocol. Simply suggest striking the term
"Proxy", hence: "Devices that establish VPN connections for use by other
devices inside a LAN or other closed network MAY act as a LIS that
implements the HELD protocol for those other
[D?]devices."
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.
[MT] As above, so
below.
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.
[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.
[rm] No, if this were a
requirement on the HELD protocol, the requirement might state,
"The protocol MUST accept from the LIS and provide to the Device
complete location information, including confidence and uncertainty, (as
applicable to geo), as well as a trust-chain-of-authority in order to attest
to the credibility of the location information." (Note: Error in my
original wording as cited, should have read "...LIS provide..." rather
than as was stated, "...LIS not provide...".)
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.”
[rm] The question is - whether or
not Location information can be *accurate* without necessarily being precise
enough for routing or dispatch? It sounds like you're saying that it can
be. This should likely be explored on a different
thread.
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.
---
