Hal wrote:
[HAL] > Do you see a way to handle the different SA client registrations for
[HAL] > events (InformInfo) where an incoming Report could go to multiple
[HAL] > clients with the current approach ? Even adding attribute ID is
[HAL] > insufficient as there would need to be some sense of what reports were
[HAL] > being registered for (perhaps by TrapNumber but one could support even
[HAL] > more granularity including ProducerType and other fields in the
[HAL] > subscription (InformInfo) request).
I think the issue I raised with the InformInfo was a bad example.
I reread the chapter. Actually, if we let two clients respond to a single incoming an-affiliated (unsolicited) MAD, we will break the assumption that there is only one response to a request. The SubnAdm.Report(Notice) has a response defined.
After reading the spec again, I think the idea was that if a client wants to register to a Report - it should use a special QP for that sake. The SA is providing filtering by whatever InformInfo field is available. The Report will be sent to the QP the SubnAdmin.Set(InformInfo) came from.
So let me revert what I have said. I think that having a single manager to each class is quite reasonable. Otherwise it is un-clear to me which client will be generating the response.
Sorry for the confussion.
EZ
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
