> Section 11., paragraph 4:
> >    In the third configuration, the AC is deployed behind a NAT.
> 
>   Because all communication originates at the WTP and is addressed to
>   the  AC, communication when the AC is behind a NAT will simply fail.
>   (Unless the NAT has been specifically configured, in which case all
>   issues can be assumed to disappear.)

Yes, this is a valid point, and the text "assumed" this, but it is much better 
To be crystal clear. Therefore, I propose changing the paragraph to:

<modified paragraph>
   In order for a CAPWAP WTP or AC to detect whether a middlebox 
isxxxxxxxxxxxxx
   In the third configuration, the AC is deployed behind a NAT. In this case,
   the AC is not reachable by the WTP unless a specific rule has been 
configured
   on the NAT to translate the address and redirect CAPWAP messages to the AC.
   This deployment presents two issues. First, an AC communicates its 
interfaces
   and corresponding WTP load using the CAPWAP Control IPv4 Address and CAPWAP
   Control IPv6 Address message elements. This message element is mandatory, 
but
   contains IP addresses that are only valid in the private address space used
   by the AC, which is not reachable by the WTP. The WTP MUST NOT utilize the
   information in these message elements if it detects a NAT (as described in 
the
   CAPWAP Transport Protocol message element in section 4.6.14). Second, since
   the addresses cannot be used by the WTP, this effectively disables the load
   balancing capabilities (see section 6.1) of the CAPWAP protocol.
   Alternatively, the AC could have a configured NAT'ed address, which it would
   include in either of the two control address message elements, and the NAT
   would need to be configured accordingly.
</modified paragraph>