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

"Richard L. Barnes" <rbarnes@bbn.com> Mon, 08 November 2010 01:37 UTC

Return-Path: <rbarnes@bbn.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 A9AA03A6932 for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 17:37:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.669
X-Spam-Level:
X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 jDVfWJ7ph55l for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 17:37:38 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2C5E228C0D0 for <sipcore@ietf.org>; Sun, 7 Nov 2010 17:37:37 -0800 (PST)
Received: from [128.89.253.162] (port=52720 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1PFGgB-000614-Iv; Sun, 07 Nov 2010 20:37:52 -0500
Message-ID: <4CD7546A.4090506@bbn.com>
Date: Mon, 08 Nov 2010 09:37:46 +0800
From: "Richard L. Barnes" <rbarnes@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
References: <C8FD749C.47D22%jon.peterson@neustar.biz>
In-Reply-To: <C8FD749C.47D22%jon.peterson@neustar.biz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "DRAGE, Keith \(Keith\)" <keith.drage@alcatel-lucent.com>, "sipcore@ietf.org" <sipcore@ietf.org>, "hannu.hietalahti@nokia.com" <hannu.hietalahti@nokia.com>
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 01:37:47 -0000

+1

What's called for here is cautionary text, not anything normative.
--Richard


On 11/8/10 9:34 AM, Peterson, Jon wrote:
>
> 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
>
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore