Original text:
The ability to request one or more tickets is useful for a variety of purposes: <del> Parallel HTTP connections: To minimize ticket reuse while still improving performance, it may be useful to use multiple, distinct tickets when opening parallel connections.  Clients must therefore bound the number of parallel connections they initiate by the number of tickets in their possession, or risk ticket re-use. </del>  Connection racing: Happy Eyeballs V2 RFC8305 describes techniques for performing connection racing.  The Transport Services computation, e.g., public key cryptographic operations, avoiding waste is desirable. <del> Decline resumption: Clients can indicate they have no intention of resuming connections by sending a ticket request with count of </del>  zero. 3. Clients MAY send this extension in ClientHello.  It contains the following structure: <del> The number of tickets desired by the client when the server chooses to negotiate a new connection. </del>  <del> The number of tickets desired by the client when the server is </del>  willing to resume using a ticket presented in this ClientHello. A client starting a new connection SHOULD set new_session_count to 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 <del> 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>  When a client presenting a previously obtained ticket finds that the server nevertheless negotiates a new connection, the client SHOULD

Reviewer comments:
From Ben: One nit that can be rolled in with any LC comments: in Section 3, we say "clients can send a resumption_count equal to the number of sessions they are attempting in parallel", and "connections" probably works better than "sessions" in that case.
Document: draft-ietf-tls-ticketrequests-06 Reviewer: Dale R. Worley Review Date: 2020-11-27 IETF LC End Date: 2020-12-03 IESG Telechat date: Not known Summary: This draft is ready for publication as a Standards Track RFC. Editorial comments: Use Cases Parallel HTTP connections: To minimize ticket reuse while still improving performance, it may be useful to use multiple, distinct tickets when opening parallel connections. To the naive reader, the ordering of the phrases doesn't seem to match the logical ordering of the concepts. Perhaps Parallel HTTP connections: To improve performance, a client may open parallel connections. To avoid ticket reuse, the client may use multiple, distinct tickets on each connection. Decline resumption: Clients can indicate they have no intention of resuming connections by sending a ticket request with count of zero. "have no intention" seems to me to suggest a decision that will not change. Since the future cannot be guaranteed, perhaps better wording is "do not intend to resume", suggesting a current state that might possibly change in the future. newsessioncount The number of tickets desired by the client when the server chooses to negotiate a new connection. resumptioncount The number of tickets desired by the client when the server is willing to resume using a ticket presented in this ClientHello. If I understand the processing which is suggested correctly, when the client sends a ClientHello, the server can choose to either negotiate a new connection, or (if a ticket is present in the ClientHello) the server can choose to resume the previous connection represented by the ticket. These two parameters provide the requested ticket count for the two situations. Assuming the above is correct, I would recommend changing the wording slightly, as "when" suggests a fact which is true over an extended period of time, whereas the provided counts are applicable in just this one instance: newsessioncount The number of tickets desired by the client if the server chooses to negotiate a new connection. resumptioncount The number of tickets desired by the client if the server chooses to resume (using the ticket presented in this ClientHello). (Change "the" to "a" in the last sentence if the ClientHello can present more than one ticket among which the server can choose.)

Revised text:
The ability to request one or more tickets is useful for a variety of purposes:  <ins> Parallel HTTP connections: To improve performance, a client may open parallel connections.  To avoid ticket reuse, the client may use multiple, distinct tickets on each connection.  Clients must therefore bound the number of parallel connections they initiate by the number of tickets in their possession, or risk ticket re- use. </ins> Connection racing: Happy Eyeballs V2 RFC8305 describes techniques for performing connection racing.  The Transport Services computation, e.g., public key cryptographic operations, avoiding waste is desirable.  <ins> Decline resumption: Clients can indicate they do not intend to resume a connection by sending a ticket request with count of </ins> zero. 3. Clients MAY send this extension in ClientHello.  It contains the following structure:  <ins> The number of tickets desired by the client if the server chooses to negotiate a new connection. </ins>  <ins> The number of tickets desired by the client if the server is </ins> willing to resume using a ticket presented in this ClientHello. A client starting a new connection SHOULD set new_session_count to 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  <ins> resumption_count equal to the number of connections 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 server nevertheless negotiates a new connection, the client SHOULD