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

["Roger Marshall" <RMarshall at telecomsys.com>]

Mary:
Thanks for combing through these comments.  I've included responses
in-line, denoted by "[rm]".  Some of these may be cross-linked to my
counter-comments back to Martin Thompson's prior email, which I just
replied to.

-roger marshall.

> -----Original Message-----
> From: Mary Barnes [mailto:mary.barnes at nortel.com] 
> Sent: Tuesday, December 11, 2007 11:31 AM
> To: Roger Marshall; geopriv at ietf.org
> Subject: RE: [GeoPriv]: Review comments on HELD draft: 
> http://tools.ietf.org/html/draft-ietf-geopriv-http-location-de
livery-03
> 
> 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-de
livery-03
> 
> 
> 
> Comments regarding the draft,
> http://tools.ietf.org/html/draft-ietf-geopriv-http-location-de
livery-03
> <http://tools.ietf.org/html/draft-ietf-geopriv-http-location-d
elivery-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]

[rm] Close to what I was trying to get at.  How about, "...The protocol
includes options for a Device to acquire location information either
by-value or by-reference form (or both)." (My objection to the original
wording was because with the use of "retrieve", the original text seemed
more indicative of a Dereference Protocol than 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".
> 
> [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]

[rm] The fact is that both terms "mobile" and "wireless" have context
baggage associated with them. I don't think that "wireless" is more
general than the term "mobile" in its most fundamental sense.  For
example, you might be on a ship, plane, train, or spaceship using either
a wired or wireless first link connection.  For location purposes an
external viewer sees your position as mobile - inside the craft, the
location/position may be static, but is also relative.  Wireless can be
easily divide into two technologies relevant for this discussion,
Wireless/CS, and Wireless/PS.  Neither of these terms helps to clarify.
To some, it may seem like a trivial difference, but it sets the
foundation for future discussions.  I think the right term to use is
"mobile".

> 
> 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]

[rm] ah, the real question here is what does an "LI" blob, (i.e.,
Location Information), equate to.  Is an LI to be viewed one in the same
as a well-formed PIDF-LO? [yes], or a location URI? [no]!

> 
> 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]

[rm] agree.

> 
> 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]

[rm] New suggestion is 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. 
> [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]

[rm] This is ok as stands, if the prior change in C5 is taken into
account.

> 
> 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]

[rm] I'll defer to a separate thread.

> 
> 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]

[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
> <http://tools.ietf.org/html/draft-ietf-geopriv-http-location-d
elivery-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]

[rm] or... of *both*.

> 
> 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]

[rm] I'm ok with the clarification here and/or from Martin Thompson's
(separate email) suggested text.

> 
> 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]

[rm] better than it was.

> 
> 
> 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]

[rm] sorry - meant "potentially negating...".  Implication here is that
VPNs do something (i.e., they impact), but it is not mentioned that they
are likely to be detrimental to the location configuration process.
Your rewording captures the important aspect of the "freshness" of
location, but doesn't address the negative impact of doing another
location configuration step *after* a VPN is established, thereby
getting a *bogus* location.

> 
> 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]

[rm] Simply suggest striking the term "Proxy" from my original
suggestion, therefore the sentence would read, "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. 
> [MB] Here again, I would propose changing the "act as" to "serve as"
> since the VPN is providing the functionality of a LIS. [/MB]

[rm] I don't disagree.

> 
> 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]

[rm] sorry - an error in my original wording as cited, should have read
"...LIS provide..." rather than as was stated, "...LIS not provide...".)
Bigger point here is that a HELD protocol specification can't hold a
LISs feet to the fire to provide an accurate (as opposed to inaccurate)
location information.

> 
> 
> 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]

[rm] thanks.

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