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

[<[e-mail]>]

Hi,
Thank you for your comments.
I have incorporated your proposals as below mentioned.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Benjamin Kaduk via Datatracker <[e-mail]> 
Gesendet: Samstag, 1. Februar 2020 01:31
An: The IESG <[e-mail]>
Cc: [e-mail]; Jean Mahoney <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Betreff: Benjamin Kaduk's No Objection on draft-ietf-sipcore-locparam-05: (with COMMENT)

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?

[RJ] It is difficult to reference the various architectures for emergency since each country, based on national regulation rules, may have it's own architecture. The framework used in Europe is based on the below mentioned [M493].


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

[RJ] The architecture ETSI [M493] does define the rules what to do if there trust relationship and there is no trust relationship between operators. I.e. not sending the "loc-src" on a non trusted relationship. These are the rules set also by national regulation.

   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.

[RJ] The name of Reference [M493] is " Functional architecture to support European requirements 
               on emergency caller location determination and transport".  So I can change the sentence to:
   The functional architecture to support emergency caller location described within ETSI [M493] is an
   example of an architecture where it makes sense to use this
   parameter.



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?

[RJ] RFC3323 is describing the privacy principles in general also mentioning the rules for Record-Route.
I have added the following to the text:

this addition provides little more exposure than
   adding a proxy identity to the Record-Route header field (privacy defined in RFC3323).


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!

[RJ] This is OK for me. I have the following text:
Adding this parameter in an untrusted network serves solely to give location information to untrusted parties, and is NOT RECOMMENDED.


   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.

[RJ] RFC6442 discusses a little bit more about TLS. Since RFC6442 is the basis used and extended by this document, I don't wanted to copy and paste all of RC6442.

   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?

[RJ] Yes Would be better to rephrase. I have changed it to:
If such trust relationship is not given, it is   strongly  recommended to delete the location information.

   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.

[RJ] I have changed it to "should". OK?