I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes an extension to the Control and Provisioning of Wireless Access Points (CAPWAP) protocol that encapsulates a station¡¯s data frames between the Wireless Transition Point (ATP) and Access Controller (AC). In some cases, it may be desirable to encapsulate data frames to an entity other than the AC (e.g. to an Access Router) or to use different encapsulation models. In particular, this would allow the WTP to tunnel non-management data frames to an endpoint different than the AC and to tunnel using different known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. A particular advantage of this approach that encapsulating only the control plane to the AC, and thus separating management of the control plane from the management of the data plane, makes scaling easier and more efficient. As far as I can tell, there do not seem to be any serious security issues with implementing this approach, especially since, as is noted in RFC [RFC5415], the data plane is already handled differently from the control plane, the control plane usually being protected by DTLS while the data plan is not. However, I think the Security Considerations Section needs to make a better case for this. The text of the Security Considerations section is as follows: This document introduces three new CAPWAP WTP message elements. These elements are transported within CAPWAP Control messages as the existing message elements. Therefore, this document does not introduce any new security risks compared to [RFC5415] and [RFC5416]. In CAPWAP, security for CAPWAP Data Channel is optional and security policy is determined by AC. Similarly, the AC determines the security for the Alternate Tunnel between WTP and Alternate Tunnel Encapsulation Gateway. The security considerations described in [RFC5415] and [RFC5416] apply here as well. I find it hard to agree with the first three sentences. The document does more than simply introduce three new message elements. It also provides considerably more freedom in encapsulating data frames. So it appears to me that what the Security Considerations section should concentrate on is the potential risk in providing this greater freedom. [duzongpeng] Add some descriptions: In the data plane, if the encapsulation type selected itself is not secured, it is suggested to protect the tunnel by using known secure methods, such as IPSec. [/duzongpeng] It¡¯s also not clear to me what the purpose of the remaining part of the section, about the AC determining the policy. Are you saying that, because the AC determines the policy in both CAPWAP and the CAPWAP extension, the security considerations for the first case also apply to the second case? Some more discussion of why this is true, with references to the relevant risks discussed in [RFC5415] and [RFC5416], would be useful. [duzongpeng] Delete the second part. I also find it is hard to understand the purpose of that part. [/duzongpeng]