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>