>Hi Brian,
>
> >-----Original Message-----
> >From: ext Brian Rosen [mailto:br@brianrosen.net]
> >Sent: Friday, June 26, 2009 1:54 PM
> >To: Bajko Gabor (Nokia-CIC/MtView); mlinsner@cisco.com
> >Cc: geopriv@ietf.org
> >Subject: RE: [Geopriv] Issue: version "negotiation"
> >
> >In order to get interoperability when multiple protocols are
> >available, you have two choices: all entities implement all
> >of them, or one end implements all of them and the other
> >implements at least one. There isn't any other way. The
> >PhoneBCP mechanism works for all applications.
> >
> >Even if you add the possibility of multiple access networks,
> >you still have to implement all of the LCPs on the end device.
> >
> >In this case, you have a (small) installed base of V0. Any
> >new device or server has to implement both V0 and V1 if
> >there is a possibility of encountering a V0-only end. It's
> >certainly possible to implement V1 only if you allow the
> >possibility of failure. For an emergency system, that would
> >not be an option, but for other use, it might be okay.
>
>Right.
>
> >What we find, however, is that the need to support the
> >emergency case forces both ends to implement what is needed
> >for that.
>
>The thing is, that currently regulators only mandate some of the
>fixed providers and all carriers operating in licenced bands to
>support emergency. In these cases, the carrier certifies a device
>before allowing it to connect to its network, thus it can force it
>to support a particular LCP or allow it to support none, if the
>carrier commits to assist the subscriber in placing the emergency call.
Gabor -- your whole argument is based on the assumption that there
will be regulations proposed, written, passed, and enforced some time
in the future -- since no one has written a single regulation
mandating one LCP vs. another be implemented.
This assumption is something we cannot rely upon in the IETF.
That doesn't mean a Canadian PSAP might not write an RFP that only
will allow 1 LCP, but this is never for the IETF to decide, or
account for -- especially before any regulation is written. The IETF
knowingly should not build protocols that violate any laws (that do
not have options not in violation) -- but something that enforced in
Canada might perfectly all right in Europe. So which way do we design
(IETF) protocols, for Canada or for Europe (or somewhere else)?
With regard to "...fixed providers and all carriers operating in
licenced bands..." -- what does that have to do with the Internet?
>Therefore, currently there is no need to support emergency outside
>the regulatory domain, thus there is no need to implement LCPs not
>required by the carrier operating in the licenced bands. A client
>will of course support all LCPs which the vendor considers to be an
>added value, ie will allow the client to acquire its location and
>provide it to location hungry applications.
>
>
> >After doing the emergency case, everything else
> >just works.
>
>Yes, emergency in generic terms is a superset of everything else and
>that comes with complexity. However, supporting emergency anywhere
>anytime is not a requirement of any government agency, thus vendors
>will not implement it just for the sake of generality, they will
>rather opt for supporting protocols which have added value to the
>customers. The market is the one which will make these decisions,
>not the standards.
so let's all wait 5 years for vendors to implement proprietary
solutions for different customers *BEFORE* we even start designing
interoperable standards... at least that way we can choose what the
market seems to be leaning towards, right? Though - then it becomes a
case of which are the loudest customers who want their version to
become _the_standard_ ...
gee, that'll be fun
>- Gabor
>
>
> >Brian
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: geopriv-bounces@ietf.org
> >[mailto:geopriv-bounces@ietf.org] On
> >> Behalf Of Gabor.Bajko@nokia.com
> >> Sent: Friday, June 26, 2009 12:55 AM
> >> To: mlinsner@cisco.com
> >> Cc: geopriv@ietf.org
> >> Subject: Re: [Geopriv] Issue: version "negotiation"
> >>
> >> Hi Mark,
> >>
> >> I think you are focused too much on the emergency service
> >case (where
> >> we expect some regulatory requirements), but geopriv's
> >scope is wider
> >> than that. Even if the access network decides to support only one
> >> specific LCP, the clients already have a choice of access
> >networks,
> >> thus the possibility to change access networks if that is
> >required to
> >> fetch their location using the preferred LCP and in the preferred
> >> format, is there.
> >>
> >> The requirement in the PhoneBCP is there just to address
> >the less-and-
> >> less likely case when there is only one access network
> >available at a
> >> given location and that access network supports one LCP.
> >> As an alternative, PhoneBCP could require the clients to
> >support all
> >> access network types instead of supporting all LCPs ;)
> >>
> >> James Polk wrote:
> >> >>Sure. But make that without requiring the clients to
> >support both
> >> >>encodings, as that will not happen.
> >>
> >> >what you just said above is a far cry from "clients MUST
> >NOT support
> >> v0"...
> >>
> >> It's not a cry. Location of the client is a commodity, for
> >which the
> >> clients are willing to pay. And some clients will not want
> >location in
> >> certain formats, so a server providing location in an
> >unpopular format
> >> will have a reduced customer base. If that format is
> >coupled with an
> >> LCP, the LCP may become unpopular too. This luckily will not be a
> >> problem of the client, as there will be a choice of LCPs
> >and location
> >> service providers anyway.
> >>
> >> - Gabor
> >>
> >>
> >> >-----Original Message-----
> >> >From: ext Marc Linsner [mailto:mlinsner@cisco.com]
> >> >Sent: Thursday, June 25, 2009 5:18 AM
> >> >To: Bajko Gabor (Nokia-CIC/MtView)
> >> >Cc: geopriv@ietf.org
> >> >Subject: Re: [Geopriv] Issue: version "negotiation"
> >> >
> >> >Gabor,
> >> >
> >> >An end host does not decide what LCP it uses to discover
> >> >it's location, the access network provider decides which LCP
> >> >it supports. Your assertion that an end host can pick and
> >> >chose which LCP it wants doesn't fly. Hence, as stated in
> >> >the PhoneBCP, clients must support all LCPs whereas access
> >> >networks must support (at least) one LCP. It's unclear (and
> >> >unlikely, IMO) whether access providers will support
> >multiple LCPs.
> >> >
> >> >-Marc-
> >> >
> >> >
> >> >On 6/24/09 11:58 PM, "Gabor.Bajko@nokia.com"
> >> ><Gabor.Bajko@nokia.com> wrote:
> >> >
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: ext James M. Polk [mailto:jmpolk@cisco.com]
> >> >>> Sent: Wednesday, June 24, 2009 4:55 PM
> >> >>> To: Bajko Gabor (Nokia-CIC/MtView);
> >> >>> bernard_aboba@hotmail.com; martin.thomson@andrew.com;
> >> >>> drage@alcatel-lucent.com; rbarnes@bbn.com; mlinsner@cisco.com
> >> >>> Cc: geopriv@ietf.org
> >> >>> Subject: RE: [Geopriv] Issue: version "negotiation"
> >> >>>
> >> >>> in-line
> >> >>>
> >> >>> At 02:42 PM 6/24/2009, Gabor.Bajko@nokia.com wrote:
> >> >>>> Below inline:
> >> >>>>
> >> >>>>> -----Original Message-----
> >> >>>>> From: ext James M. Polk [mailto:jmpolk@cisco.com]
> >> >>>>> Sent: Wednesday, June 24, 2009 11:08 AM
> >> >>>>> To: Bajko Gabor (Nokia-CIC/MtView);
> >bernard_aboba@hotmail.com;
> >> >>>>> martin.thomson@andrew.com; drage@alcatel-lucent.com;
> >> >>>>> rbarnes@bbn.com; mlinsner@cisco.com
> >> >>>>> Cc: geopriv@ietf.org
> >> >>>>> Subject: RE: [Geopriv] Issue: version "negotiation"
> >> >>>>>
> >> >>>>> At 09:53 PM 6/23/2009, Gabor.Bajko@nokia.com wrote:
> >> >>>>>
> >> >>>>>>>> Some questions:
> >> >>>>>>>>
> >> >>>>>>>> a. Should a client implementation of RFC 3825bis
> >> >>> be capable
> >> >>>>>>> of handling
> >> >>>>>>>> both v0 and v1 packets sent by a server?
> >> >>>>>>>
> >> >>>>>>> yes - because the server the client receives can be
> >> >either from a
> >> >>>>>>> v0 or v1 server.
> >> >>>>>>
> >> >>>>>> It may, but it should not be required to. If the client
> >> >>>>> does not like
> >> >>>>>> the location version provided by the server, it
> >may ignore it
> >> >>>>>
> >> >>>>> if this happens, then a client doesn't have
> >location from the
> >> >>>>> server, and has NO MEANS to tell the server it doesn't have
> >> >>>>> location except to ask for Option 123 again, which will
> >> >result in
> >> >>>>> the server sending the same v1 again - which the
> >client will
> >> >>>>> reject.
> >> >>>>>
> >> >>>>> Is this a solution?
> >> >>>>
> >> >>>> The client can make use of multiple protocols to acquire
> >> >>> its location.
> >> >>>
> >> >>> this really isn't an answer, given that this discussion
> >> >is all about
> >> >>> that to put into 3825bis -- a DHCP document.
> >> >>>
> >> >>>> If it chooses to use DHCP, but does not like the
> >encoding of the
> >> >>>> location it receives, it can choose to use some other
> >> >>> protocol, like
> >> >>>> HELD or SUPL, to get its location (possibly from a
> >> >>> different LIS) in a
> >> >>>> format it likes.
> >> >>>
> >> >>> if a client uses HELD, why waste time with DHCP?
> >> >>
> >> >> Right, this was one of the reasons why doing nothing but only
> >> >> deprecate 3825 was an alternative which the group
> >> >considered. But this
> >> >> would have not been fair towards 802.11
> >> >>
> >> >>> (I'm waiting for James and Martin to fall over.... ah,
> >> >there they go)
> >> >>>
> >> >>> I'll continue -- this isn't a catch all architecture
> >> >discussion, this
> >> >>> is how to make DHCP work, and DHCP only work.
> >> >>
> >> >> Yes, I agree. But note, a client is not interested in the
> >> >> architecture, it is only interested in its location
> >in the right
> >> >> format. If it doesn't get it using DHCP, will try other
> >> >LIS, possibly
> >> >> using other LCP. We prefer to support multiple LCPs
> >> >instead of an LCP with multiple location encodings.
> >> >>
> >> >>>>> I believe you are suggesting a configuration, not a
> >> >>> protocol design.
> >> >>>>>
> >> >>>>>> and try to find another server which provides the
> >> >>> location with the
> >> >>>>>> desired version.
> >> >>>>>
> >> >>>>> but how *in DHCP*
> >> >>>>> #1 does a client learn which servers?
> >> >>>>> #2 does a client contact another server, given that it
> >> >received the
> >> >>>>> DHCP OFFER from the client sending out a broadcast
> >> >message (asking
> >> >>>>> for any server to answer)?
> >> >>>>>
> >> >>>>> This is one of the shortfalls of DHCP, the client
> >> >accepts the first
> >> >>>>> answer from its broadcast, and doesn't move to the next
> >> >OFFER (if
> >> >>>>> there even is one).
> >> >>>>
> >> >>>> Yes, it is difficult (if not impossible) in a DHCP-only LCP
> >> >>>> environment. But since LIS/LCP is a competivite market,
> >> >>>
> >> >>> again - you are talking as if 3825bis needs to account
> >> >for all these
> >> >>> other LCPs... it doesn't.
> >> >>> This document is how
> >> >>> DHCP works -- and the WG was apparently unsatisfied with
> >> >RFC 3825, so
> >> >>> we are now modifying it to make is a viable solution.
> >> >>
> >> >> I personally care about 3825 encoding just because it was
> >> >adopted by
> >> >> 802.11, and the people there prefer to see a
> >correction in the SDO
> >> >> where the original document was created, before making the
> >> >corrections in the 802.11 standard.
> >> >>
> >> >>> We can't say 'oh, gee... use another LCP if you want
> >> >*that*...'. We
> >> >>> need to define how *that* works in DHCP the best way it can.
> >> >>
> >> >> Sure. But make that without requiring the clients to
> >support both
> >> >> encodings, as that will not happen.
> >> >> Putting the new encoding into a new dhcp option would be
> >> >one way of doing it.
> >> >>
> >> >>>> if they want the location they provide to be used by
> >> >clients, they
> >> >>>> better provide the location in a format in which clients
> >> >expect it.
> >> >>>
> >> >>> but your first reaction was to simply have the
> >client ignore the
> >> >>> OFFER, which isn't a solution at all.
> >> >>
> >> >> For some clients it will be the right solution.
> >> >>
> >> >> - Gabor
> >> >>>>>>
> >> >>>>>>> -----Original Message-----
> >> >>>>>>> From: geopriv-bounces@ietf.org
> >> >>>>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of ext
> >> >>> James M. Polk
> >> >>>>>>> Sent: Tuesday, June 23, 2009 12:23 AM
> >> >>>>>>> To: Bernard Aboba; martin.thomson@andrew.com;
> >> >>>>>>> drage@alcatel-lucent.com; rbarnes@bbn.com;
> >> >>> mlinsner@cisco.com
> >> >>>>>>> Cc: geopriv@ietf.org
> >> >>>>>>> Subject: Re: [Geopriv] Issue: version "negotiation"
> >> >>>>>>>
> >> >>>>>>> At 02:07 AM 6/23/2009, Bernard Aboba wrote:
> >> >>>>>>>> Martin said:
> >> >>>>>>>>
> >> >>>>>>>> "Certainly we shouldn't be encouraging people to try to
> >> >>>>>>> send the old
> >> >>>>>>>> encoding".
> >> >>>>>>>>
> >> >>>>>>>> There are a number of potential cases here:
> >> >>>>>>>>
> >> >>>>>>>> a. Legacy (v0) client speaking to v1 server.
> >> >>>>>>>> b. Legacy (v0) client speaking to v0 server.
> >> >>>>>>>> c. V1 client speaking to v0 server.
> >> >>>>>>>> d. V1 client speaking to v1 server.
> >> >>>>>>>>
> >> >>>>>>>> Am I correct in saying that there is nothing in the
> >> >>>>>>> DHCPDISCOVER packet
> >> >>>>>>>> (or 11k location request, etc.) which provides
> >> >>> the server with
> >> >>>>>>>> information on the version of the client?
> >> >>>>>>>
> >> >>>>>>> there is no indication of the client version.
> >> >>>>>>>
> >> >>>>>>>> Or is it possible for the server to learn (either
> >> >>>>> out-of-band or
> >> >>>>>>>> in-band) what version the client supports?
> >> >>>>>>>>
> >> >>>>>>>> Some questions:
> >> >>>>>>>>
> >> >>>>>>>> a. Should a client implementation of RFC 3825bis
> >> >>> be capable
> >> >>>>>>> of handling
> >> >>>>>>>> both v0 and v1 packets sent by a server?
> >> >>>>>>>
> >> >>>>>>> yes - because the server the client receives can be
> >> >either from a
> >> >>>>>>> v0 or v1 server.
> >> >>>>>>>
> >> >>>>>>>> b. Should a server implementation of RFC 3825bis
> >> >>> always set
> >> >>>>>>> the version
> >> >>>>>>>> number to 1?
> >> >>>>>>>
> >> >>>>>>> this depends on what it wants to convey to the
> >client. If the
> >> >>>>>>> server wants to deliver resolution bits, then a v0
> >> >packet is sent
> >> >>>>>>> to the client.
> >> >>>>>>>
> >> >>>>>>> If the server wants to send uncertainty bits, the
> >> >servers sends
> >> >>>>>>> v1 to the client.
> >> >>>>>>>
> >> >>>>>>>> c. Do we understand how existing v0 client
> >implementations
> >> >>>>>>> will behave
> >> >>>>>>>> if they receive a v1 packet from a server?
> >> >>>>>>>
> >> >>>>>>> today - no, this is not completely predictable.
> >> >>>>>>>
> >> >>>>>>> Part of 3825bis will add text to give guidance
> >on the desired
> >> >>>>>>> behavior for each scenario.
> >> >>>>>>>
> >> >>>>>>> James
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>> Geopriv mailing list
> >> >>>>>>> Geopriv@ietf.org
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
> >> >>>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>
> >> >>>
> >> >
> >> >
> >> >
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >
> >
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
