The distinction between fixed and mobile, wireline and wireless is
relevant, it is old-school thinking and isn't really applicable anymore.
We are talking about an Internet-based device, which can be any or all
of the above, and often at the same time.
I think that dissecting the networks in the manner being described below
leads to a very slippery slope very quickly.
Our requirements for an LCP were that it MUST be implemented by all
devices, not that it MUST be implemented by all device if....
LCPs, the ones currently in Phone BCP, all provide a local service
discovery technique, SUPL does not. This aspect of an LCP is important,
as it puts the target device in contact with the location server
responsible for determining the location of the Target in the local
access network. In this way, it is possible for the device to ask for
location in the same way every time, regardless of the network
technology. Again, this is not true for SUPL, different access
technologies require the Device and the home SLP to support new
measurement types, and potentially additional "out of scope"
connectivity back to the actual serving network to use this information.
Don't get me wrong, SUPL has a place in providing location in some
access network architectures, but it is far from ubiquitous, the aim of
phone BCP is specify what MUST be supported by all devices.
Cheers
James
-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
Of
Roger Marshall
Sent: Friday, 21 November 2008 8:07 AM
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
------------------------------------------------------------------------------------------------
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]