
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

<HTML>

<HEAD>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">

<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">

<TITLE>RE: [openib-general] Some Missing Features from mthca/user MADaccess</TITLE>

</HEAD>

<BODY>

<BR>


<P><FONT SIZE=2>Hal wrote:</FONT>

<BR><FONT SIZE=2>[HAL] > Do you see a way to handle the different SA client registrations for</FONT>

<BR><FONT SIZE=2>[HAL] > events (InformInfo) where an incoming Report could go to multiple</FONT>

<BR><FONT SIZE=2>[HAL] > clients with the current approach ? Even adding attribute ID is</FONT>

<BR><FONT SIZE=2>[HAL] > insufficient as there would need to be some sense of what reports were</FONT>

<BR><FONT SIZE=2>[HAL] > being registered for (perhaps by TrapNumber but one could support even</FONT>

<BR><FONT SIZE=2>[HAL] > more granularity including ProducerType and other fields in the</FONT>

<BR><FONT SIZE=2>[HAL] > subscription (InformInfo) request).</FONT>

</P>


<P><FONT SIZE=2>I think the issue I raised with the InformInfo was a bad example.</FONT>

<BR><FONT SIZE=2>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. </FONT></P>


<P><FONT SIZE=2>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.</FONT></P>


<P><FONT SIZE=2>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.</FONT></P>


<P><FONT SIZE=2>Sorry for the confussion.</FONT>

</P>


<P><FONT SIZE=2>EZ</FONT>

</P>


</BODY>

</HTML>