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 <caw@xxxxxxxxxxxxxxx> 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 > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
