Original text:
0-RTT data to ensure that an application is always aware that it is sending or receiving data that might be replayed. <del> The same warnings apply to any use of the early_exporter_secret. </del>  The remainder of this document provides a detailed description of TLS. Once the handshake is complete, it is possible for either side to update its sending traffic keys using the KeyUpdate handshake message defined in key-update.  The next generation of traffic keys is <del> computed by generating client_/server_traffic_secret_N+1 from client_/server_traffic_secret_N as described in this section then re- deriving the traffic keys as described in traffic-key-calculation. </del>  <del> The next-generation traffic_secret is computed as: </del>  <del> Once client/server_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete client_/ server_traffic_secret_N and its associated traffic keys. </del>  7.3. The exporter value is computed as: <del> Where Secret is either the early_exporter_secret or the exporter_secret.  Implementations MUST use the exporter_secret unless explicitly specified by the application.  The early_exporter_secret is define for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED, especially on a server where a single interface can make the early exporter inaccessible. </del>  If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as

Reviewer comments:
Make the variable names of various secrets correspond to the labels used for Derive-Secret(). This is not a wire format change, but just a change in the internal variable names.
NAME NAME you see any misses here?
The legends for the message flows still say "trafficsecretN" for the "[]" parts. Also, "Updating Traffic Keys and IVs" still uses "trafficsecretN" in the formula and text prior to it.
In the key schedule

Revised text:
0-RTT data to ensure that an application is always aware that it is sending or receiving data that might be replayed.  <ins> The same warnings apply to any use of the early_exporter_master_secret. </ins> The remainder of this document provides a detailed description of TLS. Once the handshake is complete, it is possible for either side to update its sending traffic keys using the KeyUpdate handshake message defined in key-update.  The next generation of traffic keys is  <ins> computed by generating client_/server_application_traffic_secret_N+1 from client_/server_application_traffic_secret_N as described in this section then re-deriving the traffic keys as described in traffic- key-calculation. </ins>  <ins> The next-generation application_traffic_secret is computed as: </ins>  <ins> Once client/server_application_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete client_/server_application_traffic_secret_N and its associated traffic keys. </ins> 7.3. The exporter value is computed as:  <ins> Where Secret is either the early_exporter_master_secret or the exporter_master_secret.  Implementations MUST use the exporter_master_secret unless explicitly specified by the application.  The early_exporter_master_secret is define for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED, especially on a server where a single interface can make the early exporter inaccessible. </ins> If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as