RE: [Geopriv] coming to terms on location by reference

Martin,

Why did i2 promise LbyR functionality prior to IETF review, if in fact NENA
was dependent on IETF for such a mechanism?

Promises YOU made in i2 does not force consensus in GeoPriv.

Btw, I do believe there is middle ground on LbyR!

-marc-

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Friday, September 15, 2006 10:43 AM
> To: Brian Rosen; Hannes Tschofenig
> Cc: GEOPRIV; Thomson, Martin; Henning Schulzrinne
> Subject: RE: [Geopriv] coming to terms on location by reference
>
> Feel free to take the suggestion to i2.5; it's a noble cause
> and I'm sure the ensuing discussion will be interesting. I
> believe your proposal is eminently complex, fraught with
> implementation difficulties, and will meet with considerable
> resistance from both VSPs and the vendors of soft switch
> products. I think you'd be better off waiting for i3 where
> the peer signaling relationship between the PSAP and the
> terminal can be capitalized on.
>
> In the mean time, i2 is in the process of implementation so
> having the IETF not helping will only likely make the IETF
> not relevant to its development which will ultimately make
> the ability of the IETF to contribute to further evolution
> that much more difficult. A great pity.
> The location reference mechanism will need to be supported,
> by wireless LIS operators at least, one way or the other.
>
> Cheers,
> Martin
>
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Friday, 15 September 2006 10:00 PM
> > To: Dawson, Martin; 'Hannes Tschofenig'
> > Cc: Thomson, Martin; 'Henning Schulzrinne'; 'GEOPRIV'
> > Subject: RE: [Geopriv] coming to terms on location by reference
> >
> > > Why is there any relevance to whether the PSAP request is
> initiated
> by
> > > the CPE automatically or by an operator clicking a button
> on a CPE
> > > screen. It seems about as relevant as the DHCP point.
> > At first blush, it seems that there is value in making a direct path
> from
> > the LIS to the VPC (where the VPC is the watcher), rather
> than looping
> > through the endpoint. However, when you look at the actual
> use case,
> I
> > think there is little value. The reason is that the frequency of
> update
> > is
> > very low, so low that any optimization seems pretty worthless.
> >
> > The FIRST location operation is MORE complex (the endpoint gets the
> > reference from the LCP, sends it to the VPC, the VPC
> exchanges it for
> > location with the LIS). The second operation would, if there was a
> direct
> > connection, be more efficient (VPC to LIS). Average them
> for two dips
> and
> > it's a wash. But 2 dips IS the usual case.
> >
> > They both work. There is no functionality difference except that in
> the
> > LbyR you need an extra interface and path.
> >
> > i2 is a lousy use case for LbyR
> >
> > >
> > > And a VPC does not have a call. If you're referring to a
> combo proxy
> and
> > > VPC, then you are relying on some proprietary functionality to get
> the
> > > request from the VPC component supporting the E2
> interface and back
> to
> > > the proxy component. You are throwing up your hands and saying -
> well do
> > > something proprietary then rather then use something eminently
> suitable
> > > like location by reference.
> > I'm saying that every VPC I know of has the proxy. If you like,
> suggest
> > an
> > update interface between the VPC and the proxy in the i2.5 effort,
> I'll
> > support that. All of the VPC interfaces are NENA developed.
> >
> > >
> > > Now, is the service bureau proxy that you're really referring to
> going
> > > to establish the subscribe directly to the device itself, or is it
> going
> > > to have to go back via the VoIP call server? If it does
> it directly
> to
> > > the device then you've just introduced all the concerns
> that you had
> > > over third parties being able to get location via a reference. How
> is
> > > the device supposed to know who this proxy is? If it goes back via
> the
> > > VSP call server, then you're now also asking the VSP to support
> some,
> > > currently unspecified, additional functionality for this update
> process.
> > > And what if the VSP is Skype? They also need to invent a location
> query
> > > protocol on top of everything else?
> > I'm asking that the VPC reInvite back towards the endpoint, which
> means it
> > goes through the VSP (this means the VPC proxy acts as a B2BUA, but
> most
> > of
> > them do this anyway for other reasons). The VSP does not need to
> support
> > anything but reInvite.
> >
> > >
> > > You were involved in the i2 WG Brian, you know we discussed all
> these
> > > sorts of options and dismissed them because we were
> looking for the
> > > minimal impact on the various participants in VoIP (in the real
> world).
> > > It seems somewhat disingenuous in another forum to be pushing
> > > impractical solutions now that i2 is published and in the
> process of
> > > implementation.
> > Mobility was not well thought out. ALL we did is to decline to do
> > anything that would preclude supporting mobility. The word
> "mobile"
> > as used in this context appears once in the i2 document, describing
> > one use of the V3 interface. My solution is eminently practical.
> >
> > >
> > > It's just occurred to me that the reference to DHCP may have been
> > > somewhat Freudian. Are all of these gymnastics driven by the
> prospect
> > > that DHCP doesn't support a location reference mechanism?
> > No, it's just that you would think using DHCP as an LCP for
> a mobile
> > device is ludicrous. In this use case, it is not. You might have
> > other use cases where it would be, but not this one.
> >
> > I'm happy to support a location reference mechanism for DHCP if we
> decide
> > that is a good thing.
> >
> > Brian
> >
>
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 15 Sep 2006 11:07:48 -0400