Document: draft-ohara-capwap-lwapp-04
Reviewer: Spencer Dawkins
Review Date: 16 April 2007
IESG Telechat date: 19 April 2007

Summary: Given that this document is an Independent Submission, and will 
include an IESG Note pointing to current work in CAPWAP, the General Area 
director should vote no-obj.

Comments:

The intention of this document, as I understand it, is to capture the 
version of the LWAPP protocol when it entered the IETF for standardization. 
Given this intention, I reviewed lightly and tried to focus on points that 
might affect implementation and interoperation. If the intention is to 
publish in the current state, that would make sense, too.

3.3.4 - discussion of "fragmentation" could probably benefit from more 
consistent identification of the specific kind of fragmentation that's 
taking place. For example, 3.4.5 is especially overloaded when it says

   IPv6 does MTU discovery so fragmentation and re-assembly is not
   necessary for UDP packets.

This could be taken as "don't have to support frag/reassembly at the LWAPP 
level" or as an implicit deprecation of host-based frag/reassembly in IPv6, 
and it's not clear to me which level of fragmentation is being referred to.

Note that the authors still have a note that says

   [ed: IP fragmentation may raise security concerns and bring
   additional configuration requirements for certain firewalls and NATs.
   One alternative is to re-use the layer 2 (application layer)
   fragmentation reassembly.  Comments are welcomed.]

6.2.4 - Several message element descriptions contain text like "Note this 
message element is only valid when LWAPP uses the IP/UDP layer 3 transport". 
It would be necessary to define behavior when invalid message elements are 
received in most protocols, if you expect interoperation between independent 
implementations.