[OPSAWG] Document Shepherd Review of draft-ietf-opsawg-sbom-access-11

[Qin Wu <[e-mail]>]

Hi, authors:
I have read the latest version of this draft, it is well written, thank for that.
Here is the identified minor issues during document shepherd review of draft-ietf-opsawg-sbom-access-11:

1.       Abstract said:
"
It may optionally be discovered through manufacturer usage descriptions.

"

[Qin] This sentence is not clear. Are you saying MUD extensions transparency can be discovered using extensions defined in section 3.9 of RFC8520?
Or software transparency and vulnerability information can be discovered by using ACL example defined in section 5.4 of this draft? I assume it is the latter. Please clarify.


2.       Section 1 said:
"
   The mechanisms specified in this document are meant to satisfy
   several use cases:

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

"
[Qin] How many use cases do we specify here? I believe it is two, how about be specific about the number of use cases here, s/several use cases/the following two use cases


3.       Section 1 said:
"   In the first case, devices will have interfaces that permit direct
   retrieval.  Examples of these interfaces might be an HTTP [RFC9110<https://datatracker.ietf.org/doc/html/rfc9110>],
   or COAP [RFC7252<https://datatracker.ietf.org/doc/html/rfc7252>] endpoint for retrieval.  There may also be private
   interfaces as well.

   In the second case, 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.

   In the third case, a supplier may wish to make an SBOM or
   vulnerability information available under certain circumstances, and
   may need to individually evaluate requests.  The result of that
   evaluation might be the SBOM or vulnerability itself or a restricted

"
[Qin] I believe the first case, the second case, the third case are corresponding to three ways to discover object instead of two key use cases listed in section 1? Therefore there are confusing to be introduced here.

I suggest to change as follows:
s/in one of three ways/ through one of three method
s/In the first case/In the first method
s/In the second case/In the second method
s/in the third case/In the third method


4.  Section 1.1

[Qin] s/in either/either in

5.  Section 1.1 said:

" The MUD semantics provide a way for manufacturers

to control how often tooling should check for those changes through

the cache-validity node. "

[Qin] Can you provide a reference section in RFC8520 about such MUD semantics.

6.  Section 3 N.B.

[Qin] What N.B. stands for? Can you provide a reference or change in other words.

7.  Section 5.4 said:

" 5.4<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-11#section-5.4>.  With ACLS



Finally, here is a complete example where the device provides SBOM

and vulnerability information, as well as access-control information.



{

"ietf-mud:mud": {

"mud-version": 1,

"extensions": [
"ol",

"transparency"
], "


[Qin] How this draft is related to draft-ietf-opsawg-ol-01? In other words, how sbom access work together with Ownership and licensing statements in YANG described in draft-ietf-opsawg-ol-01.

If 'ol' extension is needed, I think a informative reference is needed here.


8.  Section 6 said:

"N.B., for MUD, the mandatory method of retrieval is TLS. "

[Qin] New fashion of acronym,:)


9.  Section 6 said:

"

One example may be to issue a certificate to the client for

this purpose after a registration process has taken place.  Another

example would involve the use of OAUTH in combination with a
federations of SBOM servers. "

[Qin] I feel there is disconnection between the fifth sentence and the sixth sentence in the paragraph 9 . Two examples are provided here, I am wondering which security risk are addressed by which example?



10. Section 6 said:

"

Vulnerability information is generally made available to such

databases as NIST's National Vulnerability Database. "

[Qin] Do we need to list the Database Name developed by specific entity in the security section as normative text?



11. Do we have implementation that pertains to this draft?

-Qin