Subject: [Softwires] ACTION REQUIRED: Proposed AUTH48 changes to draft-ietf-softwire-map-dhcp

From: Suresh Krishnan <[email-masked]>
Date: Mon, 1 Jun 2015 04:29:20 +0000

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