Change:
3. <del> Clients can indicate to servers their desired number of tickets for a single connection via the following "ticket_request" extension: </del> <ins> As discussed in introduction, clients may want different numbers of tickets for fresh or resumed handshakes.  Clients may indicate to servers their desired number of tickets for a single connection, in the case of a full handshake or resumption, via the following "ticket_request" extension: </ins> Clients MAY send this extension in ClientHello.  It contains the following structure: <del> The number of tickets desired by the client. Clients can use TicketRequestContents.count to indicate the number of tickets they would prefer to receive.  Servers SHOULD NOT send more tickets than TicketRequestContents.count, as clients will most likely discard any additional tickets.  Servers SHOULD additionally place a limit on the number of tickets they are willing to send, to save resources.  Therefore, the number of NewSessionTicket messages sent will typically be the minimum of the server's self-imposed limit and TicketRequestContents.count. A server that supports ticket requests MAY echo the "ticket_request" extension in the EncryptedExtensions message.  If present, it contains a TicketRequestContents structure, where TicketRequestContents.count indicates the number of tickets the server expects to send to the client. </del> <ins> The number of tickets desired by the client when the server chooses to negotiate a fresh session (full handshake). The number of tickets desired by the client when the server is willing to resume using the presented ticket. A client starting a fresh connection SHOULD set new_session_count to 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 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.) When a client presenting a previously obtained ticket finds that the server nevertheless negotiates a fresh session, the client SHOULD assume that any other tickets associated with the same session as the presented ticket are also no longer valid for resumption.  This includes tickets obtained during the initial full handshake and all tickets subsequently obtained as part of subsequent resumptions. Requesting more than one ticket in cases when servers select a full handshake helps keep the session cache primed. Servers SHOULD NOT send more tickets than requested for the handshake type selected by the server (resumption or full handshake). Moreover, servers SHOULD place a limit on the number of tickets they 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. A server which supports and uses a client "ticket_request" extension MUST also send the "ticket_request" extension in the EncryptedExtensions message.  It contains the following structure: The number of tickets the server expects to send in this connection. </ins> Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection

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.