Fixed in draft-ietf-capwap-protocol-specification-11.txt

> >> 6.2 Join Response
> >> Should MUST ME be defined earlier than MAY ME?
> > This doesn't really break anything. I'm not sure we need to address 
> > this.
> I saw other message definitions always put MUST MEs in the beginning.

Well, I think this is really a nice to have, but while looking at the issue 
you are pointing out, I *just* noticed that there is a cut/paste error in this 
section since the text includes:
<bad text>
   One of the following message elements MUST be included in the
   Discovery Response Message:
</bad text>

Clearly, that should have been a Join Response, so since I'm add it, I will 
reorder the text to make sure that it is consistent with the rest of the 
message definitions, and fix the cut/paste error.

> 
> > 9.7 Data Transfer Response
> >
> >    Upon receipt of a Data Transfer Response message, the WTP transmits
> >    more information, if more information is available.
> >
> > What's this meaning of this? If the crash data or memory dump is too
> large, WTP will segment them, and transfer them
> > using multiple Data transfer req messages.
> > The AC should maintain the
> > data offset by itself?   Or you want to say, the WTP will first sent
> > crash dump. It will send the memory
> > dump after it receives the response?
> Yes, this is a series of back and forth, where the WTP will, if necessary, 
break the information to be sent across 
> multiple packets. The CAPWAP transmission layer will ensure it is 
reassembled in the proper order. Maybe I'm not 
> understanding the question you are asking.
> 
> then how the AC knows it has received all the debug data from the WTP?

I see the point you are raising, and this is something we fixed for the image 
transfer. Because of the scope of the issue, I will create a separate issue to 
track this one. So let's continue this conversation in a separate thread, 
which I will initiate shortly.

4.6.36 >=1 to >=6   this is an error.

1(reason) + 1(length) + 2(me type) + 2(me len)

4.6.37 len should be 4.

4.6.40 should be >= 22

4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number)

4.6.47 >0   to >=1

4.6.34 should define the "State" use a similar way used by 4.6.50 define 
the 'Static"


4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7

4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since they are not 
used any more.

6.2 Join Response
Should MUST ME be defined earlier than MAY ME?

8.9 Clear Config Response:

   The Clear Configuration Request message MUST include the following
   message element.

   o  Result Code, see Section 4.6.35

Shoule be RESPONSE here.

9.1 Figure 7. Is this a reasonable case?

If images are same, the WTP will go into Configure state.

9.1.1

  The decision that new firmware is to be downloaded to the WTP can
   occur in one of two ways:

      When the WTP joins the AC, the Join Response message includes the
      Image Identifier message element, which informs the WTP of the
      firmware it is expected to run. if the WTP does not currently have
      the requested firmware version, it transmits an Image Data Request
      message, with the appropriate Image Identifier message element.
      If the WTP already has the requested firmware, it simply resets.

Remove "If the WTP already has the requested firmware, it simply resets."?

9.6 Data transfer req

What's the use of Data transfer mode 4.6.17? The Data Transfer Data has the 
mode field.

9.7 Data Transfer Response

   Upon receipt of a Data Transfer Response message, the WTP transmits
   more information, if more information is available.

What's this meaning of this? If the crash data or memory dump is too large, 
WTP will segment them, and transfer them using multiple Data transfer req 
messages.
The AC should maintain the
data offset by itself?   Or you want to say, the WTP will first sent
crash dump. It will send the memory
dump after it receives the response?