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

["Joe Clarke (jclarke)" <[e-mail]>]

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

Joe

On 10/3/21 04:49, Eliot Lear wrote:
> 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:
>> 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
>> - 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
>>
>>
>>
>> _______________________________________________
>> OPSAWG mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/opsawg
>>