Hi all.
As there were no objections received from the wg, I have asked the
authors make this change during AUTH48.
Thanks
Suresh
On 06/01/2015 12:29 AM, Suresh Krishnan wrote:
Hi all,
There is a small clarification of DHCPv6 behavior that is in the
process of being adopted by the dhcpv6bis work that will impact the MAP
DHCP specification that is currently in the RFC Editor queue.
RFC 3315 states that servers don't send options that the clients did not
request in the ORO. But it's not clear about what to do about
encapsulated option (i.e. options that appear inside of other options).
In the process of working on 3315bis, the dhc wg has concluded that any
option the client wants to see, whether encapsulated or not, needs to
appear in the ORO.
The following text change can update the draft to better reflect the new
proposed behavior of the DHCPv6 servers, while still staying conformant
to the current specifications.
OLD:
This approach implies that all of the provisioning options MUST
appear only within the container options. The client MUST NOT
request any of the provisioning options directly within an ORO. MAP-
DHCP clients that receive provisioning options that are not
encapsulated in container options MUST silently ignore these options.
DHCP server administrators are advised to ensure that DHCP servers
are configured to send these options in the proper encapsulation.
NEW:
This approach implies that all of the provisioning options
appear only within the container options. MAP-
DHCP clients that receive provisioning options that are not
encapsulated in container options MUST silently ignore these options.
DHCP server administrators are advised to ensure that DHCP servers
are configured to send these options in the proper encapsulation.
ACTION REQUIRED:
Since this clarification is being proposed for AUTH48 I would like to do
a consensus check to see if there are any objections in the wg to doing
this change. Please respond to this email if you have any issues with
the proposed text by end of day June 8 AOE. If there are no objections
by then, we will go ahead with making this change.
Thanks
Suresh
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
