jiebi/TextFlow huggingface dataset:
Original text:
obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client.  This linkability is less feasible as the number of issuance events at time <del> T2 increases.  Depending on the "max-age" token challenge attribute, </del>  clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token

Reviewer comments:
The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.

Revised text:
obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client.  This linkability is less feasible as the number of issuance events at time  <ins> T2 increases.  Depending on the "max-age" token challenge parameter, </ins> clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token
Original text:
Server functionality: <del> "PP_Server_Setup": Generates server configuration and keys </del>  <del> "PP_Issue": Run on the contents of the client message in the </del>  issuance phase. <del> "PP_Verify": Run on the contents of the client message in the </del>  redemption phase. Client functionality: <del> "PP_Client_Setup": Generates the client configuration based on the configuration used by a given server. </del>  <del> "PP_Generate": Generates public and private data associated with the contents of the client message in the issuance phase. </del>  <del> "PP_Process": Processes the contents of the server response in the issuance phase. </del>  <del> "PP_Redeem": Generates the data that forms the client message in the redemption phase. </del>  We will use each of the functions internally in the description of the interfaces that follows.

Reviewer comments:
These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.

Revised text:
Server functionality:  <ins> "ServerSetup": Generates server configuration and keys </ins>  <ins> "Issue": Run on the contents of the client message in the </ins> issuance phase.  <ins> "Verify": Run on the contents of the client message in the </ins> redemption phase. Client functionality:  <ins> "ClientSetup": Generates the client configuration based on the configuration used by a given server. </ins>  <ins> "Generate": Generates public and private data associated with the contents of the client message in the issuance phase. </ins>  <ins> "Process": Processes the contents of the server response in the issuance phase. </ins>  <ins> "Redeem": Generates the data that forms the client message in the redemption phase. </ins> We will use each of the functions internally in the description of the interfaces that follows.
Original text:
Steps: <del> Run "(cfg, update) = PP_Server_Setup(id)". </del>  Construct a "config_update" message.

Reviewer comments:
These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.

Revised text:
Steps:  <ins> Run "(cfg, update) = ServerSetup(id)". </ins> Construct a "config_update" message.
Original text:
Run by the client when processing the server response in the issuance phase of the protocol.  The output of this function is an array of "RedemptionToken" objects that are unlinkable from the server's <del> computation in "PP_Issue". </del>  Inputs:

Reviewer comments:
These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.

Revised text:
Run by the client when processing the server response in the issuance phase of the protocol.  The output of this function is an array of "RedemptionToken" objects that are unlinkable from the server's  <ins> computation in "Issue". </ins> Inputs:
Original text:
Formally speaking the security model is the following: <del> The adversary runs "PP_Server_Setup" and generates a key-pair "(key, pub_key)". </del>  The adversary specifies a number "Q" of issuance phases to initiate, where each phase "i in 1..Q" consists of "m_i" server evaluations. <del> The adversary runs "PP_Issue" using the key-pair that it generated on each of the client messages in the issuance phase. </del>  When the adversary wants, it stops the issuance phase, and a random number "l" is picked from "1..Q".

Reviewer comments:
These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.

Revised text:
Formally speaking the security model is the following:  <ins> The adversary runs "ServerSetup" and generates a key-pair "(key, pub_key)". </ins> The adversary specifies a number "Q" of issuance phases to initiate, where each phase "i in 1..Q" consists of "m_i" server evaluations.  <ins> The adversary runs "Issue" using the key-pair that it generated on each of the client messages in the issuance phase. </ins> When the adversary wants, it stops the issuance phase, and a random number "l" is picked from "1..Q".
Original text:
The security model takes the following form: <del> A server is created that runs "PP_Server_Setup" and broadcasts the </del>  "ServerUpdate" message "s_update". <del> The adversary runs "PP_Client_Setup" on "s_update". </del>  The adversary specifies a number "Q" of issuance phases to initiate with the server, where each phase "i in 1..Q" consists of

Reviewer comments:
These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.

Revised text:
The security model takes the following form:  <ins> A server is created that runs "ServerSetup" and broadcasts the </ins> "ServerUpdate" message "s_update".  <ins> The adversary runs "ClientSetup" on "s_update". </ins> The adversary specifies a number "Q" of issuance phases to initiate with the server, where each phase "i in 1..Q" consists of
Original text:
encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash algorithm and salt size.  The salt size MUST match the output size of <del> the hash function associated with the public key and token type. </del>  Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide

Reviewer comments:
cc NAME NAME for an extra set of eyes to check me here -- ASN.1 is not my forte. I went based on the implementation , which I think matches what Frank did , but I would definitely appreciate confirmation!
Friendly bump NAME and NAME =)
Do you have a test vector / example to make sure it matches what I believe?
NAME yeah, each includes the encoded public key ().
Example, taken from the current test vector:
Looks good to me. But yeah, ASN.1 is not the most concise nor readable format.
ASN1 matches my expectations as well.
... we should make it clear, and provide test vectors to make sure it matches. The test vector could include public keys in PEM format and then print out the expected key ID.

Revised text:
encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash algorithm and salt size.  The salt size MUST match the output size of  <ins> the hash function associated with the public key and token type.  The parameters field for the digest used in the mask generation function and the digest being signed MUST be omitted. An example sequence of the SPKI object (in ASN.1 format) for a 2048-bit key is below: "$ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER 0:d=0 hl=4 l= 338 cons: SEQUENCE 4:d=1 hl=2 l= 61 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss 17:d=2 hl=2 l= 48 cons: SEQUENCE 19:d=3 hl=2 l= 13 cons: cont [ 0 ] 21:d=4 hl=2 l= 11 cons: SEQUENCE 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 34:d=3 hl=2 l= 26 cons: cont [ 1 ] 36:d=4 hl=2 l= 24 cons: SEQUENCE 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 49:d=5 hl=2 l= 11 cons: SEQUENCE 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 62:d=3 hl=2 l= 3 cons: cont [ 2 ] 64:d=4 hl=2 l= 1 prim: INTEGER :30 67:d=1 hl=4 l= 271 prim: BIT STRING " </ins> Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide
Original text:
<del> Privacy Pass: HTTP API draft-svaldez-pp-http-api-latest </del>  Abstract

Reviewer comments:
Also update URL with correct links
Looks reasonable. Once this lands we should see about hooking about the gh-pages generation and link to that.

Revised text:
 <ins> Privacy Pass HTTP API draft-ietf-privacypass-http-api-latest </ins> Abstract
Original text:
in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> [OPEN ISSUE: Handling of a=imageattr] </del> If the BUNDLE policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the BUNDLE policy is set to "balanced", and this is not the first m= section

Reviewer comments:
This LGTM. Actually, I thought I had written something like this :)
LGTM
Always remember to update both the offer and answer sections :)

Revised text:
in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC.  If the BUNDLE policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the BUNDLE policy is set to "balanced", and this is not the first m= section
Original text:
maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6. <del> If this m= section is for video media, an "a=imageattr" line, as specified in sec.imageattr. </del>  If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line

Reviewer comments:
This LGTM. Actually, I thought I had written something like this :)
LGTM
Always remember to update both the offer and answer sections :)

Revised text:
maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6.  <ins> If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line
Original text:
section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> [OPEN ISSUE: Handling of a=imageattr] </del> If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to exactly match the

Reviewer comments:
This LGTM. Actually, I thought I had written something like this :)
LGTM
Always remember to update both the offer and answer sections :)

Revised text:
section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC.  If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to exactly match the
Original text:
Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as <del> described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </del>  Each "a=mid" line MUST stay the same.

Reviewer comments:
LGTM
lgtm
The question has come up about what the default candidate should be set to during trickle ICE but after at least one candidate has been gathered so at least in principle you could set c= to one of those candidates. See also; URL
Want to pick a solution that works even if we we do continous trickle and ice does not finish.
Consensus on today's call is: Before ICE is completed, follow the 5245 guidance and pick the "best" candidate. Once ICE is completed, pick whatever you are actually using.
If we move to a mode where ICE never completes, perhaps use the active pair.
It turns out that this was pretty clear already. I have made it slightly clearer.

Revised text:
Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as  <ins> described in RFC5245, Section 4.3.  If ICE checking has already completed for one or more candidate pairs and a candidate pair is in active use, then that pair MUST be used, even if ICE has not yet completed.  Note that this differs from the guidance in RFC5245, Section 9.1.2.2, which only refers to offers created when ICE has completed.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </ins> Each "a=mid" line MUST stay the same.
Original text:
For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending <del> media as specified in RFC3890.  If a "TIAS" value is not </del>  present, but an "AS" value is specified, generate a "TIAS" value using this formula:

Reviewer comments:
and
I tweaked this a bit, nothing major. LGTM.
For CT without AS, probably want to just tell the congestion control to stay below CT. For CT where AS is specified, do the same, but limit any streams with AS to the indicated value (in addition to total limit).
This should go into the handling-a-remote-description section.

Revised text:
For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending  <ins> media, as specified in RFC3890.  If a "TIAS" value is not </ins> present, but an "AS" value is specified, generate a "TIAS" value using this formula:
Original text:
to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS".  Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined. <del> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2. </del> [TODO: handling of CN, telephone-event, "red"] If the media section if of type audio:

Reviewer comments:
and
I tweaked this a bit, nothing major. LGTM.
For CT without AS, probably want to just tell the congestion control to stay below CT. For CT where AS is specified, do the same, but limit any streams with AS to the indicated value (in addition to total limit).
This should go into the handling-a-remote-description section.

Revised text:
to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". <ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2. </ins> Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined.  [TODO: handling of CN, telephone-event, "red"] If the media section if of type audio:
Original text:
following restriction: The fields of the "o=" line MUST stay the same except for the <del> <session-version> field, which MUST increment if the session description changes in any way, including the addition of ICE candidates. </del>  If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the

Reviewer comments:
From meeting minutes "SDP o= line increment [] While the proposed solution on the slide was accepted, it was noted that the proposal on the slide goes against what was agreed at last meeting. Emil Ivov also commented that Trickle ICE for SIP does exactly what is described on the slide. Jonathan Lennox said that we should make sure this is compatible with whatever is done in trickle ICE SIP stacks."
This algorithm becomes correct once we decide to not allow o= modification. Editorial comments follow.
Discussion in-room: 1) add example to make it clear that there is a separate counter (other than current o=) which is what increments. 2) change text about &lt;session-version&gt; to be more of a "note that" for an edge case, as opposed to normative text about a mainline case.
Updated this branch. PTAL
LGTM
2349: "might differ" is creepy. "differs" perhaps. 2359: "N + 2" -> must be greater than N + 1 This is basically OK modulo the above

Revised text:
following restriction: The fields of the "o=" line MUST stay the same except for the  <ins> <session-version> field, which MUST increment by one on each call to createOffer if the offer might differ from the output of the previous call to createOffer; implementations MAY opt to increment <session-version> on every call.  The value of the generated <session-version> is independent of the <session-version> of the current local description; in particular, in the case where the current version is N, an offer is created with version N+1, and then that offer is rolled back so that the current version is again N, the next generated offer will still have version N+2. Note that if the application creates an offer by reading currentLocalDescription instead of calling createOffer, the returned SDP may be different than when setLocalDescription was originally called, due to the addition of gathered ICE candidates, but the <session-version> will not have changed.  There are no known scenarios in which this causes problems, but if this is a concern, the solution is simply to use createOffer to ensure a unique <session-version>. </ins> If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the
Original text:
all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints.  When acting as answerer, if there if no bundle group in the offer, the implementation will reject all but the first m= section. </del>  As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST

Reviewer comments:
NAME NAME PTAL
From Berlin: "A clarification to that rule was found when an offer is received with some m= lines bundled and some not; you accept all m= lines that are possible to bundle with the first m= line. "
I think we'll also have to update section 5.3.1 (Initial Answers) where it lists conditions for rejecting an m= section. Also, do we need to make similar modifications for the "balanced" bundle policy? LG with nits

Revised text:
all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy  <ins> endpoints.  When acting as answerer, the implementation will reject any m= sections other than the first m= section, unless they are in the same bundle group as that m= section. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST
Original text:
No supported codec is present in the offer. <del> The bundle policy is "max-bundle", the m= section is not in a bundle group, and this is not the first m= section. </del>  <del> The bundle policy is "balanced", the m= section is not in a bundle group, and this is not the first m= section for this media type. </del>  The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.

Reviewer comments:
NAME NAME PTAL
From Berlin: "A clarification to that rule was found when an offer is received with some m= lines bundled and some not; you accept all m= lines that are possible to bundle with the first m= line. "
I think we'll also have to update section 5.3.1 (Initial Answers) where it lists conditions for rejecting an m= section. Also, do we need to make similar modifications for the "balanced" bundle policy? LG with nits

Revised text:
No supported codec is present in the offer.  <ins> The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section. </ins>  <ins> The bundle policy is "balanced", and this is not the first m= section for this media type or in the same bundle group as the first m= section for this media type. </ins> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.
Original text:
The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates.  The size <del> of the ICE candidate pool can also be set, if desired; by default the candidate pool size is zero.  [[OPEN ISSUE: this is an inconsistency with the W3C spec https://github.com/rtcweb-wg/jsep/issues/12.]] </del>  In addition, the application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-

Reviewer comments:
Looks good to me
JSEP says: S 4.1.1. " The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates. The size of the ICE candidate pool can also be set, if desired; by default the candidate pool size is zero." The WebRTC spec says: "At this point the ICE Agent does not know how many ICE components it needs (and hence the number of candidates to gather), but it can make a reasonable assumption such as 2. As the RTCPeerConnection object gets more information, the ICE Agent can adjust the number of components"
Imagine 4 is more realistic.
so default in not defined but their is way for the JS to to set the default for a PC
Discussed in DC: default will be unspecified and left up to browsers, there will need to be a setting for applications to override this default.
w3c bug is URL

Revised text:
The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates.  The size  <ins> of the ICE candidate pool can also be set, if desired.  If the application does not indicate a candidate pool size, the browser may select any default candidate pool size. </ins> In addition, the application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-