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

["Peterson, Jon" <[e-mail]>]

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" <[e-mail]> 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:[e-mail]]
> Sent: 05 November 2010 04:37
> To: Elwell, John; [e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> > Sent: Thursday, November 04, 2010 5:48 PM
> > To: DRAGE, Keith (Keith); [e-mail];
> > [e-mail]; [e-mail]
> > Cc: [e-mail]
> > 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: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of DRAGE,
> Keith (Keith)
> > > Sent: 01 November 2010 23:04
> > > To: [e-mail]; [e-mail]; [e-mail]
> > > Cc: [e-mail]
> > > 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: [e-mail]
> > > [mailto:[e-mail]]
> > > > Sent: Monday, November 01, 2010 11:46 AM
> > > > To: DRAGE, Keith (Keith); [e-mail]; [e-mail]
> > > > Cc: [e-mail]
> > > > 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: [phone]
> > > >
> > > >
> > > > >-----Original Message-----
> > > > >From: [e-mail]
> > > > >[mailto:[e-mail]] On Behalf Of ext DRAGE,
> > > > Keith (Keith)
> > > > >Sent: 28 October, 2010 16:01
> > > > >To: Richard L. Barnes; James M. Polk
> > > > >Cc: [e-mail]
> > > > >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: [e-mail]
> > > > >> [mailto:[e-mail]] On Behalf Of Richard
> > L. Barnes
> > > > >> Sent: Thursday, October 28, 2010 1:19 PM
> > > > >> To: James M. Polk
> > > > >> Cc: [e-mail]
> > > > >> 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