Re: [sipcore] Location Conveyance -04 submitted, here's the changes

"Elwell, John" <john.elwell@siemens-enterprise.com> Mon, 08 November 2010 06:03 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2893A69C7 for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 22:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.47
X-Spam-Level:
X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 FduQ6lNLX1vw for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 22:03:37 -0800 (PST)
Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 963043A69BC for <sipcore@ietf.org>; Sun, 7 Nov 2010 22:03:36 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2205797; Mon, 8 Nov 2010 07:03:56 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 3C1D623F028E; Mon, 8 Nov 2010 07:03:56 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 8 Nov 2010 07:03:56 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "hannu.hietalahti@nokia.com" <hannu.hietalahti@nokia.com>, "jon.peterson@neustar.biz" <jon.peterson@neustar.biz>, "keith.drage@alcatel-lucent.com" <keith.drage@alcatel-lucent.com>, "rbarnes@bbn.com" <rbarnes@bbn.com>, "jmpolk@cisco.com" <jmpolk@cisco.com>
Date: Mon, 8 Nov 2010 07:03:53 +0100
Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes
Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlgABbnWwAABXISYACLHd3LAAJ3WTAABNZXQAACDrbA
Message-ID: <A444A0F8084434499206E78C106220CA02357AD542@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA02357AD02C@MCHP058A.global-ad.net> <C8FD749C.47D22%jon.peterson@neustar.biz> <A444A0F8084434499206E78C106220CA02357AD53B@MCHP058A.global-ad.net> <5BAF85033CB5F3439C4DE153165522B1109FEF8CAD@NOK-EUMSG-06.mgdnok.nokia.com>
In-Reply-To: <5BAF85033CB5F3439C4DE153165522B1109FEF8CAD@NOK-EUMSG-06.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2010 06:03:46 -0000

Hannu,

It may just be a case of displaying the locations in a specific order to the call taker, rather than any automated application.

John 

> -----Original Message-----
> From: hannu.hietalahti@nokia.com [mailto:hannu.hietalahti@nokia.com] 
> Sent: 08 November 2010 05:06
> To: Elwell, John; jon.peterson@neustar.biz; 
> keith.drage@alcatel-lucent.com; rbarnes@bbn.com; jmpolk@cisco.com
> Cc: sipcore@ietf.org
> Subject: RE: [sipcore] Location Conveyance -04 submitted, 
> here's the changes
> 
> John,
> 
> I agree, but I am curious to what kind of application you 
> have in mind to use the first/last/middle location object, please?
> 
> BR,
> Hannu Hietalahti
> 3GPP TSG CT Chairman
> tel: +358 40 5021724
>  
> 
> >-----Original Message-----
> >From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com] 
> >Sent: 08 November, 2010 06:55
> >To: Peterson, Jon; DRAGE, Keith (Keith); Hietalahti Hannu 
> >(Nokia-CIC/Oulu); rbarnes@bbn.com; jmpolk@cisco.com
> >Cc: sipcore@ietf.org
> >Subject: RE: [sipcore] Location Conveyance -04 submitted, 
> >here's the changes
> >
> >The only normative thing I was suggesting we add was to do 
> >with ordering, so that if there is >1 location present, the 
> >first is the one from nearest the source of the request. I 
> >don't see what harm that would do, and it could help in some 
> >circumstances.
> >
> >John 
> >
> >> -----Original Message-----
> >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
> >> Sent: 08 November 2010 01:34
> >> To: Elwell, John; DRAGE, Keith (Keith); 
> >> hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com
> >> Cc: sipcore@ietf.org
> >> Subject: Re: [sipcore] Location Conveyance -04 submitted, 
> >> here's the changes
> >> 
> >> 
> >> I don't think the draft can do anything more helpful than say 
> >> you shouldn't include multiple location objects because they 
> >> are confusing, and if you do permit multiple location 
> >> objects, do so only in an environment where the inserter and 
> >> recipient share some agreement about their meaning and 
> >> interpretation (a slight expansion of "you break it you 
> >> bought it," there). I don't think it will be a useful or 
> >> successful exercise for us to try to concretize that in a standard.
> >> 
> >> Jon Peterson
> >> NeuStar, Inc.
> >> 
> >> 
> >> On 11/5/10 12:22 AM, "Elwell, John" 
> >> <john.elwell@siemens-enterprise.com> wrote:
> >> 
> >> 
> >> 
> >> 	Yes, I agree that replacing an enterprise-provided 
> >> location is very bad. The problem with adding locations to 
> >> locations already present is how the PSAP chooses between 2 
> >> or even 3 locations. From my reading of the draft, we don't 
> >> have any normative statement on the order in which locations 
> >> are placed in the header. If we had a rule that the first 
> >> locationValue within a single or multiple Geolocation header 
> >> fields is nearest to the source of the request, and so on, it 
> >> might help. Then it would be clear that the service 
> >> provider-provided location would be the least reliable, but 
> >> it would still be there, e.g., for use if the other locations 
> >> are bogus.
> >> 	
> >> 	John
> >> 	
> >> 	> -----Original Message-----
> >> 	> From: DRAGE, Keith (Keith) 
> >> [mailto:keith.drage@alcatel-lucent.com]
> >> 	> Sent: 05 November 2010 04:37
> >> 	> To: Elwell, John; hannu.hietalahti@nokia.com;
> >> 	> rbarnes@bbn.com; jmpolk@cisco.com
> >> 	> Cc: sipcore@ietf.org
> >> 	> Subject: RE: [sipcore] Location Conveyance -04 submitted,
> >> 	> here's the changes
> >> 	>
> >> 	> Exactly, that is why I am saying you need multiples.
> >> 	>
> >> 	> Otherwise the scenario is that the PBX puts one in, and the
> >> 	> public network then replaces it because it says the regulator
> >> 	> tells the network to always provide a location. At least with
> >> 	> my approach, all the locations are there, and the PSAP then
> >> 	> sorts it out.
> >> 	>
> >> 	> Keith
> >> 	>
> >> 	> > -----Original Message-----
> >> 	> > From: Elwell, John 
> >> [mailto:john.elwell@siemens-enterprise.com]
> >> 	> > Sent: Thursday, November 04, 2010 5:48 PM
> >> 	> > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com;
> >> 	> > rbarnes@bbn.com; jmpolk@cisco.com
> >> 	> > Cc: sipcore@ietf.org
> >> 	> > Subject: RE: [sipcore] Location Conveyance -04 submitted,
> >> 	> > here's the changes
> >> 	> >
> >> 	> > Keith,
> >> 	> >
> >> 	> > Be very careful with this sort of approach. The trend is
> >> 	> > towards fewer SIP-PBXs and fewer "SIP trunks" serving an
> >> 	> > enterprise, with often a single SIP-PBX and a single entry
> >> 	> > into the SIP Service Provider for a whole country or even
> >> 	> > multiple countries. Even for the single country case, the
> >> 	> > service provider network is unlikely to have a clue as to
> >> 	> > where, in the country, the caller might be located (or even
> >> 	> > where the PBX is located if there are two geographically
> >> 	> > separate servers). Caller ID isn't likely to help either,
> >> 	> > since users can move around within the enterprise network.
> >> 	> >
> >> 	> > John
> >> 	> >
> >> 	> > > -----Original Message-----
> >> 	> > > From: sipcore-bounces@ietf.org
> >> 	> > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE,
> >> 	> Keith (Keith)
> >> 	> > > Sent: 01 November 2010 23:04
> >> 	> > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com; 
> >> jmpolk@cisco.com
> >> 	> > > Cc: sipcore@ietf.org
> >> 	> > > Subject: Re: [sipcore] Location Conveyance -04 submitted,
> >> 	> > here's the
> >> 	> > > changes
> >> 	> > >
> >> 	> > > If in 3GPP we look at subscription based business trunking
> >> 	> > > arrangement.
> >> 	> > >
> >> 	> > > The end terminal includes one location.
> >> 	> > >
> >> 	> > > The enterprise network supporting the UE adds its own
> >> 	> view of where
> >> 	> > > the UE is.
> >> 	> > >
> >> 	> > > The public network adds its own view of the location.
> >> 	> > >
> >> 	> > > That makes three.
> >> 	> > >
> >> 	> > > regards
> >> 	> > >
> >> 	> > > Keith
> >> 	> > >
> >> 	> > > > -----Original Message-----
> >> 	> > > > From: hannu.hietalahti@nokia.com
> >> 	> > > [mailto:hannu.hietalahti@nokia.com]
> >> 	> > > > Sent: Monday, November 01, 2010 11:46 AM
> >> 	> > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com; 
> >> jmpolk@cisco.com
> >> 	> > > > Cc: sipcore@ietf.org
> >> 	> > > > Subject: RE: [sipcore] Location Conveyance -04 
> >> submitted,
> >> 	> > here's the
> >> 	> > > > changes
> >> 	> > > >
> >> 	> > > > Hi Keith,
> >> 	> > > >
> >> 	> > > > yes, I remember you made this comment at Maastricht
> >> 	> > already, and I
> >> 	> > > > agree with you that from 3GPP viewpoint we need encoding
> >> 	> > that allows
> >> 	> > > > *more than one* piece of location information.
> >> 	> > > >
> >> 	> > > > In 3GPP case those would be typically the one 
> >> obtained from the
> >> 	> > > > terminal and the one added by the serving network if it
> >> 	> thinks it
> >> 	> > > > knows better.
> >> 	> > > >
> >> 	> > > > But my imagination runs out after these two. Are you
> >> 	> > saying we need
> >> 	> > > > more than 2?
> >> 	> > > >
> >> 	> > > > BR,
> >> 	> > > > Hannu Hietalahti
> >> 	> > > > 3GPP TSG CT Chairman
> >> 	> > > > tel: +358 40 5021724
> >> 	> > > > 
> >> 	> > > >
> >> 	> > > > >-----Original Message-----
> >> 	> > > > >From: sipcore-bounces@ietf.org
> >> 	> > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of 
> >> ext DRAGE,
> >> 	> > > > Keith (Keith)
> >> 	> > > > >Sent: 28 October, 2010 16:01
> >> 	> > > > >To: Richard L. Barnes; James M. Polk
> >> 	> > > > >Cc: sipcore@ietf.org
> >> 	> > > > >Subject: Re: [sipcore] Location Conveyance -04 
> >> submitted,
> >> 	> > > here's the
> >> 	> > > > >changes
> >> 	> > > > >
> >> 	> > > > >To be more specific - we had a document that 
> >> allowed multiple
> >> 	> > > > >locations. It was reduced to one without any 
> >> decision in
> >> 	> > > > that direction
> >> 	> > > > >being made by the working group. It needs to go back
> >> 	> to multiple
> >> 	> > > > >values.
> >> 	> > > > >
> >> 	> > > > >In my view there are clear use cases where 
> >> multiple values are
> >> 	> > > > >required.
> >> 	> > > > >
> >> 	> > > > >regards
> >> 	> > > > >
> >> 	> > > > >Keith
> >> 	> > > > >
> >> 	> > > > >> -----Original Message-----
> >> 	> > > > >> From: sipcore-bounces@ietf.org
> >> 	> > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf 
> >> Of Richard
> >> 	> > L. Barnes
> >> 	> > > > >> Sent: Thursday, October 28, 2010 1:19 PM
> >> 	> > > > >> To: James M. Polk
> >> 	> > > > >> Cc: sipcore@ietf.org
> >> 	> > > > >> Subject: Re: [sipcore] Location Conveyance 
> >> -04 submitted,
> >> 	> > > > here's the
> >> 	> > > > >> changes
> >> 	> > > > >>
> >> 	> > > > >> >> I'm pretty comfortable with the document 
> >> at this point,
> >> 	> > > > >> but have just
> >> 	> > > > >> >> one minor question: Why are you still 
> >> limiting the number
> >> 	> > > > >> of location
> >> 	> > > > >> >> values?  Why are three values harmful, 
> >> but not two?  This
> >> 	> > > > >> still seems
> >> 	> > > > >> >> like pointless ABNF legislation.
> >> 	> > > > >> >
> >> 	> > > > >> > we only added the ability to have a second 
> >> locationValue
> >> 	> > > > >because of
> >> 	> > > > >> > your rough-loc ID. Before that, we were firm in not
> >> 	> > > > >> allowing more than
> >> 	> > > > >> > one.  Given that choice, which do you like?
> >> 	> > > > >> >
> >> 	> > > > >> > Remember, this was Jon's proposal in 
> >> SIPCORE in Anaheim,
> >> 	> > > > which it
> >> 	> > > > >> > seemed everyone and their brother was agreeable
> >> 	> with, so ...
> >> 	> > > > >>
> >> 	> > > > >>
> >> 	> > > > >> As I recall, the proposal was to just remove 
> >> the limit on
> >> 	> > > > >the number
> >> 	> > > > >> of locations values, not to bump it up by one.  From
> >> 	> > the minutes:
> >> 	> > > > >>
> >> 	> > > > >> "Restore Geolocation header that has 
> >> multiple URIs, even
> >> 	> > > though we
> >> 	> > > > >> would not recommend it. Entities inserting 
> >> persence are
> >> 	> > > > responsbile
> >> 	> > > > >> for any resulting errors. The header parameters
> >> 	> > > > distinguishing URIs
> >> 	> > > > >> would not be added back in."
> >> 	> > > > >>
> >> 	> > > > >> At least in my mind, multiple != 2.
> >> 	> > > > >>
> >> 	> > > > >> --Richard
> >> 	> > > > >>
> >> 	> > > > >>
> >> 	> > > > >>
> >> 	> > > > >>
> >> 	> > > > >>
> >> 	> > > > >>
> >> 	> > > > >>
> >> 	> > > > >> > james
> >> 	> > > > >> >
> >> 	> > > > >> >
> >> 	> > > > >> >> --Richard
> >> 	> > > > >> >>
> >> 	> > > > >> >>
> >> 	> > > > >> >>
> >> 	> > > > >> >>
> >> 	> > > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote:
> >> 	> > > > >> >>
> >> 	> > > > >> >>> SIPCORE
> >> 	> > > > >> >>>
> >> 	> > > > >> >>> I've submitted the next version of Location
> >> 	> > Conveyance (-04)
> >> 	> > > > >> >>>
> >> 	> > > > >>
> >> 	> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio
> >> 	> > > > >> n-conveyance-04.txt
> >> 	> > > > >> >>> and I believe this version has addressed 
> >> each open
> >> 	> > > > item from the
> >> 	> > > > >> >>> mailing list, as well as what was 
> >> discussed and agreed
> >> 	> > > > to in the
> >> 	> > > > >> >>> Maastricht meeting.
> >> 	> > > > >> >>>
> >> 	> > > > >> >>> I have attempted to identify each open issue with
> >> 	> > > the specific
> >> 	> > > > >> >>> resolution here (in no particular order):
> >> 	> > > > >> >>>
> >> 	> > > > >> >>> - Martin wanted Section 3 to be broken up into
> >> 	> > > > subsections, each
> >> 	> > > > >> >>> revolving around each of the 4 diagrams. I have
> >> 	> done this.
> >> 	> > > > >> >>>
> >> 	> > > > >> >>> - allowed a maximum of two (up from one)
> >> 	> > > locationValues to be
> >> 	> > > > >> >>> present in the Geolocation header value. 
> >> The text however
> >> 	> > > > >> recommends
> >> 	> > > > >> >>> against inserting a second value. This 
> >> was agreed to in
> >> 	> > > > >> Maastricht.
> >> 	> > > > >> >>>
> >> 	> > > > >> >>> - Because we're allowing a max of two 
> >> locationValues,
> >> 	> > > > >> they can be in
> >> 	> > > > >> >>> separate Geolocation headers in the SIP request.
> >> 	> > > This scenario
> >> 	> > > > >> >>> necessitates bring a previous version's 
> >> paragraph in
> >> 	> > > > >> stating that a
> >> 	> > > > >> >>> 'SIP intermediary MUST inspect all 
> >> instances of each
> >> 	> > > > Geolocation
> >> 	> > > > >> >>> header before considering the routing-allowed
> >> 	> > > parameter to be
> >> 	> > > > >> >>> considered =yes', to ensure there isn't 
> >> a conflict in
> >> 	> > > > the 'other'
> >> 	> > > > >> >>> Geolocation header that states the policy is =no.
> >> 	> > > > >> >>>
> >> 	> > > > >> >>> - with the ability to add a second 
> >> locationValue, it is
> >> 	> > > > >> necessary to
> >> 	> > > > >> >>> warn against doing this (confusion at the LRs).
> >> 	> > > > >> >>>
> >> 	> > > > >> >>> - Added the "you break it you bought it"
> >> 	> philosophy to SIP
> >> 	> > > > >> >>> intermediaries that choose to insert a 
> >> second location
> >> 	> > > > where one
> >> 	> > > > >> >>> already existed, especially for 
> >> inserting a location
> >> 	> > > > URI in the
> >> 	> > > > >> >>> downstream SIP request.
> >> 	> > > > >> >>>
> >> 	> > > > >> >>> - Fixed the ABNF to handle zero, one or two (but
> >> 	> no more)
> >> 	> > > > >> >>> locationValues according to the 
> >> agreement in Maastricht.
> >> 	> > > > >> There is a
> >> 	> > > > >> >>> one-off use case which won't be in play 
> >> very often, but
> >> 	> > > > >> is a WG item
> >> 	> > > > >> >>> in ECRIT that several wanted to allow 
> >> the possibility for
> >> 	> > > > >> (inv
> >> 	
> >> 
> >>