Supply Chain Integrity, Transparency, and Trust
charter-ietf-scitt-01

[Ballot comment]
I am trying to understand the use case. It seems to focus on a decentralized structure. Do the proponents mean that every part of the supply chain runs their own decentralized merkle tree? (in which case, does it really need to be a merkle tree). Or is this truly decentralized, in which case what is the incentive to keep running these nodes ?

[Ballot comment]
draft-birkholz-scitt-architecture-00 is mentioned as the starting point, but the current version is already -01.  If it needs to be mentioned, don't include the version.

Given that program of work includes work already covered in draft-birkholz-scitt-architecture, perhaps the first action of the WG should be its adoption (vs. it being specified as the starting point, even if the text does say that the "WG may refine the input document on the architecture in the process").

I believe it is better for a WG to reach consensus on the seed document than for it to be included in the charter.  It is not a blocking position, just food for thought.

[Ballot comment]
The charter seems to still have some issues... not to the point of a BLOCK ballot though.

1/ the last T in SCITT (trust) does not often appear in the charter.

2/ the first line should also be clear that this is about the SW supply chain (I appreciate the added sentence in the first paragraph, but let's be clear even in the first sentence).

3/ "SCITT will initially focus on the software supply chain" is it "initially" or "only" ? Should the WG be rechartered to go beyond ?

4/ Unsure whether "The WG may refine the input document on the architecture in the process." sentence brings any value as it is implicit IMHO.

5/ it is very long...

Hope it helps

-éric

[Ballot block]
I am trying to understand the use case. It seems to focus on a decentralized structure. Do the proponents mean that every part of the supply chain runs their own decentralized merkle tree? (in which case, does it really need to be a merkle tree). Or is this truly decentralized, in which case what is the incentive to keep running these nodes ?

Changed charter milestone "Submit a HTTP-based REST API for Request-Response Interactions document to the IESG for publication", set description to "Submit an HTTP-based REST API for Request-Response Interactions document to the IESG for publication"

[Ballot comment]
# GEN AD review of charter-ietf-scitt-02

CC @larseggert

## Comments

### Paragraph 0
```
  Over the years, rapid technological advancements have motivated organizations
  to implement efficient processes for supply chains (i.e., from design to
  manufacturing, logistics, and just-in-time delivery). While these improvements
  help organizations increase efficiency and swiftly bring innovations to market,
  the rapid increase in scale, size, and complexity of supply chains has led to
  more frequent and sophisticated supply chain attacks. The traditional methods
  of safeguarding supply chains (e.g., pre- and post-audit methodologies) are no
  longer adequate.
```
This entire paragraph could be removed. The charter is somewhat long.

### Paragraph 1
```
  It is challenging to manage the conformance of products across end-to-end,
  global supply chains.
```
Can be removed.

### Section 1, paragraph 0
```
  1. Standardize the technical flows for providing information about a software
  supply chain, which also includes firmware, and covering the essential building
  blocks that make up the architecture.
```
Does "firmware" include "microcode"?

### Section 4, paragraph 2
```
  The main deliverables defined by this program of work provide a guideline for
  milestones that are in scope of the WG charter.
```
Can be removed.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

### Grammar/style

#### Section 2, paragraph 0
```
ith other standards bodies, such as the, OpenSSF, W3C, ISO, and the Trusted
                                    ^^^^
```
A word may be missing after "the".

#### Section 3, paragraph 9
```
SG for publication Jun 2024 - Submit a HTTP-based REST API for Request-Respo
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
I tend to agree with Zahed and Éric's points, and more generally think this charter suffers from being a wall of text that could pretty easily be trimmed down without loss of essential content.

None of these are fundamental flaws however and I think the program of work and scope of the group seems OK, so I'm balloting NOOBJ.

[Ballot comment]
The charter looks OK, however, I would say it has quite a bit of details (may be that is good).

I have two particular comments -

  - It says - it is a non-goal to define best practices for supply chain. I am wondering how to achieve that when the WG will define new architecture with actors and interactions. Will it not kind of define how the supply chain supposed to work hence define the recommended practices (I hope those are best practices)? I think it would be good that the charter describes the differences that it does not want to change vs it wants to create.

  - I have not found anything in the charter about "HTTP-based" technology yet there is a milestone doing exactly that. Why is that?

[Ballot comment]
This could be an interesting work to be done. But, I am afraid that the charter would benefit from some updates before going public (I was hesitating to ballot a BLOCK on those points):

1/ after reading the charter, it is still unclear to me whether it is about a generic supply chain (e.g., mechanical devices, pharmaceutical products, ...) or only about software supply chain.

2/ I was expect to see the word 'trust' cited more often

3/ have 'WG shall employ the existing work already done' in the goals section seems weird as it is more a 'means' than an 'ends'.

4/ having a 'problem statement' in the charter is also unusual, suggest to rename into "current situation' ?

Hope this helps refining the charter

regards

-éric