> >>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?
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).
>- 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
