Section 3.1.3 - Controller - Registration/Discovery

[jimsch]

version -03

There needs to be a statement about discovery of consumers as well. This is needed in order to do spontaneous publication of attributes.

You need to be able to discover portions of the control plane as well. You need to be able to find brokers and proxies as well as their capabilities.

[henkbirkholz]

In general, the discovery of target endpoints and the discovery of SACM components (with specific attributes, such as roles or functions or acting as a provider or consumer via SACM interfaces or even existing standard interfaces) must be distinguished, I think. This would also "solve" the discovery of consumers as well.

Also, the subsection "Registration/Discovery" is basically focusing on discovery and not registration.

[ncamwing]

Fair point, the draft can be clearer in these distinctions. I think I cited the "obvious" one which is the publishers, but consumers should be mentioned.
As for target endpoints, the discovery of target endpoints am not sure is a SACM component, but perhaps an operation of the SACM model?

[jimsch]

I would tend to think that discovery of target endpoints is a function of a collection task. That can either be an internal or an external collector. I agree that it is not a SAC component per say.

[llorenzin]

Lisa - seems odd to say an internal collector would have a function of discovering the endpoint it's running on
Nancy - wasn't thinking of registration / discovery of target endpoints, but of SACM components
Jess - would an internal collector be able to discover itself?
Henk - internal collector is SACM component, on fringes of SACM domain, on target endpoints that are the assessing component at the same time
Nancy - what does internal collector mean?
Henk - SACM component is part of SACM domain, runs on endpoints that are typically not target endpoints
target endpoints are endpoints of interest, to be assessed
Outside SACM domain is rest of the world visible to SACM domain
Fringe use case - line blurs because endpoint is target endpoint and also SACM component - "internal" collector resides on it
Lisa - I didn't think having an internal collector made a target endpoint a SACM component
Think the SACM component is the provider that rolls up the collection results
Nancy - that was my thought as well
Henk - target endpoint becomes a SACM component because it has building blocks running on it - SACM functions, registrative broker and publishers
Lisa - don't think every target endpoint is a SACM component - only if it's also a provider
Henk - only if it has an internal collector on it
Jess - distinction between an internal collector and a provider - why?
Lisa - internal collector doesn't necessarily publish into SACM ecosystem
if it doesn't publish, it's not a SACM component
Jess - NEA world, collector provides information to a server, which is part of the control plane
Lisa - NEA server is the provider, NEA client is just software on endpoint
Henk - semantically, if a piece of software on an endpoint is speaking SACM - can discover guidance or register to a broker - this can be the case, should be highlighted - it's a SACM component
if just produces information and transports it to the first SACM component, then this is remote collection
typical collection that over the network is assessing the endpoint
maybe have a trusted, registered, attested component on the target endpoint - could trust it
Lisa - that's not what an external collector is either
In the NEA example the NEA client is just software on the endpoint
it's not a SACM component - doesn't publish into the provider/consumer ecosystem, doesn't use a SACM transport
NEA server is the provider, so it aggregates the information from the internal collectors on target endpoints and uses the SACM transport to provide that information
Jess - wasn't aware this group had defined a transport
Nancy - XMPP-Grid is a proposed transport
Jess - what about IF-T TLS?
Henk - transport here is overloaded
Lisa - we decided not to specify the transport between the target endpoint and the SACM component
SACM transport is transport between SACM components
other transport between endpoint and SACM component
Jess - NEA client publishing data about itself, is that a SACM component?
Lisa - if it's publishing directly, yes
Nancy - think you're mixing implementation details
if you made the NEA client become a SACM provider, adhered to the data model, then yes
Lisa - endpoint can be a SACM component but doesn't have to be
Henk - we don't define how you get information from the target endpoint
Just says the SACM component uses any means to get information from the target endpoint
Think this is restricting the scope of the SACM domain, important choice, should be highlighted to the email list
Understand the argument - don't see why you can't allow a SACM component to reside on a target endpoint
Lisa - not saying that - like difference between TNC client and IMC - IMC is like internal collector, TNC client is like SACM component
Josh - have a simple drawing?
Lisa - would be good to have a drawing showing relationships between functions and components
Josh - basic entity / relationship map

[llorenzin]

NCW - consumer could be another SACM component, as well as portions of the control plane
separate from the thread of NEA Client
LL - will open a new open issue for the question of whether a NEA client is SACM component or internal collector
NCW - discovery is meant to be of any SACM component, not just provides
Nancy to add new language to reflect discovery of any SACM component and of control plane capabilities