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

[Alissa Cooper <[e-mail]>]

Dale, thanks for your review. Chris, thanks for addressing Dale’s comments. I entered a No Objection ballot.

Alissa


> On Dec 3, 2020, at 10:22 PM, Christopher Wood <[e-mail]> wrote:
> 
> 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]
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art