Eliot Lear <[email protected]> wrote: >> Hi Eliot, >> >> 0) PLEASE ADOPT THIS DOCUMENT. >> (Also I have some other MUD related documents which await the chairs' attention)
> +1, but let’s not expect a rush on approval. Lots of work needed.
>>
>> As I said in the meeting, I don't really understand sbom-local.
>> I asked this online, but let me repeat.
>>
>> 1) It seems that just putting coaps:///.well-known/sbom in the URI might
work as well.
>> If necessary, then maybe: coaps://127.0.0.1/.well-known/sbom or
https://[::1]/.well-known/sbom
>> CoAP does have a Content-Type for returned content, but it is true that
>> there isn't as much negotiation by default in the form of Accept:
> I don’t think /// is a real construct. There are two issues. We don’t
> know the hostname and we don’t know the scheme. But the MUD manager
> does know the hostname, and we need to be provided the scheme. There
> is no convention for ME without a pre-existing context. That might be
> something to work on, but it would hav to happen in coordination with
> the COAP and HTTP working groups, and I don’t know how big a job it
> would be. Thus what’s there.
okay, good point.
I think that the self-hosted SBOM is relatively unlikely.
I just don't think we should complicate the system too much to accomodate it.
>> 2) I think that I'm interested in what the format of the sbom is than I
am
>> about how to get it.
> Well, you have your choice of at least three different classes and
> multiple encoding variants. Nice thing about standards, eh?
:-)
>> 3) I think that, in general, that the SBOMs will seldom be hosted on a
>> constrained device that is capable of being described by MUD.
>> {that is, devices that can self-host an SBOM, will tend to be servers,
>> desktops, etc. that are not easily described by MUD.
> Perhaps. I can’t say. We’re going to need some operational
> experience. There are a number of use cases in the IoT field where you
> plug in different components that require different software loads.
> One aspect of SBOM, by the way, that hasn’t been explored is the
> difference between software being installed and the code being placed
> in service. Particularly drivers and supporting user-level software.
I completely agree: same actuator platform connector to different kinds of
"valves"
No reason why a variable gas regulator should be significantly different than
a variable water regulator.
Except for the physical mechanism they are attached to, and therefore some
parameters about how fast/slow to move things. Why keep two kinds of spares?
>> So I am not convinced that this is use case is reasonable.
>>
>> Alternative paths:
>>
>> a) There is also a draft, draft-moran-suit-mud-00
>> Strong Assertions of IoT Network Access Requirements
>>
>> which would provide a MUD URL as part of a Software Update process.
>> It will be at secdispatch on Thursday.
> How did this go?
It has been sent back to SUIT.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
