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

Commentary: Add an applicability statement . This only addresses buffer space issues , not processing or bandwidth constraints . I did n't observe ( in the introduction ) that this can negatively affect bandwidth , that 's later . Hannes also observed that we do n't really talk about the path MTU . I made it clear that these are separate and independent limitations . For 
 Thanks for providing this text . While I had been hoping for more clarifications about the interactions between the MTU information entering the stack from below and the RSL parameter passed to the stack from the application side I think it is a good start . 
 Oh , also , I have moved the intro text down a paragraph . I think that it is better to talk about the properties of this extension rather than focus more on what MFL does or does n't do .
A smaller protected record size is just one of many problems that a
constrained implementation might need to address.  The
"record_size_limit" extension only addresses the memory allocation
problem, it does not address limits of code size, or processing and
bandwidth capacity.
The record size limit can interact with the maximum transmission unit
(MTU) in DTLS, but it is a separate and independent constraint on
record size.  In particular, it is not appropriate to use the record
size limit in place of path MTU detection.  The record size limit is
a fixed property of an endpoint that is set during the handshake and
fixed thereafter.  In comparison, the MTU is determined by the
network path and can change dynamically over time.
Draft: draft-ietf-tls-record-limit

Commentary: requests : I believe we should re - word the text in the draft in such a way that it does not say record with plaintext that is larger than the RecordSizeLimit value it receives from its peer . but instead says what you explained below . In essence , the RecordSizeLimit value can then be used by the TLS stack to determine the size of the fragments . " below " being that when writing , the limit determines when to create new records . It should n't prohibit writes that exceed the limit .
The value of RecordSizeLimit is the maximum size of record in octets
that the endpoint is willing to receive.  When the
"record_size_limit" extension is negotiated, an endpoint MUST NOT
generate a protected record with plaintext that is larger than the
RecordSizeLimit value it receives from its peer.  Unprotected
messages - handshake messages in particular - are not subject to this
limit.
The value of RecordSizeLimit is the maximum size of record in octets
that the endpoint is willing to receive.  This value is used to limit
the size of records that are created when encoding application data
and handshake message into records.
When the "record_size_limit" extension is negotiated, an endpoint
MUST NOT generate a protected record with plaintext that is larger
than the RecordSizeLimit value it receives from its peer.
Unprotected messages - handshake messages in particular - are not
subject to this limit.
Draft: draft-ietf-tls-record-limit

Commentary: And simply explain what the costs of smaller records actually are . 
 Great summary . Thanks for adding the text . One minor question : My reading of the referenced email discussion is that the computational overhead is not just a matter of cryptographic processing but also the processing related to multiplexing , TCP - related processing and other implementation details ( e.g. , threading ) . Is this also your understanding of what the folks in the email thread were referring to ? 
 My understanding is that the performance costs are largely due to context switching . That might be worse because of multiplexing . Willy did a separate talk on the costs of doing crypto at high data rates that I wish that I could reference . He had some great numbers about what it took just to move data from the kernel to user space and that was a significant impact on overall throughput .
For large data transfers, small record sizes can materially affect
performance TARREAU.  Consequently, clients that are capable of
receiving large records could be unwilling to risk reducing
performance by offering the extension, especially if the extension is
rarely needed.
For large data transfers, small record sizes can materially affect
performance.  Every record incurs additional costs, both in the
additional octets for record headers and for expansion due to
encryption.  Processing more records also adds computational
overheads that can be amortized more effectively for larger record
sizes.  Consequently, clients that are capable of receiving large
records could be unwilling to risk reducing performance by offering
the extension, especially if the extension is rarely needed.
Draft: draft-ietf-tls-record-limit

Commentary: This is n't as easy as in TLS 1.3 , which has a clearly defined structure for what is fed into the AEAD . I 've done my best . this is the only change from your email that you might disagree with . Can you have a look please ?
This value is the length of the plaintext of a protected record.  The
value includes the content type and padding added in TLS 1.3 (that
is, the complete length of TLSInnerPlaintext).  Padding added as part
of encryption, such as that added by a block cipher, is not included
in this count (see expansion).
This value is the length of the plaintext of a protected record.  The
value includes the content type and padding added in TLS 1.3 (that
is, the complete length of TLSInnerPlaintext).  In TLS 1.2 and
earlier, the limit covers all input to compression and encryption,
that is the data that ultimately produces TLSCiphertext.fragment.
Padding added as part of encryption, such as that added by a block
cipher, is not included in this count (see expansion).
Draft: draft-ietf-tls-record-limit

Commentary: This is a good part of what motivates the existence of the mechanism . 
 The text changes look good to me . I only had a minor remark regarding another sentence .
An Authentication Encryption with Additional Data (AEAD) ciphers (see
RFC5116) API requires that an entire record be present to decrypt and
authenticate it.  Similarly, other ciphers cannot produce
authenticated data until the entire record is present.  Thus,
incremental processing of records minimally exposes endpoints to the
risk of forged data.
The "max_fragment_length" extension is also ill-suited to cases where
the capabilities of client and server are asymmetric.  Constraints on
record size are often receiver constraints.  In particular, an
Authentication Encryption with Additional Data (AEAD) ciphers (see
RFC5116) API requires that an entire record be present to decrypt and
authenticate it.  Some implementations choose not to implement an
AEAD interface in this way to avoid this problem, but that exposes
them to risks that an AEAD is intended to protect against.
The "max_fragment_length" extension is also ill-suited to cases where
the capabilities of client and server are asymmetric.  Constraints on
record size are often receiver constraints.
Draft: draft-ietf-tls-record-limit

Commentary: I ca n't believe that I did n't actually say this . 
 Looks good .
The value of RecordSizeLimit is the maximum size of record that the
endpoint is willing to receive.  When the "record_size_limit"
extension is negotiated, an endpoint MUST NOT generate a protected
record with plaintext that is larger than the RecordSizeLimit value
it receives from its peer.  Unprotected messages - handshake messages
in particular - are not subject to this limit.
This value is the size of the plaintext of a protected record.  The
value includes the content type and padding added in TLS 1.3 (that
is, the complete length of TLSInnerPlaintext).  Padding added as part
of encryption, such as that added by a block cipher, is not included
in this count (see expansion).
The value of RecordSizeLimit is the maximum size of record in octets
that the endpoint is willing to receive.  When the
"record_size_limit" extension is negotiated, an endpoint MUST NOT
generate a protected record with plaintext that is larger than the
RecordSizeLimit value it receives from its peer.  Unprotected
messages - handshake messages in particular - are not subject to this
limit.
This value is the length of the plaintext of a protected record.  The
value includes the content type and padding added in TLS 1.3 (that
is, the complete length of TLSInnerPlaintext).  Padding added as part
of encryption, such as that added by a block cipher, is not included
in this count (see expansion).
Draft: draft-ietf-tls-record-limit

Commentary: Seems obvious , but ... 
 A good text clarification ! Thanks
The record size limit only applies to records sent toward the
endpoint that advertises the limit.  An endpoint MAY send records
that are larger than the limit it advertises as its own limit.
The record size limit only applies to records sent toward the
endpoint that advertises the limit.  An endpoint can send records
that are larger than the limit it advertises as its own limit.  An
endpoint that receives a record larger than its advertised limit MUST
generate a fatal "record_overflow" alert.
Draft: draft-thomson-tls-record-limit

Commentary: The idea of this change is to try to constrain how much padding a sender can add . This is done by calculating the size of a record with maximum plaintext and minimum padding . No other record can exceed this size , though smaller packets can pad to reach this size . I was going to include a formula , then realized that the simple answer is best : pad to the record size limit , then pad to get to a multiple of the block size as normal . Most implementations will be OK because they do n't bother with the first step .
This value is the size of the plaintext of a protected record.  The
value includes the content type and padding added in TLS 1.3 (that
is, the complete length of TLSInnerPlaintext).  Padding added as part
of encryption, such as that added by a block cipher, is not included
in this count.
This value is the size of the plaintext of a protected record.  The
value includes the content type and padding added in TLS 1.3 (that
is, the complete length of TLSInnerPlaintext).  Padding added as part
of encryption, such as that added by a block cipher, is not included
in this count (see expansion).
The size limit expressed in the "record_size_limit" extension doesn't
account for expansion due to compression or record protection.  It is
expected that a constrained device will disable compression and know
- and account for - the maximum expansion possible due to record
protection based on the cipher suites it offers or selects.  Note
that up to 256 octets of padding and padding length can be added to
block ciphers.
The size limit expressed in the "record_size_limit" extension doesn't
account for expansion due to compression or record protection.  It is
expected that a constrained device will disable compression to avoid
unpredictable increases in record size.  Stream ciphers and existing
AEAD ciphers don't permit variable amounts of expansion, but block
ciphers do permit variable expansion.
In TLS 1.2, block ciphers allow between 1 and 256 octets of padding.
When a limit lower than the protocol-defined limit is advertised, a
second limit applies to the length of records that use block ciphers.
An endpoint MUST NOT add padding to records that would cause the
protected record to exceed the size of a protected record that
contains the maximum amount of plaintext and the minimum permitted
amount of padding.
For example, TLS_RSA_WITH_AES_128_CBC_SHA has 16 octet blocks and a
20 octet MAC.  Given a record size limit of 256, a record of that
length would require a minimum of 11 octets of padding (for RFC5246
where the MAC is covered by encryption); or 15 octets if the
"encrypt_then_mac" extension RFC7366 is negotiated.  With this limit,
a record with 250 octets of plaintext could be padded to the same
length by including at most 17 octets of padding; or 21 octets with
"encrypt_then_mac".
An implementation that always adds the minimum amount of padding will
always comply with this requirement.