jiebi/TextFlow huggingface dataset:
Original text:
1. Censorship is where an entity in a position of power - such as a <del> government, organization, or individual - supresses communication </del>  that it considers objectionable, harmful, sensitive, politically incorrect or inconvenient.  (While censors that engage in censorship or establish censorship regimes must do so through legal, military,

Reviewer comments:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Revised text:
1. Censorship is where an entity in a position of power - such as a  <ins> government, organization, or individual - suppresses communication </ins> that it considers objectionable, harmful, sensitive, politically incorrect or inconvenient.  (While censors that engage in censorship or establish censorship regimes must do so through legal, military,
Original text:
interference.  Prescription is the process by which censors determine what types of material they should block, i.e. they decide to block a list of pornographic websites.  Identification is the process by <del> which censors classify specific traffic to be blocked or impaird, </del>  i.e. the censor blocks or impairs all webpages containing "sex" in the title or traffic to sex.com.  Interference is the process by which the censor intercedes in communication and prevents access to

Reviewer comments:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Revised text:
interference.  Prescription is the process by which censors determine what types of material they should block, i.e. they decide to block a list of pornographic websites.  Identification is the process by  <ins> which censors classify specific traffic to be blocked or impaired, </ins> i.e. the censor blocks or impairs all webpages containing "sex" in the title or traffic to sex.com.  Interference is the process by which the censor intercedes in communication and prevents access to
Original text:
4.1.  Packet dropping is a simple mechanism to prevent undesirable traffic. The censor identifies undesirable traffic and chooses to not properly forward any packets it sees associated with the traversing

Reviewer comments:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Revised text:
4.1. <ins> While other interference techniques outlined in this section mostly focus on blocking or preventing access to content, it can be an effective censorship strategy in some cases to not entirely block access to a given destination, or service but instead degrade the performance of the relevant network connection.  The resulting user experience for a site or service under performance degradation can be so bad that users opt to use a different site, service, or method of communication, or may not engage in communication at all if there are no alternatives.  Traffic shaping techniques that rate-limit the bandwidth available to certain types of traffic is one example of a performance degradation. Trade offs: While implementing a performance degradation will not always eliminate the ability of people to access a desire resource, it may force them to use other means of communication where censorship (or surveillance) is more easily accomplished. Empirical examples: Iran is known to shape the bandwidth available to HTTPS traffic to encourage unencrypted HTTP traffic Aryan-2012. 4.2. </ins> Packet dropping is a simple mechanism to prevent undesirable traffic. The censor identifies undesirable traffic and chooses to not properly forward any packets it sees associated with the traversing
Original text:
uses Packet Dropping as the mechanisms for throttling SSH Aryan-2012. These are but two examples of a ubiquitous censorship practice. <del> 4.2. </del>  Packet injection, generally, refers to a man-in-the-middle (MITM) network interference technique that spoofs packets in an established

Reviewer comments:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Revised text:
uses Packet Dropping as the mechanisms for throttling SSH Aryan-2012. These are but two examples of a ubiquitous censorship practice.  <ins> 4.3. </ins> Packet injection, generally, refers to a man-in-the-middle (MITM) network interference technique that spoofs packets in an established
Original text:
interference is especially evident in the interruption of encrypted/ obfuscated protocols, such as those used by Tor Winter-2012. <del> 4.3. </del>  There are a variety of mechanisms that censors can use to block or filter access to content by altering responses from the DNS

Reviewer comments:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Revised text:
interference is especially evident in the interruption of encrypted/ obfuscated protocols, such as those used by Tor Winter-2012.  <ins> 4.4. </ins> There are a variety of mechanisms that censors can use to block or filter access to content by altering responses from the DNS
Original text:
TLDs as well, but only Iran has acted by blocking all Israeli (.il) domains Albert-2011. <del> 4.4. </del>  Distributed Denial of Service attacks are a common attack mechanism used by "hacktivists" and black-hat hackers, but censors have used

Reviewer comments:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Revised text:
TLDs as well, but only Iran has acted by blocking all Israeli (.il) domains Albert-2011.  <ins> 4.5. </ins> Distributed Denial of Service attacks are a common attack mechanism used by "hacktivists" and black-hat hackers, but censors have used
Original text:
comandeered those user agents to send DDoS traffic to various sites Marczak-2015. <del> 4.5. </del>  While it is perhaps the crudest of all censorship techniques, there is no more effective way of making sure undesirable information isn't

Reviewer comments:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Revised text:
comandeered those user agents to send DDoS traffic to various sites Marczak-2015.  <ins> 4.6. </ins> While it is perhaps the crudest of all censorship techniques, there is no more effective way of making sure undesirable information isn't
Original text:
can be physically seized or the hosting provider can be required to prevent access Anderson-2011.  7. This document benefited from discussions with Stephane Bortzmeyer,

Reviewer comments:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Revised text:
can be physically seized or the hosting provider can be required to prevent access Anderson-2011. <ins> 6.4. In some countries, legal mechanisms exist where an individual can issue a legal request to a content host that requires the host to take down content.  Examples include the voluntary systems employed by companies like Google to comply with "Right to be Forgotten" policies in the European Union Google-RTBF and the copyright-oriented notice and takedown regime of the United States Digital Millennium Copyright Act (DMCA) Section 512 DMLP-512. </ins> 7. This document benefited from discussions with Stephane Bortzmeyer,
Original text:
13.2. <del> In cases where ICE is used to establish some kind of session that is not real time, and has no fixed rate associated with it that is known to work on the network in which ICE is deployed, Ta and RTO revert to more conservative values.  Ta SHOULD be configurable, SHOULD have a default of 500 ms, and MUST NOT be configurable to be less than 500 ms. </del>  <del> If other Ta value than the default is used, the agent MUST indicate the value it prefers to use in the ICE exchange.  Both agents MUST use the higher out of the two proposed values. </del>  <del> In addition, the retransmission timer for the STUN transactions, RTO, SHOULD be configurable and during the gathering phase, SHOULD have a default of: </del>  <del> where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers. </del>  <del> For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of: </del>  14.

Reviewer comments:
Ta and RTO settings are now the same for real-time media and non-real-time media. An appendix has been added, showing bandwidth consumption based on different values, and different ufrag value sizes.

Revised text:
13.2.  <ins> ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media. ICE agents MUST NOT use a Ta value smaller than 5 ms. If an ICE agent wants to use another Ta value than the default value, the agent MUST indicate the proposed value to its peer during the ICE exchange.  Both agents MUST use the higher value of the proposed values.  If an agent does not propose a value, the default value is used for that agent when comparing which value is higher. NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values. </ins>  <ins> 13.3. </ins>  <ins> During the ICE gathering phase, ICE agents SHOULD calculate the RTO value using the following formula: </ins>  <ins> For connectivity checks, ICE agents SHOULD calculate the RTO value using the following formula: </ins>  <ins> ICE agents MAY calculate the RTO value using other mechanisms than those described above.  ICE agents MUST NOT use a RTO value smaller than 500 ms. </ins> 14.
Original text:
In order to limit the attacks described in sec-ice-hammer, an ICE agent MUST limit the total number of connectivity checks the agent <del> performs across all check lists to a specific value, and this value MUST be configurable.  A default of 100 is RECOMMENDED.  This limit is enforced by discarding the lower-priority candidate pairs until there are less than 100.  It is RECOMMENDED that a lower value be utilized when possible, set to the maximum number of plausible checks that might be seen in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </del>  6.1.2.6.

Reviewer comments:
The following issues are addressed in this commit: URL URL
LGTM
To prevent one check list from starving.
This was discussed (and, as far as I am concerned, agreed) on the list 1st June. But, it's good to have a reminder :)
This one has not been addressed as far as I can tell. Now we get to decided if it's important enough or not to do something about :)
I had a look at this, but for some reason it never got implemented. I think it should be an easy fix.
The changes section looks very small compared to how many changes we've made, so it definitely needs updating. Now we need to decide whether we have to update it before or after requesting publication.
Yes - we just have to remember everything :) However, I don't think we should go into details: the major changes (that I can think of when writing this) are removal of regular/aggressive nomination, and the changes related to "Emil's table".
LGTM

Revised text:
In order to limit the attacks described in sec-ice-hammer, an ICE agent MUST limit the total number of connectivity checks the agent  <ins> performs across all check lists in the check list set.  This is done by limiting the total number of candidate pairs in the check list set.  The default limit of candidate pairs for the check list set is 100, but the value MUST be configurable.  The limit is enforced by, within in each check list, discarding lower-priority candidate pairs until the total number of candidate pairs in the check list set is smaller than the limit value.  The discarding SHOULD be done evenly so that the number of candidate pairs in each check list is reduced the same amount. It is RECOMMENDED that a lower limit value than the default is picked when possible, and that the value is set to the maximum number of plausible candidate pairs that might be created in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </ins> 6.1.2.6.
Original text:
22. <del> Following is the list of changes from RFC 5245 </del>  <del> The specification was generalized to be more usable with any protocol and the parts that are specific to SIP and SDP were moved to a SIP/SDP usage document I-D.ietf-mmusic-ice-sip-sdp. </del>  <del> Default candidates, multiple components, ICE mismatch detection, subsequent offer/answer, and role conflict resolution were made optional since they are not needed with every protocol using ICE. </del>  <del> With IPv6, the precedence rules of RFC 6724 are used instead of the obsoleted RFC 3483 and using address preferences provided by the host operating system is recommended. </del>  <del> Candidate gathering rules regarding loopback addresses and IPv6 addresses were clarified. </del> 

Reviewer comments:
The following issues are addressed in this commit: URL URL
LGTM
To prevent one check list from starving.
This was discussed (and, as far as I am concerned, agreed) on the list 1st June. But, it's good to have a reminder :)
This one has not been addressed as far as I can tell. Now we get to decided if it's important enough or not to do something about :)
I had a look at this, but for some reason it never got implemented. I think it should be an easy fix.
The changes section looks very small compared to how many changes we've made, so it definitely needs updating. Now we need to decide whether we have to update it before or after requesting publication.
Yes - we just have to remember everything :) However, I don't think we should go into details: the major changes (that I can think of when writing this) are removal of regular/aggressive nomination, and the changes related to "Emil's table".
LGTM

Revised text:
22.  <ins> The purpose of this updated ICE specification is to: </ins>  <ins> Clarify procedures in RFC 5245. </ins>  <ins> Make technical changes, due to discovered flows in RFC 5245 and based on feedback from the community that has implemented and deployed ICE applications based on RFC 5245. </ins>  <ins> Make the procedures signaling protocol independent, by removing the SIP and SDP procedures.  Procedures specific to a signaling protocol will be defined in separate usage documents.  I-D.ietf- mmusic-ice-sip-sdp defines the ICE usage with SIP and SDP. </ins>  <ins> The following technical changes have been done: Aggressive nomination removed. The procedures for calculating candidate pair states and scheduling connectivity checks modified. Procedures for calculation of Ta and RTO modified. Active check list and frozen check list definitions removed. 'ice2' ice option added. IPv6 considerations modified. Usage with no-op for keepalives, and keepalives with non-ICE peers, removed. </ins>
Original text:
identification systems (such as is served by telephone numbers or email addresses in other communications systems). <del> Development of The Universal Solution has proved hard, however, for all the usual reasons. </del>  The last few years have also seen a new platform rise for deployment of services: The browser-embedded application, or "Web application".

Reviewer comments:
Made changes to address Warren's first and third, but not 2nd nit. I'm unsure whether the changes in the spacing I introduced will fix the odd spacing in Olle's name.
Warren noted the following nits in his ballot: 1: "Development of The Universal Solution has proved hard, however, for all the usual reasons." -- this is cute, but leaves people wondering what "all the usual reasons are". Perhaps just "Development of The Universal Solution has, however, proved hard." (or just cut after the "however in the original"). 2: I'm not sure why you have "Protocol" in the terminology section. It doesn't seem like it is useful for the document, and this document doesn't seem like the right place to (re) define it. 3: Acknowledgements: Funny spacing in "Olle E. Johansson

Revised text:
identification systems (such as is served by telephone numbers or email addresses in other communications systems).  <ins> Development of The Universal Solution has, however, proved hard. </ins> The last few years have also seen a new platform rise for deployment of services: The browser-embedded application, or "Web application".
Original text:
entities that handle the data, but do not modify it (such as TURN relays). <del> It includes necessary functions for congestion control: When not to send data. </del>  WebRTC endpoints MUST implement the transport protocols described in I-D.ietf-rtcweb-transports.

Reviewer comments:
Spencer had the following comment: I'm not sure how tutorial you want section 4 to be, but I'd at least mention appropriate retransmission and in-order delivery, in addition to congestion control, since you get that with SCTP on the data channel.

Revised text:
entities that handle the data, but do not modify it (such as TURN relays).  <ins> It includes necessary functions for congestion control, retransmission, and in-order delivery. </ins> WebRTC endpoints MUST implement the transport protocols described in I-D.ietf-rtcweb-transports.
Original text:
multiple data channels between them. An implementation of the Interactive Connectivity Establishment <del> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </del>  Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another

Reviewer comments:
EKR entered the following DISCUSS: Your citation to ICE is to 5245-bis, but at least the JSEP editor consensus was that WebRTC depended on 5245, so this needs to be resolved one way or the other.
Sean asked me to leave this one open. Personally, I'd somewhat prefer to 5245bis because it separates out the SDP machinery, but JSEP has a specific section reference (section 15.4) that has to go to either 5245 or to mmusic-ice-sip-sdp, and one could argue that we need to pull in -sip-sdp here too. I'm OK with 5245 as a reference, but will let the chairs make the call.
I no longer care about this distinction.

Revised text:
multiple data channels between them. An implementation of the Interactive Connectivity Establishment  <ins> (ICE) RFC5245 protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </ins> Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another