> On 14 Oct 2020, at 21:41, Michael Richardson <[email protected]> wrote: > > > Eliot Lear <[email protected]> wrote: >> This is the same draft that was presented some time ago to you. >> However, the emphasis is changed- MUD is not the sole means by which an >> SBOM can be discovered. The context will matter. > > okay. > >> My request is that we discuss this in the WG, and then consider it for >> adoption, understanding that it has a bit of a road to travel still. > > I'm not sure that I understand why you are using the term "layer" in > "application-layer management system"? Or maybe it is "application" > That section reads poorly, even though I eventually understood it.
Yeah, edits welcome. Imagine a pool of applications servers that you’re managing with a cloud orchestration system. That’s the use case. > > I understand that it's an *application management system*, because it is > managing some application server. But, I don't understand "layer" here, > which suggests "layer-7", when really the application management system > really manages all the layers? > Maybe people think of HTTP as being a kind of layer-5 or 6, rather than 7. > (But, really nothing beyond layer 4 has any meaning between OSI terminology > and reality) > > Anyway, I thought that you were going to use a template for local-uri, > instead of having the enumeration of scheme? I got an opinion that either we go with .well-known OR we go with a schema, but not both. I think this is still an open issue, tho. > > While the set of SBOM formats is far from set in stone, and I think that > each will have a MIME type, I want to suggest that this document make it > clear that HTTP content negotiation should be used to get the format > one wants and/or that the type returned will be tagged via Content-Type. Agree. > > Should the MUD file contain a text description of what content-type(s) are > available? Avoiding for now, any kind if enumeration, aiming just for > human consumption? I guess I would want to explore the use case a bit. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
