All,

The following was raised during IESG Review:

> There seem to be no way of indicating in the Image Data 
> Request (CA->WTP) message the offset in the file of the data. As the 
> download may take substantial time, is it thought that one can 
> interleave other type of control message while the download goes on?
> If yes, then I think one need to clarify which messages that are 
> possible without corrupting the state necessary for the download to 
> progress without issues. If no, probably fine but should be clarified 
> and may lock up the WTP for substantial time while data transfer is ongoing.

The CAPWAP state machine is explicit about which messages are possible when.
However, in researching an answer to your question, I have found an 
inconsistency 
in the spec. The text states that the EchoInterval timer is started during the
Join->Image Data state transition, which means that the AC can expect to 
Join->also receive Echo Requests, and the WTP can expect Echo Responses.

<modified state machine text>
2.3.1.  CAPWAP Protocol State Transitions [...]
   Image Data to Image Data (j):  The Image Data state is used by the
      WTP and the AC during the firmware download phase.

      WTP:  The WTP enters the Image Data state when it receives an
         Image Data Response message indicating that the AC has more
         data to send.  This state transition also occurs when the WTP
         receives the subsequent Image Data Requests, at which time it
         resets the ImageDataStartTimer time to ensure it receives the
         next expected Image Data Request from the AC.  This state
         transition can also occur when the WTP's EchoInterval timer
         (see Section 4.7.7) expires, in which case the WTP transmits an
         Echo Request message (see Section 7.1), and resets its
         EchoInterval timer.  The state transition also occurs when the
         WTP receives an Echo Response from the AC (see Section 7.2.

      AC:  This state transition occurs either when the AC receives the
         Image Data Response message from the WTP while already in the
         Image Data state.  This state transition also occurs when the
         AC receives an Echo Request (see Section 7.1) from the WTP, in
         which case it responds with an Echo Response (see Section 7.2),
         and resets its EchoInterval timer (see Section 4.7.7).
</modified state machine text>

I then found that the echoInterval was actually being enabled on the WTP when 
it hit the Configure->Data Check state transition, which doesn't really make 
sense. The intent was for it to only occur once the WTP entered the Run state.
I am therefore proposing eliminating it from the former, and adding it to the 
Data Check->Run state transition, which would look like:

<modified text>
   Data Check to Run (o):  This state transition occurs when the linkage
      between the control and data channels is established, causing the
      WTP and AC to enter their normal state of operation.

      WTP:  The WTP enters this state when it receives a successful
         Change State Event Response message from the AC.  The WTP
         initiates the data channel, which MAY require the establishment
         of a DTLS session, starts the DataChannelKeepAlive timer (see
         Section 4.7.2) and transmits a Data Channel Keep Alive packet
         (see Section 4.4.1).  The WTP then starts the EchoInterval
         timer and DataChannelDeadInterval timer (see Section 4.7).
</modified text>

Finally, the text was describes the Echo Request message needs to be modified 
to include the Image Data state:

<modified text>
7.1.  Echo Request
[...]
   Echo Request messages are sent periodically by a WTP in the Image
   Data or Run state (see Section 2.3) to determine the state of the 
</modified text>

PatC