Re: [sipcore] WGLC: draft-ietf-sipcore-locparam

Hi Robert,
thank you for your comments. And sorry for the delay in answering.

Here are my proposals to your comments:

1. I think this gets along with Christers comments he had.

So I changed:
>   "The SIP geolocation specification [RFC6442] describes the
>   "Geolocation" SIP header field which is used to indicate that the SIP
>   message is conveying location information.  The specification
>   suggests that only one location value should be conveyed."

To:
>   "The SIP geolocation specification [RFC6442] describes the   "Geolocation" SIP header field which is used to indicate that the SIP
>   message is conveying location information.  
> "The specification specifies that SIP intermediaries should not add location values to a SIP request that already contains location value."

In addition I can add the sentence:
[RFC6442] also states that if a SIP intermediary adds location it is fully responsible for addressing the concerns of any
   424 (Bad Location Information) SIP response it receives.

Would this OK for you?

2:
I think this is a left over from some changes of the past. It is only saying that in the case we do not need anay location to allocate the emergency call then we do also not need any location-source parameter.
Old Text:
The location-source parameter is not included in a SIP message
         sent to another network if there is no trust relationship.  The
         The location-source parameter is not applicable if the administrative domain manages
         emergency calls in a way that does not require location source generating the location.

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

3. 
This document does not add any further behavior on privacy since we are adding an additional parameter to the geo-priv header.
The fact is that we have requirements on emergency calling depended on regulatorily rules.
So seen from this the fact that a location is sent towards the PSAP is based on these rules.
We have also a lot of words regarding privacy ruling based on access and location service within RF6280 where RFC6442 is also referring to.
From my point of view RFC6442 is already describing everything.

So would you like to see everything repeated? Or is there any specific what we needs to take into consideration what I missed?

Thank you and Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: sipcore <sipcore-bounces@ietf.org> Im Auftrag von Robert Sparks
Gesendet: Donnerstag, 29. August 2019 16:54
An: A. Jean Mahoney <mahoney@nostrum.com>; SIPCORE <sipcore@ietf.org>
Betreff: Re: [sipcore] WGLC: draft-ietf-sipcore-locparam

A few comments:

I disagree that 6442 "suggests that only one location value should be conveyed". 6442 doesn't say that at all. It says if you add additional things, you become responsible for what they mean and how they're used (See the "you break it, you bought it" discussion). I suggest this part of the introduction be rephrased to accurately reflect what 6442 says.

In Section 3, This sentence: "The The loc-src parameter is not applicable if the administrative domain manages emergency calls in a way that does not require location source generating the location" has a repeated "The" and does not parse. What does "require location source generating the location" mean?

The privacy considerations section should say more about the "priv" part of geopriv. A person providing a location with geopriv gets to specify policy for the use of a location in addition to the location. As 6442 tries to point out, a middlebox adding location can't _know_ the person's wishes, and can only unilaterally apply its own privacy policies. For emergency calling, I know about the argument that relies on an implicit agreement assuming that the user would _want_ their location conveyed.  But the document is currently silent on this. It should be explicit. The claim that this behavior doesn't change the privacy considerations in 6442 is a little edgy.

RjS

On 8/15/19 2:43 PM, A. Jean Mahoney wrote:
> Hi all,
>
> This begins the Working Group Last Call of draft-ietf-sipcore-locparam 
> (Location Source Parameter for the SIP Geolocation Header Field).
>
> Please post any feedback to the sipcore mailing list by Friday, August 
> 30.
>
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-locparam/
>
> Thanks!
>
> Jean
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore