[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Location Protocols in Phone BCP
No objection to saying that SUPL in its present form is not a good
choice for wire-map, but would object to saying the same for other types
of 'non-measured' location.
Rather, SUPL is in fact an excellent choice for non-endpoint measured
location such as 'CellID'.
-roger.
> -----Original Message-----
> From: Brian Rosen [mailto:br at brianrosen.net]
> Sent: Thursday, November 20, 2008 12:32 PM
> To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes'
> Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com;
> hannes.tschofenig at nsn.com; ecrit at ietf.org
> Subject: RE: [Ecrit] Location Protocols in Phone BCP
>
> Phonebcp doesn't have a pre-disposition. It's neutral. If
> we need to parse more carefully, SUPL isn't very suitable for
> wiremap forms of location determination.
>
> Brian
>
> -----Original Message-----
> From: Roger Marshall [mailto:RMarshall at telecomsys.com]
> Sent: Thursday, November 20, 2008 3:22 PM
> To: Brian Rosen; Stark, Barbara; Richard Barnes
> Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com;
> hannes.tschofenig at nsn.com; ecrit at ietf.org
> Subject: RE: [Ecrit] Location Protocols in Phone BCP
>
> > Generally, I agree that SUPL is unsuitable for access
> > networks that don't use GPS or some form of measured location.
>
> [rsm - measured only - really? - surely you aren't suggesting
> that OMA (and therefore 3GPP, 3GPP2) throw away their
> reliance on 'rough location' via CellID, are you?
>
> Wiremap location - given (manually input)] CellID location -
> given Terrestial trilateration - measured Celestial
> trilateration - measured Geocoded/reverse geocoded - derived
>
> I would hope that PhoneBCP doesn't show a pre-disposition to 'given'
> location scenarios, aka wiremap, etc. that are more Wireline
> oriented, rather than mobile. For the future, wireline
> devices reduce in number, mobile (or even nomadic) devices
> will continue in their distribution bias. Fixed vs. Mobile
> has been the fundamental difference between how the IETF
> looks at things vs. these mentioned other fora. I contend
> that if we solve this for mobile - then we can begin
> communicating better with OMA/3GPP/3GPP2, and... Solving
> fixed will be easier.
> /]
>
> > -----Original Message-----
> > From: Brian Rosen [mailto:br at brianrosen.net]
> > Sent: Thursday, November 20, 2008 12:07 PM
> > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes'
> > Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com;
> > hannes.tschofenig at nsn.com; ecrit at ietf.org
> > Subject: RE: [Ecrit] Location Protocols in Phone BCP
> >
> > Gabor accuses us of ignoring reality. The 3GPP crowd has its own
> > version of that.
> >
> > All 3GPP networks I know of support a raw packet service. On that
> > service will run applications like MSN or AOL instant messaging.
> > Those services
> > will need to be able to make emergency chats. To route
> > properly, they need
> > location. That means that EVERY handset must deploy some LCP, and
> > must be able to get location suitable for emergency call
> routing and
> > dispatch per -phonebcp. The RV example is yet another case of the
> > same thing. The mistake is assuming that all emergency calls will
> > come through the E-CSCF.
> > They won't, and the 3GPP access network must conform to all the
> > -phonebcp requirements.
> >
> > Generally, I agree that SUPL is unsuitable for access networks that
> > don't use GPS or some form of measured location.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Stark, Barbara [mailto:bs7652 at att.com]
> > Sent: Thursday, November 20, 2008 2:54 PM
> > To: Roger Marshall; Brian Rosen; Richard Barnes
> > Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com;
> > hannes.tschofenig at nsn.com; ecrit at ietf.org
> > Subject: RE: [Ecrit] Location Protocols in Phone BCP
> >
> > I cannot support requiring SUPL in DSL routers, desktop
> computers (and
> > related operating systems, SIP soft clients), analog terminal
> > adaptors, or other similar devices that are intended for use in a
> > wireline environment. I think that organizations that can drive
> > requirements for devices intended to be use in an environment where
> > SUPL would actually work, should be responsible for having device
> > requirements requiring SUPL. In other words, 3GPP/3GPP2 are
> absolutely
> > in a position to require SUPL support for devices that
> operate in an
> > environment where SUPL works. This is a perfect example of the
> > "closed" network that Brian describes somewhere (framework,
> I think).
> >
> > Phonebcp is about requirements for devices in access environments
> > where the operators of the access environment cannot be assumed to
> > have any control over the type or nature of devices that
> connect to or
> > through it. Phonebcp needs to continue to have that as its purpose.
> >
> > I agree that nothing in phonebcp should preclude the use of
> SUPL, or
> > be incompatible with the use of SUPL. And I don't think it does.
> > Barbara
> >
> > -----Original Message-----
> > From: ecrit-bounces at ietf.org
> [mailto:ecrit-bounces at ietf.org] On Behalf
> > Of Roger Marshall
> > Sent: Thursday, November 20, 2008 2:36 PM
> > To: Brian Rosen; Richard Barnes
> > Cc: Gabor.Bajko at nokia.com; marc.linsner at cisco.com;
> > hannes.tschofenig at nsn.com; ecrit at ietf.org
> > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> >
> >
> > If the choice is between preventing, allowing, or
> requiring PhoneBCP
> > suppport of SUPL, then my vote is to NOT prevent! I would prefer
> > 'require' since *most* of the location-aware 3G compatible
> > handsets/aircards over the next several years will (I
> predict) have a
> > SUPL stack included. In the same time frame, many of those
> will also
> > have WiFi support, others will have LTE or WiMAX support as hybrids.
> >
> > SUPL will be common-place. OMA may not be 'Open-Source', it is
> > open-minded, and there is movement afoot to expand OMA/SUPL (as we
> > heard in the geopriv mtg. on Tuesday) w/respect expected proposals
> > such as LocSIP, etc. Over the fairly near-term, I think
> there will be
> > fewer protocol, location representation, and privacy
> discontinuities -
> > things that too often get cited - yet are seldom well understood.
> >
> > Let's encourage continued IETF communication with OMA/SUPL
> - not block
> > its use altogether. This is a case where we need to be
> inclusive, not
> > exclusive.
> >
> > As to the mobile RV sample case, the solution is also forseeable -
> > especially given that the location of the 3G aircard in the
> router is
> > good enough for routing. The scenario given needs some
> integration,
> > but is doable. Given that the aircard acts as a logical
> SET, with a
> > SUPL stack on board, and a GPS/AGPS chipset inside. This
> combination
> > *WILL* (I believe) interoperate with a number of end client
> > applications to initiate and complete a location-routed, 3261 style
> > SIP, emergency call through the core, and into an ESInet.
> >
> > -roger.
> >
> > > -----Original Message-----
> > > From: ecrit-bounces at ietf.org
> > [mailto:ecrit-bounces at ietf.org] On Behalf
> > > Of Brian Rosen
> > > Sent: Thursday, November 20, 2008 8:23 AM
> > > To: 'Richard Barnes'
> > > Cc: Gabor.Bajko at nokia.com; hannes.tschofenig at nsn.com;
> > > marc.linsner at cisco.com; ecrit at ietf.org
> > > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > >
> > > It's very hard to have L2 specific LCPs. The problem is that the
> > > clients are generally not very L2 aware. It's the clients
> > that have
> > > the problem.
> > > You can do things like interwork an L2 specific LCP to a
> > common LCP so
> > > that non L2 aware devices can work, but you have to do that, and
> > > usually, that's impractical. Use my example. Suppose
> that the L2
> > > used SUPL. It's possible for the PC Card that is plugged
> into the
> > > router could implement a SUPL client and a HELD server and
> > interwork
> > > SUPL in the GSM system to HELD on the Ethernet so the
> Ethernet VoIP
> > > phone could get location via HELD. Possible, but not practical.
> > > There are all sorts of these kinds of problems. That's why
> > > L2 specific LCPs don't work.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: Richard Barnes [mailto:rbarnes at bbn.com]
> > > Sent: Thursday, November 20, 2008 11:11 AM
> > > To: Brian Rosen
> > > Cc: Gabor.Bajko at nokia.com; James.Winterbottom at andrew.com;
> > > ecrit at ietf.org; marc.linsner at cisco.com; hannes.tschofenig at nsn.com
> > > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > >
> > > The IETF can't (and shouldn't) try to make particular
> standards for
> > > every access technology that's out there. What we can say
> > is that the
> > > paradigm for those protocols should be the same as at the
> IP layer:
> > > Clients MUST implement all, networks MUST implement at least one.
> > >
> > > (This is a little different from the text I sent before,
> > and clearer,
> > > I
> > > think.)
> > >
> > > All I'm saying is that we shouldn't try to enumerate all
> > the possible
> > > protocols at lower layers, we should just state the general
> > rule. It
> > > seems to me that this achieves the same level of
> > interoperability at
> > > all layers.
> > >
> > > --Richard
> > >
> > > > If there are exactly two LCPs all UAs must implement, and
> > > any number
> > > > of optional ones, then every network has to implement at
> > > least one of
> > > > those
> > > two
> > > > LCPs, and any number of optional ones. That means that
> > > "any number of
> > > > optional ones" is useless for both parties.
> > > > If the network can limit UAs to ONLY those that implement
> > > one of the
> > > > optional protocols, then it works, but in practice, it
> is usually
> > > impossible
> > > > to do that. My example is the wired, Ethernet connected
> > > phone in an
> > > > RV traveling down the road with wireless data card in a
> > > router. These
> > > > EXIST, now.
> > > >
> > > > Brian
> > > > -----Original Message-----
> > > > From: Richard Barnes [mailto:rbarnes at bbn.com]
> > > > Sent: Thursday, November 20, 2008 10:11 AM
> > > > To: Brian Rosen
> > > > Cc: Gabor.Bajko at nokia.com; James.Winterbottom at andrew.com;
> > > > ecrit at ietf.org; marc.linsner at cisco.com;
> hannes.tschofenig at nsn.com
> > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > > >
> > > > I think we need to pull up a level. It's not reasonable
> > > for an RFC to
> > > > try to list all of the location protocols out there, if for
> > > no other
> > > > reason than that it will rapidly become obsolete. Instead,
> > > we should
> > > > say something like the following:
> > > >
> > > > "
> > > > INT-12 Devices MUST support the DHCP location options
> > [RFC4776] and
> > > > [RFC3825] and HELD
> > > [I-D.ietf-geopriv-http-location-delivery]. Devices
> > > > SHOULD support all location protocols supported at lower
> > layers by
> > > > their interfaces (e.g., LLDP-MED [LLDP-MED]).
> > > > "
> > > >
> > > >
> > > >
> > > >
> > > > Brian Rosen wrote:
> > > >> The problem with SUPL is that the majority of networks
> > where SUPL
> > > >> would
> > > be
> > > >> available have a proxy (E-CSCF) insert location. It
> also has an
> > > >> incompatible location representation, and an incompatible
> > > privacy model.
> > > >> That makes it very hard to interwork with any of the rest
> > > of the IETF
> > > > work.
> > > >> I will say this. For quite some time, the IETF has been
> > trying to
> > > > interest
> > > >> OMA into cooperation on location so that we have
> > > interoperability at
> > > >> the protocol, location representation and privacy
> > levels. So far,
> > > >> that has
> > > > not
> > > >> happened. If, as part of a comprehensive agreement to
> > accomplish
> > > >> such a goal, SUPL became one of the LCPs, I would not object.
> > > >>
> > > >> Brian
> > > >>
> > > >> -----Original Message-----
> > > >> From: ecrit-bounces at ietf.org
> [mailto:ecrit-bounces at ietf.org] On
> > > >> Behalf Of Gabor.Bajko at nokia.com
> > > >> Sent: Thursday, November 20, 2008 9:26 AM
> > > >> To: James.Winterbottom at andrew.com; ecrit at ietf.org
> > > >> Cc: hannes.tschofenig at nsn.com; marc.linsner at cisco.com
> > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > > >>
> > > >> Hi,
> > > >>
> > > >> Is the intent to list the LCPs which are access-type
> > > agnostic but not
> > > >> supported anywhere, or instead have a list of LCPs which
> > > are highly
> > > >> probable to produce the intended result?
> > > >>
> > > >> There are restrictions everywhere, things come at a cost
> > > even in the
> > > >> general Internet model. The reality is that most of the
> > > devices with
> > > >> internet access have a home network already.
> > > >>
> > > >> - Gabor
> > > >>
> > > >>
> > > >> >-----Original Message-----
> > > >> >From: ext Winterbottom, James
> > > [mailto:James.Winterbottom at andrew.com]
> > > >> >Sent: Thursday, November 20, 2008 12:06 AM
> > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit at ietf.org
> > > >> >Cc: marc.linsner at cisco.com; Tschofenig Hannes (NSN
> - FI/Espoo)
> > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP
> > > >> >
> > > >> >Hi Gabor,
> > > >> >
> > > >> >The list of LCPs in the phone BCP is a must support
> > list, and is
> > > >> access-
> > > >> >type agnostic.
> > > >> >I am curious that you say that SUPL is a MUST support
> > > given that:
> > > >> >a) it requires a home network in order to operate
> > > >> >b) it simply doesn't work for DSL or Cable
> > > >> >c) it is questionable whether it is really deployable
> > for WiFi
> > > >> networks
> > > >> >
> > > >> >Can you perhaps describe how it fits into the general
> > > Internet model?
> > > >> >
> > > >> >Cheers
> > > >> >James
> > > >> >
> > > >> >
> > > >> >-----Original Message-----
> > > >> >From: ecrit-bounces at ietf.org on behalf of
> > Gabor.Bajko at nokia.com
> > > >> >Sent: Thu 11/20/2008 12:48 AM
> > > >> >To: ecrit at ietf.org
> > > >> >Cc: marc.linsner at cisco.com; hannes.tschofenig at nsn.com
> > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > > >> >
> > > >> >I was requested to send my observations regarding this
> > > requirement:
> > > >> >
> > > >> > ED-21/INT-12 Devices MUST support all of: DHCP
> > > location options
> > > >> > [RFC4776] and [RFC3825], HELD
> > > >> > [I-D.ietf-geopriv-http-location-delivery] and
> > > LLDP-MED [LLDP-MED].
> > > >> >
> > > >> >
> > > >> >I believe we should come up with a list of LCPs which
> > > are likely
> > > >> to be
> > > >> >supported in devices in a not so distant future. Since
> > > I have no
> > > >> seen or
> > > >> >heard about LLDP support yet, at least that should be
> > replaced
> > > >> with what
> > > >> >is mostly used today (OMA SUPL) and the 802.11
> > > mechanism, with the
> > > >> >condition that this MUST only be supported if there
> is a wifi
> > > >> interface
> > > >> >available on the device.
> > > >> >
> > > >> >- Gabor
> > > >> >
> > > >> >
> > > >> >
> > > >> >________________________________
> > > >> >
> > > >> >From: ext Tschofenig, Hannes
> > > >> >
> > > >> >Sent: Tuesday, November 18, 2008 12:49 PM
> > > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner at cisco.com
> > > >> >Subject: Location Protocols in Phone BCP
> > > >> >
> > > >> >
> > > >> >
> > > >> >Gabor,
> > > >> >
> > > >> >Could you please raise your question about location
> > > protocols in
> > > >> Phone
> > > >> >BCP mentioned at ESW5 in the ECRIT WG session again?
> > > >> >
> > > >> >Ciao
> > > >> >Hannes
> > > >> >
> > > >> >
> > > >>
> > > >>>
> > >
> --------------------------------------------------------------------
> > > >>> ---
> > > >> --
> > > >> >-----------------------
> > > >> >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]
> > > >>
> > > >> _______________________________________________
> > > >> Ecrit mailing list
> > > >> Ecrit at ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/ecrit
> > > >>
> > > >> _______________________________________________
> > > >> Ecrit mailing list
> > > >> Ecrit at ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/ecrit
> > > >>
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit at ietf.org
> > > https://www.ietf.org/mailman/listinfo/ecrit
> > >
> >
> > CONFIDENTIALITY NOTICE: The information contained in this
> message may
> > be privileged and/or confidential. If you are not the intended
> > recipient, or responsible for delivering this message to
> the intended
> > recipient, any review, forwarding, dissemination, distribution or
> > copying of this communication or any attachment(s) is strictly
> > prohibited. If you have received this message in error,
> please notify
> > the sender immediately, and delete it and all attachments from your
> > computer and network.
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit at ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit
> >
> > *****
> >
> > The information transmitted is intended only for the person
> or entity
> > to which it is addressed and may contain confidential, proprietary,
> > and/or privileged material. Any review, retransmission,
> dissemination
> > or other use of, or taking of any action in reliance upon this
> > information by persons or entities other than the intended
> recipient
> > is prohibited. If you received this in error, please contact the
> > sender and delete the material from all computers. GA621
> >
> >
> >
>
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit