>#10: Server Version Support
>---------------------------------------+------------------------------------
> Reporter: martin.thomson@andrew.com | Owner:
>
> Type: enhancement | Status: new
>
> Priority: major | Milestone:
> draft-ietf-geopriv-3825bis
>Component: rfc3825bis | Version:
>
> Severity: - | Resolution:
>
> Keywords: |
>---------------------------------------+------------------------------------
>
>Comment(by bernard_aboba@hotmail.com):
>
> Client Version Support
>
> Clients implementing this specification MUST support receiving responses
> of versions 0 and 1. Since this specification utilizes the same DHCP
> option code as [RFC3825], the option format does not provide a means for
> the client to indicate the highest version that it supports to the server.
>
> Server Version Support
>
> Servers implementing this specification MUST support sending v0 and v1
> responses. The version of the response depends on server configuration.
> For example, where few v0 clients are expected, the server could be
> configured to send only v1 responses. Where few v1 clients are expected,
> the server could be configured to send only v0 responses. Where a mixture
> of v0 and v1 clients are expected, the server could be configured to send
> either a v0 or v1 response (possibly making the choice based on
> information such as the client MAC address). It is NOT RECOMMENDED for a
> server to send a response containing both a v0 and a v1 option.
everything was fine until this last sentence. If an OFFER (which is a
DHCP response) contains two Option values where both Options are
identified as the same Option _number_, the second Option overwrites
the first Option value. Therefore a server cannot respond to a
client by providing both versions, as the first will become
immediately useless and forgotten.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
