Re: [OPSAWG] 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

I've read the draft and I support the adoption. In addition, I have the following comments:

1) 
1. Introduction
An application-layer management system retrieving an SBOM in order
to evaluate the posture of an application server of some form.
These application servers may themselves be containers or
hypervisors. Discovery of the topology of a server is beyond the
scope of this memo.

Comment> I know there are application-layer firewalls, but I don't think it's also appropriate to use "application-layer" to describe the management system. The management system manages the application server, but should not be specific to "application-layer".

Comment> For an application server which doesn't support MUD before, if it wants to advertise its SBOM info, it needs to send a MUD URL and the related MUD file contains a SBOM URL, why doesn't it just send a SBOM URL?

2)
1. Introduction
A network-layer management system retrieving an SBOM from an IoT
device as part of its ongoing lifecycle. Such devices may or may
not have interfaces available to query SBOM information.

Comment> I also suggest not using "network-layer" to describe the management system, but saying that the management system evaluates the network behavior of the IoT devices.

Comment> For disambiguation, in the last sentence, it's better to say "to be queried for SBOM information".

3)
1.3. Discussion points
Are there other retrieval mechanisms that need to be specified?

Comment> Can the SBOM info be directly stored/written in the MUD file?

4)
3. The mud-sbom augmentation to the MUD YANG model
In the description of "leaf-list sbom-local", it is said:
"The choice of sbom-local means that the SBOM resides at
a location indicated by an indicted scheme for the
device in question, at well known location
’/.well-known/sbom’. For example, if the MUD file
indicates that coaps is to be used and the host is
located at address 10.1.2.3, the SBOM could be retrieved
at ’coaps://10.1.2.3/.well-known/sbom’. N.B., coap and
http schemes are NOT RECOMMENDED.";

Comment> The leaf-list "sbom-local" only indicates the transport Protocol, how can the MUD controller know the host address?

5)
4. Examples
The first MUD file demonstrates how to get the SBOM
without ACLs, and the second has ACLs.

Comment> Here should be "The first three MUD files demonstrate ..., and the forth has ACLs."

6)
5. Security Considerations
Another risk is a skew in the SBOM listing and the actual software
inventory of a device/container. For example, a manufactuer may
update the SBOM on its server, but an individual device has not be
upgraded yet. This may result in an incorrect policy being applied
to a device. A unique mapping of a device’s firmware version and its
SBOM can minimize this risk.

Comment> Can we add the firmware version info in the MUD file? So that there will be the mapping of firmware version and SBOM.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Henk
> Birkholz
> Sent: Tuesday, January 5, 2021 12:10 AM
> To: opsawg <opsawg@ietf.org>
> Subject: [OPSAWG] 🔔 WG Adoption Call on
> draft-lear-opsawg-sbom-access-00
> 
> Dear OPSAWG members,
> 
> this starts a call for Working Group Adoption on
> https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on
> Monday, January 25.
> 
> As a reminder, this I-D describes different ways to acquire Software Bills of
> Material (SBOM) about distinguishable managed entities. The work was
> updated by the authors on October 13th and now elaborates on three ways
> SBOM can be found, including a MUD URI as one of the options.
> 
> Please reply with your support and especially any substantive comments
> you may have.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg