Original text:
normal SRTP or SRTCP processing takes place including replay protection. <del> 2.2.2.1. </del>  The value of the EKTCiphertext field is identical in successive packets protected by the same EKT parameter set and the same SRTP that out of order packets can be processed as well as packets sent during the time keys are changing. <del> 2.3. </del>  EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext.  This specification defines the interface to the These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P.  Each cipher also has a limit T on the number of times that it can be used <del> with any fixed key value.  The EKTKey MUST NOT be used more that T times. </del>  Security requirements for EKT ciphers are discussed in sec. <del> 2.3.1. </del>  The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding RFC5649 algorithm.  It requires a plaintext length As AES-128 is the mandatory to implement transform in RFC3711, AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented. <del> 2.3.2. </del>  Other specifications may extend this document by defining other EKTCiphers as described in iana.  This section defines how those an input.  The values of the parameters L, and T MUST be defined by each EKTCipher. <del> 2.4. </del>  If a source has its EKTKey changed by the key management, it MUST also change its SRTP master key, which will cause it to send out a master key, so that traffic can be decrypted only by those who know the current EKTKey. <del> 2.5. </del>  EKT SHOULD be used over SRTP, and other specification MAY define how to use it over SRTCP.  SRTP is preferred because it shares fate with for RTCP transmission limits, and to avoid SRTCP compound packets with RTP translators and mixers. <del> 2.6. </del>  A system using EKT learns the SRTP master keys distributed with FullEKTFields sent with the SRTP, rather than with call signaling.  A helps mitigate this issue. Each EKT cipher specifies a value T that is the maximum number of <del> times a given key can be used.  An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey.  In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in dtls-srtp-extensions. </del>  The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher and at least as strong

Reviewer comments:
,
Changes look good , except for few typos .
Nothing to add beyond Suhas' comments.
Section 4 Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 3.2.
ektttl: The maximum amount of time, in seconds, that this ektkeyvalue can be used. The ektkey_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires.
These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times.

Revised text:
normal SRTP or SRTCP processing takes place including replay protection.  <ins> 2.3. </ins> The value of the EKTCiphertext field is identical in successive packets protected by the same EKT parameter set and the same SRTP that out of order packets can be processed as well as packets sent during the time keys are changing.  <ins> When receiving a new EKTKey, implementations need to use the ekt_ttl to create a time after which this key cannot be used and they also need to create a counter that keeps track of how many times the keys has been used to encrypt data to ensure it does not exceed the T value for that cipher.  If either of theses limits are exceeded, the key can no longer be used for encryption.  At this point implementation need to either use the call signaling to renegotiation a new session or need to terminate the existing session.  Terminating the session is a reasonable implementation choice because theses limits should not be exceeded except under an attack or error condition. 2.4. </ins> EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext.  This specification defines the interface to the These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P.  Each cipher also has a limit T on the number of times that it can be used  <ins> with any fixed key value.  The EKTKey MUST NOT be used for encryption more that T times.  Note that if the same EKT packet is retransmitted 3 times, that only counts as 1 encryption. </ins> Security requirements for EKT ciphers are discussed in sec.  <ins> 2.4.1. </ins> The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding RFC5649 algorithm.  It requires a plaintext length As AES-128 is the mandatory to implement transform in RFC3711, AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented.  <ins> 2.4.2. </ins> Other specifications may extend this document by defining other EKTCiphers as described in iana.  This section defines how those an input.  The values of the parameters L, and T MUST be defined by each EKTCipher.  <ins> 2.5. </ins> If a source has its EKTKey changed by the key management, it MUST also change its SRTP master key, which will cause it to send out a master key, so that traffic can be decrypted only by those who know the current EKTKey.  <ins> 2.6. </ins> EKT SHOULD be used over SRTP, and other specification MAY define how to use it over SRTCP.  SRTP is preferred because it shares fate with for RTCP transmission limits, and to avoid SRTCP compound packets with RTP translators and mixers.  <ins> 2.7. </ins> A system using EKT learns the SRTP master keys distributed with FullEKTFields sent with the SRTP, rather than with call signaling.  A helps mitigate this issue. Each EKT cipher specifies a value T that is the maximum number of  <ins> times a given key can be used.  An endpoint MUST NOT encrypt more than T different Full EKT Field using the same EKTKey.  In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in dtls-srtp-extensions. </ins> The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher and at least as strong