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 the follow-up. Responses embedded below with [MB2].  And, I'm
also bringing in some of Martin's suggestions. And, I've snipped out the
ones for which we have agreement.

Mary.

-----Original Message-----
From: Roger Marshall [mailto:RMarshall at telecomsys.com] 
Sent: Tuesday, December 11, 2007 3:58 PM
To: Barnes, Mary (RICH2:AR00); geopriv at ietf.org
Subject: RE: [GeoPriv]: Review comments on HELD draft:
http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-03

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.)
[MB2] I think the "acquire" is fine, since it is used elsewhere in the
document (contrary to Martin's concern).  I think the "and" is adequate
and we don't need to add the "both" in the abstract, since the "both"
aspect is addressed in the introduction. [/MB2]

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

[MB2] As a compromise, I propose that we go with Martin's suggestion
(with a slight modification expanding on the examples for wireless) here
then OR we just use both and say "wireless mobile" or "mobile wireless".
I did a search and found that the combination is quite common. 
 "... 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, wireless LAN, cellular) with varying degrees of
Device mobility ."
[/MB2]

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

[MB2] Okay - I see your point, but I still don't think your proposed
sentence isn't accurate either, since the method for receiving the LI is
the same (i.e., the method is a Location response which can contain
multiple values and types for/of location information). I'd propose then
to change that sentence to the following to include your suggestion to
change the verb from "acquire" to "receive":
"This specification identifies two types of location information that
may be received from the LIS."
[/MB2]


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

[MB2] Okay. [/MB2]

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

[MB2] Yep. [/MB2]


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

[MB2] I think the "and" takes care of the *both*.  The *both* doesn't
add clarity and indeed can be confusing, since it implies you can only
get two Locations in a response. However, you can receive multiple
Locations URIs and types of location in the multiple forms. [/MB2]

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

[MB2] Unless Martin has a concern over the text I proposed, I'll make
that change. His text provides more detail, but it doesn't seem
necessary to make the statement that the LIS may return LI, since that's
basic, expected functionality. [/MB2]
> 
> 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.

[MB2] The other alternative is to change WAN to Martin's suggestion of
"Internet", but my preference is the above. [/MB2]

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

[MB2] So, if we want to be explicit about the inverse (which isn't a bad
idea in general with "shoulds"), let's add the following after that
sentence:
"If a Device performs the HELD query after establishing the VPN tunnel,
the Device may receive inaccurate location information." 
[/MB2]

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

[MB2] Okay, except the "MAY" will be "may" and yes, "devices" will be
"Devices" to be consistent with the rest of the document format. [/MB2]


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

[MB2] Correct. As was discussed at the meeting and captured in the
minutes, we can't make normative statements about the LIS. [/MB2]



_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv