---------------------------------------+------------------------------------
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):
Revision:
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 a v1 response (possibly making the choice based on
information such as the client MAC address).
As a matter of practice within DHCP, a server sending one version of
Option 123 to a client followed by the other version (in the same response
or a separate response) does not allow clients to retain both versions in
memory. Receiving two copies of the same Option causes the client to
replace the old information with the new information of the same Option
(123 in this case). Therefore it is not useful for a server to send both
v0 and v1 options to the client.
--
Ticket URL: <http://rsync.tools.ietf.org/wg/geopriv/trac/ticket/10#comment:2>
geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
