Re: [Sip] a question about IETF draft location conveyance 09

Ted Hardie <hardie@qualcomm.com> Wed, 21 November 2007 21:02 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwiJ-00080f-UL; Wed, 21 Nov 2007 16:02:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IuwiH-00080S-TO for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:02:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwiH-0007yt-Hf for sip@ietf.org; Wed, 21 Nov 2007 16:02:25 -0500
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuwiD-0004S4-0d for sip@ietf.org; Wed, 21 Nov 2007 16:02:25 -0500
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lALL2JUM008483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Nov 2007 13:02:19 -0800
Received: from [67.169.50.136] (carbuncle.qualcomm.com [129.46.226.27]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lALL2InA005852; Wed, 21 Nov 2007 13:02:19 -0800
Mime-Version: 1.0
Message-Id: <p06240608c36a4849ecf3@[67.169.50.136]>
In-Reply-To: <XFE-SJC-211EAOeIiGX000013f8@xfe-sjc-211.amer.cisco.com>
References: <4742BDF5.9040302@unibo.it> <XFE-SJC-212qXLFfJNw000012bf@xfe-sjc-212.amer.cisco.com> <p06240607c36a38613297@[67.169.50.136]> <XFE-SJC-211EAOeIiGX000013f8@xfe-sjc-211.amer.cisco.com>
Date: Wed, 21 Nov 2007 13:02:16 -0800
To: "James M. Polk" <jmpolk@cisco.com>, Daniel Grotti <daniel.grotti@unibo.it>, IETF SIP List <sip@ietf.org>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] a question about IETF draft location conveyance 09
Content-Type: text/plain; charset="us-ascii"
X-PerlMx: Message inspected by PerlMx
X-PerlMx: Message inspected by PerlMx
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b
Cc:
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 2:28 PM -0600 11/21/07, James M. Polk wrote:
>Ted
>
>The "recipient=" within the Geolocation header is a SIP parameter, in a SIP document.  Everything discussed in Geopriv regarding this document needs to be approved in SIP too.  The SIP WG hasn't heard this part of the discussion because most members of SIP aren't subscribed to the Geopriv list.

That SIP parameter in a SIP document relates to a PIDF-LO object carried by
SIP; in that context, SIP is a using protocol of the GEOPRIV framework.  SIP
folks should certainly understand the work they're reusing, or the implementations
won't do the right thing.  But re-starting the conversation in SIP without
reference to the discussions that have already occurred in GeoPRIV is a
recipe for conflict at IETF Last Call.  We might as well start getting people
on the same page now.  From my  perspective, the right way to do that is
to start the discussion from where it last left off, even if that wasn't in
the same group.  That tells people where the consensus of that group was
and informs the rest of the discussion.

>
>I'm on the agenda right now to present in SIP in Vancouver, and this is one issue I'd like the SIP WG to comment on, so I'll be asking it there.

I look forward to your presentation.

Further commments inline.



>the rest of my reply is in-line
>
>At 01:51 PM 11/21/2007, Ted Hardie wrote:
>>At 6:33 PM -0600 11/20/07, James M. Polk wrote:
>>>Daniel
>>>
>>>wow... you nailed this one quickly.
>>>
>>>Neither the SIP WG nor Geopriv WG have a position with regard to this.  I don't like the parameter at all, and have said so from its introduction into discussions about putting it in the draft.  I don't think it accomplishes much more than confusion or a false sense of security by implementors.
>>
>>Well, I think the Geopriv working group discussed this a great deal, and that
>>there was reasonable (albeit rough) consensus that it be included.  Anyone
>>interested can certainly see a lively debate on the Geopriv list.
>
>and where was the SIP WG discussion on a SIP header parameter?  Since this parameter, from what you state below,  has a UA understanding the topology of a request - all the way to the endpoint - which is not part of the Geopriv charter to know or make decisions on, where's that discussion, at least as confirmation that SIP UAC's can know the full topology of a network enough to make this decision (that can't be changed)?

You are making a big leap here.  It doesn't have a UA understanding of the topology;
it has User control over private information.  The user gets to say by whom his or
her location gets used; that's a core aspect of RFC 4119 and friends, and you don't
get to reuse that work without getting that assumption built in.  We've had
exceptions for emergency services (discussed in the ECRIT BCPs), but they're
not general.  If a user does not want that private information used by the
SIP routing system but is willing to give it to the SIP entity receiving the call,
the system has to provide a way of making that clear.  We discussed several
ways to achieve that (including changes to 4119), and there was pretty
clear consensus on this way forward.  The version with retransmission-allowed
or routing-query-allowed did not see support, nor did redefining "retransmission=no"
to mean "except for SIP".

Yes, this does mean that a UA that sends a location object with recipient=end-point
may have a call fail if location-based routing is absolutely required; so will any
call not containing location, though, and the UA will have to be able to handle
that case.  It may very well be what is wanted, as we discussed in relation to
taxi services at some length (I may be willing to send my location to a local
taxi service so it can send the taxi, but not willing to send my location to
the sip-routing system so it can pick a taxi-service local to me).

>For example, Alice calls PizzaHut.com, and Pizza Hut routes her call to the Pizza Hut store most local to wherever she is to take her order.  Does her UAC understand this type of call well enough to have "recipient=both"?  Or would it just enter "recipient=endpoint", thus preventing her SIP request from being retargetted?
>
>How does her UAC understand the different from this type of call to Pizza Hut from merely a complaint to Pizza Hut corporate?
>
>I still can't seem to get over this simple example of a limitation and assumption created by this header parameter that the caller doesn't control.

Perhaps I don't see what you mean by "caller doesn't control" here.  Can you
elaborate?



>
>>The current text is:
>>A locationValue has the following independent header parameters,
>>
>>(snip of other parameters)
>>
>>the "recipient=" parameter to allow recipients to infer what SIP
>>      element type this locationValue was intended to be for.  The
>>      types are
>>
>>         o "endpoint" - meaning the ultimate destination UAS;
>>
>>         o "routing-entity" - meaning SIP servers that route messages
>>                    based on the location contents of requests; and
>>
>>         o "both" - meaning this locationValue is to be viewed by both
>>                    types of SIP entities.
>>
>>      Not all SIP entities have to read the locationValue within a
>>      Geolocation header, therefore a parameter value of "both" does
>>      not mean "every" SIP element receiving this request, it means all
>>      that care to pay attention to a locationValue.  The default
>>      behavior of SIP entities reading the locationValue is that if
>>      this header parameter is NOT present, the intended recipient is
>>      the destination UAS.
>>
>>A proxy seeing a locationValue with a recipient= tag of
>>routing-entity or both MAY do location based routing using
>>the location (as the draft says, it does not have to).  A proxy
>>seeing a locationValue with a recipient=endpoint should understand
>>that the locationValue was not intended to be used for
>>location-based routing.    The draft is pretty clear that the
>>privacy rules in RFC 4119; in Section 5 it says pretty bluntly:
>>
>>   Location Recipients MUST obey the privacy and security rules in the
>>   PIDF-LO as described in RFC 4119 regarding retransmission and
>>   retention.
>>
>>If a proxy is not the intended recipient, as given in this parameter,
>>it shouldn't be storing or acting on this data, just sending it along.
>>
>>
>>>That said, a proxy has "ar" capabilities wrt the Geolocation according to Table 1. (on page 7), and associated text states this pretty clearly. There is no text (not even a hint) that a proxy cannot read a location because "recipient=endpoint", therefore it can.  I would take this "recipient=" parameter as a hint to each type of SIP entity that
>>>
>>>        + if a UAS receives this parameter (meaning in a SIP request with
>>>           a Geolocation header), and it is set to "recipient", the UAS
>>>           shouldn't ignore the location in the request (like it otherwise
>>>           might).
>>>
>>>        + If a proxy receives this parameter (meaning in a SIP request with
>>>           a Geolocation header), and it is set to "server", the proxy
>>>           shouldn't ignore the location in the request (like it otherwise
>>>           might).
>>>
>>>I don't think either indication *ever* means the other SIP entity type cannot view the location, based on the parameter.
>>
>>I don't understand what you mean by "view" here.  A proxy putting this to memory
>>in order to send it along is doing fine; someone doing location-based-routing when
>>recipient=endpoint is not doing the right thing (except in the Emergency Services
>>case, where all bets are off).
>
>RFC3261 says proxies can view message bodies that aren't encrypted.

And what does "view" mean here?  If it understands it enough to know
how to use a pidf-lo object for location-based routing, it pretty much has
to understand it enough to know that it is not an intended recipient of
such a body, based on the header here and the pidf-lo internal rules.
If it doesn't understand pidf-lo, then "viewing" it means something like
"copying", "forwarding", or similar, no?

>I don't see the text giving an exemption in the emergency case, not at least in this doc.

The exception is in the ECRIT documents, or was the last I checked (sorry that I
have no time to confirm now).

>
>> >The only exception I can think of is a Location-by-value hidden by S/MIME means no one save who has the decryption key can view the contents of what's encrypted.
>>>
>>>Does this make sense?
>>
>>I suggest we continue the conversation in GeoPRIV if we have further discussion
>>on this particular point.
>
>But this is a SIP parameter, and a SIP document.  Everything discussed in Geopriv needs to be approved in SIP too.  The SIP WG hasn't heard this part of the discussion because most members of SIP aren't subscribed to the Geopriv list.

I'm reluctant to suggest cross-posting, but I do believe that folks commenting on
this should be aware of the discussion in the Geopriv group prior to this.  I continue
to recommend that folks review the geopriv archive, searching for the document
name, in order to get that context.

Note that deciding to ignore the privacy implications of geopriv's framework is
simply going to create "confusion and delay", as my son's favorite railroad
director says, and if we actually hope to see this work we need to work within
the framework as much as we can.

			regards,
				Ted Hardie






>>                                Ted
>>
>>
>>
>>>James
>>>
>>>At 04:59 AM 11/20/2007, Daniel Grotti wrote:
>>>>Hi all,
>>>>I'd like to ask a question about "draft-ietf-sip-location-conveyance-09.txt".
>>>>
>>>>How does Proxy Server have to work when a Geolocation Header contain "recipient=endpoint" parameter ?
>>>>Does the Proxy server just have to forward the SIP message (without do anything else) or can it read the information conveyed ?
>>>>thanks,
>>>>Regards
>>>>daniel
>>>>
>>>>--
>>>>
>>>>---------------------------------------------------
>>>>Daniel Grotti
>>>>DEIS - University of Bologna
>>>>Via Venezia, 52 - 47023 Cesena (FC) - ITALY
>>>>
>>>>Contacts
>>>>e-mail : daniel.grotti@unibo.it
>>>>Skype name : Daniel Grotti
>>>>---------------------------------------------------
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>This list is for NEW development of the core SIP Protocol
>>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>Use sipping@ietf.org for new developments on the application of sip
>>>
>>>
>>>_______________________________________________
>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip