* 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.
Thanks. Much better.
* 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.
I can't recall having seen this done before, but I was thinking along the lines
of:
type inet:uri {
pattern "(mailto)|(https?)|(tel):.*";
}
* 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.
Identities and indentityrefs are standard YANG constructs. One need not have
*CONF to use them.
* 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.
WFM.
* 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?
The draft came back to life, but I still think it's extra material that isn't
needed to understand the SBOM use case.
* 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.
Yeah, figured it just needed a typo check.
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 .
Okay. You did shore up security requirements.
Joe
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
