A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information
draft-ietf-opsawg-sbom-access-18

Thank you to Christian Huitema for the SECDIR review.

Like Eric, I find the yang module name a bit odd, but have no good suggestion for a better alternative.

Thank you to Christian Huitema for the SECDIR review.

Thank you for addressing my DISCUSS and most of my COMMENT feedback.

** Section 5.1

==[ snip ]==
The second example demonstrates that just SBOM information is included.

{
  "ietf-mud:mud": {
    "mud-version": 1,
    "extensions": [
      "transparency"
    ],
    "mudtx:transparency": {
      "sbom-local-well-known": "https"
    },
    "mud-url": "https://iot.example.com/modelX.json",
    "mud-signature": "https://iot.example.com/modelX.p7s",
    "last-update": "2022-01-05T13:29:47+00:00",
    "cache-validity": 48,
    "is-supported": true,
    "systeminfo": "retrieving SBOM info via a cloud service",
    "mfg-name": "Example, Inc.",
    "documentation": "https://iot.example.com/doc/modelX",
    "model-name": "modelX"
  }
}
==[ snip ]==

In -15 systeminfo said "retrieving vuln and SBOM info via a cloud service".  In response to my ballot, -16 now reads "retrieving SBOM info via a cloud service".  However, since the sbom-local-well-known field is present and the narrative text says "The second example demonstrates that just SBOM information is included", systeminfo should read "retrieving SBOM information locally from the device" (or something to that effect).

Thank you for this document, and also much thanks to Henk for the OpsDir review - https://datatracker.ietf.org/doc/review-ietf-opsawg-sbom-access-03-opsdir-early-comstedt-2021-12-19/

I found it an easy read, and only have a few nits to offer:

1: "A number of activities have been working to improve visibility to
   what software is running on a system, and what vulnerabilities that
   software may have[EO2021]."
Missing space before the [EO2021] reference.

2: "... two classes of questions *at scale*:"
I think that you should drop the "emphasis" - I really don't think that it helps readability, and looks "odd". I often use this form for emphasis, but I really don't think that it should be used in an RFC. 

3: "Examples of these interfaces might be an HTTP [RFC7231],[RFC9110], or COAP [RFC7252] endpoint for retrieval."
Missing space after [RFC7231] -- hey, I *did* mention that this is all nits (and also that I *emphasize text*).

4: "Using the second method, when a device does not have an appropriate retrieval interface, but one is directly available from the manufacturer, a URI to that information MUST be discovered."
I don't really understand the uppercase MUST here; it's unclear who / what the MUST is directed at.

5: "To address either risk, any change in a URL, and in particular to the authority section, should be treated with some suspicion.  One mitigation would be to test any cloud-based URL against a reputation service."
I don't really have any useful text to suggest, but I find the wording of "To address either risk, ..., should be treated with some suspicion" to be strange. I don't really view treating something with suspicion as addressing a risk. I *do* know what you are trying to say, but I don't really think that this accomplishes it. I'm also not really sure why the second sentence only views 'cloud-based' URLs as different to non-cloud-based ones - why is foo.bar.example.com more or less sketchy if it is on AWS then on a physical server? And I think that the hand-wavy "check it against some sort of reputation thing" is sufficiently underspecified that it's not helpful.

Please notes that these really are just intended to be nits / attempts to help improve the document; I seem to be having a hard time with my tone in this writeup and apologize if it came out as snarky....

Thanks for working on this specification. 

I also stumbled upon "sbom" and "vuln" nodes in section 1.2. I assumed these refers to the nodes in the YANG tree sbom node = starts with sbom- and vuln node = starts with vuln- .... yes that I had to guess to continue reading. Now I see Roman has a discuss on this point hence supporting the discuss. I believe evenif it might be a convention call those node as I assumed, we could be more clear by actually describing the notion in the doc. And if my assumption is wrong then we definitely need to describe the nodes so that readers like me don't make wrong assumption :-).

# GEN AD review of draft-ietf-opsawg-sbom-access-15

CC @larseggert

Thanks to Russ Housley for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/c_Npcow_0xA8aojaPi07NMcoeaw).

## Comments

### Section 1, paragraph 3
```
     Put simply, we seek to answer two classes of questions *at scale*:
```
What does "at scale" mean here? Ask the questions to a large number of systems?
Ask the questions and expect very large results? Something else?

## 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.

### Uncited references

Uncited references: `[RFC8446]`, `[RFC6242]`, and `[RFC8341]`.

### Outdated references

Reference `[RFC7231]` to `RFC7231`, which was obsoleted by `RFC9110` (this may
be on purpose).

### Grammar/style

#### Section 1, paragraph 16
```
: * on devices themselves * on a web site (e.g., via URI) * through some for
                                 ^^^^^^^^
```
Nowadays, it's more common to write this as one word.

#### Section 4, paragraph 13
```
this device. Publication dates can found inside the SBOMs."; } choice vuln-r
                                   ^^^^^
```
Make sure that the ambiguous verb form "found" is correct. (It can either be
the base form "found", or the past tense of a different verb.).

## 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