[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Location Protocols in Phone BCP
Martin:
I agree with your excellent reference frame explanation, and would
support additional documentation/discussion around how we assemble and
use the location 'complex' you've mentioned - since phonebcp
requirements provide for these kinds of location information by which a
complex could be formed.
-roger.
> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson at andrew.com]
> Sent: Friday, November 21, 2008 11:30 AM
> To: Roger Marshall
> Cc: ecrit at ietf.org
> Subject: RE: [Ecrit] Location Protocols in Phone BCP
>
> Hi Roger,
>
> To answer this question, you have to first answer the
> question: how many reference frames exist? My answer is one.
>
> It helps to only have a single reference frame for this
> purpose. That is, earth-centred, earth-fixed is the single
> reference frame we use to determine movement. Anything
> moving in that reference frame is moving. Establishing ad
> hoc reference frames increases the complexity of any solution
> that we develop.
>
> In the plane example, you might use a complex of the geodetic
> location of the plane with uncertainty, plus a civic address
> with SEAT=34C. However, this would be considered to be
> moving at 3500m/s.
>
> Thanks,
> Martin
>
> > -----Original Message-----
> > From: Roger Marshall [mailto:RMarshall at telecomsys.com]
> > Sent: Friday, 21 November 2008 12:54 PM
> > To: Brian Rosen; Thomson, Martin
> > Cc: ecrit at ietf.org
> > Subject: RE: [Ecrit] Location Protocols in Phone BCP
> >
> > I agree with the differentiation of protocol requirement which
> > differentiate between mobile and non-mobile (use whatever term you
> > like), but I do not support terms such as 'wireless' (as is in the
> > draft) for the reasons you reasonably cite.
> >
> > The airplane example provides two notions of location. One may
> > relative to a wired database, which is inside a closed
> system, which
> > can only provide a relative location (e.g., you're in seat
> 34C). The
> > other view is that of being mobile, in this case, best
> given by some
> > 3space datum coordinate set (it could either represent the plane's
> > position or the end device location - you pick). The two
> forms have
> > different levels of importance, but each is relevant.
> >
> > The question is, is the end device fixed or mobile?
> >
> > -roger.
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br at brianrosen.net]
> > > Sent: Friday, November 21, 2008 8:53 AM
> > > To: 'Thomson, Martin'; Roger Marshall
> > > Cc: ecrit at ietf.org
> > > Subject: RE: [Ecrit] Location Protocols in Phone BCP
> > >
> > > The plane is a great example of an indirect connection to
> a network.
> > > My RV was another. You can't make assumptions about mobility or
> > > anything else of relevance to the group from the
> characteristics of
> > > the device placing the emergency call, or it's first hop
> connection.
> > > It's another example of how difficult it is to make use
> of layer 2
> > > specific LCPs.
> > > Generally, assuming that bridging devices will bridge LCPs is a
> > > losing proposition.
> > >
> > > Brian
> > >
> > > -----Original Message-----
> > > From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On
> > > Behalf Of Thomson, Martin
> > > Sent: Friday, November 21, 2008 11:43 AM
> > > To: Roger Marshall
> > > Cc: ecrit at ietf.org
> > > Subject: Re: [Ecrit] Location Protocols in Phone BCP
> > >
> > > I strongly disagree with this from a philosophical
> standpoint. Type
> > > of access should only affect protocol design where attributes of
> > > that access affect the protocol.
> > >
> > > For instance, we design protocols for networks with long delays,
> > > which happen to be applicable to inter-planetary communication.
> > > This means that when someone uses that protocol for
> shipping data on
> > > reindeer, it doesn't break because someone assumes that
> it a radio
> > > link in space.
> > >
> > > So, what we need to do is identify attributes of the network that
> > > are relevant to the protocol design. As far as the document is
> > > currently specified, the attribute that we're interested in is
> > > mobility - that is, the fact that location changes. Do not
> > > mistakenly assign this attribute to wireless networks.
> > >
> > > For an example of how this is harmful, imagine that it is
> possible
> > > that a wired connection on a plane (now, why don't they do
> > > that...seems logical).
> > > If we had a client that was on a wire, there is the risk
> that they
> > > continue this assumption to detrimental effect.
> > >
> > > Cheers,
> > > Martin
> > >
> > > > -----Original Message-----
> > > > From: ecrit-bounces at ietf.org
> > > [mailto:ecrit-bounces at ietf.org] On Behalf
> > > > Of Roger Marshall
> > > > Sent: Friday, 21 November 2008 9:29 AM
> > > > To: DRAGE, Keith (Keith); 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
> > > >
> > > > Keith:
> > > > I agree completely with the first part of what you said,
> > > and want to
> > > > clarify my intent of highlighting differences in general:
> > > >
> > > > We've already got different requirements by access
> 'type' (i.e.,
> > > > 'wireless' and 'mobile' mentioned by name), so for some other
> > > > requirements - certainly, I would think those that mention the
> > > > term 'wire database' - those imply their application to a fixed
> > > > type of network access (it wouldn't work to well for mobile).
> > > >
> > > > What I was asking for, (and to my understanding, it was
> > > agreed to in
> > > > the ecrit meeting), was that since these requirements
> > > already mention
> > > > different access types, that there should be some
> > > additional text that
> > > > acknowledges the existance of these different access types, as
> > > > background for their respective requirements.
> > > >
> > > > -roger.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com]
> > > > > Sent: Thursday, November 20, 2008 9:22 PM
> > > > > To: Roger Marshall; Brian Rosen; Stark, Barbara;
> 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
> > > > >
> > > > > We are moving towards a state where devices support
> multiple of
> > > > > these, and in some cases where they may be active at the same
> > > > time.
> > > > >
> > > > > We certainly already have devices that may be simultaneously
> > > > > registered in WLAN and 3GPP access.
> > > > >
> > > > > As soon as you start distinguishing any type of phone
> by access
> > > > > technology, you will end up with these devices having
> to support
> > > > > multiple different requirements.
> > > > >
> > > > > regards
> > > > >
> > > > > Keith
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: ecrit-bounces at ietf.org
> > > > > [mailto:ecrit-bounces at ietf.org] On Behalf
> > > > > > Of Roger Marshall
> > > > > > Sent: Thursday, November 20, 2008 9:07 PM
> > > > > > To: Brian Rosen; Stark, Barbara; 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
> > > > > >
> > > > > > Isn't there a need to set the scope [text] of phonebcp,
> > > so that it
> > > > > > makes clear what that the requirements apply (without
> > > > > > bias) to both fixed and mobile end devices (and their
> > > associated
> > > > > > network deployment types)?
> > > > > >
> > > > > > Below is some keyword sampling to show some implications
> > > > > with regard
> > > > > > to fixed vs. mobile, but which isn't as crisp as it
> could be
> > > > > > (depending on the scope).
> > > > > >
> > > > > > A search of phonebcp for the following terms yields the
> > > associated
> > > > > > references:
> > > > > >
> > > > > > Fixed:
> > > > > > (none);
> > > > > >
> > > > > > Wireline:
> > > > > > (none);
> > > > > >
> > > > > > Mobile:
> > > > > > AN-11;
> > > > > > ED-35/AN-19;
> > > > > > ED-35;
> > > > > >
> > > > > > Wireless:
> > > > > > AN-7/INT-6;
> > > > > > AN-9;
> > > > > > AN-7;
> > > > > > INT-6;
> > > > > >
> > > > > > From the toc, it is listed...
> > > > > >
> > > > > > 6.2.2. Access network "wire database" location
> > > > > information .
> > > > > > 7
> > > > > > 6.2.3. End-system measured location
> information . . .
> > > > > > . . . . 7
> > > > > > 6.2.4. Network-measured location
> information . . . .
> > > > > > . . . . 8
> > > > > >
> > > > > > -roger.
> > > > > >
> > > > > >
> > > > > > No mention of fixed, wireline, wireless, or mobile in any
> > > > > of the text
> > > > > > sections (Intro, etc.)
> > > > > >
> > > > > > > -----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
> > > > > >
> > > > >
> > > > _______________________________________________
> > > > Ecrit mailing list
> > > > Ecrit at ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ecrit
> > >
> > > --------------------------------------------------------------
> > > --------------
> > > --------------------
> > > 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
> > >
> > >
>
> --------------------------------------------------------------
> ----------------------------------
> 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