Change:
As per RFC5077, and as described in RFC8446, TLS servers vend clients an arbitrary number of session tickets at their own discretion in <del> NewSessionTicket messages.  There are two limitations with this design.  First, servers choose some (often hard-coded) number of tickets vended per connection.  Second, clients do not have a way of expressing their desired number of tickets, which can impact future connection establishment.  For example, clients can open multiple TLS connections to the same server 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 requesting more than one ticket is desirable. </del> <ins> NewSessionTicket messages.  There are at least three limitations with this design. First, servers vend some (often hard-coded) number of tickets per connection.  Some server implementations return a different default 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. Second, clients do not have a way of expressing their desired number of tickets, which can impact future connection establishment.  For example, clients can open multiple TLS connections to the same server 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 requesting more than one ticket is desirable. Third, all tickets in the client's possession ultimately derive from 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. </ins> This document specifies a new TLS extension - "ticket_request" - that can be used by clients to express their desired number of session

Discussion:
This is without ticket re-use text. This also includes changes from . The following table outlines the ticket request values for a a client that wants N tickets and always attempts to race a connection across K paths. Did I get this right? Does this make sense? Should we put this in the document directly?
NAME NAME do you think we should include the table in the PR's description in the text? I think its contents are implied from the text, so adding more text is just being verbose. But I could be persuaded otherwise.
I think that it might be confusing. For instance, I see no reason that a client wouldn't have a fixed configuration. A client that never races resumptions could send N and 1 always.
Can you please provide text?
NAME I can't really provide text as I'm unclear on what the field is trying to even describe.