From @huitema.

You probably want to be clear that ticket_request cannot appear in HRR, given that you have a section on it.

typos: send, sended

Good catch -- will fix.

I think that the use cases should list a situation in which the client does
not expect to perform session resume, so it can inform the server of that by
sending the value 0.

Good suggestion! We can certainly add this.

The draft does not state what is the expected behaviour with tickets in
relation to post-handshake authentication.

As the extension is merely a hint to servers when deciding how many tickets to vend, I think this is out of scope for the document.

The draft does not state if the extension is negotiated once per session or
its values should be reused for resumed sessions.

It's intended to be once per session, and we'll add that.

The draft does not state how the extension interacts with Hello Retry Request
handshake. Can it be dropped/added/changed in 2nd CH message? What is expected
to happen when client does change it?

Also a good catch. Like other extensions that are not affected by the possibly updated ClientHello, it must not change. We need to specify the server side behavior, too.

Servers that support ticket requests MUST NOT echo "ticket_request"
in the EncryptedExtensions.

It's not spelled out what the client is expected to do when server does
violate this expectation. I'd say it should abort with unsupported_extension.

That seems reasonable to me.

From @martinthomson.

From Ben: One nit that can be rolled in with any LC comments: in Section 3, we say "clients can send a resumption_count equal to the number of sessions they are attempting in parallel", and "connections" probably works better than "sessions" in that case.

If they don't enforce a limit, clients can cause them to do a lot of work.