[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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