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
