>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
