jiebi/TextFlow huggingface dataset:
Original text:
3. <del> A Working Group Chairs are responsible for determining how to best </del>  accomplish the Charter in an open and transparent fashion.  The Working Group Chairs are responsible for determining if there is interest in using GitHub and making a consensus call to determine if <del> a the proposed policy and use is acceptable. </del>  <del> Chairs MUST involve Area Directors any decision to use GitHub for anything more than managing of drafts. </del>  While a document editor can still use GitHub independently for documents that they edit, even if the working group does not

Reviewer comments:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Revised text:
3.  <ins> Working Group Chairs are responsible for determining how to best </ins> accomplish the Charter in an open and transparent fashion.  The Working Group Chairs are responsible for determining if there is interest in using GitHub and making a consensus call to determine if  <ins> the proposed policy and use is acceptable. </ins>  <ins> Chairs MUST involve Area Directors in any decision to use GitHub for anything more than managing drafts. </ins> While a document editor can still use GitHub independently for documents that they edit, even if the working group does not
Original text:
multiple documents. Maintaining multiple documents in the same repository can add <del> overheads that negatively affect individual documents.  For instance, </del>  issues might require additional markings to identify the document that they affect.  Also, because editors all have write access to the repository, managing the set of people with write access to a larger

Reviewer comments:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Revised text:
multiple documents. Maintaining multiple documents in the same repository can add  <ins> overhead that negatively affects individual documents.  For instance, </ins> issues might require additional markings to identify the document that they affect.  Also, because editors all have write access to the repository, managing the set of people with write access to a larger
Original text:
One common practice is to use these continuous integration services to build a text or HTML version of a document.  This is then published to GitHub Pages, which allows users to view a version of <del> the most recent revision of a document.  Including prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </del>  Continuous integration can also validate pull requests and other changes for errors.  The most basic check is whether the source file <del> can be transformed successful into a valid Internet-Draft.  For </del>  example, this might include checking that XML source is syntactically correct. <del> For documents that use formal languages a part of specifications, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </del>  8.

Reviewer comments:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Revised text:
One common practice is to use these continuous integration services to build a text or HTML version of a document.  This is then published to GitHub Pages, which allows users to view a version of  <ins> the most recent revision of a document.  Including a prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </ins> Continuous integration can also validate pull requests and other changes for errors.  The most basic check is whether the source file  <ins> can be transformed successfully into a valid Internet-Draft.  For </ins> example, this might include checking that XML source is syntactically correct.  <ins> For a document that use formal languages as part of the specification, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </ins> 8.
Original text:
If a contributor makes a comment that raises what you believe to be a new issue, create an issue for them.  If the issue has an obvious solution, consider creating a pull request.  It doesn't matter what <del> venue the issue was raised in, email, issue discussion, a pull request review, capturing issues quickly ensures that problems become visible and can be tracked. </del>  This takes a little more effort, but these simple steps can help encourage contributions, which will ultimately improve the quality of

Reviewer comments:
A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara

Revised text:
If a contributor makes a comment that raises what you believe to be a new issue, create an issue for them.  If the issue has an obvious solution, consider creating a pull request.  It doesn't matter what  <ins> venue the issue was raised in (e.g., email, issue discussion, a pull request review); capturing issues quickly ensures that problems become visible and can be tracked. </ins> This takes a little more effort, but these simple steps can help encourage contributions, which will ultimately improve the quality of
Original text:
Group will rely upon.  features contains a more thorough discussion on the different features that can be used. <del> Once a document is published in a repository on GitHub, many features like pull requests, issue tracking or the wiki can be individually disabled.  If specific features are not used by the Working Group in the development of the document, disabling those features avoids creating confusion in the wider community about what can be used. </del> 3.2. Working Group Chairs that decide to use GitHub MUST inform their

Reviewer comments:
Two changes, two issues, but really this is the one idea. The previous draft said that features not used could be disabled. This is bad advice because that might be denying editors access to tools that would make their task easier. The new advice says that editors can use features that the working group doesn't rely on. It also says that chairs should consult editors to ensure that policies aren't adversely affecting them.
Most of the operating modes assume that editors are given considerable latitude in how repositories are managed. This is good up until the point that the Working Group starts to formally rely on things that are in the respository. The document sort of prevaricates about this point, including strong admonitions that suggest rules be formalized for every aspect of usage. Instead, I think that it would be better if the document said - up-front - that editors are to be given control unless the Working Group starts to formally depend on a particular function (like issue opening/closing, labels, pull requests, whatever...). At that point, it is the chair's responsibility to identify what the WG depends on and to clearly articulate the policies around that usage.
Section 3.1 talks about turning off GitHub features not being used by the WG, but it doesn't say how to do that in the UI. I ask this because I cannot see a way to prevent issues or PRs just by wandering through the GUI.
This isn't something that I'd want to publish. The way that features are configured is too tightly coupled to UX decisions that GitHub might remake and any point. In fact, I might prefer not to include the offending text at all. Disabling features can be a useful way to slim down the options presented to users (which can help new users), but it can also be fairly hostile to new contributors. For instance, if the working group disables issues because they aren't using them, it sounds reasonable, but new contributors might then be dissuaded from opening a genuine issue. Working groups might be better served by informally letting contributors know how to best provide their input.
I'm happy with either the current text plus "At the time this is written, to turn of y" or removing the suggestion.

Revised text:
Group will rely upon.  features contains a more thorough discussion on the different features that can be used.  3.2. Working Group Chairs that decide to use GitHub MUST inform their
Original text:
sufficient, though it might be helpful to occasionally remind new contributors of these guidelines. <del> A choice to use GitHub is similar to the formation of a design team (see Section 6.5 of RFC2418) provided that the work uses a public repository.  That is, the output of any activity using GitHub needs to be taken to the Working Group mailing list and subject to approval, rejection, or modification by the Working Group as with any other input. </del> Working Group Chairs are responsible for ensuring that any policy they adopt is enforced and maintained.

Reviewer comments:
This is the way we've been treating this, so let's acknowledge that.
As I noted on the list, I don't think this is correct. I proposed alternate text.
Still LGTM. :-)

Revised text:
sufficient, though it might be helpful to occasionally remind new contributors of these guidelines.  Working Group Chairs are responsible for ensuring that any policy they adopt is enforced and maintained.
Original text:
documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes.  3.2. New repositories can be created within the Working Group organization

Reviewer comments:
This is the way we've been treating this, so let's acknowledge that.
As I noted on the list, I don't think this is correct. I proposed alternate text.
Still LGTM. :-)

Revised text:
documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. <ins> Work done in GitHub has no special status.  The output of any activity using GitHub needs to be taken to the Working Group and is subject to approval, rejection, or modification by the Working Group as with any other input. </ins> 3.2. New repositories can be created within the Working Group organization
Original text:
discovered.  Such elements may include classes of data, major roles, and role interactions.  This scenario also informs protocol and data model development in support of vulnerability assessment, as part of <del> overall posture assessment.  Vulnerability discovery, disclosure, and publication is out of scope. </del>  2.

Reviewer comments:
We should review the appendices and include the appropriate references to them through the main body of the document.

Revised text:
discovered.  Such elements may include classes of data, major roles, and role interactions.  This scenario also informs protocol and data model development in support of vulnerability assessment, as part of  <ins> overall posture assessment (see implementation-examples for examples of solutions that support this scenario). Vulnerability discovery, disclosure, publication, and prioritization is out of scope.  However, given the importance of prioritization in an enterprise's vulnerability assessment process, it is discussed in priority. Information on how the scenario aligns with SACM and other existing work is discussed in sacm-usage-scenarios through alignment-with- other-existing-works. </ins> 2.
Original text:
data, and vulnerability assessment results. The enterprise has a procedure for reassessment of endpoints at <del> some point after initial assessment. </del>  4.

Reviewer comments:
We should review the appendices and include the appropriate references to them through the main body of the document.

Revised text:
data, and vulnerability assessment results. The enterprise has a procedure for reassessment of endpoints at  <ins> some point after initial assessment (see continuous-vulnerability- assessment for more information). </ins> 4.
Original text:
performed on an ongoing basis, resulting in routine, or even event- driven, collection of basic endpoint information. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del>  4.2.

Reviewer comments:
We should review the appendices and include the appropriate references to them through the main body of the document.

Revised text:
performed on an ongoing basis, resulting in routine, or even event- driven, collection of basic endpoint information.  <ins> See data-attribute-table for information-specific details. </ins> 4.2.
Original text:
processing of vulnerability description data is expected to trigger the vulnerability assessment. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del>  5.

Reviewer comments:
We should review the appendices and include the appropriate references to them through the main body of the document.

Revised text:
processing of vulnerability description data is expected to trigger the vulnerability assessment.  <ins> See data-attribute-table for information-specific details. </ins> 5.
Original text:
capability can be pushed to the vulnerability assessment capability by the endpoint whenever that information changes. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del>  6.

Reviewer comments:
We should review the appendices and include the appropriate references to them through the main body of the document.

Revised text:
capability can be pushed to the vulnerability assessment capability by the endpoint whenever that information changes.  <ins> See data-attribute-table for information-specific details. </ins> 6.
Original text:
with sufficient context, so that appropriate action can be taken. Vulnerability assessment results are ideally stored for later use. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del>  7.

Reviewer comments:
We should review the appendices and include the appropriate references to them through the main body of the document.

Revised text:
with sufficient context, so that appropriate action can be taken. Vulnerability assessment results are ideally stored for later use.  <ins> See data-attribute-table for information-specific details. </ins> 7.
Original text:
Push services might need to limit the size and number of stored push messages to avoid overloading.  In addition to using the 413 (Payload Too Large) status code for too large push messages, a push service <del> MAY expire push messages prior to any advertised expiration time. </del>  7.3.

Reviewer comments:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

Revised text:
Push services might need to limit the size and number of stored push messages to avoid overloading.  In addition to using the 413 (Payload Too Large) status code for too large push messages, a push service  <ins> MAY expire push messages prior to any advertised expiration time.  A push service can reduce the impact push message retention by reducing the time-to-live of push messages. </ins> 7.3.
Original text:
9.  This document registers three URNs for use in identifying link relation types.  These are added to a new "Web Push Identifiers" registry according to the procedures in Section 4 of RFC3553; the

Reviewer comments:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

Revised text:
9. <ins> This protocol defines new HTTP header fields in iana.header.fields. New link relation types are identified using the URNs defined in iana.urns. 9.1. HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message- headers/>. This document defines the following HTTP header fields, so their associated registry entries shall be added according to the permanent registrations below (see RFC3864): The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 9.2. </ins> This document registers three URNs for use in identifying link relation types.  These are added to a new "Web Push Identifiers" registry according to the procedures in Section 4 of RFC3553; the
Original text:
(this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del>  urn:ietf:params:push:reg

Reviewer comments:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

Revised text:
(this document)  <ins> The Web Push WG (webpush@ietf.org) </ins> urn:ietf:params:push:reg