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

Ah, I see. Yes, this does need to be mentioned, thanks for pointing that out. 
The issue being raised here is that the Echo Request is used by a WTP to keep 
its session alive with the AC. However, if the AC doesn't receive an Echo 
Request in a certain amount of time, it needs to consider the WTP dead (this 
text is already covered in section 7.2). 

Note that this does not break interoperability with -10. The older spec was 
ambiguous in how the AC would timeout a WTP, and I suspect that most people at 
least implemented what's being described below. The change is specifically 
around being clear when the EchoInterval is set/reset in the actual FSM. It 
was mentioned already in the description of the Echo Request and Echo Response 
messages, but it does need to also be mentioned in the FSM. 

The only new change is the mention of the EchoInterval timer being reset on 
the WTP when it transmits a request to the AC while in the Run state. 
Similarly, the AC resets its own EchoInterval timer when it receives a request 
from the WTP. This language is necessary in order to fulfill the language from 
section 4.5:

<existing text>
4.5.  CAPWAP Control Messages
[...]
   CAPWAP control messages sent from the WTP to the AC indicate that the
   WTP is operational, providing an implicit keep-alive mechanism for
   the WTP.  The Control Channel Management Echo Request and Echo
   Response messages provide an explicit keep-alive mechanism when other
   CAPWAP control messages are not exchanged.
</existing text>

Here is the new proposed text. Note that the text in section 4.6.14 is only 
the mention of how the EchoInterval is set on the AC. No other changes are 
made:

<text>
   Run to Run (q):  This is the normal state of operation.

      WTP:  This is the WTP's normal state of operation.  The WTP resets
         its EchoInterval timer whenever it transmits a request to the
         AC.  There are many events that result this state transition:
[...]
         Echo Request:  The WTP sends an Echo Request message
            (Section 7.1) or receives the corresponding Echo Response
            message, (see Section 7.2) from the AC.  When the WTP
            receives the Echo Response, it resets its EchoInterval timer
            (see Section 4.7.7).
[...]
      AC:  This is the AC's normal state of operation.  Note that the
         receipt of any Request from the WTP causes the AC to reset its
         EchoInterval timer (see Section 4.7.7).
[...]
         Echo Request:  The AC receives an Echo Request message (see
            Section 7.1), to which it MUST respond with an Echo Response
            message(see Section 7.2).

   Run to DTLS Teardown (p):  This state transition occurs when an error
      has occurred in the DTLS stack, causing the DTLS session to be
      torn down.
[...]
      AC:  The AC enters this state when it receives one of the
         following DTLS notifications: DTLSAborted,
         DTLSReassemblyFailure or DTLSPeerDisconnect (see
         Section 2.3.2.2).  The WTP MAY tear down the DTLS session if it
         receives frequent DTLSDecapFailure notifications.  The AC
         transitions to this state if the underlying reliable
         transport's RetransmitCount counter has reached the
         MaxRetransmit variable (see Section 4.7).  This state
         transition also occurs when the AC's EchoInterval timer expires
         (see Section 4.7.7).

4.6.14.  CAPWAP Timers

   The CAPWAP Timers message element is used by an AC to configure
   CAPWAP timers on a WTP.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Discovery   | Echo Request  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
   Echo Request:   The number of seconds between WTP Echo Request CAPWAP
      messages.  This value is used to configure the EchoInterval timer
      (see Section 4.7.7).  The AC sets its EchoInterval timer to this
      value, plus the maximum retransmission time as described in
      Section 4.5.3.
</text>

I want to say for 5 is that:

Only WTP sends echo request. So if the WTP is dead,  the AC will not be able 
to receive the echo req, and this will trigger a failure event in AC side 
after some time. We need to add this event to FSM.

Since AC does not send the req, " the retransmission, and subsequent 
timeout, ..." will not be used.

Yong

4. Run to Run. I now understand the point you are trying to make. The text for 
Clear Configuration Request/Response is not consistent with the other commands 
in this section. I am proposing the following changes, which does not change 
any behavior, but only creates more consistency in the text:

<text>
   Run to Run (q):  This is the normal state of operation.

      WTP:  This is the WTP's normal state of operation.  There are many
         events that result this state transition:
[...]
         Clear Config Request:  The WTP receives a Clear Configuration
            Request message (see Section 8.8) and MUST generate a
            corresponding Clear Configuration Response message (see
            Section 8.9).  The WTP MUST reset its configuration back to
            manufacturer defaults.
[...]
      AC:  This is the AC's normal state of operation:
[...]
         Clear Config Response:  The AC sends a Clear Configuration
            Request message (see Section 8.8) to the WTP to clear its
            configuration.  The AC receives a Clear Configuration
            Response message from the WTP (see Section 8.9).
</text>

5. Unfortunately, I'm still not understanding the issue you are trying to 
raise. I am not claiming that the AC sends echo requests, I am simply stating 
that requests (in general) can be transmitted by either the WTP or the AC, 
while certain requests may have restrictions which are clearly documented in 
the spec. So regardless of whether a request is an echo request, or any other 
request, the retransmission, and subsequent timeout, is the same. Therefore 
there is no need to add a specific clause for echo requests timing out.

>> 4.   Run to Run (q): AC
>>
>> Clear Config Response:  The AC receives a Clear Configuration
>>             Response message from the WTP (see Section 8.9).
>>
>> Need to add Clear Configuration REQ send.
> I'm not sure that I understand what you are saying. This event occurs 
> when the response is received. The Request was sent some time ago, 
> hence why the response was received. The receive of the Clear Config 
> Request is handled in the WTP section, and is present already.

Refer to other messages description in AC RUN state: Ac need to send out the 
REQ, and AC need to receive RESP.
Just WTP clear Config Response also has the problem.


>> 5. Run to DTLS Teardown (p) maybe need to add echo failure case.
>>
>>          "transitions to this state if the underlying reliable
>>          transport's RetransmitCount counter has reached the
>>          MaxRetransmit variable (see Section 4.7)."
>>
>> This can cover WTP, but not AC.
> The echo would cause a retransmission timeout, which makes use of the 
> RetransmitCount counter. I guess I'm not sure that I understand the 
> issue you are trying to raise. Both the WTP and the AC can transmit 
> requests, so it is possible that either side timeouts, forcing this 
> state transition.
>

I only see the WTP sends REQ, and AC recvs RESP.  Where is it said that AC 
also sends ECHO REQ?

> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State Transitions, 
although it is said in CAPWAP/DTLS interface 
> chapter.
Yes, you are correct. The description for the StartDTLS command is clear that 
the WaitDTLS timer needs to be started, but it would be worth including this 
in the state transition description, as all of the other timers are also 
included in that section.

<text>
   Idle to DTLS Setup (3):  This transition occurs to establish a secure
      DTLS session with the peer.

      WTP:  The WTP initiates this transition by invoking the DTLSStart
         command(see Section 2.3.2.1), which starts the DTLS session
         establishment with the chosen AC and the WaitDTLS timer is
         started (see Section 4.7).  When the discovery phase is
         bypassed, it is assumed the WTP has locally configured ACs.
</text>

> 2. Join REQ need to be send at here.
> 
>   DTLS Connect to Join (d):  This transition occurs when the DTLS
>      Session is successfully established.
>
>      WTP:  This state transition occurs when the WTP receives the
>         DTLSEstablished notification (see Section 2.3.2.2), indicating
>         that the DTLS session was successfully established.  When this
>         notification is received, the FailedDTLSSessionCount counter is
>         set to zero.
Yes, this was a strange omission - an obvious thing to do, but it needs to be 
very clear.

<text>
   DTLS Connect to Join (d):  This transition occurs when the DTLS
      Session is successfully established.

      WTP:  This state transition occurs when the WTP receives the
         DTLSEstablished notification (see Section 2.3.2.2), indicating
         that the DTLS session was successfully established.  When this
         notification is received, the FailedDTLSSessionCount counter is
         set to zero.  The WTP enters the Join state by transmiting the
         Join Request to the AC.
</text>

> 3.
> Data Check to DTLS Teardown (n):  This transition occurs when the WTP
>       does not complete the Data Check exchange.
> 
>       WTP:  This state transition occurs if the WTP does not receive the
>          Change State Event Response message before a CAPWAP
>          transmission timeout occurs.
> 
>     Does the above need to be change to something like  RetransmitCount
>   counter has reached the MaxRetransmit variable? Since we do not use 
transmission timeout timer.
Yes, good point. I am including the same text we have in other state 
transitions.

<text>
   Data Check to DTLS Teardown (n):  This transition occurs when the WTP
      does not complete the Data Check exchange.

      WTP:  This state transition occurs if the WTP does not receive the
         Change State Event Response message before a CAPWAP
         retransmission timeout occurs.  The WTP also transitions to
         this state if the underlying reliable transport's
         RetransmitCount counter has reached the MaxRetransmit variable
         (see Section 4.7).
</text>

> 4.   Run to Run (q): AC
> 
> Clear Config Response:  The AC receives a Clear Configuration
>             Response message from the WTP (see Section 8.9).
> 
> Need to add Clear Configuration REQ send.
I'm not sure that I understand what you are saying. This event occurs when the 
response is received. The Request was sent some time ago, hence why the 
response was received. The receive of the Clear Config Request is handled in 
the WTP section, and is present already.

> 5. Run to DTLS Teardown (p) maybe need to add echo failure case.
> 
>          "transitions to this state if the underlying reliable
>          transport's RetransmitCount counter has reached the
>          MaxRetransmit variable (see Section 4.7)."
> 
> This can cover WTP, but not AC.
The echo would cause a retransmission timeout, which makes use of the 
RetransmitCount counter. I guess I'm not sure that I understand the issue you 
are trying to raise. Both the WTP and the AC can transmit requests, so it is 
possible that either side timeouts, forcing this state transition.

1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State Transitions, 
although it is said in CAPWAP/DTLS interface chapter.

2. Join REQ need to be send at here.

   DTLS Connect to Join (d):  This transition occurs when the DTLS
      Session is successfully established.

      WTP:  This state transition occurs when the WTP receives the
         DTLSEstablished notification (see Section 2.3.2.2), indicating
         that the DTLS session was successfully established.  When this
         notification is received, the FailedDTLSSessionCount counter is
         set to zero.

3.
Data Check to DTLS Teardown (n):  This transition occurs when the WTP
      does not complete the Data Check exchange.

      WTP:  This state transition occurs if the WTP does not receive the
         Change State Event Response message before a CAPWAP
         transmission timeout occurs.

    Does the above need to be change to something like  RetransmitCount
  counter has reached the MaxRetransmit variable? Since we do not use 
transmission timeout timer.

4.   Run to Run (q): AC

Clear Config Response:  The AC receives a Clear Configuration
            Response message from the WTP (see Section 8.9).

Need to add Clear Configuration REQ send.

5. Run to DTLS Teardown (p) maybe need to add echo failure case.

         "transitions to this state if the underlying reliable
         transport's RetransmitCount counter has reached the
         MaxRetransmit variable (see Section 4.7)."

This can cover WTP, but not AC.