Change:
First, servers vend some (often hard-coded) number of tickets per connection.  Some server implementations return a different default <del> number of tickets for session resumption than for the initial full handshake that created the session.  No static choice, whether fixed, or resumption-dependent is ideal for all situations. </del> <ins> number of tickets for session resumption than for the initial connection that created the session.  No static choice, whether fixed, or resumption-dependent is ideal for all situations. </ins> Second, clients do not have a way of expressing their desired number of tickets, which can impact future connection establishment.  For <del> example, clients can open multiple TLS connections to the same server </del> <ins> example, clients can open parallel TLS connections to the same server </ins> for HTTP, or race TLS connections across different network interfaces.  The latter is especially useful in transport systems that implement Happy Eyeballs RFC8305.  Since clients control connection concurrency and resumption, a standard mechanism for <del> requesting more than one ticket is desirable. </del> <ins> requesting more than one ticket is desirable for avoiding ticket reuse.  See RFC8446, Appendix C.4 for discussion of ticket reuse risks. </ins> Third, all tickets in the client's possession ultimately derive from <del> some initial full handshake.  Especially when the client was initially authenticated with a client certificate, that session may need to be refreshed from time to time.  Consequently, a server may periodically force a full handshake even when the client presents a valid ticket.  When that happens, it is possible that any other tickets derived from the same original session are equally invalid. A client avoids a full handshake on subsequent connections if it replaces all stored tickets with fresh ones obtained from the just performed full handshake.  The number of tickets the server should vend for a full handshake may therefore need to be larger than the number for routine resumption. </del> <ins> some initial connection.  Especially when the client was initially authenticated with a client certificate, that session may need to be refreshed from time to time.  Consequently, a server may periodically force a new connection even when the client presents a valid ticket. When that happens, it is possible that any other tickets derived from the same original session are equally invalid.  A client avoids a full handshake on subsequent connections if it replaces all stored tickets with new ones obtained from the just performed full handshake.  The number of tickets the server should vend for a new connection may therefore need to be larger than the number for routine resumption. </ins> This document specifies a new TLS extension - "ticket_request" - that <del> can be used by clients to express their desired number of session tickets.  Servers can use this extension as a hint for the number of </del> <ins> clients can use to express their desired number of session tickets. Servers can use this extension as a hint for the number of </ins> NewSessionTicket messages to vend.  This extension is only applicable to TLS 1.3 RFC8446, DTLS 1.3 I-D.ietf-tls-dtls13, and future versions of (D)TLS.

Discussion:
I opted to go with "new connection" instead of "full handshake" (where appropriate), since that seemed to be the more natural phrase. Please let me know what you think! cc NAME (and thanks for the review!)