Subject: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02

From: Ebben Aries via Datatracker <[email-masked]>
Date: Sat, 02 Oct 2021 16:15:26 -0700

Reviewer: Ebben Aries
Review result: Almost Ready

Apologies for not turning this around sooner.  Structure wise, the model is
fairly sound.  Most of the comments below are either nits/wording, slight
adjustments and questions/clarifications.

1 module in this draft:
- [email-masked]

No YANG compiler errors or warnings (pyang 2.5.0, yanglint 2.0.88, confdc 7.2.3.4)
- L#364: CODE BEGINS : filename must be defined on same line for tools such as
  rfcstrip to correctly parse the module contents

Module [email-masked]:
- import `ietf-inet-types` should reference RFC 6991 per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- import `ietf-mud` should reference RFC 8520 per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- L#016 - Minor nit: looks like L#17 should be moved up here
- L#018-020 - Minor nit: adjust email address formatting per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
- The type and enum members are identically defined for
  `sbom-local-well-known` and `vuln-local-well-known`.  Is this something you
  can leverage by using a typedef or a grouping or is there intention to keep
  these separately defined?
- When retrieving say an 'sbom' from the device, is it assumed that it be via
  `sbom-local-well-known`?  What if it is necessary to host this on an
  alternate port for one of the communication protocols chosen?  Would this
  scenario then best use `sbom-url` to define a static URI? (Same question
  applies to vuln as well)
- Independent of the answer to the above question, is `cloud` the best choice
  or wording for the other case statement under the retrieval method choices?

  It seems to be that we have 3 cases for sbom/vuln retrieval methods which
  correspond to the draft wording at L#176-180 which seems to not pair
  identically.

  * on devices themselves: Could be /.well-known/ or a static URI could it
    not?
  * on a website: Static URI only
  * out-of-band: Static URI only - should this leaf be named something closer
    to that vs. 'contact'?

General comments on the draft/modules:
- L#0021: s/provide access this/provide access to this/
- L#0117: s/bills of material/bill of materials/
- L#0627: JSON example needs correct prefix for the augment
  `ietf-mud-transparency:transparency`
- L#0941: s/not be/not been/
- L#0961: s/authoration/authorization/
- Since `ietf-mud-transparency` imports `ietf-inet-types`, a normative
  reference must be added per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3.9

---

From: Eliot Lear <[email-masked]>
Date: Sun, 3 Oct 2021 10:48:10 +0200

Ebben,

Thank you VERY much for your thorough review.  We will respond and 
update the draft in due course.

Eliot

On 03.10.21 01:15, Ebben Aries via Datatracker wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Sun, 3 Oct 2021 17:25:37 +0000

Yes, thank you, Ebben.  The chairs (and I'm sure the ADs) also
appreciate your thorough review and comments.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Oct 2021 14:30:03 +0200

Hi Ebben and thanks for your review.  Please see below:

>    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
Corrected.
>    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
Corrected.
> - L#016 - Minor nit: looks like L#17 should be moved up here
Corrected.
>    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C

Corrected.

>    these separately defined?

I think we are removing vuln-local-well-known.

>    scenario then best use `sbom-url` to define a static URI? (Same question

We truly hadn't considered this aspect, but I think you would be right: 
best to use sbom-url.  Alternatively we could add an optional port 
parameter.

>    or wording for the other case statement under the retrieval method choices?

Pick something better?

>    * on devices themselves: Could be /.well-known/ or a static URI could it
.well-known.  The issue is this: management systems may well query 
.well-known without ever referring to this model.
>    * on a website: Static URI only
Correct.
>    * out-of-band: Static URI only - should this leaf be named something closer

I think contact covers this appropriately.

> - L#0021: s/provide access this/provide access to this/
Corrected.
> - L#0117: s/bills of material/bill of materials/
Both need an s.
>    `ietf-mud-transparency:transparency`
Will correct in the tooling that generated this.
> - L#0941: s/not be/not been/
Corrected.
> - L#0961: s/authoration/authorization/
Corrected.
>    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3.9

Done

And thanks!

Eliot

---

From: "Dick Brooks" <[email-masked]>
Date: Fri, 22 Oct 2021 10:11:17 -0400

Eliot,

REA has open-sourced a Vendor Response File XML format that addresses SBOM access, using a URL, along with other required data needed for a comprehensive NIST software supply chain risk assessment (C-SCRM), i.e. Known Vulnerabilities disclosure:
https://github.com/rjb4standards/REA-Products

Schema file: https://github.com/rjb4standards/REA-Products/raw/master/SAGVendorSchema.xsd
Example Vendor Response File: https://github.com/rjb4standards/REA-Products/raw/master/SAG-PM-VendorResponseExample.xml
Known Vulnerabilities Declaration: https://github.com/rjb4standards/REA-Products/blob/master/KnownVulnDisclosure.docx?raw=true

A software vendor makes the Vendor Response file available to customers via an access controlled customer portal.

The materials contained in the response file are sufficient for software vendors to meet the upcoming "SBOM law" that's working its way through Congress, H.R. 4611; https://www.congress.gov/bill/117th-congress/house-bill/4611 

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: Friday, October 22, 2021 8:30 AM
To: Ebben Aries <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02

On 03.10.21 01:15, Ebben Aries via Datatracker wrote:
> Apologies for not turning this around sooner.  Structure wise, the 
> model is fairly sound.  Most of the comments below are either 
> nits/wording, slight adjustments and questions/clarifications.
>
> 1 module in this draft:
Corrected.
Corrected.
Corrected.

Corrected.

We truly hadn't considered this aspect, but I think you would be right: 
best to use sbom-url.  Alternatively we could add an optional port parameter.

Pick something better?

>    * on devices themselves: Could be /.well-known/ or a static URI could it
.well-known.  The issue is this: management systems may well query .well-known without ever referring to this model.
Correct.

Corrected.
Both need an s.
Corrected.
Corrected.

Done

And thanks!

Eliot