Re: [Geopriv] Another Update to draft-ietf-geopriv-loc-filters-05.txt

"James M. Polk" <jmpolk@cisco.com> Tue, 28 July 2009 10:01 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2483A6DC5 for <geopriv@core3.amsl.com>; Tue, 28 Jul 2009 03:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.482
X-Spam-Level:
X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlOHGsB1kghN for <geopriv@core3.amsl.com>; Tue, 28 Jul 2009 03:01:58 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C3CC53A6DA8 for <geopriv@ietf.org>; Tue, 28 Jul 2009 03:01:58 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIGAO9pbkqrR7PE/2dsb2JhbACIR7F7iCePQAWEDA
X-IronPort-AV: E=Sophos;i="4.43,282,1246838400"; d="scan'208";a="220023886"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2009 10:01:51 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6SA1pP4016792; Tue, 28 Jul 2009 03:01:51 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SA1pDB018082; Tue, 28 Jul 2009 10:01:51 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 03:01:51 -0700
Received: from jmpolk-wxp01.cisco.com ([10.89.11.121]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 03:01:50 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 28 Jul 2009 05:01:43 -0500
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, "'Thomson, Martin'" <Martin.Thomson@andrew.com>, geopriv@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <027f01ca0eda$e6900ce0$0301a8c0@nsnintra.net>
References: <017d01ca0525$c2102fd0$1116a20a@nsnintra.net> <E51D5B15BFDEFD448F90BDD17D41CFF10608AEB6@AHQEX1.andrew.com> <02f901ca06c6$6ab2bb70$0301a8c0@nsnintra.net> <XFE-SJC-212LFQG101s00009d83@xfe-sjc-212.amer.cisco.com> <027f01ca0eda$e6900ce0$0301a8c0@nsnintra.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID: <XFE-SJC-212k4TWIqgI0000a231@xfe-sjc-212.amer.cisco.com>
X-OriginalArrivalTime: 28 Jul 2009 10:01:50.0562 (UTC) FILETIME=[6D25BC20:01CA0F6A]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3269; t=1248775311; x=1249639311; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:=20RE=3A=20[Geopriv]=20Another=20Update=20to=20=0A =20=20draft-ietf-geopriv-loc-filters-05.txt |Sender:=20; bh=1C3+ZME8OlxKCN2I+KTMkSvmOu1/mB4dtrKMU0U3Tks=; b=KeKV8GjAcpQR02L7uEo5PnkjV4QALWv0QoMNTF6LZXI+C2F9VNWq4cVP+X 6SnnTfxvNFSvnATy/AEcgvwgUYyzkbpz05QKfHZOWdwe2Y60QxwoTlG90QJX HQAOMB1csa;
Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Subject: Re: [Geopriv] Another Update to draft-ietf-geopriv-loc-filters-05.txt
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2009 10:02:00 -0000

At 11:54 AM 7/27/2009, Hannes Tschofenig wrote:
>Hi James,
>
> >> >More seriously: I'm not entirely sure how to interpret responseTime
> >> >in the context of a SIP PA.  This might work as you have described,
> >> >but I would suggest that it complicates things
> >considerably.  There's
> >> >discussion on this point in my draft here:
> >> >
> >> ><http://tools.ietf.org/html/draft-thomson-simple-cont-presence->val
> >> -req-02#section-4.6.1.1>
> >> >
> >> >I don't know how to solve this problem yet.
> >> >
> >>
> >>I am not sure I see the problems.
> >>
> >>Imagine a SIP proxy receives a SIP message with an LbyR and wants to
> >>retrieve location information for routing. Depending on the
> >URI scheme
> >>(HTTP vs. SIP) he would either use
> >>http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-prot
> >ocol-03.t
> >>xt
> >>Or
> >>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-fil
> >ters-04.t
> >>xt
> >
> >I'm confused.
> >
> >For SIP, why would the filters doc be used when Conveyance
> >already has how a server dereferences a location URI for routing?
> >
> >This isn't a soliciting action requiring filters.
>
>How does SIP Location Conveyance dereference location URIs?
>My reading of draft-ietf-sip-location-conveyance was that it conveys
>location by value and/or by reference.

I have a section on this. Specifically it is section 4.5

         "Using sip/sips/pres as a Dereference Scheme"

I even have a pretty diagram.


>What "indication" is used in a SIP SUBSCRIBE to indicate "Please give me
>location information suitable for routing."?

err, a proxy routes based on the location information it is given (if 
it initiates a dereference transaction in the first place, there is 
no "suitable-ness" to it.

The location-based routing process asks for, and receives (or not) 
the PIDF-LO of the Target, then processes the message (i.e., making 
routing decisions) as if it were sent the PIDF-LO in the original SIP 
request. There's no magic to a location URI to get a routable 
location vs. an unroutable location -- especially since there is no 
difference in our that same proxy receives location by value.

If you believe there needs to be a suitable-ness to location 
information, then we need a new error code for cases in which the 
supplied location isn't suitable, with exactly what an inserter is 
supposed to do with that error code (i.e., in that error code, there 
needs to be an indication what was missing - other than the whole 
location - that needs to be in the subsequent SIP request to make is 
worthy of being routed.

Which do you want -

#1 - route based on the available location supplied (by-value or by-reference)?
or
#2 - a new error code and inserter behavior to know what to do when 
insufficient location was provided in the initial SIP request?

#1 is easy, cuz that's the way Conveyance is written now.

#2 is much more complicated - both to the routing proxy, and the 
burden on the location inserter to understand what isn't enough 
location, and to correct for just that amount - to satisfy the 
proxy's determination of what it thinks it needs to route the message 
propoerly.

James


>Ciao
>Hannes