jiebi/TextFlow huggingface dataset:
Original text:
4.1.3. <del> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is </del>  the output session key of a successful EDHOC exchange. <del> Keys for applications are derived using EDHOC_Exporter from PRK_exporter (see exporter) which in turn is derived from PRK_out. For the purpose of generating application keys, it is sufficient to store PRK_out or PRK_exporter.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a Trusted Execution Environment, see impl-cons). </del>  4.2. This section defines EDHOC_Exporter in terms of EDHOC_KDF and <del> PRK_out.  A key update function is defined in keyupdate. </del>  4.2.1.

Reviewer comments:
I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.

Revised text:
4.1.3.  <ins> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf, is </ins> the output session key of a successful EDHOC exchange.  <ins> Keys for applications are derived using EDHOC_Exporter (see exporter) from PRK_exporter, which in turn is derived from PRK_out as shown in fig-edhoc-kdf.  For the purpose of generating application keys, it is sufficient to store PRK_out or PRK_exporter.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a Trusted Execution Environment, see impl-cons). </ins> 4.2. This section defines EDHOC_Exporter in terms of EDHOC_KDF and  <ins> PRK_exporter.  A key update function is defined in keyupdate. </ins> 4.2.1.
Original text:
length is a uint defined by the application <del> PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite. </del> The (exporter_label, context) pair used in EDHOC_Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same

Reviewer comments:
I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.

Revised text:
length is a uint defined by the application  The (exporter_label, context) pair used in EDHOC_Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same
Original text:
(method equals 1 or 3), then mac_length_2 is the EDHOC MAC length of the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then <del> mac_length_2 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del>  ID_CRED_R - identifier to facilitate the retrieval of CRED_R, see

Reviewer comments:
I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.

Revised text:
(method equals 1 or 3), then mac_length_2 is the EDHOC MAC length of the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then  <ins> mac_length_2 is equal to hash_length. </ins> ID_CRED_R - identifier to facilitate the retrieval of CRED_R, see
Original text:
(method equals 2 or 3), then mac_length_3 is the EDHOC MAC length of the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then <del> mac_length_3 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del>  ID_CRED_I - identifier to facilitate the retrieval of CRED_I, see

Reviewer comments:
I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.

Revised text:
(method equals 2 or 3), then mac_length_3 is the EDHOC MAC length of the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then  <ins> mac_length_3 is equal to hash_length. </ins> ID_CRED_I - identifier to facilitate the retrieval of CRED_I, see
Original text:
4. <del> Applications MUST use external PSKs that adhere to the following requirements: Each PSK MUST be derived from at least 128 of entropy and MUST be at least 128-bits long unless the TLS handshake is being used with a separate key establishment mechanism such as a Diffie-Hellman exchange.  This recommendation protects against passive attacks using exhaustive search of the PSK. </del>  Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a

Reviewer comments:
This builds on .
Summary: use a high-entropy PSK with DH, otherwise, with a low-entropy PSK, use a PAKE. Reference appendix with security properties from NAME

Revised text:
4.  <ins> Applications MUST adhere to the following requirements for external PSKs: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a
Original text:
violated, then the security properties of TLS are severely weakened. As discussed in use-cases, there are use cases where it is desirable <del> for multiple clients or multiple servers share a PSK.  If this is </del>  done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious

Reviewer comments:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Revised text:
violated, then the security properties of TLS are severely weakened. As discussed in use-cases, there are use cases where it is desirable  <ins> for multiple clients or multiple servers to share a PSK.  If this is </ins> done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious
Original text:
appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when <del> using external PSKs if these risks. </del>  In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can

Reviewer comments:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Revised text:
appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when  <ins> using external PSKs to mitigate these risks. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can
Original text:
constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. <del> Some devices are provisioned PSKs via an out-of-band, cloud-based </del>  syncing protocol. Some secrets may be baked into or hardware or software device

Reviewer comments:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Revised text:
constrained UI.  Moreover, PSK production lacks guidance unlike user passwords.  <ins> Some devices provision PSKs via an out-of-band, cloud-based </ins> syncing protocol. Some secrets may be baked into or hardware or software device
Original text:
Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH <del> exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </del>  Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a

Reviewer comments:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Revised text:
Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH  <ins> exchange for forward secrecy.  As discussed in sec-properties, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided.  Low entropy keys are only secure against active attack if a Password Authenticated Key Exchange (PAKE) is used with TLS. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a
Original text:
6.1. <del> Most major TLS implementations support external PSKs.  And all have a common interface that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </del>  OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake. <del> These callbacks must provide a PSK identity (as a character string) and key (as a byte string).  (If no identity is provided, a default one is assumed.)  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. </del>  mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. <del> Servers must implement callbacks similar to that of OpenSSL.  PSK lengths are validate to be between [1, 16] bytes. </del>  gnuTLS: Applications configure PSK values, either as raw byte <del> strings or hexadecimal strings.  The PSK size is not validated. </del>  wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.

Reviewer comments:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Revised text:
6.1.  <ins> Most major TLS implementations support external PSKs.  Stacks supporting external PSKs provide interfaces that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </ins> OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake.  <ins> These callbacks must provide a PSK identity and key.  The exact format of the callback depends on the negotiated TLS protocol version with new callback functions added specifically to OpenSSL for TLS 1.3 RFC8446 PSK support.  The PSK length is validated to be between [1, 256] bytes.  The PSK identity may be up to 128 bytes long. </ins> mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline.  <ins> Servers must implement callbacks similar to that of OpenSSL.  Both PSK identity and key lengths may be between [1, 16] bytes long. </ins> gnuTLS: Applications configure PSK values, either as raw byte  <ins> strings or hexadecimal strings.  The PSK identity and key size are not validated. </ins> wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.
Original text:
Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions. <del> [[OPEN ISSUE: discuss implication of collisions between external and resumption PSKs.]] </del>  7.

Reviewer comments:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Revised text:
Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions.  <ins> 6.1.2. It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity.  The TLS stack implementation and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the application's registered callback function before checking the stack's internal session resumption cache.  This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK. </ins> 7.
Original text:
indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used.  This is in contrast to methods <del> like RTX RFC4588 or flexfec I-D.ietf-payload-flexible-fec-scheme retransmissions, which only transmit redundant data when necessary, at the cost of an extra roundtrip. </del>  Given this, WebRTC implementations SHOULD consider using RTX or flexfec retransmissions instead of FEC when RTT is low, and SHOULD

Reviewer comments:
Ah, I see now. I think what would help is "in contrast to methods like RTX or flexfec (when retransmissions are used) [I-D.]"

Revised text:
indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used.  This is in contrast to methods  <ins> like RTX RFC4588 or flexfec's retransmission mode ( I-D.ietf-payload- flexible-fec-scheme, Section 1.1.7), which only transmit redundant data when necessary, at the cost of an extra roundtrip. </ins> Given this, WebRTC implementations SHOULD consider using RTX or flexfec retransmissions instead of FEC when RTT is low, and SHOULD
Original text:
This approach, as described in RFC2198, allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous <del> packet, or for codecs that support variable-bitrate encodings, </del>  possibly a smaller, lower-quality representation.  In certain cases, <del> the redundant data could include multiple prior packets. </del>  Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant

Reviewer comments:
It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.

Revised text:
This approach, as described in RFC2198, allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous  <ins> payload, or for codecs that support variable-bitrate encodings, </ins> possibly a smaller, lower-quality representation.  In certain cases,  <ins> the redundant data could include encodings of multiple prior audio frames. </ins> Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant
Original text:
Some audio codecs, notably Opus RFC6716 and AMR RFC4867, support their own in-band FEC mechanism, where redundant data is included in <del> the codec payload. </del>  <del> For Opus, packets deemed as important are re-encoded at a lower bitrate and added to the subsequent packet, allowing partial recovery </del>  of a lost packet.  This scheme is fairly efficient; experiments performed indicate that when Opus FEC is used, the overhead imposed <del> is about 20-30%, depending on the amount of protection needed.  Note that this mechanism can only carry redundancy information for the immediately preceding packet; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </del>  For AMR/AMR-WB, packets can contain copies or lower-quality encodings <del> of multiple prior audio frames.  This mechanism is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient.  See RFC4867, Section 3.7.1 for details on this mechanism. </del>  In-band FEC mechanisms cannot recover any of the RTP header.

Reviewer comments:
It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.

Revised text:
Some audio codecs, notably Opus RFC6716 and AMR RFC4867, support their own in-band FEC mechanism, where redundant data is included in  <ins> the codec payload.  This is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient. </ins>  <ins> For Opus, audio frames deemed important are re-encoded at a lower bitrate and appended to the next payload, allowing partial recovery </ins> of a lost packet.  This scheme is fairly efficient; experiments performed indicate that when Opus FEC is used, the overhead imposed  <ins> is only about 20-30%, depending on the amount of protection needed. Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </ins> For AMR/AMR-WB, packets can contain copies or lower-quality encodings  <ins> of multiple prior audio frames.  See RFC4867, Section 3.7.1 for details on this mechanism. </ins> In-band FEC mechanisms cannot recover any of the RTP header.
Original text:
Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described <del> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1, as an </del>  additional supported media type for the associated m= section in the SDP offer RFC3264.  As mentioned above, when BUNDLE is used, only a single flexfec repair stream will be created for each BUNDLE group,

Reviewer comments:
It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.

Revised text:
Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described  <ins> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1.2, as an </ins> additional supported media type for the associated m= section in the SDP offer RFC3264.  As mentioned above, when BUNDLE is used, only a single flexfec repair stream will be created for each BUNDLE group,
Original text:
result MAY be used by the client instance in the request- capabilities of the request. <del> OPTIONAL.  A list of the AS's interaction methods.  The values of this list correspond to the possible fields in the request- interact of the request. </del>  OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the

Reviewer comments:
The discovery fields for the interaction methods were still in a single list, even though those have now been split into start and finish sections.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 754d971b07753b2b9580c2c6f0b3c8997c34b260 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Yes, makes sense

Revised text:
result MAY be used by the client instance in the request- capabilities of the request.  <ins> OPTIONAL.  A list of the AS's interaction start methods.  The values of this list correspond to the possible values for the request-interact-start of the request. OPTIONAL.  A list of the AS's interaction finish methods.  The values of this list correspond to the possible values for the method element of the request-interact-finish of the request. </ins> OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the
Original text:
Mutual TLS certificate verification <del> OAuth Demonstration of Proof-of-Possession key proof header </del> HTTP Signing signature header OAuth PoP key proof authentication header

Reviewer comments:
remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now

Revised text:
Mutual TLS certificate verification  HTTP Signing signature header OAuth PoP key proof authentication header