Re: [TLS] Genart last call review of draft-ietf-tls-ticketrequests-06

[Christopher Wood <[e-mail]>]

Thanks for the feedback, Dale! We addressed your comments and updated the draft. The diff is available here:

   https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-ticketrequests-07.txt

Best,
Chris

On Fri, Nov 27, 2020, at 7:54 PM, Dale Worley via Datatracker wrote:
> Reviewer: Dale Worley
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> 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:
> 
> 2.  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.
> 
>    new_session_count  The number of tickets desired by the client when
>       the server chooses to negotiate a new connection.
> 
>    resumption_count  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:
> 
>    new_session_count  The number of tickets desired by the client if
>       the server chooses to negotiate a new connection.
> 
>    resumption_count  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.)
> 
> [END]
> 
> 
> 
>