jiebi/TextFlow huggingface dataset:
Original text:
identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product. <del> A consumer of released software component wants: </del>  to offload the burden of identifying all relevant authoritative entities to an entity who does it on their behalf

Reviewer comments:
Addressing issue and
This fixes issue and issue
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM

Revised text:
identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product.  <ins> A consumer of released software product wants: </ins> to offload the burden of identifying all relevant authoritative entities to an entity who does it on their behalf
Original text:
There is no standardized way to: enable the consumer to verify that software originated from a <del> 'duly authorized signing party' on behalf of the Supplier. </del>  3.2.

Reviewer comments:
Updated firmware and Software integrator use case to the same format as the ones above.
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.

Revised text:
There is no standardized way to: enable the consumer to verify that software originated from a  <ins> 'duly authorized signing party' on behalf of the supplier, and is still valid. </ins> 3.2.
Original text:
identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product. <del> A consumer of released software component wants: </del>  to offload the burden of identifying all relevant authoritative entities to an entity who does it on their behalf

Reviewer comments:
Updated firmware and Software integrator use case to the same format as the ones above.
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.

Revised text:
identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product.  <ins> A consumer of released software product wants: </ins> to offload the burden of identifying all relevant authoritative entities to an entity who does it on their behalf
Original text:
assessments.  There is no assurance that all the bodies may be aware of statements from other authoritative entities or actively acknowledge them.  Discovery of all sources of such reports and/or <del> identity of the authoritaitve bodies adds a significant cost to the </del>  end user or consumer of the product. A consumer of released software product wants:

Reviewer comments:
Thanks for merge. I realize these are minor things (especially in developing a draft), so know that I am reading and digesting/thinking on the actual content. Thanks for your and the others' efforts.
LGTM! Sincere thanks for spotting them!

Revised text:
assessments.  There is no assurance that all the bodies may be aware of statements from other authoritative entities or actively acknowledge them.  Discovery of all sources of such reports and/or  <ins> identity of the authoritative bodies adds a significant cost to the </ins> end user or consumer of the product. A consumer of released software product wants:
Original text:
security analysis tools on the same product.  The intention is to identify any security weaknesses or vulnerabilities in the package. <del> Initially a particluar analysis can identify itself as a simple </del>  weakness in a software component.  Over a period of time, a statement from another third-party illustrates that the weakness is exposed in the same software component in a way that it is an exploitable

Reviewer comments:
Thanks for merge. I realize these are minor things (especially in developing a draft), so know that I am reading and digesting/thinking on the actual content. Thanks for your and the others' efforts.
LGTM! Sincere thanks for spotting them!

Revised text:
security analysis tools on the same product.  The intention is to identify any security weaknesses or vulnerabilities in the package.  <ins> Initially a particular analysis can identify itself as a simple </ins> weakness in a software component.  Over a period of time, a statement from another third-party illustrates that the weakness is exposed in the same software component in a way that it is an exploitable
Original text:
allow for application in constrained node environments a simple and low cost way to update the configuration of a system <del> component in charge of validity or authenticity cecking </del>  There is no standardized way to:

Reviewer comments:
Thanks for merge. I realize these are minor things (especially in developing a draft), so know that I am reading and digesting/thinking on the actual content. Thanks for your and the others' efforts.
LGTM! Sincere thanks for spotting them!

Revised text:
allow for application in constrained node environments a simple and low cost way to update the configuration of a system  <ins> component in charge of validity or authenticity checking </ins> There is no standardized way to:
Original text:
Cybersecurity Executive Order (EO) 14028 recommendations from NIST and will need to supply "Software Bill of Materials" (SBOM) and a "Vulnerability Disclosure Report" (VDR) NIST attestation to the DOI <del> prior to procurement. </del>  4.2.1.

Reviewer comments:
A few edits for brevity and conciseness Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution Signed-off-by: Steve Lasker
A VDR is a living document that can be linked to an SBOM document directly, see SPDX V2.3 K.1.9; URL
Is there a proposed change associated with this comment?
Feels like an agreement to the "Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution" above?
Thanks NAME I'd suggest the thing we want to capture with SCITT is the continual evolution of information. It's not ok to just update a document as there's no way to know what the state of the document was at a previous date. Example: Jan 1, 2022 - the software was deployed and the VDR showed (all is good). A SCITT claim was submitted, attesting to that current state Jan 10, 2022, the software was deployed, as there were no known issues. A SCITT claim On March 1, 2022 a new vulnerability was discovered that applied to the previous released and deployed software On March 2, 2022, a security auditor might ask: "Why did you deploy the net-monitor:v1` software when there's clearly a security problem? The system has the VDR report from Jan 10, when the software was deployed, to indicate no known vulnerabilities were known at that point. SCITT and the underlying evidence store will need to provide the most recent version of an artifactType, with the ability to query the history as well. Does this give you what you're looking for?
Steve, each new VDR will have a different hash value, so any/all of the VDR artifacts can be checked for trustworthiness, but the "most current VDR should always be registered in SCITT, IMO.
No additional changes are needed, just replace VEX with VDR and we're good to go.

Revised text:
Cybersecurity Executive Order (EO) 14028 recommendations from NIST and will need to supply "Software Bill of Materials" (SBOM) and a "Vulnerability Disclosure Report" (VDR) NIST attestation to the DOI  <ins> prior to procurement.  Unlike SBOMs, VDRs continue to evolve over time as new vulnerabilities are discovered that may impact previously released software.  Consumers will continually check their vendors and potentially other SCITT sources for updated VDR reports providing the most up to date information on new and previously consumed software. </ins> 4.2.1.
Original text:
Generate a Vulnerability Disclosure Report (VDR) listing all the known vulnerabilities and mitigation plans to meet Executive Order <del> 14028 and OMB M-22-18 requirements. </del>  Digitally sign the VDR artifact. <del> Place the VDR and digital signature artifacts within an access- controlled location, i.e., a customer portal, and provide the end consumer with a link to these artifacts for downloading to the customers environment. </del>  4.2.2.

Reviewer comments:
A few edits for brevity and conciseness Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution Signed-off-by: Steve Lasker
A VDR is a living document that can be linked to an SBOM document directly, see SPDX V2.3 K.1.9; URL
Is there a proposed change associated with this comment?
Feels like an agreement to the "Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution" above?
Thanks NAME I'd suggest the thing we want to capture with SCITT is the continual evolution of information. It's not ok to just update a document as there's no way to know what the state of the document was at a previous date. Example: Jan 1, 2022 - the software was deployed and the VDR showed (all is good). A SCITT claim was submitted, attesting to that current state Jan 10, 2022, the software was deployed, as there were no known issues. A SCITT claim On March 1, 2022 a new vulnerability was discovered that applied to the previous released and deployed software On March 2, 2022, a security auditor might ask: "Why did you deploy the net-monitor:v1` software when there's clearly a security problem? The system has the VDR report from Jan 10, when the software was deployed, to indicate no known vulnerabilities were known at that point. SCITT and the underlying evidence store will need to provide the most recent version of an artifactType, with the ability to query the history as well. Does this give you what you're looking for?
Steve, each new VDR will have a different hash value, so any/all of the VDR artifacts can be checked for trustworthiness, but the "most current VDR should always be registered in SCITT, IMO.
No additional changes are needed, just replace VEX with VDR and we're good to go.

Revised text:
Generate a Vulnerability Disclosure Report (VDR) listing all the known vulnerabilities and mitigation plans to meet Executive Order  <ins> 14028 and OMB M-22-18 requirements with the date the report was generated. </ins> Digitally sign the VDR artifact.  <ins> Submit the VDR and digital signature to the same SCITT instance, providing a common feed of supply chain information. If the VDR contains critical vulnerabilities, a SCITT claim may be generated, identifying any potential mitigations such as new versions. </ins> 4.2.2.
Original text:
Abstract <del> Generalized Software Supply Chain Use Case Descriptions </del>  1.

Reviewer comments:
Please note the template is based on: https://rfc-URL We would like to stick to this template and progress this document!

Revised text:
Abstract  <ins> This document includes a collection of representative Software Supply Chain Use Case Descriptions.  These use cases aim at identifying software supply chain problems that the industry faces today and acts as a guideline for developing a comprehensive solution for these class of scnenarios. </ins> 1.
Original text:
third-party code, development practices and tools, deployment methods and infrastructure, and interfaces and protocols.  The software supply chain comprises all elements associated with an application's <del> design, development, deployment, and maintenance throughout its entire lifecycle.  The complexity of software coupled with a lack of lifecycle visibility increases the risks associated with system attack surface and the number of cyber threats capable of harmful impacts, such as exfiltration of data, disruption of operations, and loss of reputation, intellectual property, and financial assets. There is a need for a platform architecture that will allow consumers to know that suppliers maintained appropriate security practices without requiring access to proprietary intellectual property. SCITT-enabled products and analytics solutions will assist in managing compliance and assessing risk to help prevent and detect supply chain attacks across the entire software lifecycle while prioritizing data privacy. </del>  1.1.

Reviewer comments:
Please note the template is based on: https://rfc-URL We would like to stick to this template and progress this document!

Revised text:
third-party code, development practices and tools, deployment methods and infrastructure, and interfaces and protocols.  The software supply chain comprises all elements associated with an application's  <ins> design, development, build, integration, deployment, and maintenance throughout its entire lifecycle.  The complexity of software coupled with a lack of lifecycle visibility increases the risks associated with system attack surface and the number of cyber threats capable of harmful impacts, such as exfiltration of data, disruption of operations, and loss of reputation, intellectual property, and financial assets.  There is a need for a platform architecture that will allow consumers to know that suppliers maintained appropriate security practices without requiring access to proprietary intellectual property.  SCITT-enabled products and analytics solutions will assist in managing compliance and assessing risk to help prevent and detect supply chain attacks across the entire software lifecycle while prioritizing data privacy. </ins> 1.1.
Original text:
4.  There are two ways a client can receive updates for a resource: At a high level, an ALTO client opens a persistent HTTP connection

Reviewer comments:
NAME Med, I have migrated the draft to markdown format (see ). The changes are merged as well. I am taking a complete pass of the markdown before merging it to the main branch.
Thank you, NAME Looking forward merging the new branch into the main.

Revised text:
4. <ins> 4.1. </ins> There are two ways a client can receive updates for a resource: At a high level, an ALTO client opens a persistent HTTP connection
Original text:
A client that prefers server push can use the following workflow: <del> 4.1. </del>  The HTTP version a "https" connection uses is negotiated between client and server using the TLS ALPN extension, described in RFC9113

Reviewer comments:
NAME Med, I have migrated the draft to markdown format (see ). The changes are merged as well. I am taking a complete pass of the markdown before merging it to the main branch.
Thank you, NAME Looking forward merging the new branch into the main.

Revised text:
A client that prefers server push can use the following workflow:  <ins> 4.2. </ins> The HTTP version a "https" connection uses is negotiated between client and server using the TLS ALPN extension, described in RFC9113
Original text:
Hence, the server processing logic SHOULD be: <del> 7.2.1. </del> It is RECOMMENDED that the server uses the following HTTP codes to indicate errors, with the media type "application/alto-error+json", regarding update item requests.

Reviewer comments:
NAME Med, I have migrated the draft to markdown format (see ). The changes are merged as well. I am taking a complete pass of the markdown before merging it to the main branch.
Thank you, NAME Looking forward merging the new branch into the main.

Revised text:
Hence, the server processing logic SHOULD be:  It is RECOMMENDED that the server uses the following HTTP codes to indicate errors, with the media type "application/alto-error+json", regarding update item requests.
Original text:
8.3. <del> 8.3.1. </del> The server push MUST satisfy the following requirements: 9.

Reviewer comments:
NAME Med, I have migrated the draft to markdown format (see ). The changes are merged as well. I am taking a complete pass of the markdown before merging it to the main branch.
Thank you, NAME Looking forward merging the new branch into the main.

Revised text:
8.3.  The server push MUST satisfy the following requirements: 9.
Original text:
11. <del> IANA is requested to register the following media types following the same process in RFC7285: </del>  application/alto-tips+json: as described in open-resp;

Reviewer comments:
This will help me fix this part in the writeup: Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]).

Revised text:
11.  <ins> IANA is requested to register the following media types from the registry available at IANA-Media-Type: </ins> application/alto-tips+json: as described in open-resp;
Original text:
TIPS uses this directory schema to generate template URIs which allow clients to construct the location of incremental updates after receiving the tips-view-uri path from the server.  The generic <del> template for the location of the update item on the edge from node i to node j in the updates graph is: </del>  Due to the sequential nature of the update item IDs, a client can long poll a future update that does not yet exist (e.g., the

Reviewer comments:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Revised text:
TIPS uses this directory schema to generate template URIs which allow clients to construct the location of incremental updates after receiving the tips-view-uri path from the server.  The generic  <ins> template for the location of the update item on the edge from node 'i' to node 'j' in the updates graph is: </ins> Due to the sequential nature of the update item IDs, a client can long poll a future update that does not yet exist (e.g., the
Original text:
4.4. Conceptually, the sequence number space of TIPS views satisfy the <del> following requirements: First, for a specific client, it may expect to see the same sequence number for the same version, to avoid occasional disconnections.  Second, the coupling of sequence numbers should be minimized for ALTO resources monitored by multiple clients. </del>  <del> Thus, the sequence number space is constant for each TIPS view per </del>  client but is independent across TIPS views.  Note that For the same TIPS resource queried by different clients, multiple TIPS views will be created, one for each client, whose sequence number spaces are independent. <del> Independence implies that the clients must not assume there is a </del>  consensus of how different versions map to sequence numbers but does not force the sequence numbers to be different.  See shared- tips-view for cases where an ALTO server may desire to use the

Reviewer comments:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Revised text:
4.4. Conceptually, the sequence number space of TIPS views satisfy the  <ins> following requirements: First, a specific client may expect to see the same sequence number for the same version to avoid occasional disconnections.  Second, the coupling of sequence numbers should be minimized for ALTO resources monitored by multiple clients. </ins>  <ins> Thus, the sequence number space is constant for each TIPS view per- </ins> client but is independent across TIPS views.  Note that For the same TIPS resource queried by different clients, multiple TIPS views will be created, one for each client, whose sequence number spaces are independent.  <ins> Independence implies that ALTO clients must not assume there is a </ins> consensus of how different versions map to sequence numbers but does not force the sequence numbers to be different.  See shared- tips-view for cases where an ALTO server may desire to use the
Original text:
5.4. <del> Extending the IRD example in Section 8.1 of RFC8895, below is the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, and ALTO TIPS. </del>  Note that it is straightforward for an ALTO server to run HTTP/2 and support concurrent retrieval of multiple resources such as "my-

Reviewer comments:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Revised text:
5.4.  <ins> Extending the IRD example in Section 8.1 of RFC8895, ex-ird is the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, and ALTO TIPS. </ins> Note that it is straightforward for an ALTO server to run HTTP/2 and support concurrent retrieval of multiple resources such as "my-
Original text:
"400 Bad Request" to the ALTO client; the body of the response follows the generic ALTO error response format specified in Section 8.5.2 of RFC7285.  Hence, an example ALTO error response has <del> the format: </del>  Note that "field" and "value" are optional fields.  If the "value" field exists, the "field" field MUST exist.

Reviewer comments:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Revised text:
"400 Bad Request" to the ALTO client; the body of the response follows the generic ALTO error response format specified in Section 8.5.2 of RFC7285.  Hence, an example ALTO error response has  <ins> the format shown in ex-bad-reques. </ins> Note that "field" and "value" are optional fields.  If the "value" field exists, the "field" field MUST exist.
Original text:
For simplicity, assume that the ALTO server is using the Basic authentication.  If a client with username "client1" and password "helloalto" wants to create a TIPS view of an ALTO Cost Map resource <del> with resource ID "my-routingcost-map", it can send the following request: </del>  <del> If the operation is successful, the ALTO server returns the following message: </del>  6.4.

Reviewer comments:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Revised text:
For simplicity, assume that the ALTO server is using the Basic authentication.  If a client with username "client1" and password "helloalto" wants to create a TIPS view of an ALTO Cost Map resource  <ins> with resource ID "my-routingcost-map", it can send the request depiced in ex-op. </ins>  <ins> If the operation is successful, the ALTO server returns the message shown in ex-op-rep. </ins> 6.4.
Original text:
7.3. Assume the client wants to get the contents of the update item on <del> edge 0 to 101.  The request is: </del>  <del> And the response will be: </del>  7.4.

Reviewer comments:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Revised text:
7.3. Assume the client wants to get the contents of the update item on  <ins> edge 0 to 101.  The format of the request is shown in ex-ge. </ins>  <ins> The response is shown in ex-get-res. </ins> 7.4.