Define the method to describe capabilities

[wmunyan]

As discovered during personal hackathoning pre-IETF 110, an extensible set of enumerations (IANA table?) should be defined to describe the different capabilities that components could implement. Types of orchestrators, collectors, evaluators, etc.

Devised a set of "capability urn's" that represent these. Implementations can then associate a "capability urn" to a topic or set of topics to which messages can be sent/received/published/subscribed, at the discretion of the implementation.

i.e.

urn:capability:collection:oval --> capability to collect posture information defined in OVAL objects.

[adammontville]

@wmunyan, in the above you wrote, "Devised a set...". Does that mean that you have a list of URNs that represent the capabilities defined somewhere, or did you mean that these URNs still need to be defined? If they exist somewhere, can you publish here so they can be added to the draft?

[bmunyan]

@adammontville anything i might have had/added was on a VM that became CIS property, so as a great replicant once said, it is now "lost in time, like tears in the rain"

[adammontville]

That's unfortunate. Do you have any recollection of what you did?

[bmunyan]

apart from the example above, not much. i think the idea was to associate "capability urn's" to topic(s), but i feel like, during the "pre-the-previous-ietf" timeframe, i may have thought it was overkill to try and abstract specific topic names to the capability urn crap.

I feel like this was part of the component onboarding bits - some component registers with the manager and says "i can do 'foo'", and the manager replies with "because you can do 'foo', subscribe to these topics" -- it was a way to let components advertise what they do.