Re: [sacm] Question regarding Figure 2 in the SACM Architecture -00

["Schmidt, Charles M." <[e-mail]>]

Hi Bill,

Thanks for the clarification (and sorry about my delay in responding).

Your goal for figure 2 makes sense, and I appreciate that you are including. My confusion came from the multi-component nature of both SWIMA and EPCP. There are some parts of those standards where it would make complete sense to integrate with an XMPP-Grid Connector (namely the NEA servers), but other parts where this makes less sense (SWIMA PCs and PVs, or individual endpoints). I was a bit concerned that by lumping everything together under "SWIMA", there might be some confusion.

That said, in reviewing the figure again, "Datastream", "YANG Push", and "IPFIX" are also pretty general terms, so I suspect I was reading too much into the diagram. Given a better look at the context and your explanation, I think my concerns are allayed. 

Thanks for your help.

Charles

-----Original Message-----
From: Bill Munyan <[e-mail]> 
Sent: Wednesday, September 12, 2018 8:55 AM
To: Schmidt, Charles M. <[e-mail]>
Cc: <[e-mail]> <[e-mail]>
Subject: Re: [sacm] Question regarding Figure 2 in the SACM Architecture -00

Charles, 
Thanks for the question.  I think the intent of figure 2 is to provide notional examples of the fact that there could be many different endpoint attribute collection systems representing various types of posture collection, such as asset inventory, configuration and vulnerability management.  EPCP is one such collection system (and is diagrammed as a pointer to asset inventory) and the box for that in the diagram should represent an entire EPCP implementation, as per that spec (including posture collection manager, posture collectors, posture validators, etc).  Another example, labeled "datastream" is meant to represent those collectors able to interpret SCAP datastreams, collect system characteristics, etc.  The idea is that many disparate collection systems may collect endpoint posture attributes in their own way, and would thus need a set of interfaces (the "XMPP Grid Connector") to publish that information to the message transfer system (XMPP with Pub/Sub for example).

If the labeling is off or misleading, we'd be happy to get consensus on what would be the clearest label.

Cheers, 
-Bill M.


On Tue, Sep 11, 2018 at 3:59 PM Schmidt, Charles M. <[e-mail] <mailto:[e-mail]> > wrote:


	Hello,

	 

	A quick question regarding Figure 2 in the SACM Architecture -00 draft: It looks like there is a connection between “SWIMA” and an XMPP-Grid connector. By “SWIMA” do you mean a “NEA Server”? I could certainly see a NEA server interacting with an XMPP Grid Connector. I’m less convinced of there being a SWIMA PV or a SWIMA PC having a direct connection to a Connector.

	 

	For that matter, NEA Server might be an appropriate word to use for the ECP as well, since ECP is also multi-component, and some of those components probably don’t need direct interactions with Connectors.

	 

	Thoughts?

	 

	Charles

	_______________________________________________
	sacm mailing list
	[e-mail] <mailto:[e-mail]> 
	https://www.ietf.org/mailman/listinfo/sacm