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] > > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
