Re: [yang-doctors] [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-sbom-access-02

[Eliot Lear <[e-mail]>]

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

On 03.10.21 01:15, Ebben Aries via Datatracker wrote:
> 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:
> - [e-mail]
>
> 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 [e-mail]:
> - import `ietf-inet-types` should reference RFC 6991 per
>    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
Corrected.
> - import `ietf-mud` should reference RFC 8520 per
>    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.
> - L#018-020 - Minor nit: adjust email address formatting per
>    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C

Corrected.

> - 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?

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

> - 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)

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.

> - 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?

Pick something better?

>
>    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?
.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
>      to that vs. 'contact'?

I think contact covers this appropriately.


>
> General comments on the draft/modules:
> - L#0021: s/provide access this/provide access to this/
Corrected.
> - L#0117: s/bills of material/bill of materials/
Both need an s.
> - L#0627: JSON example needs correct prefix for the augment
>    `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.
> - 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


Done


And thanks!


Eliot