Hi Joe,Thanks for your review. Please see below. What is listed is what is proposed (my co-author might have some thoughts here).
See also the changes in https://github.com/elear/mud-sbom. On 14.04.22 23:38, Joe Clarke (jclarke) wrote:
A number of comments as a contributor: * The tree diagram doesn't reference RFC8340 (see RFC8407 Section 3.4)
Corrected.
* The description of the transparency-extension grouping is a tautology. This is one of my pet peeves. Can you add more flavor here?
Fleshed out a tad.
* Replace use of s/w and h/w with software and hardware respectively.
Done.
* Would it make sense to further refine your contact leafs to check for the MUST URI schemas?
I know what you want, but I'm not quite sure it is well specified how to do it. Patterns in general seem underspecified. If someone can explain how to do it, I'm happy to add.
* Your description for sbom-url and vuln-url are different. One says statically located URI whereas the other says statically located URL. I think the latter is correct.
Corrected.
* The type for sbom-local-well-known is an enum. Would it make sense to make this an identityref so that other schemes may be used in the future?
Yes, I think this makes sense, but I would like to understand if there are any implications when the YANG has to stand alone without the use of NETCONF or RESTCONF.
* When you say "customers" in this document, I think "users" is a better term.
There are two specific uses of the term. I've replaced one of them with "administrators". The other one seems to be correct with customers.
* Your example in Section 5.1 also uses the "ol" extension. I think you should omit that in this draft for better clarity.
There was some discussion about this. What do others think?
* In your security considerations, I don't grok this text: In as much as the module itself is made writeable, this only indicates a change in how to retrieve what read-only elements.
That's probably because it's poor English. The word "what" is extraneous, and I will make clear that there is no way to upload, for instance, an SBOM.
But it does raise a question: why are these objects read-write? I'd think they'd be more operational and read-only from a Thing or device.
I can't envision every use of the module, and it might be the case that there are some times when it may be useful to administratively point the URL elsewhere .
* Section 8: "review" is misspelled.
Corrected. Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
