jiebi/TextFlow huggingface dataset:
Original text:
DeriveKeyPair. The constants "Ne" and "Ns" are as defined in OPRF, Section 4 for <del> OPRF(P-384, SHA-384). </del>  5.1. this might be provided by the redemption protocol in AUTHSCHEME. Given this configuration and these inputs, the two messages exchanged <del> in this protocol are described below. </del>  6.1.

Reviewer comments:
doesn't define . The preceding text to the example says that Nk is 512, but AFAICT the value of Nk is not relevant to the example.
Section 8.2 defines Nk=256 for type 0x0002. Section 6.1 should still apply for any value Nk if another type is added for a different size key. My two suggestions would be: (1) mention in Section 6.1 that Nk is fixed according to the token type definition and (2) use Nk=256 for the example so it matches the only currently defined blind token type (0x0002).

Revised text:
DeriveKeyPair. The constants "Ne" and "Ns" are as defined in OPRF, Section 4 for  <ins> OPRF(P-384, SHA-384).  The constant "Nk" is defined by private-token- type. </ins> 5.1. this might be provided by the redemption protocol in AUTHSCHEME. Given this configuration and these inputs, the two messages exchanged  <ins> in this protocol are described below.  The constant "Nk" is defined by public-token-type. </ins> 6.1.
Original text:
Issuers MUST provide two parameters for configuration: <del> Issuer Request URI: A token request URL for generating access </del>  tokens.  For example, an Issuer URL might be <del> https://issuer.example.net/request.  This parameter uses resource media type "text/plain". </del>  Issuer Public Key values: A list of Issuer Public Keys for the issuance protocol.

Reviewer comments:
Are the changes to other files on this one intentional NAME ?
Oh, hrm, no, they're not. I'll remove them.
NAME fixed!
There are several related issues in URL Should the well-known location require mTLS? The two well-known public implementations previously highlighted by Apple disagree on this point. Our opinion: mTLS should not be required for the token issuer directory. is underspecified. Should this be an absolute URI, a relative URI, or allow either format? Our opinion: We prefer relative URIs, and think either option should be supported. A relative URI is also used by at least one well-known public implementation.
No. That's deployment specific decision. Either is fine, as evidenced by current implementations. We'll make this clear.
Since this URI is intended to be used as a URL later in the protocol -- and the description in fact calls it a URL -- would it be cleaner to name the parameter "Issuer Request URL"/? What "thing" is actually ? The directory itself is , the resulting content is JSON (whose strings do not carry a notion of media types), and the token request/response using this URI use /.
I think just dropping the media type mention at all is probably best here. It's just a URL string, so let's just call it that. Does work for you?
That looks much better. Should the parameter also be ?

Revised text:
Issuers MUST provide two parameters for configuration:  <ins> Issuer Request URL: A token request URL for generating access </ins> tokens.  For example, an Issuer URL might be  <ins> https://issuer.example.net/request. </ins> Issuer Public Key values: A list of Issuer Public Keys for the issuance protocol.
Original text:
"application/private-token-request".  An example request is shown below.  Upon receipt of the request, the Issuer validates the following conditions: The TokenRequest.blinded_msg is of the correct size. If any of these conditions is not met, the Issuer MUST return an HTTP <del> 400 error to the client. 5.2. Upon receipt of a TokenRequest, the Issuer tries to deseralize </del>  TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of OPRF, yielding "blinded_element".  If this fails, the Issuer MUST return an HTTP 400 error to the client.  Otherwise, if the Issuer is request is "application/private-token-request".  An example request is shown below:  Upon receipt of the request, the Issuer validates the following conditions: If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Client, which will forward the error to the client. <del> 6.2. If the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </del>  This is encoded and transmitted to the client in the following TokenResponse structure:

Reviewer comments:
ends with two paragraphs that really belong in Section 5.2, because they are about the processing of the request.

Revised text:
"application/private-token-request".  An example request is shown below. <ins> 5.2. </ins> Upon receipt of the request, the Issuer validates the following conditions: The TokenRequest.blinded_msg is of the correct size. If any of these conditions is not met, the Issuer MUST return an HTTP  <ins> 400 error to the client.  The Issuer then tries to deseralize </ins> TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of OPRF, yielding "blinded_element".  If this fails, the Issuer MUST return an HTTP 400 error to the client.  Otherwise, if the Issuer is request is "application/private-token-request".  An example request is shown below: <ins> 6.2. </ins> Upon receipt of the request, the Issuer validates the following conditions: If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Client, which will forward the error to the client.  <ins> Otherwise, if the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </ins> This is encoded and transmitted to the client in the following TokenResponse structure:
Original text:
6.3.2.  6.3.3.  6.3.4. 6.3.5.

Reviewer comments:
Rewrite parts of intro Clean up protocol overview Rewrite API functions Rewrite protocol instantiation Update ciphersuites (This is a big change, apologies!) cc NAME NAME for reviews (will also notify mailing list).
API has been updated at URL quite substantially.
SecretKey, to me, implies a symmetric key. Can we make this PrivateKey? That's the terminology used (mostly) in RFC7748, at least.
Done in

Revised text:
6.3.2. <ins> For this functionality, note that we supply multiple tokens in "msg" to "Evaluate".  This allows batching a single proof object for multiple evaluations.  While the construction in I-D.irtf-cfrg-voprf only permits a single input, we follow the advice for providing vectors of inputs. </ins> 6.3.3. <ins> Similarly to "Issue", we follow the advice for providing vectors of inputs to the "Unblind" function for verifying the batched proof object. </ins> 6.3.4. 6.3.5.
Original text:
on a fairly regular cycle to reduce the harmfulness of a server key compromise.  7.2. Similarly to the server rotation dynamic that is raised above, if 8.2. <del> We highlighted previously that short key-cycles can be used to reduce client privacy.  However, regular key rotations of the issuing key are still recommended to maintain good server key hygiene. We recommend that Privacy Pass issuing keys are rotated from anywhere between 1 and 12 weeks.  With an active user-base, a week gives a fairly large window for clients to participate in the Privacy Pass protocol and thus enjoy the anonymity guarantees of being part of a larger group.  The low ceiling of 12 weeks prevents a key compromise from being too destructive.  If a server realizes that a key compromise has occurred then the server should sample a new key and upload the public key to the key registry; invoking any revocation procedures that may apply for the old key. 8.3. </del> When a client holds tokens for an server, it is possible for any verifier to invoke that client to redeem tokens for that server. This can lead to an attack where a malicious verifier can force a need be, by providing an expiry date or by signaling that records from a particular window need to be refreshed. <del> 8.4. </del>  [[OPEN ISSUE: explain potential and mitigations for server centralization]]

Reviewer comments:
cc NAME NAME
Yeah, I agree. Something to bring up for discussion.
LGTM, 1 week might still be too small of a window for actively malicious servers, but I think that ties in to the open issue regarding malicious servers rather than the generic key rotation considerations.

Revised text:
on a fairly regular cycle to reduce the harmfulness of a server key compromise. <ins> With an active user-base, a week gives a fairly large window for clients to participate in the Privacy Pass protocol and thus enjoy the anonymity guarantees of being part of a larger group.  The low ceiling of 12 weeks prevents a key compromise from being too destructive.  If a server realizes that a key compromise has occurred then the server should sample a new key, and upload the public key to the key registry; invoking any revocation procedures that may apply for the old key. </ins> 7.2. Similarly to the server rotation dynamic that is raised above, if 8.2.  When a client holds tokens for an server, it is possible for any verifier to invoke that client to redeem tokens for that server. This can lead to an attack where a malicious verifier can force a need be, by providing an expiry date or by signaling that records from a particular window need to be refreshed.  <ins> 8.3. </ins> [[OPEN ISSUE: explain potential and mitigations for server centralization]]
Original text:
A Manifest Information Model for Firmware Updates in IoT Devices <del> draft-ietf-suit-information-model-10 </del>  Abstract provides the motivations for each of the manifest information elements.  4.1. The following sub-sections aim to provide information about the 4.3.7. The location where a target should find a payload MUST be <del> authenticated. </del>  Mitigates: threat-net-redirect,

Reviewer comments:
Section 4 We should probably mention the URI security considerations (RFC 3986) somewhere, as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.
Addressed in URL
Addressed in draft-ietf-suit-information-model-11
It might also be worth reiterating the topic that came up during one of the other review threads: firmware update is by definition remote code execution, so if you trust an entity to provide your firmware, you are trusting them to do the right thing. Many classes of attack involving malicious or modified payloads then become irrelevant, so we are left with just needing to verify that it did come from a trusted party and is not going backwards, topics that are covered quite well already (including TOCTOU).
Addressed in URL
Addressed in draft-ietf-suit-information-model-11

Revised text:
A Manifest Information Model for Firmware Updates in IoT Devices  <ins> draft-ietf-suit-information-model-11 </ins> Abstract provides the motivations for each of the manifest information elements. <ins> Note that it is worthwhile to recall that a firmware update is, by definition, remote code execution.  Hence, if a device is configured to trust an entity to provide firmware, it trusts this entity to do the "right thing".  Many classes of attacks can be mitigated by verifying that a firmware update came from a trusted party and that no rollback is taking place.  However, if the trusted entity has been compromised and distributes attacker-provided firmware to devices then the possibilities for deference are limited. </ins> 4.1. The following sub-sections aim to provide information about the 4.3.7. The location where a target should find a payload MUST be  <ins> authenticated.  Remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.  The security considerations of Uniform Resource Identifiers (URIs) are applicable RFC3986. </ins> Mitigates: threat-net-redirect,
Original text:
3.25. The delegation chain offers enhanced authorization functionality via <del> authorization tokens.  Each token itself is protected and does not require another layer of protection.  Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the Manifest. </del>  This element is OPTIONAL.

Reviewer comments:
Clarify that delegation chains are lists of authentication tokens where each token provides credentials for the next until the final token which provides the credentials for the manifest.
Ben Kaduk wrote:

Revised text:
3.25. The delegation chain offers enhanced authorization functionality via  <ins> authorization tokens, such as CBOR Web Tokens RFC8392 with Proof of Possession Key Semantics RFC8747.  Each token itself is protected and does not require another layer of protection.  Each authorization token typically includes a public key or a public key fingerprint, however this is dependent on the tokens used.  Each token MAY include additional metadata, such as key usage information.  Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the Manifest. The first token in any delegation chain MUST be autheticated by the recipient's Trust Anchor.  Each subsequent token MUST be authenticated using the previous token.  This allows a recipient to discard each antecedent token after it has authenticated the subsequent token.  The final token MUST enable authentication of the manifest.  More than one delegation chain MAY be used if more than one signature is used.  Note that no restriction is placed on the encoding order of these tokens, the order of elements is logical only. </ins> This element is OPTIONAL.
Original text:
negative effects on both the proxy and on media quality. Note also that these concerns predate WebRTC; Adobe Flash Player has <del> provided similar functionality since the introduction of RTMFP RFC7016 in 2008. </del>  4. quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. <del> Mode 1 MUST only be used when user consent has been provided.  The </del>  details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively, implementations can provide a specific mechanism to

Reviewer comments:
(nit) §3: Please expand "RTMFP" on first mention. (nit) §5.2: "Mode 1 MUST only be used when user consent has been provided" Please consider "... MUST NOT be used unless user consent has been provided." : It seems like the references for STUN and TURN should be normative.

Revised text:
negative effects on both the proxy and on media quality. Note also that these concerns predate WebRTC; Adobe Flash Player has  <ins> provided similar functionality since the introduction of Real-Time Media Flow Protocol (RTMFP) support RFC7016 in 2008. </ins> 4. quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server.  <ins> Mode 1 MUST NOT be used unless user consent has been provided.  The </ins> details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively, implementations can provide a specific mechanism to
Original text:
By default, WebRTC should be able to negotiate direct peer-to-peer connections between endpoints (i.e., without traversing a NAT or <del> relay server).  This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. </del>  It should be possible to configure WebRTC to not disclose private local IP addresses, to avoid the issues associated with web

Reviewer comments:
There is an implicit "where possible" here. The specific scenario is for two devices behind the same NAT who could communicate directly if only they knew each others' addresses; in this case, a direct connection should be possible, which implies that there needs to be some way for the two sides to share their machine addresses. Naturally, devices behind different NATs will not be able to do this. Noted.

Revised text:
By default, WebRTC should be able to negotiate direct peer-to-peer connections between endpoints (i.e., without traversing a NAT or  <ins> relay server) when such connections are possible.  This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. </ins> It should be possible to configure WebRTC to not disclose private local IP addresses, to avoid the issues associated with web
Original text:
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 <del> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  3.

Reviewer comments:
Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.
When I say "local" here, I am referring to the fact that the IP address is local to the machine, rather than an address for a remote party. To avoid confusion, I probably could just omit the word altogether here. Regarding NATing, your observation is often correct, but NAT64 is becoming increasingly common. I could just clarify and say that overall IPv6 avoids the issue through use of 4941 addresses.
The most obvious case is a NAT64 scenario, where the IPv6 address is never seen by the outside world, and therefore exposing said address to the web site presents a potential leakage concern. This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address.

Revised text:
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  <ins> 14 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 3.
Original text:
For any dots (".") outside character classes (first alternative of "charClass" production): replace dot by "[^nr]". <del> Envelope the result in "^" and "$". </del>  Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: <del> Enclose the regexp in "A" and "z". </del>  6.

Reviewer comments:
Clarifications in conversion to platform regexps.
Looks plausible but I don't know these regexps well enough to approve.

Revised text:
For any dots (".") outside character classes (first alternative of "charClass" production): replace dot by "[^nr]".  <ins> Envelope the result in "^(?:" and ")$". The ECMAScript regexp is to be interpreted as a Unicode pattern ("u" flag; see Section 21.2.2 "Pattern Semantics" of ECMA-262). </ins> Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is:  <ins> Enclose the regexp in "A(?:" and ")z". </ins> 6.
Original text:
lists each desired encoding, and no "recv" simulcast stream description.  The "m=" section will also include an "a=rid" attribute for each encoding, as specified in RFC8851; the use of Restriction <del> Identifiers (RIDs) allows the individual encodings to be disambiguated even though they are all part of the same "m=" section. </del>  3.8. Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m=" section(s) and further processing of the RTP/RTCP is done at the <del> RtpTransceiver level.  This includes using RID RFC8851 to distinguish between multiple encoded streams, as well as to determine which </del>  Source RTP stream should be repaired by a given redundancy RTP stream.

Reviewer comments:
This also adds in a sentence about using the MID header extension in outgoing streams, which was previously omitted despite there being a corresponding sentence for incoming streams.
The comment "[rfced] Please let us know if any changes are needed for the..." should also be removed.
AUTH48 on this document started with sixty [rfced] questions sent to the authors (NAME NAME NAME 2020 July 7. These questions were added as GitHub issues through . Follow on issues were created (in particular, splitting issues and ) to isolate some of the questions and to review normative text (). When PR is merged, all AUTH48 [rfced] questions will have been addressed, but there are some remaining XML comments that need to be removed.
This is sort of nuts but LGTM

Revised text:
lists each desired encoding, and no "recv" simulcast stream description.  The "m=" section will also include an "a=rid" attribute for each encoding, as specified in RFC8851; the use of Restriction  <ins> Identifiers (RIDs, also called rid-ids or RtpStreamIds) allows the individual encodings to be disambiguated even though they are all part of the same "m=" section. </ins> 3.8. Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m=" section(s) and further processing of the RTP/RTCP is done at the  <ins> RtpTransceiver level.  This includes using the RID mechanism RFC8851 and its associated RtpStreamId and RepairedRtpStreamId identifiers to distinguish between multiple encoded streams and determine which </ins> Source RTP stream should be repaired by a given redundancy RTP stream.
Original text:
Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent.  In the case of a new remote candidate, <del> connectivity checks will be sent to the new candidate. </del>  4.1.20.

Reviewer comments:
is supplied to the ICE agent. In the case of a new remote candidate, connectivity checks will be sent to the new candidate. However, if you do this prior to setLD() this will not cause connectivity checks to be sent, right?
That is correct.
Do you think we should change the text to say that? Perhaps "In the case of a new remote candidate, connectivity checks will be sent to the new candidate as soon as setLD(answer) is called, or immediately if it has been called already."
Something like that seems like a good idea. It won't always be setLD with an answer though.
maybe just add ", assuming setLocalDescription has already been called to initialize the ICE gathering process."

Revised text:
Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent.  In the case of a new remote candidate,  <ins> connectivity checks will be sent to the new candidate, assuming setLocalDescription has already been called to initialize the ICE gathering process. </ins> 4.1.20.