I'm not interested in preventing SUPL. The drafts allow others. The
problem is, and remains interoperability. The basic LCP "rule" is
"endpoints implement all, access networks implement one". That rule
provides interoperability. There is nothing you can do with SUPL that is
interoperable unless it goes on the list. If you implement SUPL, then the
network and the endpoints ALSO need to implement another protocol from the
list, or we don't have interoperability. It's possible for the network to
implement SUPL and some endpoints implement SUPL and those endpoints will
work. Others won't, and that is very bad.
There is no short cut. Either SUPL goes on the list, or the network has to
implement one of the LCPs on the list.
Given the current level of non-interoperability of SUPL with the rest of the
LCPs, I oppose adding SUPL to the list at this time.
I don't understand your comments on the RV case. The card can implement a
SUPL client. Unless it implements a DHCP or HELD server and interworks the
SUPL location to the HELD/DHCP protocols, we have a problem. And of course,
we can't reasonably get the privacy right doing that, and in some cases we
can't interwork the location representation.
Brian
-----Original Message-----
From: Roger Marshall [mailto:RMarshall at telecomsys.com] Sent:
Thursday, November 20, 2008 2:36 PM
To: Brian Rosen; 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
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.