RE: [GeoPriv]: Review comments on HELD draft: http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-03

["Mary Barnes" <mary.barnes at nortel.com>]

Hi Roger,
 
Thanks for your review and comments. My responses are embedded below
[MB]. Also, note that I'm not using CAPs for things like "may" and
"should" in most of the responses, since they are recommendations for
device and LIS behaviors, and are not describing normative protocol
functionality.  This is another general change that needs to be made to
the document. 

Note, I have not reviewed Martin's responses yet, so we'll resolve any
differences in a separate email. 

Mary. 

________________________________

From: Roger Marshall [mailto:RMarshall at telecomsys.com] 
Sent: Thursday, December 06, 2007 2:17 AM
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
<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. 

[MB]  I'm not clear on your specific reason, but I agree that it does
need to include that both can be acquired by a device. I would suggest
something like: 
"The protocol allows a device to acquire the location information in two
forms: by-value and by-reference."
[/MB]

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

[MB] "mobile networks" is not general enough.  In my experience, "mobile
networks" refers to the cellular networks that we all use for our cell
phones and includes more than just the access network.  Wikipedia agrees
with me as it brings up "Cellular networks" when you search for mobile
network.  I consider wireless access networks to be a more general term
that encompasses wireless lan and WIMAX.  If we want the most general
term, then we could replace both the terms with "wireless networks".
[/MB]

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.

[MB] That sentence doesn't equate the two types of location information
and the next two sentences distinctly state how they are different. Both
types are received (from a protocol perspective) in the same manner
through a Location Response. To be more specific, we should perhaps
reword that sentence as follows:
OLD:
  This specification identifies two methods for acquiring LI.
NEW:
  This specification identifies two types of location information that
may be acquired. 
[/MB]

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 <???>].
[MB] I think the "compatible" was meant to imply that they both use the
same protocol mechanism, but I can see that is not quite clear.  I would
propose to just remove that beginning part of the sentence and reword
the sentence from:
OLD:
   Both of these methods are compatible, and both can be provided
concurrently from
   the same LIS so that application needs can be addressed individually.
  
NEW:
  Both of these methods can be provided concurrently from the same LIS
to accommodate application
  requirements for different types of location information. 
[/MB]

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.

[MB] Okay. I'll just suggest some slightly different wording:
"This document assumes that the LIS is present within the same
administrative domain as the Device (the access network)."
[/MB]

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. 
[MB] It's not clear to me which part of the sentence to which you want
this assumption applied.  I don't think we need to re-iterate the
assumption about the LIS being in the access network since we just said
that in the previous sentence. And, I don't think we're assuming that
the LIS is there, so that the device can acquire LI.  But, if others
agree that this is necessary, I'll add the text. 
[/MB]

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

[MB] I would like more WG feedback on this.  By definition, the LIS
caches location information, but it was not my understanding that
alleviating load on the target was a motivation.  [/MB]

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)."

[MB] I agree with your point, but am reluctant to restrict how LI is
determined, per the i.e., since the alternatives are better described in
RFC 3693. So, I would propose:
   "This document does not specify how LI is determined."
[/MB]
 

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
<http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-03
#ref-21> ] of any scheme, which a Location Recipient (LR) can use to
retrieve LI." 

[MB] I see your point. I also think this isn't the only place that this
slight mis-statement exists, so I will make a note to look for others.
I would prefer something along the lines in terms of clarification:
  "The HELD protocol facilitates retrieval of location directly in the
form of a PIDF-LO document
   (by-value) and indirectly as a Location URI (by-reference)." 
[/MB]

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. 
[MB] I would take this one step further and change that sentence to the
following, since it's not totally obvious what "this" refers to:
"All cases of NATs do not introduce inaccuracies in the returned
location. For example, ..."
[/MB]

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.

[MB]  This is a single topology. Perhaps, we can clarify that second
sentence as follows:
   "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, on the LAN side of the NAT, since the covered geographical
area is small."
[/MB]


C12. Section 4.1, pp3., Clarify wording (2x). 
Change from: "address" 
Change to: "IP address" 
[MB] Ok. [/MB]

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..." 
[MB] I don't see how the "potential negating" really adds a whole lot of
clarity to that statement.  I would propose something like: 
"In VPN scenarios, Devices should perform their HELD
 query, prior to establishing a VPN tunnel, to ensure the accuracy of
the location information."
[/MB]

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

[MB] I agree we shouldn't be qualifying the term LIS with HELD, but I
don't think we want to introduce the term "LIS proxy" either. How about
something like the following:
  "Devices that establish VPN connections for use by other devices
   inside a LAN or other closed network may serve as a LIS for those
   other devices." 
[/MB]

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. 
[MB] Here again, I would propose changing the "act as" to "serve as"
since the VPN is providing the functionality of a LIS. [/MB]

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.

[MB] I agree with your point, but not the proposed rewording.  That
whole paragraph can be re-ordered/re-worded to more accurately relate
that 1st sentence to the specific scenario being described.  :
OLD:

"  A LIS MUST NOT provide location information to a Device if it cannot
   provide accurate information.  This applies where the Device uses a
   VPN connection or is behind a NAT that serves a large geographic area
   or multiple geographic locations (for example, a NAT used by an
   enterprise to connect their private network to the Internet).  The
   LIS needs to be configured to recognize identifiers that represent
   these conditions."

NEW: 
"  In the cases where the Device uses a
   VPN connection or is behind a NAT that serves a large geographic area
   or multiple geographic locations (for example, a NAT used by an
   enterprise to connect their private network to the Internet), the LIS
may not be 
   able to return an accurate LI. If the LIS cannot determine an
accurate LI, 
   it should not provide location information to the requesting device.
   The LIS needs to be configured to recognize identifiers that
represent
   these conditions."
[/MB]


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).
[MB] I don't think this document should address location hiding, but
your point about the "MUST NOT provide ..." is a valid concern per your
point C18 and my response to C16.
[/MB]

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.

[MB] As discussed at the meeting (per the minutes), there are cases
where we have associated "musts" with discussion of how a LIS should
handle processing for this protocol.   In addition to the one you
mention in C17, there is one in section 6.2, pp2., s2.  I will scan the
document and reword any others I find. The only MUSTS we should be
applying to the LIS are specific to the protocol elements and security. 
[/MB]

--- 

 

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