Early Review of draft-ietf-opsawg-sbom-access-02
review-ietf-opsawg-sbom-access-02-yangdoctors-early-aries-2021-10-02-00

Request Review of draft-ietf-opsawg-sbom-access-02
Requested revision 02 (document currently at 18)
Type Early Review
Team YANG Doctors (yangdoctors)
Deadline 2021-08-25
Requested 2021-08-04
Requested by Joe Clarke
Authors Eliot Lear , Scott Rose
I-D last updated 2021-10-02
Completed reviews Secdir Early review of -09 by Christian Huitema (diff)
Yangdoctors Early review of -02 by Ebben Aries (diff)
Genart Early review of -03 by Russ Housley (diff)
Opsdir Early review of -03 by Niclas Comstedt (diff)
Secdir Last Call review of -14 by Christian Huitema (diff)
Comments 
The authors have requested a specific review from SEC DIR and YANG Doctors.  On the security side, a look at veracity of the SBOM vulnerability proposal in additional to its general usefulness.  On the YANG Doctors side, Eliot has said he regularly makes YANG mistakes so guidance would be appreciated.
Assignment Reviewer Ebben Aries
State Completed
Request Early review on draft-ietf-opsawg-sbom-access by YANG Doctors Assigned
Posted at https://mailarchive.ietf.org/arch/msg/yang-doctors/Yo55mOLONFUsz1YT4G4089jfOCA
Reviewed revision 02 (document currently at 18)
Result Almost ready
Completed 2021-10-02
review-ietf-opsawg-sbom-access-02-yangdoctors-early-aries-2021-10-02-00
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:
- ietf-mud-transparency@2021-07-06.yang

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 ietf-mud-transparency@2021-07-06.yang:
- 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