[sipcore] Benjamin Kaduk's No Objection on draft-ietf-sipcore-locparam-05: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sipcore-locparam-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-locparam/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.