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: - [email protected] 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 protected]: - 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?
* 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
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
