On 6/26/09 12:54 AM, "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com> wrote:
> 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 ;)
I believe the requirement in PhoneBCP is to address real-world IP networks.
I also don't agree with your assertion of multiple access providers
available to most users. This is certainly not true in the enterprise
space.
The PhoneBCP requirement of hosts supporting all LCPs is an attempt to
support hosts moving from network to network. As an example, we are trying
to allow for the same host to have network provided location available in
both office and home domains as many enterprise clients take their laptop
home with them. Since this is example is obviously different network
environments, access providers will implement the LCP that best suits their
environment. It's quite obvious that a network that doesn't support DHCP
won't offer RFC3285/4776. It's also quite obvious a non-802 network will
not utilize LLDP-MED. But, an 802 network using DHCP for host configuration
can utilize either choice, or choose HELD. The arguments for a single LCP
are behind us.
So an end host with multiple access methods and one of which is an 802
network will need to support DHCP/HELD and imo, LLDP-MED. The likelihood of
a host jumping from access network to access network to find their desired
LCP is a stretch, imo.
-Marc-
>
> 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
