From: OPSAWG <[email protected]> on behalf of Russ Housley via Datatracker <[email protected]> Sent: 13 December 2021 22:02 Subject: [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03
Reviewer: Russ Housley Review result: Almost Ready <snip> Note: I am not a good persone to review the YANG specification. I assume one of the YANG Doctors will have a look at this document too. <tp> You could say that there is no YANG Module as YANG Modules must be registered with IANA and the IANA Considerations in this I-D do not do so:-) So IANA Considerations must register the module as per YANG Guidelines Security Considerations must use the template referenced by YANG Guidelines The title in the revision reference clause bears little relationship to that of the I-D YANG prefix must be unique and should be easy to use; I think that 'mud-transparency' is about 12 characters longer than I would class as easy to use (e.g. mudtx) URL is insecure and to an obsolete web site (tools) No mention of NMDA or lack of support thereof Lots of abbreviations not expanded on first use In our modern pageless format, Section one would be easier to refer to with more subsections such as one for terminology with expanded abbreviations Why have a grouping and a uses which for me makes the module harder to understand? It is not as if this grouping is going to be imported in lots of places AFAICT. Tom Petch Major Concerns: Section 1 says: To satisfy these two key use cases, objects may be found in one of three ways: This lead to some confusion for me. Earlier in the document, it says: This specification does not allow for vulnerability information to be retrieved directly from the endpoint. That's because vulnerability information changes occur at different rates to software updates. After thinking about it, I realized that the objects do not include vulnerability information, but pointers to obtain vulnerability information. Please reword to others do not need to give it the same amount of thought. Minor Concerns: Section 1, first sentence: The reference to "A number of activities" is very vague. It is not wrong. Please be more specific, provide some references, or drop the vague reference altogether. Section 1 says: In the second case, when a device does not have an appropriate retrieval interface, but one is directly available from the manufacturer, a URI to that information must be discovered. s/must/MUST/ ? Nits: The terms "software" and "firmware" are used with essentially the same meaning in this document. If there is a difference, it needs to be explained. If they are the same in the context of this document, please say so. Abstract, last sentence: please add "(MUD)" and also a pointer to RFC 8520. Section 1, first sentence: The reference to "A number of activities" is very vague. It is not wrong. Please be more specific, provide some references, or drop the vague reference altogether. ______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
