Location Source Parameter for the SIP Geolocation Header Field
draft-ietf-sipcore-locparam-06

** Section 7.  It is likely worth emphasizing that the veracity of the “loc-src” parameter, like all elements of locationValue, is dependent on the security properties of the architectures conveying the information; and the trust placed in the participating nodes.  Put another way, just because it is there, does mean the loc-src is accurate or the true source.

** Editorial Nits
-- Section 3.  s/Each has it own/Each has its own/

-- Per [M493], s/Februar 2015/February 2015/

Thank you for the work put into this document. I found the document easy to read even for a non SIP-fluent person like me. 

I have just one non-blocking comment/question. Your reply will be appreciated.

-- Section 7 --
If the source of location is critical, then I wonder why this source is not cryptographically authenticated... Having hop-by-hop TLS protection is not enough probably as the UE (or any adverse proxy on the path) could insert a fake Geoloc with a fake loc-src.

I hope that this helps to improve the document,

Regards,

-éric

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly * 
* about perceived successes or failures of this experiment.          *
**********************************************************************

The following comments were provided by Benjamin Schwartz <bemasc@google.com>:

Benjamin would have balloted *YES* on this document.

## Section 1

Typo: “to identity itself”

Purpose: “How the entity adding the locationValue to the header field obtains the location information is out of scope of this document.” -> OK, but if this document isn’t intending to change the semantic intent of the Geolocation header, then it should say so.  In the current text, it’s hard to tell whether the field indicates the location of the endpoint or the intermediary.  Some text like “this parameter does not alter the subject of the locationValue” would help.

## Section 7

“If such trust domain is not given, it is strongly recommended to delete the location information.” -> Is this consistent with the example in Figure 2?  I think this is worth clarifying in the example text.

I agree with Ben’s comments, and have only some editorial ones of my own to add:

— Section 4 —

   Only a fully qualified host name is valid.  The syntax does not
   support IP addresses, and if an entity conforming to this
   specification receives a Geolocation header field with a "loc-src"
   parameter containing an IP address then the parameter MUST be
   removed.

It’s a small point, but as you’re already identifying a subject (“an entity conforming to this specification”), it’s unnecessarily awkward to use oassive voice:

NEW
   Only a fully qualified host name is valid.  The syntax does not
   support IP addresses, and if an entity conforming to this
   specification receives a Geolocation header field with a "loc-src"
   parameter containing an IP address, it MUST remove the
   parameter.
END

— Section 7 —

   This document introduces the ability of a SIP intermediary to insert
   a host name indicating that they added the specific locationValue to
   the Geolocation header field.

Make it “indicating that it added”; there aren’t multiple intermediaries here.

   If such trust domain is not given, it is
   strongly recommended to delete the location information.

I think the right fix to Ben’s comment here is “If a sufficient trust relationship does not exist, it is strongly recommended that the location information be deleted.”

Thanks for this easy-to-read document!
I do have a few comments, including places where we could improve
the internal consistency of our recommendations and requirements.

Section 3

   The primary intent of the "loc-src" parameter in this specification
   is for use in emergency calling.  There are various architectures
   defined for providing emergency calling using SIP-based messaging.

It's a little interesting to see this listed as the "primary intent" to the
implied exclusion of the other uses of location envisoned by RFC 6442.
Would those other uses for location information not also be interested in
the origin of a given piece of location information?

   The "loc-src" parameter is not included in a SIP message sent to
   another network if there is no trust relationship.  The "loc-src"
   parameter is not applicable if the administrative domain manages
   emergency calls in a way that does not require any generation of the
   location.

This statement seems to provide stronger constraints (e.g., be in conflict
with) the previous quote about "primary intent", and corresponds more to
"sole intent" than "primary intent".

   The functional architecture described within ETSI [M493] is an
   example of an architecture where it makes sense to use this
   parameter.

nit: I expect that there are many architectures specified by ETSI, so
additional qualifiers (e.g., "telephony" or "emergency telephony") might be
appropriate.

Section 6

   This document doesn't change any of the privacy considerations
   described in [RFC6442].  While the addition of the "loc-src"
   parameter identifies the entity that added the location in the
   signaling path, this addition provides little more exposure than
   adding a proxy identity to the Record-Route header field.

Are the privacy considerations of adding a proxy identity to the
Record-Route header field documented somewhere we could reference?

Section 7

   This document introduces the ability of a SIP intermediary to insert
   a host name indicating that they added the specific locationValue to
   the Geolocation header field.  The intent is for this field to be
   used by the location recipient in the event that the SIP message
   contains multiple locationValues.  As a consequence this parameter
   should only be used by the location recipient in a trusted network.

I see that essentially the same sentiment is already included in the
following paragraph, but I might consider noting here that "adding this
parameter in an untrusted network serves solely to give location information
to untrusted parties, and is disrecommended" out of some sense of
parallelism.  But that' purely stylistic, so do what sounds best to you!

   As already stated in [RFC6442], securing the location hop-by-hop,
   using TLS, protects the message from eavesdropping and modification
   in transit, but exposes the information to all SIP intermediaries on

Hmm, though RFC 6442 does not seem to require use of TLS (or equivalent).
It would be reasonable to include a brief discussion of the risks incurred
by not using TLS, though I don't insist on it.

   the path as well as the endpoint.  The "loc-src" parameter is
   applicable within a single private administrative domain or between
   different administrative domains where there is a trust relationship
   between the domains.  If such trust domain is not given, it is
   strongly recommended to delete the location information.

nit: I'm not sure if "If such trust domain is not given" parses properly; is
there a missing word or two?

   multiple locations.  To avoid problems with misinterpretation of the
   "loc-src" parameter, the value may be removed when passed to another
   domain.

I think we already made a suggestion stronger than "may" to do so.