<div dir="ltr">Hi,<div><br></div><div>Yesterday we had a discussion about a BMC aggregator. I've put together a summary of the topics we discussed.</div><div><br></div><div>----------------------------------------------------------------------------------------</div><div>Security</div><div><br></div><div>The meeting started by addressing the security model for the aggregator.  The head node of the aggregator should have some form of mutual authentication with each of the child nodes that are being aggregated. This authentication between nodes may be waived in cases where there is some implicit trust in physical link (i.e. an IPMI connection over LPC or SMBUS).</div><div><br></div><div>Regardless of the internal authentication mechanism used, the head node will be solely in charge of authenticating external client requests, and it will also be in charge of assigning authorization rules.</div><div><br></div><div>One point that was made was that if the aggregator ever lives "off" the machine that may break this security model, since it would force all of the child nodes to be aware of the external network</div><div><br></div><div>----------------------------------------------------------------------------------------------</div><div>Supported Protocols and Data Models</div><div><br></div><div>We had a discussion about the supported protocols.  There is a pretty diverse set of protocols that we may want to support as inputs into the aggregator.  There will need to be a process/daemon that is in charge of importing child nodes, and converting them to the aggregator data model.</div><div><br></div><div>One point that was made in the meeting is that having many processes each doing their own protocol transformations is a performance risk. This risk can be mitigated if we assume that an aggregator is only aggregating a single protocol at a time. </div><div><br></div><div>----------------------------------------------------------------------------------------------</div><div>Presentation</div><div><br></div><div>When it comes to the presentation of the aggregator, there will most likely be a Redfish frontend and an IPMI frontend.  However, there may be use cases in the future with upcoming protocols (e.g. RDE over PLDM).</div><div><br></div><div>Because there may be a number of disparate requirements for exposing the aggregator to the outside world, it is very important that the aggregator provides a rich data model that other applications can program against.</div><div><br></div><div>----------------------------------------------------------------------------------------------</div><div>Next Steps</div><div><br></div><div>At this point I think we have gotten a lot of feedback on use cases and requirements.  The next step is to iterate on designing a data model.  I will be putting together a first pass at the data model for us to discuss.</div><div><br></div><div>Regards,</div><div>Richard</div></div>