jiebi/TextFlow huggingface dataset:
Original text:
to know where to get these security statements from producers and third-parties related to the software product in a timely and <del> unambiguous fashion, </del>  <del> how to attribute them to an authoritative issuer, </del>  how to associate the statements in a meaningful manner via a set <del> of well-known semantic relationships, and </del>  how to consistently, efficiently, and homogeneously check their <del> authenticity. </del>  There is no standardized way to: <del> know the various sources of statements, </del>  <del> how to express the provenance and historicity of statements, </del>  how to related/link various heterogeneous statements in a simple <del> fashion, and </del>  check that the statement comes from a source with authority to <del> issue that statement. </del>  3.4.

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
to know where to get these security statements from producers and third-parties related to the software product in a timely and  <ins> unambiguous fashion </ins>  <ins> how to attribute them to an authoritative issuer </ins> how to associate the statements in a meaningful manner via a set  <ins> of well-known semantic relationships </ins> how to consistently, efficiently, and homogeneously check their  <ins> authenticity </ins> There is no standardized way to:  <ins> know the various sources of statements </ins>  <ins> how to express the provenance and historicity of statements </ins> how to related/link various heterogeneous statements in a simple  <ins> fashion </ins> check that the statement comes from a source with authority to  <ins> issue that statement </ins> 3.4.
Original text:
A consumer of a released software wants: to understand if a particular provider is actually the original <del> provider or a promoter, </del>  to know if and how the source, or resulting binary, of a promoted <del> software component differs from the original software component, </del>  to check the provenance and history of a software component's <del> source back to its origin, and </del>  <del> to assess whether to trust a promoter or not. </del>  There is no standardized way to:

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
A consumer of a released software wants: to understand if a particular provider is actually the original  <ins> provider or a promoter </ins> to know if and how the source, or resulting binary, of a promoted  <ins> software component differs from the original software component </ins> to check the provenance and history of a software component's  <ins> source back to its origin </ins>  <ins> to assess whether to trust a promoter or not </ins> There is no standardized way to:
Original text:
artifact against a Reference Integrity Manifest (RIM).  Corresponding procedures are often called authenticated, measured, or secure boot. The output of these high assurance boot procedures is often used as <del> input to more complex verification known as remote attestation </del>  procedures. If measurements before execution are not possible, static after-the-

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
artifact against a Reference Integrity Manifest (RIM).  Corresponding procedures are often called authenticated, measured, or secure boot. The output of these high assurance boot procedures is often used as  <ins> input to more complex verifications known as remote attestation </ins> procedures. If measurements before execution are not possible, static after-the-
Original text:
acquisition and deployment of software in certain security domains of the organization, a check of software quality and characteristics must succeed.  Compliance and requirement checking includes audits of <del> the results of organisational procedures and technical procedures, </del>  which can originate from checks conducted by the organization itself or checks conducted by trusted third parties.  Consecutively, <del> consumers of statements about a released software can be auditors. Examples of procedure results important to audits include: available fresh and applicable code reviews, certification documents (e.g., FIPS or Common Criteria), virus scans, vulnerability disclosure reports (fixed or not fixed), security impact or applicability justification statements.  Relevant compliance, requirement, and check result documents originate from various sources and include a wide range of representations and formats. </del>  A consumer of a released software wants:

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
acquisition and deployment of software in certain security domains of the organization, a check of software quality and characteristics must succeed.  Compliance and requirement checking includes audits of  <ins> the results of organizational procedures and technical procedures, </ins> which can originate from checks conducted by the organization itself or checks conducted by trusted third parties.  Consecutively,  <ins> consumers of statements about released software can be auditors. Examples of procedure results important to audits include: available fresh and applicable code reviews certification documents (e.g., FIPS or Common Criteria) virus scans vulnerability disclosure reports (fixed or not fixed) security impact or applicability justification statements Relevant compliance, requirement, and check result documents originate from various sources and include a wide range of representations and formats. </ins> A consumer of a released software wants:
Original text:
compromised due to an insider risk - be it malicious or otherwise to confirm that the publishers know if their deliverable has been <del> compromised.  Can they trust their key protection or audit logging? </del>  to know how the update client on an instance of a health monitoring system discerns a general update from one specially

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
compromised due to an insider risk - be it malicious or otherwise to confirm that the publishers know if their deliverable has been  <ins> compromised.  (For example, can they trust their key protection or audit logging?) </ins> to know how the update client on an instance of a health monitoring system discerns a general update from one specially
Original text:
of firmware revisions to verify that the firmware update seen by a single device, is <del> indeed the same as seen by all the devices. </del>  reliably discern an update that has been signed by the appropriate and intended signing identity make an informed judgement on all available information about <del> firmware at the install time.  For example, the firmware is still in a good state or otherwise? </del>  3.9. Software Integration is a complex activity.  This typically involves <del> getting various software components from multiple suppliers and </del>  producing an integrated package deployed as part of device assembly. For example, car manufacturers source integrated software for their autonomous vehicles from third parties that integrates software components from various sources.  Integration complexity creates a higher risk of security vulnerabilities to the delivered software. <del> Consumer of an integrated software wants: </del>  all components presents in a software product listed, and the ability to identify and retrieve them from a secure and tamper-

Reviewer comments:
Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.

Revised text:
of firmware revisions to verify that the firmware update seen by a single device, is  <ins> indeed the same as seen by all the devices </ins> reliably discern an update that has been signed by the appropriate and intended signing identity make an informed judgement on all available information about  <ins> firmware at the install time.  (For example, the firmware is still in a good state or otherwise?) </ins> 3.9. Software Integration is a complex activity.  This typically involves  <ins> getting various software components from multiple suppliers, </ins> producing an integrated package deployed as part of device assembly. For example, car manufacturers source integrated software for their autonomous vehicles from third parties that integrates software components from various sources.  Integration complexity creates a higher risk of security vulnerabilities to the delivered software.  <ins> Consumers of an integrated software wants: </ins> all components presents in a software product listed, and the ability to identify and retrieve them from a secure and tamper-
Original text:
security scans of running software provide valid annotations on build integrity to ensure conformance 

Reviewer comments:
Provides baseline discussion for clarifying . See
Minor nits and there is no paragraph/subsection included in the proposed use case

Revised text:
security scans of running software provide valid annotations on build integrity to ensure conformance <ins> 3.10. Software producers often have multiple and concurrent supported versions of a product.  The versions may represent major feature or compatibility differentiating releases (1.0, 2.0), or implementations for different Operating System Platforms and Architectures (Linux, Mac, Windows, AMD, ARM, x86, x64). For each release, the software producer must be capable of providing statements, unique to that version.  Producers may provide free patching to a specific version the consumer has purchased, while requiring upgrades to newer major releases.  Consumers need to know which updates are compatible with their environment.  Third parties that provide statements of quality need to know how to differentiate supported version bands, avoiding the recommendation to upgrade to an incompatible version. As versions age, and vulnerabilities are discovered, consumers need to know the newer version of a particular product.  Software producers implement versioning updates, however there are no standards for consumers and third parties to apply across software producers. Consumers and Producers want: a standard means to associate vulnerability information, statements of quality, statements of support and end of life (EOL) with a specific version of a product a standard means to identify a patched version, specific to their Operating System and Platform a standard means to differentiate major and minor version upgrades a standard means to provide concurrent versioned updates </ins>
Original text:
must succeed.  Compliance and requirement checking includes audits of the results of organizational procedures and technical procedures, which can originate from checks conducted by the organization itself <del> or checks conducted by trusted third parties.  Consecutively, </del>  consumers of statements about released software can be auditors. Examples of procedure results important to audits include:

Reviewer comments:
I believe this is a typo, but perhaps I misunderstood the intended meaning.
Good catch, NAME Thanks for the PR
LGTM

Revised text:
must succeed.  Compliance and requirement checking includes audits of the results of organizational procedures and technical procedures, which can originate from checks conducted by the organization itself  <ins> or checks conducted by trusted third parties.  Consequently, </ins> consumers of statements about released software can be auditors. Examples of procedure results important to audits include:
Original text:
host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected. <del> It may be noted that just as you can plug several home routers together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </del>  The goal of this document is to describe the minimal set of changes or behaviors required to use existing IETF specifications to support

Reviewer comments:
AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?

Revised text:
host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected.  <ins> It may be noted that just as you can plug several CPEs together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </ins> The goal of this document is to describe the minimal set of changes or behaviors required to use existing IETF specifications to support
Original text:
described in RFC4861. Support for adjacent infrastructure links on networks where Neighbor <del> Discovery is not supported are out of scope for this document.  Stub routers do not provide routing between adjacent infrastructure links when connected to more than one such link. </del>  5.1.

Reviewer comments:
AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?

Revised text:
described in RFC4861. Support for adjacent infrastructure links on networks where Neighbor  <ins> Discovery is not supported and is out of scope for this document. Stub routers do not provide routing between adjacent infrastructure links when connected to more than one such link. </ins> 5.1.
Original text:
A prefix is not considered a usable on-link prefix if it is advertised on the link as on-link, but the 'm' bit is set in the Router Advertisement message header (RFC4861) that contains the <del> Prefix option.  This indicates that node addressibility is being </del>  managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "usable"&#151;not all hosts can actually use it.

Reviewer comments:
AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?

Revised text:
A prefix is not considered a usable on-link prefix if it is advertised on the link as on-link, but the 'm' bit is set in the Router Advertisement message header (RFC4861) that contains the  <ins> Prefix option.  This indicates that node addressability is being </ins> managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "usable"&#151;not all hosts can actually use it.
Original text:
reachable, it is necessary that each partition of the stub network have its own prefix.  When such a partition occurs, the stub routers must detect that it has occurred.  If a stub router is currently <del> providing a prefix on the stub network, it need take no action.  If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network. It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </del>  When partitions of this type occur, they may also heal.  When a partition heals in a situation where two stub routers have both been

Reviewer comments:
AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?

Revised text:
reachable, it is necessary that each partition of the stub network have its own prefix.  When such a partition occurs, the stub routers must detect that it has occurred.  If a stub router is currently  <ins> providing a prefix on the stub network, it needs to take no action. If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </ins> When partitions of this type occur, they may also heal.  When a partition heals in a situation where two stub routers have both been
Original text:
host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected. <del> It may be noted that just as you can plug several CPEs together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </del>  The goal of this document is to describe the minimal set of changes or behaviors required to use existing IETF specifications to support

Reviewer comments:
The working group didn't actually agree on the use of the term "CPE Router", and there were substantive objections to it. I've used the term Home Gateway here, and included a definition that I think includes both ISP-provided routers with integrated uplink support (cable modem or DSL modem) and also includes routers where the WAN link is an ethernet connector. Not clear that this is correct, but hopefully it's evolving in the right direction.

Revised text:
host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected.  <ins> It may be noted that just as you can plug several Home Gateway devices together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from plugging it into another stub network router.  In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way.  Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create. </ins> The goal of this document is to describe the minimal set of changes or behaviors required to use existing IETF specifications to support
Original text:
reachable, it is necessary that each partition of the stub network have its own prefix.  When such a partition occurs, the stub routers must detect that it has occurred.  If a stub router is currently <del> providing a prefix on the stub network, it needs to take no action. If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </del>  When partitions of this type occur, they may also heal.  When a partition heals in a situation where two stub routers have both been

Reviewer comments:
The working group didn't actually agree on the use of the term "CPE Router", and there were substantive objections to it. I've used the term Home Gateway here, and included a definition that I think includes both ISP-provided routers with integrated uplink support (cable modem or DSL modem) and also includes routers where the WAN link is an ethernet connector. Not clear that this is correct, but hopefully it's evolving in the right direction.

Revised text:
reachable, it is necessary that each partition of the stub network have its own prefix.  When such a partition occurs, the stub routers must detect that it has occurred.  If a stub router is currently  <ins> providing a prefix on the stub network, it does not need to take action.  If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </ins> When partitions of this type occur, they may also heal.  When a partition heals in a situation where two stub routers have both been