jiebi/TextFlow huggingface dataset:
Original text:
types.  That is, if a handshake message is split over two or more records, there MUST NOT be any other records between them. <del> Handshake messages MUST NOT span key changes.  Because the </del>  ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate <del> messages can arrive immediately prior to a key change, upon receiving these messages a receiver MUST verify that the end of these messages aligns with a record boundary; if not, then it MUST terminate the connection with an "unexpected_message" alert. </del>  Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding.

Reviewer comments:
…appens rather than on receipt of handshake messages. It is only actually necessary to verify that a handshake message aligns with a key change when changing keys, not when receiving the message, and it can be simpler to implement the check in this way. This change requires senders to align all these messages with a record boundary as before, but only requires recipients to verify the record boundary when the key change actually happens.

Revised text:
types.  That is, if a handshake message is split over two or more records, there MUST NOT be any other records between them.  <ins> Handshake messages MUST NOT span key changes.  Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert.  Because the </ins> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate  <ins> messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary. </ins> Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding.
Original text:
%%% Updating Keys <del> The EndOfEarlyData message is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be sent at all) and that the following records are protected under </del>  handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert.  This message is encrypted under keys

Reviewer comments:
31f836238e5968a85c9e4d64d8ab23c0bbed8061 missed a spot.
NAME
:+1: Having a definition on when EOED must be sent is good for both interoperability and as a guildeline of how 0RTT support should be implemented.

Revised text:
%%% Updating Keys  <ins> If the server sent an "early_data" extension, the client MUST send an EndOfEarlyData after receiving the server Finished.  This indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under </ins> handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert.  This message is encrypted under keys
Original text:
this connection (thus preventing replay of client CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges <del> described in post-handshake-authentication. </del>  A set of extensions describing the parameters of the certificate being requested.  The "signature_algorithms" extension MUST be

Reviewer comments:
be unpredictable in order to prevent pre-computation of CertificateVerify. Maybe this should actually be a MUST?
Note: an attacker can of course forge a complete handshake but maybe for some quirk of the environment that's not as good.

Revised text:
this connection (thus preventing replay of client CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges  <ins> described in post-handshake-authentication.  When requesting post- handshake authentication, the server SHOULD make the context unpredictable to the client (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the client's private key from pre-computing valid CertificateVerify messages. </ins> A set of extensions describing the parameters of the certificate being requested.  The "signature_algorithms" extension MUST be
Original text:
ECDHE parameters for both clients and servers are encoded in the the opaque key_exchange field of a KeyShareEntry in a KeyShare structure. <del> For secp256r1, secp384r1 and secp521r1, the contents are the byte string representation of an elliptic curve public value following the conversion routine in Section 4.3.6 of ANSI X9.62 X962. Although X9.62 supports multiple point formats, any given curve MUST specify only a single point format.  All curves currently specified in this document MUST only be used with the uncompressed point format (the format for all ECDH functions is considered uncompressed). Peers MUST validate each other's public value Y by ensuring that the point is a valid point on the elliptic curve. For the curves secp256r1, secp384r1 and secp521r1, the appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.6 of KEYAGREEMENT.  This process consists of three steps: (1) verify that Y is not the point at infinity (O), (2) verify that for Y = (x, y) both integers 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. </del>  For X25519 and X448, the contents of the public value are the byte string inputs and outputs of the corresponding functions defined in

Reviewer comments:
As suggested by Nikos, provide a formal description of the point format modelled on 4492-bis.
Per Nikos's comment.

Revised text:
ECDHE parameters for both clients and servers are encoded in the the opaque key_exchange field of a KeyShareEntry in a KeyShare structure.  <ins> For secp256r1, secp384r1 and secp521r1, the contents are the serialized value of the following struct: X and Y respectively are the binary representations of the X and Y values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters.  For P-256 this means that each of X and Y use 32 octets, padded on the left by zeros if necessary.  For P-384 they take 48 octets each, and for P-521 they take 66 octets each. 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.6 of KEYAGREEMENT.  This process consists of three steps: (1) verify that Y is not the point at infinity (O), (2) verify that for Y = (x, y) both integers 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. </ins> For X25519 and X448, the contents of the public value are the byte string inputs and outputs of the corresponding functions defined in
Original text:
Sent by servers when a client certificate is desired but none was provided by the client.  New Alert values are assigned by IANA as described in iana- considerations.

Reviewer comments:
RFC 7301 defines the ALPN extension and defined a new alert "noapplicationprotocol". TLS 1.3 uses ALPN but currently misses the alert in Section 6.
URL You also need to add it to the Error Alerts section with a description.

Revised text:
Sent by servers when a client certificate is desired but none was provided by the client. <ins> Sent by servers when a client advertises protocols that the server does not support. </ins> New Alert values are assigned by IANA as described in iana- considerations.
Original text:
In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the <del> TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher suites. (see cipher-suites) </del>  A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for

Reviewer comments:
Note that I'm not entirely convinced we need the GCM reference because RFC 5116, which is referenced in B.4 for the suites, includes a reference to it.
ID nits complains of the following unused references: == Unused Reference: 'AES' is defined on line 4147, but no explicit reference was found in the text == Unused Reference: 'GCM' is defined on line 4305, but no explicit reference was found in the text == Unused Reference: 'PKCS6' is defined on line 4339, but no explicit reference was found in the text == Unused Reference: 'PKCS7' is defined on line 4342, but no explicit reference was found in the text == Unused Reference: 'RFC4279' is defined on line 4371, but no explicit reference was found in the text == Unused Reference: 'RFC4507' is defined on line 4392, but no explicit reference was found in the text == Unused Reference: 'RFC5054' is defined on line 4401, but no explicit reference was found in the text == Unused Reference: 'RFC5746' is defined on line 4425, but no explicit reference was found in the text == Unused Reference: 'RFC5878' is defined on line 4436, but no explicit reference was found in the text == Unused Reference: 'RFC7366' is defined on line 4479, but no explicit reference was found in the text
Looking at the editor's copy only AES and GCM remain. I think we can safely remove both because those references are picked up but the cipher suite definitions.
Strike that since we're defining some suites we need to include GCM and move it normative. We can drop the AES reference because it's picked up by the GCM reference.

Revised text:
In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the  <ins> TLS_AES_128_GCM_SHA256 GCM cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 GCM and TLS_CHACHA20_POLY1305_SHA256 RFC7539 cipher suites.  (see cipher-suites) </ins> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
Original text:
in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. <del> Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in RFC5246.  IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm Registry to list values 4-223 as "Reserved". </del>

Reviewer comments:
Is it strictly necessary to include the following in the TLS1.3 draft: Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in [RFC5246]. IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as “Reserved” and the TLS SignatureAlgorithm Registry to list values 4-223 as “Reserved”. If this text wasn't in the TLS1.3 draft everything would be fine right? If that's the case, then this text from s10 should be moved to .
Sorry, I'm not following the issue. I'm happy to move it out, though.
It kind of seems like the move of registries should be done atomically, which is ~guaranteed by doing it in the same document, but could still be done atomically if the two documents are advanced at the same time. (I, like ekr, am not really clear on what the issue is, though.)
I guess I see reserving the remaining values as essentially slamming the door on future assignments. Was that the intent? spt
I should have also added that URL already includes a paragraph indicating that Compression Method Identifiers, HashAlgorithm, and SignatureAlgorithm are obsoleted by TLS1.3; adds a note to the registries indicating as much. spt
My understanding was that yes, "don't look here, go look over there" was the idea. Any new allocation would need to go in the SignatureScheme registry, regardless of whether it also ended up in the HashAlgorithm or SignatureAlgorithm registry as well for someone's convenience. Since you have to go to the new registry anyway, it doesn't seem like there would be value in also adding it to the old/deprecated registry.
Okay that makes sense and it explains why the values in the Compression Method Identifiers isn’t also “reserved”. I guess I’m off the mind that this para could safely be move to the IANA draft.
Specially move the text to s13 of .

Revised text:
in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519.
Original text:
Also, candidate trickling needs to be correlated to a specific ICE negotiation session, so that if there is an ICE restart, any delayed updates for a previous session can be recognized as such and ignored <del> by the receiving party. </del>  One important aspect of Vanilla ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by

Reviewer comments:
NAME and NAME had an editors' discussion (see URL) about how to specify the handling of ICE restarts in the context of Trickle ICE. One possible approach would be to send a new ufrag and pwd without triggering a full offer/answer exchange, because Trickle (and ICE itself) can be used with application protocols that are not tied to O/A. There is an SDP dependency on the a= line, but we've disengaged Trickle ICE from SDP, too. Also, if the sender doesn't include a media description then a new offer might not be necessary anyway. I'm hoping that NAME can propose text...
At IETF 95, there was support for explicitly indicating which ufrag/pwd the candidate applies to. But the specifics are signaling-specific. So perhaps we should just update the text to say "SHOULD be explicit" in some way. URL
I am fine also adding to the spec a sample way of labeling them (the way Trickle for SIP does) Emil , Peter Thatcher EMAIL wrote:
By the way, this came up in the JSEP work recently, that with ICE restarts being roll-back-able, the explicit ufrag is really needed for edge cases there. We think the right solution is using a ufrag on the JS object, not on the SDP (since we also need to include it on the end of candidates message, and since it would look weird being duplicated in so many lines in the current remote description).
It looks like we already have a paragraph that indicates an implementation should have an explicit ufrag (or other correlation). Great! So, I made a PR to add some examples: URL
resolved

Revised text:
Also, candidate trickling needs to be correlated to a specific ICE negotiation session, so that if there is an ICE restart, any delayed updates for a previous session can be recognized as such and ignored  <ins> by the receiving party.  For example, applications that choose to signal candidates via SDP may include a ufrag value in the SDP that represents candidates (such as "a=candidate ... ufrag abc").  Or as another exmaple, WebRTC implementations may include a ufrag in the JavaScript objects that represent candidates. </ins> One important aspect of Vanilla ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by
Original text:
Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL domain and ROLL.  RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation.  It should just be noted that an incoming RH3 must be fully consumed, or very carefully <del> inspected. </del>  The RPI, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different

Reviewer comments:
…S and COMMENT) On December 18, 2020 at 10:42:24 AM, Pascal Thubert (pthubert) (pthubert=EMAIL) wrote: Hello Michael and all: Yes, I expected policies that would validate the right of a Leaf to participate to a DODAG ,or to remap the information from the leaf (could be the RPI, the opaque field in the EARO, or the 6-tuple) into an RPI. Yes, as I said in my response I thought it was quite common. I'm surprised to find little art to quote. Cool, we're good! Pascal Roll mailing list EMAIL URL Roll mailing list EMAIL URL

Revised text:
Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL domain and ROLL. <ins> Consumed: A Routing Header is consumed when the Segments Left field is zero, which indicates that the destination in the IPv6 header is the final destination of the packet and that the hops in the Routing Header have been traversed. </ins> RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation.  It should just be noted that an incoming RH3 must be fully consumed, or very carefully  <ins> inspected to match a policy that applies to this network and is correctly processed by the leaves. </ins> The RPI, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different
Original text:
Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL Domain and ROLL. <del> RPL-aware-node: A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. </del>  <del> RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. </del>  RPL-unaware-node: A device which does not implement RPL, thus the device is not-RPL-aware.  Please note that the device can be found inside the LLN. <del> RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. </del>  6LoWPAN Node (6LN): RFC6775 defines it as: "A 6LoWPAN node is any host or router participating in a LoWPAN.  This term is used when The final node should be able to remove one or more IPv6-in-IPv6 headers which are all addressed to it.  The final node does not process the RPI, the node ignores the RPI.  Further details about <del> this are mentioned in I-D.thubert-roll-unaware-leaves, which specifies RPL routing for a 6LN acting as a plain host and not being aware of RPL. </del>  The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to zero in order to aid in compression RFC6437.

Reviewer comments:
RPL was missing a good definition of a LEAF. this clarifies.
updated the deprecated ref to rul draft

Revised text:
Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL Domain and ROLL.  <ins> RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a consumed Routing Header and as an IPv6 host, it is expected to ignore a Hop-by-Hop header.  It results that a RPL Leaf can correctly receive a packet with RPL artifacts.  On the other hand, a RPL Leaf is not expected to generate RPL artifacts or to support IP-in-IP encapsulation.  For simplification, this document uses the standalone term leaf to mean a RPL leaf. </ins>  <ins> RPL-aware-node (RAN): A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. </ins> RPL-unaware-node: A device which does not implement RPL, thus the device is not-RPL-aware.  Please note that the device can be found inside the LLN.  <ins> RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. </ins> 6LoWPAN Node (6LN): RFC6775 defines it as: "A 6LoWPAN node is any host or router participating in a LoWPAN.  This term is used when The final node should be able to remove one or more IPv6-in-IPv6 headers which are all addressed to it.  The final node does not process the RPI, the node ignores the RPI.  Further details about  <ins> this are mentioned in I-D.ietf-roll-unaware-leaves, which specifies RPL routing for a 6LN acting as a plain host and not being aware of RPL. </ins> The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to zero in order to aid in compression RFC6437.
Original text:
changes from a fork (or any branch) into their copy. Editors SHOULD make pull requests for all substantial changes rather <del> than committing directly to the "master" branch of the repository. Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </del>  This document assumes that there is a unified effort on a document, all concentrated on a git "master" branch.  More

Reviewer comments:
Section 4.2 says "Editors SHOULD make pull requests for all substantial changes rather than committing directly to the "master" branch of the repository." Adding a short explanation will help make this more likely to happen.

Revised text:
changes from a fork (or any branch) into their copy. Editors SHOULD make pull requests for all substantial changes rather  <ins> than committing directly to the "master" branch of the repository.  A pull request creates an artifact that records the reasons for changes and provides other contributors with an opportunity to review the change.  Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </ins> This document assumes that there is a unified effort on a document, all concentrated on a git "master" branch.  More