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

From: "Roger Marshall" <[email-masked]>
Date: Thu, 6 Dec 2007 00:17:26 -0800

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.

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

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.

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

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.

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.

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

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

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

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.

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.

C12. Section 4.1, pp3., Clarify wording (2x).
Change from: "address"
Change to: "IP address" 

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

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

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.

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.

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

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.

---

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 10 Dec 2007 22:36:00 -0600

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:[email-masked]] 
Sent: Thursday, 6 December 2007 7:17 PM
To: [email-masked]
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. 

---- 

   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.

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

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.

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

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

[MT] Same response as above.

   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?

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.

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

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

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, 

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?

[MT] Good.

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

C15. Section 4.1.1, pp3, Clarify terminology, what is meant by the following phrase, "act as a LIS"?  (taken from following statement:

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.

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.

--- 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 11 Dec 2007 13:31:22 -0600

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:[email-masked]] 
Sent: Thursday, December 06, 2007 2:17 AM
To: [email-masked]
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
> .  

-roger marshall. 

---- 

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

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

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

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]

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

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]

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

Change from: 

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

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

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]

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

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

   inside a LAN or other closed network may act as a LIS Proxy that

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

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]

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

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

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 11 Dec 2007 15:39:24 -0500

Mary,
I agree with your replies to Roger's comments. You asked for feedback on
the following:

--------------end snipped text-------------------------------

In the current HELD draft, we only have the source IP address as the
identifier. Without extensions to support other IDs, the only way that
the LIS could be used to alleviate load from the target device, is for
the device to give out the (unsecured) location URI. Since we haven't
defined a way for the LIS to be populated with security rules for who
can dereference location, I think it would be a bad idea for us to
encourage this use, or claim that it is desirable in some way.
Therefore, I don't agree with adding this function to the description.

To me, alleviating load from the target is more what I would expect from
a Presence Server. There's nothing that would stop a server that has LIS
functionality on it, from also being a SIP Presence server. Within the
definition of Presence Server, we know how to do security and all sorts
of URIs, including long-lasting ones, like SIP user IDs or IMS PUIDs.
Let's not change the definition of LIS to somehow also incorporate the
definition of a presence server.
Barbara 

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 11 Dec 2007 13:57:21 -0800

Martin:
I appreciate your responses.  Please see my counter-comments, marked as
"[rm]", in-line.  Thanks.
 
-roger marshall.

	From: Thomson, Martin [mailto:[email-masked]] 
	Sent: Monday, December 10, 2007 8:36 PM
	To: Roger Marshall; [email-masked]
	Subject: RE: [GeoPriv]: Review comments on HELD
draft:http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delive
ry-03

	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:[email-masked]] 
	Sent: Thursday, 6 December 2007 7:17 PM
	To: [email-masked]
	Subject: [GeoPriv]: Review comments on HELD
draft:http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delive
ry-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. 

	---- 

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

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

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

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

	[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),

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

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

	[MT] Good.

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

	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.

	"A LIS MUST NOT provide location information to a Device if it
cannot

	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.

	---

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 11 Dec 2007 13:58:04 -0800

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:[email-masked]] 
> Sent: Tuesday, December 11, 2007 11:31 AM
> Subject: RE: [GeoPriv]: Review comments on HELD draft: 
> 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. 
> 

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

> term, then we could replace both the terms with "wireless networks".

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

> equate an LI

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

> something like,

[rm] agree.

> administrative domain as the Device (the access network)."

[rm] New suggestion is to make the wording not so exclusive sounding,
change "(the access network)" to "(e.g., the access network)".

> agree that this is necessary, I'll add the text. 

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

> alleviating load on the target was a motivation.  [/MB]

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

[rm] agree.

> either of
> LbyV LO or

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

> sounding like

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

>    residence, on the LAN side of the NAT, since the covered 

[rm] better than it was.

> the location information."

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

>    inside a LAN or other closed network may serve as a LIS for those

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

> since the VPN is providing the functionality of a LIS. [/MB]

[rm] I don't disagree.

>    The LIS needs to be configured to recognize identifiers that

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

> applying to the LIS are specific to the protocol elements and 

[rm] thanks.

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 11 Dec 2007 17:41:42 -0800

Barbara:
Device-to-LIS interoperation can take many forms.

If a LIS provides a Device's location when queried (by an element) and
interacts with the Device each time, then I agree there is no inherent
offloading of work.

If, on the other hand, a Device interacts with the LIS on a periodic
basis which results in a location update, then in turn makes that
location information available to any authorized requestor, then that
does show a case whereby the LIS sheds some load from the Device.

I don't think its necessary to introduce a Presence server into the
above equation, though I admit that one might be used in a solution.  A
'watcher' application might go through another level of indirection,
such as a HTTP location app. server, as is the case for typical "Friend
Finder" services, each of these have a Presence server component
somewhere.

>    its own LI, it may be more efficient with assistance." 

While the above statement is true wrt increased efficiency of location
determination, that is not the sole reason that a LIS exists.  Even if
all Devices *could* do self-location-determination, a LIS would still be
valuable for the reasons, including the distribution of load due to the
Device not being in a radio coverage area, not being powered up, or not
being willing to accept a direct query.

As to the idea that a LIS caches location, maybe it does or maybe it
doesn't - probably depends on the type of LIS and caching (storing) has
a range of values, from something transitory to something infinite.

-roger marshall.  

> the only way that the LIS could be used to alleviate load 
> from the target device, is for the device to give out the 
> (unsecured) location URI. Since we haven't defined a way for 

> From: Stark, Barbara [mailto:[email-masked]] 
> Sent: Tuesday, December 11, 2007 12:39 PM
> To: Mary Barnes; Roger Marshall; [email-masked]
> Subject: RE: [GeoPriv]: Review comments on HELDdraft: 
> I agree with your replies to Roger's comments. You asked for 
> feedback on the following:
> --------- snipped text of Roger's comment C7 and Mary's 
> response ------ C7. Section 3, pp1., s4.  Change wording. 
> Change from: 
> 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."
> 
> [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] --------------end snipped 
> text-------------------------------
> 
> In the current HELD draft, we only have the source IP address 
> as the identifier. Without extensions to support other IDs, 
> the only way that the LIS could be used to alleviate load 
> from the target device, is for the device to give out the 
> (unsecured) location URI. Since we haven't defined a way for 
> the LIS to be populated with security rules for who can 
> dereference location, I think it would be a bad idea for us 
> to encourage this use, or claim that it is desirable in some way.
> To me, alleviating load from the target is more what I would 
> expect from a Presence Server. There's nothing that would 
> stop a server that has LIS functionality on it, from also 
> being a SIP Presence server. Within the definition of 
> Presence Server, we know how to do security and all sorts of 
> URIs, including long-lasting ones, like SIP user IDs or IMS PUIDs.
> Let's not change the definition of LIS to somehow also 
> incorporate the definition of a presence server.
> Barbara 
> 
> *****
> 
> The information transmitted is intended only for the person 
> or entity to which it is addressed and may contain 
> confidential, proprietary, and/or privileged material. Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this information by 
> persons or entities other than the intended recipient is 
> prohibited. If you received this in error, please contact the 
> sender and delete the material from all computers. GA623
> 
> 
>

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 13 Dec 2007 15:14:58 -0600

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:[email-masked]] 
Sent: Tuesday, December 11, 2007 3:58 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: RE: [GeoPriv]: Review comments on HELD draft:

Mary:

-roger marshall.

> functionality.

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

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

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

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

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

[MB2] Okay. [/MB2]

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

[MB2] Yep. [/MB2]

>  
> 
> C9. Section 4, pp1., s1., Clarify wording, Change from:
> "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 
> 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),
> 
> [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.

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

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

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

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

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

>    enterprise to connect their private network to the Internet), the 
> LIS may not be

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Dec 2007 15:51:38 -0600

Thanks for sorting these out Mary.  I don't have any major concerns.

> Sent: Friday, 14 December 2007 8:15 AM
> Cc: Thomson, Martin

[MT] Quite right.  My concern with "acquire" was the grammatical use.  I just couldn't think of a better option.  Either of the later suggestions is good.

> technology (e.g. WiMAX, wireless LAN, cellular) with varying degrees of

[MT] I'm happy with that.

> may be received from the LIS."

[MT] This is OK.  I think that it is easier (on everyone) if we can just agree that "LI" covers both by-value (PIDF-LO) and by-reference (location URI).  That avoids this whole pickle, albeit by relying on the malleability of the definition.

> Locations URIs and types of location in the multiple forms. [/MB2]

[MT] That's right - the cost of being this careful is a dense specification - it's already tough enough.
 
> basic, expected functionality. [/MB2]

[MT]  I'm good with your suggestion.  Your suggestion is more compact, and therefore more readable.

> "Internet", but my preference is the above. [/MB2]

[MT] I tend to agree - the reason that WAN was originally used was to cover the double+ NAT situations, where using "Internet" is actually misleading.

> the Device may receive inaccurate location information."

[MT] s/may/might/ or s/may/could/ , i.e. probable, not permissible ;)

> "Devices" to be consistent with the rest of the document format. [/MB2]

[MT] Yep. 
 
> minutes, we can't make normative statements about the LIS. [/MB2]

[MT] I like your new text, suggest using words like "might" rather than "may":  s/LIS may not be/LIS might not be/.  The should is OK as a non-binding recommendation.

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 13 Dec 2007 14:07:13 -0800

Mary:
I'm okay with all the comments/suggestions cited, as indicated by [rm2]
responses in-line.

Thanks very much.

-roger marshall.

> Sent: Thursday, December 13, 2007 1:15 PM
> 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.
> 
> 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.
> 
> embedded below 
> resolve any
> document - 
> > "The protocol allows a device to acquire the location 
> information in 
> > two
> [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"

[rm2] agreed.

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

[rm2] agree to go with Martin's suggestion.

> equate an 
> [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 
> "This specification identifies two types of location 
> information that may be received from the LIS."
> [/MB2]

[rm2] agreed.

> [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]
> 
> > 
> [rm] This is ok as stands, if the prior change in C5 is taken 
> into account.
> 
> [MB2] Yep. [/MB2]
> 
> 
> >  
> > 
> [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]

[rm2] agree to leaving out the term "both".

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

[rm2] no contest here.

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

[rm2] I'm ok with either combination.

> query, prior to 
> [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]

[rm2] yes! I agree.

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

[rm2] okay.

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

[rm2] agree.