jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
text: 4.1. Micro Coding Wizards (MCW) is a small, fictional, software <del> development company providing software solutions to help manage a fleet of electric vehicles (EV) for corporations.  MCW's software solution, MCWManager, is an asset management platform specifically designed to manage electric vehicle fleets.  MCWManager tracks usage, charge level, range, and other important characteristics of each EV in the fleet.  The US Department of the Interior (DOI), a government agency has expressed interest in licensing the MCWManager software to manage a fleet of 20 Electric Vehicles, spread across the Western Region, which includes States west of the Rocky Mountains. </del> <ins> development company providing software solutions for managing fleets of electric vehicles (EV).  MCW's software solution, MCWManager, is an asset management platform specifically designed to manage fleets of electric vehicles.  MCWManager tracks usage, charge level, range, and other important characteristics of each EV in the fleet.  The US Department of the Interior (DOI), a government agency has expressed interest in licensing the MCWManager software to manage a fleet, starting with 20 Electric Vehicles. </ins> MCW has been informed by DOI that their software will be subject to Cybersecurity Executive Order (EO) 14028 recommendations from NIST
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <ins> 14028 and OMB M-22-18 requirements with the date the report was generated. </ins> 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> <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.
Code change:
Please note the template is based on: https://rfc-URL We would like to stick to this template and progress this document!

Related discussion:
text: Abstract <del> Generalized Software Supply Chain Use Case Descriptions </del> <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.
Code change:
Please note the template is based on: https://rfc-URL We would like to stick to this template and progress this document!

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
text: A client that prefers server push can use the following workflow: <del> 4.1. </del> <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
Code change:
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.

Related discussion:
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.
Code change:
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]).

Related discussion:
text: 11. <del> IANA is requested to register the following media types following the same process in RFC7285: </del> <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;
Code change:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Related discussion:
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> <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
Code change:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Related discussion:
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> <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> <del> Thus, the sequence number space is constant for each TIPS view per </del> <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. <del> Independence implies that the clients must not assume there is a </del> <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
Code change:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Related discussion:
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> <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-
Code change:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Related discussion:
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> <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.
Code change:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Related discussion:
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> <ins> with resource ID "my-routingcost-map", it can send the request depiced in ex-op. </ins> <del> If the operation is successful, the ALTO server returns the following message: </del> <ins> If the operation is successful, the ALTO server returns the message shown in ex-op-rep. </ins> 6.4.
Code change:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Related discussion:
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> <ins> edge 0 to 101.  The format of the request is shown in ex-ge. </ins> <del> And the response will be: </del> <ins> The response is shown in ex-get-res. </ins> 7.4.
Code change:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Related discussion:
text: correctly enabled.  The requested URL is the root path of the TIPS view, appended with "push", as shown below. <del> The server returns an JSON object with content type "application/ alto-tipsparams+json".  The response MUST include only one field "server-push".  If the server push is enabled, the value of the "server-push" field MUST be the JSONBool value "true" (without the quote marks), and otherwise JSONBool value "false" (without the quote marks). </del> <ins> The server returns a JSON object with content type "application/alto- tipsparams+json".  The response MUST include only one field "server- push".  If the server push is enabled, the value of the "server-push" field MUST be the JSONBool value "true" (without the quote marks), and otherwise JSONBool value "false" (without the quote marks). </ins> 8.1.3.
Code change:
Fix for
NAME PTAL
NAME PTAL
(moved to issue)
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.

Related discussion:
text: is communicated using PACI Extensions defined in [RFC7798] Section 4.4.4.2. A WebRTC implementation that has negotiated use of RTP header extensions containing TSCI information (such as the Dependency Descriptor [DD]) SHOULD <del> NOT send TSCI information within the PACI, and where TSCI information is being received in RTP header extensions MUST ignore TSCI information contained in the PACI. </del> <ins> NOT send TSCI information within the PACI.  If TSCI information is being received in an RTP header extension, implementations MUST ignore TSCI information contained in the PACI. </ins> Implementations of the H.265 codec have utilized a wide variety of optional parameters.  To improve interoperability, the following
Code change:
Add discussion of the tx-mode SDP parameter. Fix for Rebase of
NAME PTAL
I think we need a different approach. We want to say that support for "SRST" mode is mandatory If no tx-mode parameter is present, a value of "SRST" MUST be inferred. It is up to the offering implementation whether to include SRST or omit it. implementations that do not implement the other modes should not negotiate a codec with that mode
NAME Updated the PR to include your suggestions.
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.

Related discussion:
text: tx-mode: Implementations SHOULD NOT include this parameter within SDP. If no tx-mode parameter is present, a value of "SRST" MUST be inferred. <del> Support for the "MRST" and "MRMT" modes is OPTIONAL; implementations that do not support the "MRST" or "MRMT" modes MUST NOT include these modes in the tx-mode parameter. </del> <ins> Implementations MUST support "SRST"; support for "MRST" and "MRMT" is OPTIONAL. Implementations that do not support "MRST" or "MRMT" MUST NOT include these tx-mode values in SDP. </ins> sprop-sps, sprop-pps, sprop-vps, sprop-sei: H.265 allows sequence and picture information to be sent both in-band and out-of-band.  WebRTC implementations
Code change:
In regards to not requesting registration in the RTP payload registry, please remove the following sentence in Section 11: The motivation and removal of the registry the above sentence request are in: URL (from Magnus Westerlund)

Related discussion:
text: RTP Payload Format for sub-codestream latency JPEG 2000 streaming <del> draft-ietf-avtcore-rtp-j2k-scl-02 </del> <ins> draft-ietf-avtcore-rtp-j2k-scl-03 </ins> Abstract
Code change:
In regards to not requesting registration in the RTP payload registry, please remove the following sentence in Section 11: The motivation and removal of the registry the above sentence request are in: URL (from Magnus Westerlund)

Related discussion:
text: 11. This memo requests that IANA registers the content type specified at <del> sec-media-type.  The media type is also requested to be added to the IANA registry for RTP Payload Format MIME types [1]. </del> <ins> sec-media-type. </ins> 12.