Original text:
establishment, or a label for a pre-shared key established externally. <del> For each ticket, the time since the client learned about the server configuration that it is using, in milliseconds.  This value is added modulo 2^32 to the "ticket_age_add" value that was included with the ticket, see NSTMessage.  This addition prevents passive observers from correlating connections unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. </del>  A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension 4.2.10.1.  The PSK binder value forms a binding between a PSK and the current handshake, as well as between the handshake in which the PSK was generated (if via a NewSessionTicket message) and the handshake where and then reinjected as a "handshake_hash" message, as described in the-transcript-hash. <del> 4.2.10.2. </del>  Clients are permitted to "stream" 0-RTT data until they receive the server's Finished, only then sending the EndOfEarlyData message.  In ServerHello, rather than waiting for the client's EndOfEarlyData message. <del> 4.2.10.3. </del>  As noted in zero-rtt-data, TLS provides a limited mechanism for replay protection for data sent by the client in the first flight. <del> The "obfuscated_ticket_age" parameter in the client's "pre_shared_key" extension SHOULD be used by servers to limit the time over which the first flight might be replayed.  A server can store the time at which it sends a ticket to the client, or encode the time in the ticket.  Then, each time it receives an "pre_shared_key" extension, it can un-obfuscate the ticket age and compare it to the difference between the current time and the ticket creation time, to see if the value for the time elapsed sent by the client is consistent with the time since the ticket was issued. The ticket age (the value with "ticket_age_add" subtracted) provided by the client will be shorter than the actual time elapsed on the server by a single round trip time.  This difference is comprised of the delay in sending the NewSessionTicket message to the client, plus the time taken to send the ClientHello to the server.  For this reason, a server SHOULD measure the round trip time prior to sending the NewSessionTicket message and account for that in the value it saves. To properly validate the ticket age, a server needs to save at least two items: The time that the server generated the session ticket and the estimated round trip time can be added together to form a baseline time. The "ticket_age_add" parameter from the NewSessionTicket is needed to recover the ticket age from the "obfuscated_ticket_age" parameter. </del>  There are several potential sources of error that make an exact measurement of time difficult.  Variations in client and server clock corrections.  Network propagation delays are the most likely causes of a mismatch in legitimate values for elapsed time.  Both the NewSessionTicket and ClientHello messages might be retransmitted and <del> therefore delayed, which might be hidden by TCP. A small allowance for errors in clocks and variations in measurements is advisable.  However, any allowance also increases the opportunity for replay.  In this case, it is better to reject early data and fall back to a full 1-RTT handshake than to risk greater exposure to replay attacks.  In common network topologies for browser clients, small allowances on the order of ten seconds are reasonable.  Clock skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric replay window. </del>  4.3.

Reviewer comments:
…s , , .
NAME if you want to propose some revised text, I will TAL.
From Nikos's comment:
This is relating to . I will try to resolve both issues.
It is hard to understand the current text of Section 4.2.9.3 (Replay Properties). NAME explained me that a server should check: The server can tell: serverrecvtime == now serversendtime == one parameter in the ticket clientsendtime - clientrecvtime == ticketage == obfuscatedticketage + ticketage_add If this understanding is correct, I would suggest to add more explanation to the section.
Yes, that's correct. PRs welcome
I made a tweak to avoid referring to the "base value", in , though more changes may still be helpful.

Revised text:
establishment, or a label for a pre-shared key established externally.  <ins> An obfuscated version of the age of the key.  ticket-age describes how to form this value for identities established via the NewSessionTicket message.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. </ins> A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension 4.2.10.1. <ins> The client's view of the age of a ticket is the time since the receipt of the NewSessionTicket message.  Clients MUST NOT attempt to use tickets which have ages greater than the "ticket_lifetime" value which was provided with the ticket.  The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the "ticket_age_add" value that was included with the ticket, see NSTMessage modulo 2^32.  This addition prevents passive observers from correlating connections unless tickets are reused.  Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds.  Because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds. 4.2.10.2. </ins> The PSK binder value forms a binding between a PSK and the current handshake, as well as between the handshake in which the PSK was generated (if via a NewSessionTicket message) and the handshake where and then reinjected as a "handshake_hash" message, as described in the-transcript-hash.  <ins> 4.2.10.3. </ins> Clients are permitted to "stream" 0-RTT data until they receive the server's Finished, only then sending the EndOfEarlyData message.  In ServerHello, rather than waiting for the client's EndOfEarlyData message.  <ins> 4.2.10.4. </ins> As noted in zero-rtt-data, TLS provides a limited mechanism for replay protection for data sent by the client in the first flight.  <ins> This mechanism is intended to ensure that attackers cannot replay ClientHello messages at a time substantially after the original ClientHello was sent. To properly validate the ticket age, a server needs to store the following values, either locally or by encoding them in the ticket: The time that the server generated the session ticket. The estimated round trip time between the client and server; this can be estimated by measuring the time between sending the Finished message and receiving the first message in the client's second flight, or potentially using information from the operating system. The "ticket_age_add" parameter from the NewSessionTicket message in which the ticket was established. The server can determine the client's view of the age of the ticket by subtracting the ticket's "ticket_age_add value" from the "obfuscated_ticket_age" parameter in the client's "pre_shared_key" extension.  The server can independently determine its view of the age of the ticket by subtracting the the time the ticket was issued from the curren time.  If the client and server clocks were running at the same rate, the client's view of would be shorter than the actual time elapsed on the server by a single round trip time.  This difference is comprised of the delay in sending the NewSessionTicket message to the client, plus the time taken to send the ClientHello to the server. The mismatch between the client's and server's views of age is thus given by: </ins> There are several potential sources of error that make an exact measurement of time difficult.  Variations in client and server clock corrections.  Network propagation delays are the most likely causes of a mismatch in legitimate values for elapsed time.  Both the NewSessionTicket and ClientHello messages might be retransmitted and  <ins> therefore delayed, which might be hidden by TCP.  Thus, an an allowance on the order of ten seconds to account for errors in clocks and variations in measurements is advisable.  Outside this range, the server SHOULD reject early data and fall back to a full 1-RTT handshake.  Clock skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric range of permissible mismatch values. </ins> 4.3.