Subject: Re: [Gen-art] [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03

From: Eliot Lear <[email-masked]>
Date: Tue, 4 Jan 2022 17:16:37 +0100

Hi Russ,

And thanks for your review. Please see below.

On 13.12.21 23:02, Russ Housley via Datatracker wrote:
> Reviewer: Russ Housley
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-opsawg-sbom-access-03
> Reviewer: Russ Housley
> Review Date: 2021-12-13
> IETF LC End Date: unknown
> IESG Telechat date: unknown
>
> Summary: Almost Ready
>
>
> Note: I am not a good persone to review the YANG specification.  I
> assume one of the YANG Doctors will have a look at this document too.
>
>
> Major Concerns:
>
> Section 1 says:
>
>     To satisfy these two key use cases, objects may be found in one of
>     three ways:
>
> This lead to some confusion for me.  Earlier in the document, it says:
>
>     This specification does not allow for vulnerability information to be
>     retrieved directly from the endpoint.  That's because vulnerability
>     information changes occur at different rates to software updates.
>
> After thinking about it, I realized that the objects do not include
> vulnerability information, but pointers to obtain vulnerability
> information.  Please reword to others do not need to give it the
> same amount of thought.

What I propose is first the following early on in the introduction:

> This memo doesn't specify the format of  this information, but rather
> only how to locate and retrieve these    objects.

>
>
> Minor Concerns:
>
> Section 1, first sentence: The reference to "A number of activities"
> is very vague.  It is not wrong.  Please be more specific, provide
> some references, or drop the vague reference altogether.

It'd be fun to reference an executive order.  Never done that before.

>
> Section 1 says:
>
>     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.
>
> s/must/MUST/ ?
>
Sure.

> Nits:
>
> The terms "software" and "firmware" are used with essentially the same
> meaning in this document.  If there is a difference, it needs to be
> explained.  If they are the same in the context of this document, please
> say so.

I've removed the term "firmware".

> Abstract, last sentence: please add "(MUD)" and also a pointer to
> RFC 8520.

I think this got rewritten.  Let me know when you see the update.

Thanks again for the review.

    Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 4 Jan 2022 17:28:20 +0100

Hi Tom,

Thanks for your review.  Please see below.

On 14.12.21 11:15, tom petch wrote:
> From: OPSAWG <[email-masked]> on behalf of Russ Housley via Datatracker <[email-masked]>
> Sent: 13 December 2021 22:02
> Subject: [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03
>
> Reviewer: Russ Housley
> <snip>
> <tp>
> You could say that there is no YANG Module as YANG Modules must be registered with IANA and the IANA Considerations in this I-D do not do so:-)
>
> So
> IANA Considerations must register the module as per YANG Guidelines
Added.
>
> Security Considerations must use the template referenced by YANG Guidelines

This one's a little weird, since we are augmenting the MUD module, which 
isn't intended to be retrieved via NETCONF, and nothing here is intended 
to be writeable.  I could add read-only to all of this stuff.

>
> The title in the revision reference clause bears little relationship to that of the I-D
Corrected.
>
> YANG prefix must be unique and should be easy to use; I think that 'mud-transparency' is about 12 characters longer than I would class as easy to use (e.g. mudtx)
Sold.
>
> URL is insecure and to an obsolete web site (tools)
>
> No mention of NMDA or lack of support thereof

Text welcome for this.

>
> Lots of abbreviations not expanded on first use
>
> In our modern pageless format, Section one would be easier to refer to with more subsections such as one for terminology with expanded abbreviations

Generally we should expand abbreviations on first use.  I will clean 
those up.

>
> Why have a grouping and a uses which for me makes the module harder to understand?  It is not as if this grouping is going to be imported in lots of places AFAICT.

It may.  That is why it's a grouping.

Again, thanks for the review.

Eliot

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 4 Jan 2022 11:37:07 -0500

>     information changes occur at different rates to software updates.

In practice today, consumers are indeed retrieving vulnerability information directly from the vendor endpoint where SBOM's are being distributed. SBOM Vulnerability Disclosure Reports (VDR) can update independently from an SBOM, but remain at a given URL for download. An example of this method is available online using the AWS client software for demonstration only:

https://github.com/rjb4standards/REA-Products/tree/master/C-SCRM-Use-Case

AWS-CLI SBOM: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/C-SCRM-Use-Case/AWS_SBOM.spdx 
AWS-CLI VDR:  https://raw.githubusercontent.com/rjb4standards/REA-Products/master/C-SCRM-Use-Case/AWSCLIVDR.xml 

FYI: VEX is a different form of vulnerability disclosure, reporting CVE info on a product level, i.e. Log4j, whereas the SBOM VDR reports CVE's at the SBOM component level. These are not competitive offerings, they are complementary offerings.

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of Eliot Lear
Sent: Tuesday, January 4, 2022 11:17 AM
To: Russ Housley <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03

Hi Russ,

On 13.12.21 23:02, Russ Housley via Datatracker wrote:
> Review Team (Gen-ART) reviews all IETF documents being processed by 
> the IESG for the IETF Chair. Please wait for direction from your 
> information.  Please reword to others do not need to give it the same 
> amount of thought.

Sure.

> explained.  If they are the same in the context of this document, 
> please say so.

> Abstract, last sentence: please add "(MUD)" and also a pointer to RFC 
> 8520.

    Eliot