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. I believe that this document is ready, with minor issues in the Security Considerations Section.  This ID concerns the correction of an ambiguity in the CAPWAP protocol.  That protocol supports two Medium Access Control (MAC) modes with respect to two entities: a Wireless Transmission Point (WTP) and an Access Controller (AC).  In one of the modes, split mode, encryption functionality can be located at either the WTP or the AC, but no clear way is given of having the AC inform the WTP of where the encryption functionality should be located.  This ID presents a means by which the WTP informs the AC of the various MAC profiles it supports, and then the AC determines the appropriate profile and configures the WTP with the profile while configuring the WLAN. The Security Considerations Section says that this document does not introduce any new security risks compared to RFC5416, and that the security considerations described in RFC5416 apply here as well.  I believe that a document that addresses the placement of encryption functionality should say something more, in particular *why* it introduces no new security risks.  In the case of negotiation, the main security risk is that an attacker could interfere with the negotiation so that a less secure alternative is chosen even when a more secure one is available.  In the security considerations section of RFC5416 it is noted that there is a possibility of a replay attack if encryption resides at the WTP.  The risk is slight, and the only way of closing the security gap is expensive, so the authors of RFC5416 decide to let the risk stand.  However, this presents a conceivable attack in which an attacker could cause an AC to believe that a WTP only supports   encryption functionality at the WTP, and the AC would choose the less secure mode.  Although the risk this introduces is also slight, I believe that this should be mentioned. Also, would I be correct in assuming that a WTP that supports encryption at the WTP but not at the AC is unlikely? If that is so, it might be possible to close the security gap by having the ATP reject advertisements (request a retransmit?) that only support encryption at the WTP, and if so you should mention that too.   Nits: The word “clearly” is repeated in line 7 of the abstract.   Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email:  catherine.meadows at nrl.navy.mil