Change:
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!)

Discussion:
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.

tickets, distinct tickets prevent premature ticket invalidation by racing. <del> Connection priming: In some systems, connections can be primed or bootstrapped by a centralized service or daemon for faster connection establishment.  Requesting tickets on demand allows such services to vend tickets to clients to use for accelerated handshakes with early data.  (Note that if early data is not needed by these connections, this method SHOULD NOT be used. Fresh handshakes SHOULD be performed instead.) </del> Less ticket waste: Currently, TLS servers use application- specific, and often implementation-specific, logic to determine how many tickets to issue.  By moving the burden of ticket count

3. As discussed in introduction, clients may want different numbers of <del> tickets for fresh or resumed handshakes.  Clients may indicate to </del> <ins> tickets for new or resumed connections.  Clients may indicate to </ins> servers their desired number of tickets to receive on a single <del> connection, in the case of a full handshake or resumption, via the </del> <ins> connection, in the case of a new or resumed connection, via the </ins> following "ticket_request" extension: Clients MAY send this extension in ClientHello.  It contains the following structure: The number of tickets desired by the client when the server <del> chooses to negotiate a fresh session (full handshake). </del> <ins> chooses to negotiate a new connection. </ins> The number of tickets desired by the client when the server is willing to resume using a ticket presented in this ClientHello. <del> A client starting a fresh connection SHOULD set new_session_count to </del> <ins> A client starting a new connection SHOULD set new_session_count to </ins> the desired number of session tickets and resumption_count to 0. Once a client's ticket cache is primed, a resumption_count of 1 is a <del> good choice that allows the server to replace each ticket with a fresh ticket, without over-provisioning the client with excess tickets.  However, clients which race multiple connections and place a separate ticket in each will ultimately end up with just the tickets from a single resumed session.  In that case, clients can send a resumption_count equal to the number of sessions they are attempting in parallel.  (Clients which send a resumption_count less than the number of parallel connection attempts might end up with zero tickets.) </del> <ins> good choice that allows the server to replace each ticket with a new ticket, without over-provisioning the client with excess tickets. However, clients which race multiple connections and place a separate ticket in each will ultimately end up with just the tickets from a single resumed session.  In that case, clients can send a resumption_count equal to the number of sessions they are attempting in parallel.  (Clients which send a resumption_count less than the number of parallel connection attempts might end up with zero tickets.) </ins> When a client presenting a previously obtained ticket finds that the <del> server nevertheless negotiates a fresh session, the client SHOULD </del> <ins> server nevertheless negotiates a new connection, the client SHOULD </ins> assume that any other tickets associated with the same session as the presented ticket are also no longer valid for resumption.  This <del> includes tickets obtained during the initial full handshake and all </del> <ins> includes tickets obtained during the initial (new) connection and all </ins> tickets subsequently obtained as part of subsequent resumptions. <del> Requesting more than one ticket in cases when servers select a full handshake helps keep the session cache primed. </del> <ins> Requesting more than one ticket in cases when servers complete a new connection helps keep the session cache primed. </ins> <del> Servers SHOULD NOT send more tickets than requested for the handshake type selected by the server (resumption or full handshake). </del> <ins> Servers SHOULD NOT send more tickets than requested for the connection type selected by the server (new or resumed connection). </ins> Moreover, servers SHOULD place a limit on the number of tickets they <del> are willing to send, whether for full handshakes or resumptions, to save resources.  Therefore, the number of NewSessionTicket messages sent will typically be the minimum of the server's self-imposed limit and the number requested.  Servers MAY send additional tickets, up to the same limit, if the tickets that are originally sent are somehow invalidated. </del> <ins> are willing to send, whether for new or resumed connections, to save resources.  Therefore, the number of NewSessionTicket messages sent will typically be the minimum of the server's self-imposed limit and the number requested.  Servers MAY send additional tickets, typically using the same limit, if the tickets that are originally sent are somehow invalidated. </ins> A server which supports and uses a client "ticket_request" extension MUST also send the "ticket_request" extension in the

The number of tickets the server expects to send in this connection. <del> Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in either of these messages. </del> <ins> Servers MUST NOT send the "ticket_request" extension in any handshake message, including ServerHello or HelloRetryRequest messages.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in any server handshake message. </ins> If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second

encryption keys frequently, clients may be encouraged to obtain and use tickets beyond common lifetime windows of, e.g., 24 hours. Despite ticket lifetime hints provided by servers, clients SHOULD <del> dispose of pooled tickets after some reasonable amount of time that </del> <ins> dispose of cached tickets after some reasonable amount of time that </ins> mimics the session ticket encryption key rotation period. <ins> Specifically, as specified in Section 4.6.1 of RFC8446, clients MUST NOT cache tickets for longer than 7 days. </ins> In some cases, a server may send NewSessionTicket messages immediately upon sending the server Finished message rather than