jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-ticketrequests

Commentary: Write up text for 
 This PR looks good to me 
 From 
 Fixed by .
Servers can send tickets in NewSessionTicket messages any time after
the server Finished message (see RFC8446; Section 4.6.1).  A server
which chooses to send a large number of tickets to a client can
potentially harm application performance if the tickets are sent
before application data.  For example, if the transport connection
has a constrained congestion window, ticket messages could delay
sending application data.  To avoid this, servers should prioritize
sending application data over tickets when possible.
Draft: draft-ietf-tls-ticketrequests

Commentary: Addresses and . The server hint came up in the context of QUIC , e.g. , as a possible optimization to let clients know if they should expect any post handshake messages . cc 
 Looks like this got merged without any business days to review it :) but otherwise the text looks good , approved . 
 Every day is a business day ! ;-) 
 From 
 Fixed by . 
 You probably want to be clear that ticket_request can not appear in HRR , given that you have a section on it . 
 Fixed in . 
 I 'm not a huge fan of sending extensions that are n't really needed , but this seems fine . I missed the QUIC discussion ( or maybe it 's still in my inbox ) . BTW , I still like the idea of hoisting tickets to the application layer , but ekr seems to think that they belong at the TLS layer . I guess we 'll just have to keep disagreeing on that point :)
Servers that support ticket requests MUST NOT echo "ticket_request"
in the EncryptedExtensions message.  A client MUST abort the
connection with an "illegal_parameter" alert if the "ticket_request"
extension is present in the EncryptedExtensions message.
A server that supports ticket requests MAY echo the "ticket_request"
extension in the EncryptedExtensions message.  If present, it
contains a TicketRequestContents structure, where
TicketRequestContents.count indicates the number of tickets the
server expects to send to the client.
Servers MUST NOT send the "ticket_request" extension in ServerHello
or HelloRetryRequest messages.  A client MUST abort the connection
with an "illegal_parameter" alert if the "ticket_request" extension
is present in either of these messages.
IANA is requested to Create an entry, ticket_request(TBD), in the
existing registry for ExtensionType (defined in RFC8446), with "TLS
set to "Yes".
IANA is requested to Create an entry, ticket_request(TBD), in the
existing registry for ExtensionType (defined in RFC8446), with "TLS
being set to "Yes".
Draft: draft-ietf-tls-ticketrequests

Commentary: Adding the text proposed in the email 
 Unless I am missing something , I believe that checking the IP address may be useful to filter packets that are outside the key exchange , but I do not see this as a counter measure to the amplification attack . With a single round trip , unless i am missing something , I do not see how the server can verify the Client 's IP address . It receives the ClientHello responds with the ServerHello .. Finished , NewSessionTickets . In other cases , the server received from the given IP address the ClientHello and the client Finished which I think proves that IP receives the the ServerHello and responds to it . Yours ,    has a cookie extension for this purpose , for example . 
 Thanks , looks good to me . Yours ,    agree with the change below and updated the text . OLD : Server should limit the number of NewSessionTicket messages sent in response to a " ticket_request " should be based on the applicability and the amplification factor of such attack . NEW Servers SHOULD limit the number of NewSessionTicket messages they send until they have verified the client 's ownership of its IP address . 
 Great ! We 're just waiting on 
 Approved pending  ' last suggestion
In some cases, a server may send NewSessionTicket messages
immediately upon sending the server Finished message rather than
waiting for the client Finished.  If the server has not verified the
client's ownership of its IP address, e.g., with the TLS Cookie
extension (see RFC8446; Section 4.2.2), an attacker may take
advantage of this behavior to create an amplification attack
proportional to the count value toward a target by performing a key
exchange over UDP with spoofed packets.  Servers SHOULD limit the
number of NewSessionTicket messages they send until they have
verified the client's ownership of its IP address.
Draft: draft-ietf-tls-ticketrequests

Commentary: I do n't think any of this paragraph should have 2119 language in it . But , even overlooking that minor disagreement , it 's important to avoid unintentional requirements . I think my edit guides well - meaning implementors , while making no guarantees . 
 This editorial change is fine by me .
Clients can use TicketRequestContents.count to indicate the number of
tickets they would prefer to receive.  Servers SHOULD NOT send more
tickets than TicketRequestContents.count, as clients will most likely
discard any additional tickets.  Servers SHOULD additionally place a
limit on the number of tickets they are willing to send, to save
resources.  Therefore, the number of NewSessionTicket messages sent
will be the minimum of the server's self-imposed limit and
TicketRequestContents.count.
Clients can use TicketRequestContents.count to indicate the number of
tickets they would prefer to receive.  Servers SHOULD NOT send more
tickets than TicketRequestContents.count, as clients will most likely
discard any additional tickets.  Servers SHOULD additionally place a
limit on the number of tickets they are willing to send, to save
resources.  Therefore, the number of NewSessionTicket messages sent
will typically be the minimum of the server's self-imposed limit and
TicketRequestContents.count.
Draft: draft-ietf-tls-ticketrequests

Commentary: Good catch -- will fix . Good suggestion ! We can certainly add this . 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 . It 's intended to be once per session , and we 'll add that . 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 . That seems reasonable to me . 
 Thanks ! Approved pending
Connection racing: Happy Eyeballs V2 RFC8305 describes techniques
for performing connection racing.  The Transport Services
Architecture implementation from I-D.ietf-taps-impl also describes
how connections may race across interfaces and address families.
In cases where clients have early data to send and want to
minimize or avoid ticket re-use, unique tickets for each unique
connection attempt are useful.  Moreover, as some servers may
implement single-use tickets (and even session ticket encryption
keys), distinct tickets will be needed to prevent premature ticket
invalidation by racing.
Connection racing: Happy Eyeballs V2 RFC8305 describes techniques
for performing connection racing.  The Transport Services
Architecture implementation from TAPS also describes how
connections may race across interfaces and address families.  In
cases where clients have early data to send and want to minimize
or avoid ticket re-use, unique tickets for each unique connection
attempt are useful.  Moreover, as some servers may implement
single-use tickets (and even session ticket encryption keys),
distinct tickets will be needed to prevent premature ticket
invalidation by racing.
Decline resumption: Clients may indicate they have no intention of
resuming connections by sending a ticket request with count of
zero.
Servers that support ticket requests MUST NOT echo "ticket_request"
in the EncryptedExtensions.
Servers that support ticket requests MUST NOT echo "ticket_request"
in the EncryptedExtensions message.  A client MUST abort the
connection with an "illegal_parameter" alert if the "ticket_request"
extension is present in the EncryptedExtensions message.
Clients MUST NOT change the value of TicketRequestContents.count in
second ClientHello messages sent in response to a HelloRetryRequest.