>#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):
>
> Incorporating comments. How about this?
I would add one clarification near the end of the last paragraph. see
in-line below
> 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 Selection
>
> A DHCP server that provides location information cannot provide options
> with both v0 and v1 formats in the same response. This is not useful
> since receiving two copies of the same Option (either in the same response
> or a separate response) causes a DHCP client to replace the information in
> the old Option with the information in the new Option.
>
> A server uses configuration to determine which version to send in a
> response. For example, where a mixture of v0 and v1 clients are expected,
> the server could be configured to send v0 or v1 depending on configuration
> (possibly making the choice based on information such as the client MAC
> address). Where few v0 clients are expected, the server could be
> configured to send only v1 responses.
>
> Servers that opt to send location in v1 format are likely to cause clients
> that support v0 clients to reject the Option.
This scenario results in the client not having location information
with no ability to indicate to the server this version (1) was not supported.
>Therefore, where any
> significant proportion of clients are known to support only v0, by default
> the server SHOULD send a v0 response.
NOTE: I would also use another word than "significant" in the
sentence above, as that could be interpreted as "a majority" of
clients, when in reality every v0 only client will reject any v1
Option, meaning each will be without location with no way to tell
anyone about it. This is a situation I think we want to avoid, and I
wish there was a better way to do this, but there isn't.
>--
>Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/10#comment:3>
>geopriv <http://tools.ietf.org/geopriv/>
>
>_______________________________________________
>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
