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: >> - [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 >> - 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsawg >> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
