I have made the requested changes, and the resulting text looks like:

<modified text>
2.  CAPWAP AC DHCPv4 Option
[...]
   A DHCPv4 client, acting on behalf of a CAPWAP WTP, MUST request the
   CAPWAP AC DHCPv4 Option in a Parameter Request List Option, as
   described in [RFC2131] and [RFC2132].

   A DHCPv4 server returns the CAPWAP AC Option to the client if the
   server policy is configured appropriately and the server is
   configured with a list of CAPWAP AC addresses.

3.  CAPWAP AC DHCPv6 Option
[...]
   A DHCPv6 client, acting on behalf of a CAPWAP WTP, MUST request the
   CAPWAP AC DHCPv6 Option in a Parameter Request List Option, as
   described in [RFC3315].

   A DHCPv6 server returns the CAPWAP AC Option to the client if the
   server policy is configured appropriately and the server is
   configured with a list of CAPWAP AC addresses.
</modified text>

All,

During the IESG review, there were some comments associated with whether some 
of the text in the draft should be changed from a SHOULD to a MUST. After 
review of the draft, the following comment was made:

All - I have a couple of concerns about simply changing the SHOULDs to MUSTs 
in the paragraphs describing the DHCP (I'll use DHCP for DHCPv[46] throughout) 
client and server behaviors.

The first concern is about the timing of the DHCP client in the WTP device, 
especially if the WTP function is instantiated in a device  
after the DHCP client has completed its initial message exchange.   
That is, the DHCP client may not know that the WTP will be instantiated at 
some point, and may not know to ask for the CAPWAP AC option.

It is possible for the WTP function, if it finds it does not have access to 
the CAPWAP AC option info, to use a separate message (DHCPINFORM or 
Information-Request) to obtain the information.  I suggest the following text 
for DHCPv4 and (with appropriate changes)
DHCPv6:

   A DHCPv4 client, acting on behalf of a CAPWAP WTP, MUST request the CAPWAP 
AC DHCPv4 Option
   in a Parameter Request List Option, as described in RFC 2131 and RFC 2132.

I think this text allows for the case when the DHCP client is unaware of the 
WTP, and the WTP function invokes DHCPINFORM/Information- Request later.

The second concern is about the description of when the DHCP server should 
respond with the CAPWAP AC option.  The current text doesn't allow for DHCP 
server policy to control the inclusion of the option in the response to the 
client.  This policy may work both ways - the server may have a policy to 
return the option even if the client hasn't requested it, because the server 
can determine that the device is a WTP and will need the option, or the server 
may have a policy not to return the option to certain clients even if the 
client lists the option in the PRL/ORO.  Text to allow for server policy might 
be:

   A DHCPv4 server returns the CAPWAP AC Option to the client if the server 
policy is configured
   appropriately and the server is configured with a list of CAPWAP AC 
addresses.