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

2020-12-16 Thread Alissa Cooper 
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  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=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
>> 
>> .
>> 
>> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

2020-12-03 Thread Christopher Wood 
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=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
> 
> .
> 
> 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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

2020-11-27 Thread Dale Worley via Datatracker 
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

.

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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art