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

Commentary: I might do " both integers x and y " but I can see how it would be okay as - is .
Paragraph (version A):
For the curves secp256r1, secp384r1 and secp521r1, peers MUST
validate each other's public value Y by ensuring that the point is a
valid point on the elliptic curve.  The appropriate validation
procedures are defined in Section 4.3.7 of X962 and alternatively in
Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three
steps: (1) verify that the point (X, Y) is not the point at infinity
(O), (2) verify that both X and Y are integers in the correct
interval, (3) ensure that (X, Y) is a correct solution to the
elliptic curve equation.  For these curves, implementors do not need
to verify membership in the correct subgroup.
Paragraph (version B):
For the curves secp256r1, secp384r1 and secp521r1, peers MUST
validate each other's public value Q by ensuring that the point is a
valid point on the elliptic curve.  The appropriate validation
procedures are defined in Section 4.3.7 of X962 and alternatively in
Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three
steps: (1) verify that Q is not the point at infinity (O), (2) verify
that for Q = (x, y) both integers x and y are in the correct
interval, (3) ensure that (x, y) is a correct solution to the
elliptic curve equation.  For these curves, implementers do not need
to verify membership in the correct subgroup.
Draft: draft-ietf-tls-tls13

Commentary: works for me
Paragraph (version A):
Upon receipt of a HelloRetryRequest, the client MUST perform the
checks specified in server-hello and then process the extensions,
starting with determining the version using "supported_versions".
Clients MUST abort the handshake with an "illegal_parameter" alert if
the HelloRetryRequest would not result in any change in the
ClientHello.  If a client receives a second HelloRetryRequest in the
same connection (i.e., where the ClientHello was itself in response
to a HelloRetryRequest), it MUST abort the handshake with an
"unexpected_message" alert.
Paragraph (version B):
Upon receipt of a HelloRetryRequest, the client MUST check the
legacy_version, legacy_session_id_echo, cipher_suite, and
legacy_compression_method as specified in server-hello and then
process the extensions, starting with determining the version using
"supported_versions".  Clients MUST abort the handshake with an
"illegal_parameter" alert if the HelloRetryRequest would not result
in any change in the ClientHello.  If a client receives a second
HelloRetryRequest in the same connection (i.e., where the ClientHello
was itself in response to a HelloRetryRequest), it MUST abort the
handshake with an "unexpected_message" alert.
Draft: draft-ietf-tls-tls13

Commentary: We currently have which is a little confusing , since it does n't note that the server has the non - early exporter available once it has generated its first flight , and doubly so since the actual motivation for separate interfaces is for security reasons of not accidentally using the early exporter when the main one is needed . ( Split out from )
Paragraph (version A):
Where Secret is either the early_exporter_master_secret or the
exporter_master_secret.  Implementations MUST use the
exporter_master_secret unless explicitly specified by the
application.  The early_exporter_master_secret is defined for use in
settings where an exporter is needed for 0-RTT data.  A separate
interface for the early exporter is RECOMMENDED.
Paragraph (version B):
Where Secret is either the early_exporter_master_secret or the
exporter_master_secret.  Implementations MUST use the
exporter_master_secret unless explicitly specified by the
application.  The early_exporter_master_secret is defined for use in
settings where an exporter is needed for 0-RTT data.  A separate
interface for the early exporter is RECOMMENDED; this avoids the
exporter user accidentally using an early exporter when a regular one
is desired or vice versa.
Draft: draft-ietf-tls-tls13

Commentary: if I am understanding correctly the nature of the complaint .
Paragraph (version A):
Versions of TLS before 1.3 supported compression with the list of
supported compression methods being sent in this field.  For every
TLS 1.3 ClientHello, this vector MUST contain exactly one byte set
to zero, which corresponds to the "null" compression method in
prior versions of TLS.  If a TLS 1.3 ClientHello is received with
any other value in this field, the server MUST abort the handshake
with an "illegal_parameter" alert.  Note that TLS 1.3 servers
might receive TLS 1.2 or prior ClientHellos which contain other
compression methods and MUST follow the procedures for the
appropriate prior version of TLS.  TLS 1.3 ClientHellos are
identified as having a legacy_version of 0x0303 and a
supported_versions extension present with 0x0304 as the highest
version indicated therein.
Paragraph (version B):
Versions of TLS before 1.3 supported compression with the list of
supported compression methods being sent in this field.  For every
TLS 1.3 ClientHello, this vector MUST contain exactly one byte set
to zero, which corresponds to the "null" compression method in
prior versions of TLS.  If a TLS 1.3 ClientHello is received with
any other value in this field, the server MUST abort the handshake
with an "illegal_parameter" alert.  Note that TLS 1.3 servers
might receive TLS 1.2 or prior ClientHellos which contain other
compression methods and (if negotiating such a prior version) MUST
follow the procedures for the appropriate prior version of TLS.
TLS 1.3 ClientHellos are identified as having a legacy_version of
0x0303 and a supported_versions extension present with 0x0304 as
the highest version indicated therein.
Draft: draft-ietf-tls-tls13

Commentary: The I - D checklist requires that updates and obsoletes be included in the abstract ; thought RFC . I personally feel this is [ redacted ] stupid , but I do not think that we should risk a process appeal to fight this battle .
Paragraph (version B):
This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs
5077, 5246, and 6961.
Draft: draft-ietf-tls-tls13

Commentary: Based on Saravanan 's comments .
Paragraph (version A):
ECDHE parameters for both clients and servers are encoded in the the
opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
Paragraph (version B):
ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
Draft: draft-ietf-tls-tls13

Commentary: LGTM ! 
 This is natural , since if you negotiate prior to 1.3 you must use the ServerHello rules for the negotiated
Paragraph (version B):
draft-26 - Clarify that you can't negotiate pre-TLS 1.3 with
supported_versions.
Paragraph (version A):
A server which negotiates TLS 1.3 MUST respond by sending a
"supported_versions" extension containing the selected version value
(0x0304).  It MUST set the ServerHello.legacy_version field to 0x0303
(TLS 1.2).  Clients MUST check for this extension prior to processing
the rest of the ServerHello (although they will have to parse the
ServerHello in order to read the extension).  If this extension is
present, clients MUST ignore the ServerHello.legacy_version value and
MUST use only the "supported_versions" extension to determine the
selected version.  If the "supported_versions" extension contains a
version not offered by the client, the client MUST abort the
handshake with an "illegal_parameter" alert.
Paragraph (version B):
A server which negotiates a version of TLS prior to TLS 1.3 MUST set
ServerHello.version and MUST NOT send the "supported_versions"
extension.  A server which negotiates TLS 1.3 MUST respond by sending
a "supported_versions" extension containing the selected version
value (0x0304).  It MUST set the ServerHello.legacy_version field to
0x0303 (TLS 1.2).  Clients MUST check for this extension prior to
processing the rest of the ServerHello (although they will have to
parse the ServerHello in order to read the extension).  If this
extension is present, clients MUST ignore the
ServerHello.legacy_version value and MUST use only the
"supported_versions" extension to determine the selected version.  If
the "supported_versions" extension contains a version not offered by
the client or contains a version prior to TLS 1.3, the client MUST
abort the handshake with an "illegal_parameter" alert.
Draft: draft-ietf-tls-tls13

Commentary: Previous PR plus some cleanup . 
 Looks good to me , for what it 's worth :) 
 ekr : please merge this so we can get a new version out for the IESG . 
 can you be more precise about the appendix D text ? is the issue that we say " ignored " but then use it as additional_data ? 
 : PTAL
Paragraph (version B):
Minor clarifications.
Paragraph (version B):
IANA cleanup.
Paragraph (version A):
The legacy_record_version field is always 0x0303.  TLS 1.3
TLSCiphertexts are not generated until after TLS 1.3 has been
negotiated, so there are no historical compatibility concerns
where other values might be received.  Implementations MAY verify
that the legacy_record_version field is 0x0303 and abort the
connection if it is not.  Note that the handshake protocol
including the ClientHello and ServerHello messages authenticates
the protocol version, so this value is redundant.
Paragraph (version B):
The legacy_record_version field is always 0x0303.  TLS 1.3
TLSCiphertexts are not generated until after TLS 1.3 has been
negotiated, so there are no historical compatibility concerns
where other values might be received.  Note that the handshake
protocol including the ClientHello and ServerHello messages
authenticates the protocol version, so this value is redundant.
Paragraph (version A):
AEAD algorithms take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as
described in Section 2.1 of RFC5116.  The key is either the
client_write_key or the server_write_key, the nonce is derived from
the sequence number (see nonce) and the client_write_iv or
server_write_iv, and the additional data input is empty (zero
length).  Derivation of traffic keys is defined in traffic-key-
calculation.
Paragraph (version A):
The plaintext input to the AEAD algorithm is the encoded
TLSInnerPlaintext structure.
Paragraph (version B):
AEAD algorithms take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as
described in Section 2.1 of RFC5116.  The key is either the
client_write_key or the server_write_key, the nonce is derived from
the sequence number (see nonce) and the client_write_iv or
server_write_iv, and the additional data input is the record header.
I.e.,
Paragraph (version B):
The plaintext input to the AEAD algorithm is the encoded
TLSInnerPlaintext structure.  Derivation of traffic keys is defined
in traffic-key-calculation.
Paragraph (version B):
Then the encrypted_record field of TLSCiphertext is set to
AEADEncrypted.
Draft: draft-ietf-tls-tls13

Commentary: This clarifies two items relevant to stateless HelloRetryRequests : 1 ) If a HelloRetryRequest does not contain a keyshare extension , the negotiated group does not have to match the non - existent selected group in the HRR . 2 ) If a HelloRetryRequest does select a group , the server can still choose to use pskke key exchange . When sending a stateless HelloRetryRequest , the server may not know if it will accept a PSK yet . This allows the server to still select a group in the HelloRetryRequest which it would need for a full handshake , but later decide to accept the PSK with psk_ke mode . 
 Seems reasonable to me .
Paragraph (version A):
If using (EC)DHE key establishment, servers offer exactly one
KeyShareEntry in the ServerHello.  This value MUST be in the same
group as the KeyShareEntry value offered by the client that the
server has selected for the negotiated key exchange.  Servers MUST
NOT send a KeyShareEntry for any group not indicated in the
"supported_groups" extension and MUST NOT send a KeyShareEntry when
using the "psk_ke" PskKeyExchangeMode.  If a HelloRetryRequest was
received by the client, the client MUST verify that the selected
NamedGroup in the ServerHello is the same as that in the
HelloRetryRequest.  If this check fails, the client MUST abort the
handshake with an "illegal_parameter" alert.
Paragraph (version B):
If using (EC)DHE key establishment, servers offer exactly one
KeyShareEntry in the ServerHello.  This value MUST be in the same
group as the KeyShareEntry value offered by the client that the
server has selected for the negotiated key exchange.  Servers MUST
NOT send a KeyShareEntry for any group not indicated in the
"supported_groups" extension and MUST NOT send a KeyShareEntry when
using the "psk_ke" PskKeyExchangeMode.  If using (EC)DHE key
establishment, and a HelloRetryRequest containing a "key_share"
extension was received by the client, the client MUST verify that the
selected NamedGroup in the ServerHello is the same as that in the
HelloRetryRequest.  If this check fails, the client MUST abort the
handshake with an "illegal_parameter" alert.
Draft: draft-ietf-tls-tls13

Commentary: says : But the following text follows : MAY and MUST mismatch . Let 's s / MUST / SHOULD/
Paragraph (version A):
This document describes TLS 1.3, which uses the version 0x0304.  This
version value is historical, deriving from the use of 0x0301 for TLS
compatibility, records containing an initial ClientHello MUST have
version 0x0301 and a record containing a second ClientHello or a
ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2
respectively.  When negotiating prior versions of TLS, endpoints
follow the procedure and requirements in backward-compatibility.
Paragraph (version B):
This document describes TLS 1.3, which uses the version 0x0304.  This
version value is historical, deriving from the use of 0x0301 for TLS
compatibility, records containing an initial ClientHello SHOULD have
version 0x0301 and a record containing a second ClientHello or a
ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2
respectively.  When negotiating prior versions of TLS, endpoints
follow the procedure and requirements in backward-compatibility.
Draft: draft-ietf-tls-tls13

Commentary: Given that it 's common to select the strongest cipher by default ( thus likely using SHA-384 PRF ) and that the default Hash associated with a PSK is SHA-256 , simple upgrade of server and client to TLS 1.3 may cause handshake failures if only PSK key exchanges were configured and the existing implementor 's note is followed .
Paragraph (version A):
Implementor's note: the most straightforward way to implement the
PSK/cipher suite matching requirements is to negotiate the cipher
suite first and then exclude any incompatible PSKs.  Any unknown PSKs
(e.g., they are not in the PSK database or are encrypted with an
unknown key) SHOULD simply be ignored.  If no acceptable PSKs are
found, the server SHOULD perform a non-PSK handshake if possible.
Paragraph (version B):
Implementor's note: when session resumption is the primary use case
of PSKs the most straightforward way to implement the PSK/cipher
suite matching requirements is to negotiate the cipher suite first
and then exclude any incompatible PSKs.  Any unknown PSKs (e.g., they
are not in the PSK database or are encrypted with an unknown key)
SHOULD simply be ignored.  If no acceptable PSKs are found, the
server SHOULD perform a non-PSK handshake if possible.  If backwards
compatibility is important, client provided, externally established
PSKs SHOULD influence cipher suite selection.
Draft: draft-ietf-tls-tls13

Commentary: " A client MUST provide a ' pskkeyexchangemodes ' extension if it offers a ' preshared_key ' extension . "
Paragraph (version B):
"psk_key_exchange_modes" is REQUIRED for PSK key agreement.
Draft: draft-ietf-tls-tls13

Commentary: PTAL 
 Looks good . Minor typo : " a records "
Paragraph (version A):
This value MUST be set to 0x0303 for all records generated by a
TLS 1.3 implementation other than the ClientHello, where it MAY
also be 0x0301 for compatibility purposes.  This field is
deprecated and MUST be ignored for all purposes.  Previous
versions of TLS would use other values in this field under some
circumstances.
Paragraph (version B):
This value MUST be set to 0x0303 for all records generated by a
TLS 1.3 implementation other than an initial ClientHello (i.e.,
one not generated after a HelloRetryRequest), where it MAY also be
0x0301 for compatibility purposes.  This field is deprecated and
MUST be ignored for all purposes.  Previous versions of TLS would
use other values in this field under some circumstances.
Paragraph (version A):
This document describes TLS 1.3, which uses the version 0x0304.  This
version value is historical, deriving from the use of 0x0301 for TLS
compatibility, records containing the ClientHello MUST have version
0x0301 and records containing the ServerHello MUST have version
0x0303, reflecting TLS 1.0 and TLS 1.2 respectively.  When
negotiating prior versions of TLS, endpoints follow the procedure and
requirements in backward-compatibility.
Paragraph (version B):
This document describes TLS 1.3, which uses the version 0x0304.  This
version value is historical, deriving from the use of 0x0301 for TLS
compatibility, records containing an initial ClientHello MUST have
version 0x0301 and a record containing a second ClientHello or a
ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2
respectively.  When negotiating prior versions of TLS, endpoints
follow the procedure and requirements in backward-compatibility.
Draft: draft-ietf-tls-tls13

Commentary: the type is called signaturealgorithmscert ( singular ) everywhere , not signaturealgorithmscerts ( plural )
Paragraph (version A):
IANA [SHALL update/has updated] this registry to include the
"key_share", "pre_shared_key", "psk_key_exchange_modes",
"early_data", "cookie", "supported_versions",
"certificate_authorities", "oid_filters", "post_handshake_auth",
and "signature_algorithms_certs", extensions with the values
defined in this document and the Recommended value of "Yes".
Paragraph (version B):
IANA [SHALL update/has updated] this registry to include the
"key_share", "pre_shared_key", "psk_key_exchange_modes",
"early_data", "cookie", "supported_versions",
"certificate_authorities", "oid_filters", "post_handshake_auth",
and "signature_algorithms_cert", extensions with the values
defined in this document and the Recommended value of "Yes".
Draft: draft-ietf-tls-tls13

Commentary: remove extra _ at the end of name -- the name in SignatureScheme enum lacks it
Paragraph (version A):
A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
TLS-compliant application MUST support key exchange with secp256r1
(NIST P-256) and SHOULD support key exchange with X25519 RFC7748.
Paragraph (version B):
A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
TLS-compliant application MUST support key exchange with secp256r1
(NIST P-256) and SHOULD support key exchange with X25519 RFC7748.
Draft: draft-ietf-tls-tls13

Commentary: Issue 1 : supportedversions is required in TLS 1.3 SH . Issue 2 : supportedversions.selected_version must be identical in HRR and SH 
 please submit a PR to add yourself to acknowledgements 
 Thanks for the fixup .
Paragraph (version A):
A list of extensions.  The ServerHello MUST only include
extensions which are required to establish the cryptographic
context.  Currently the only such extensions are "key_share" and
"pre_shared_key".  All current TLS 1.3 ServerHello messages will
contain one of these two extensions, or both when using a PSK with
(EC)DHE key establishment.  The remaining extensions are sent
separately in the EncryptedExtensions message.
Paragraph (version B):
A list of extensions.  The ServerHello MUST only include
extensions which are required to establish the cryptographic
context and negotiate the protocol version.  All TLS 1.3
ServerHello messages MUST contain the "supported_versions"
extension.  Current ServerHello messages contain either the
"pre_shared_key" or "key_share" extensions, or both when using a
PSK with (EC)DHE key establishment.  The remaining extensions are
sent separately in the EncryptedExtensions message.
Paragraph (version B):
The value of selected_version in the HelloRetryRequest
"supported_versions" extension MUST be retained in the ServerHello,
and a client MUST abort the handshake with an "illegal_parameter"
alert if the value changes.
Draft: draft-ietf-tls-tls13

Commentary: implementatations -implementations
Paragraph (version A):
The "signature_algorithms_cert" extension was added to allow
implementatations which supported different sets of algorithms for
certificates and in TLS itself to clearly signal their capabilities.
TLS 1.2 implementations SHOULD also process this extension.
Paragraph (version B):
The "signature_algorithms_cert" extension was added to allow
implementations which supported different sets of algorithms for
certificates and in TLS itself to clearly signal their capabilities.
TLS 1.2 implementations SHOULD also process this extension.
Draft: draft-ietf-tls-tls13

Commentary: LGTM , modulo the link issueI'm fine with this .
Paragraph (version B):
When a server is operating statelessly it may receive an unprotected
record of type change_cipher_spec between the first and second
ClientHello (see record-protocol).  Since the server is not storing
any state this will appear as if it were the first message to be
received.  Servers operating statelessly MUST ignore these records.
Paragraph (version A):
An implementation may receive an unencrypted record of type
change_cipher_spec consisting of the single byte value 0x01 at any
time during the handshake and MUST simply drop it without further
processing.  Note that this record may appear at a point at the
handshake where the implementation is expecting protected records and
so it is necessary to detect this condition prior to attempting to
deprotect the record.  An implementation which receives any other
change_cipher_spec value or which receives a protected
change_cipher_spec record MUST abort the handshake with an
"unexpected_message" alert.  After the handshake is complete,
change_cipher_spec MUST be treated as an unexpected record type.
Paragraph (version B):
An implementation may receive an unencrypted record of type
change_cipher_spec consisting of the single byte value 0x01 at any
time after the first ClientHello message has been sent or received
and before the peer's Finished message has been received and MUST
simply drop it without further processing.  Note that this record may
appear at a point at the handshake where the implementation is
expecting protected records and so it is necessary to detect this
condition prior to attempting to deprotect the record.  An
implementation which receives any other change_cipher_spec value or
which receives a protected change_cipher_spec record MUST abort the
handshake with an "unexpected_message" alert.  A change_cipher_spec
record received before the first ClientHello message or after the
peer's Finished message MUST be treated as an unexpected record type.
Draft: draft-ietf-tls-tls13

Commentary: RFC 8174 updates RFC 2119 so the boilerplate words have changed slightly according to s2 of RFC 8174 . Just trying to save us another GENART comment .
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 RFC2119.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.