Original text:
with B and probably retry the request, leading to duplication on the server system as a whole. <del> The first class of attack can be prevented by the mechanism described in this section.  Servers need not permit 0-RTT at all, but those which do SHOULD implement either the single-use tickets or ClientHello recording techniques described in the following two sections. </del>  The second class of attack cannot be prevented at the TLS layer and MUST be dealt with by any application.  Note that any application whose clients implement any kind of retry behavior already needs to implement some sort of anti-replay defense. <del> In normal operation, clients will not know which, if any, of these mechanisms servers actually implement and therefore MUST only send early data which they are willing to have subject to the attacks described in replay-0rtt. </del> 8.1. The simplest form of anti-replay defense is for the server to only

Reviewer comments:
This change rephrases the requirements and recommendations from prescribing specific mechanisms of 0-RTT replay protection to prescribing the guarantees expected from implementations, thus letting the implementations to choose the way they can provide those guarantees. This change also introduces a MUST-level requirement for protection equivalent to having at least local strike register.
I've addressed all editorial nits suggested (except for the comma one, which I leave to editor's discretion).
There are some nits noted inline (by me and others), but those are subject to editorial discretion, so I will mark my overall approval.

Revised text:
with B and probably retry the request, leading to duplication on the server system as a whole.  <ins> The first class of attack can be prevented by sharing state to guarantee that the 0-RTT data is accepted at most once.  Servers SHOULD provide that level of replay safety, by implementing one of the methods described in this section or by equivalent means.  It is understood, however, that due to operational concerns not all deployments will maintain state at that level.  Therefore, in normal operation, clients will not know which, if any, of these mechanisms servers actually implement and hence MUST only send early data which they deem safe to be replayed. In addition to the direct effects of replays, there is a class of attacks where even operations normally considered idempotent could be exploited by a large number of replays (timing attacks, resource limit exhaustion and others described in replay-0rtt).  Those can be mitigated by ensuring that every 0-RTT payload can be replayed only a limited number of times.  The server MUST ensure that any instance of it (be it a machine, a thread or any other entity within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once; this limits the number of replays to the number of server instances in the deployment.  Such a guarantee can be accomplished by locally recording data from recently-received ClientHellos and rejecting repeats, or by any other method that provides the same or a stronger guarantee.  The "at most once per server instance" guarantee is a minimum requirement; servers SHOULD limit 0-RTT replays further when feasible. </ins> The second class of attack cannot be prevented at the TLS layer and MUST be dealt with by any application.  Note that any application whose clients implement any kind of retry behavior already needs to implement some sort of anti-replay defense.  8.1. The simplest form of anti-replay defense is for the server to only