<html>
<body>
<font size=3>At 03:11 AM 9/29/2004, Hal Rosenstock wrote:<br>
<blockquote type=cite class=cite cite="">On Tue, 2004-09-28 at 11:38,
Roland Dreier wrote:<br>
> Hal> At IBA 1.2, C15-0.1.22 is obsolete
and has been replaced by<br>
> Hal> C15-0.2.1. C15-0.2.1: When a
requester node sends a trusted<br>
> Hal> request to SA, the requested data
shall be returned. When a<br>
> Hal> requester node sends a non-trusted
request for data to SA<br>
> Hal> that would provide information about
a subject node, the SA<br>
> Hal> shall return only data providing
information about subject<br>
> Hal> nodes for which the requester shares
a P_Key, with exceptions<br>
> Hal> noted below in C15-0.1.23.<br>
> <br>
> Hmm, this seems like the only difference from C15-0.1.22 is that
it<br>
> talks about trusted requests. C15-0.1.23 (below) still says
that<br>
> MCMemberRecords don't provide information about any subject nodes,
so<br>
> I guess the SM should not worry about P_Keys when returning the
table<br>
> of multicast groups.<br><br>
You are correct about the IBA 1.1/1.2 compliance difference (and
the<br>
trusted request part is not relevant to this discussion). <br><br>
C15-0.1.22 does, however, talk about PKey sharing which is relevant
to<br>
this (and consistent with 15.4.1 below).<br><br>
The intent is that the SA only return information relative to the<br>
partitions that the port was part of. The below is from IBA 1.1 (and
1.2<br>
as well):<br><br>
15.4.1 Restrictions on Access<br>
There are two types of access restrictions involved in SA:<br>
Authenticating the requester of information, and restricting the
data<br>
that the requester is allowed to receive. These are discussed below.
The<br>
SA access restrictions described here are based on partition
membership,<br>
and are intended to implement this rule: If access to data is allowed
by<br>
partition membership, that access is granted; but if it is
disallowed,<br>
the requester should remain unaware of the existence of that
information<br>
and of the network elements containing that information.
Additionally,<br>
in no event is authentication information made available to
untrusted<br>
requests. That a node s PortInfo:M_Key and PortInfo:M_KeyProtectBits
may<br>
prohibit access to some data by SMPs without a valid M_Key has no<br>
bearing on SA access restrictions.<br><br>
> Roland> C15-0.1.23: [...] MCMemberRecords
shall always be provided<br>
> Roland> with the PortGID, Join- State and
ProxyJoin components set<br>
> Roland> to 0, except for the case of a
trusted request, in which<br>
> Roland> case the actual component
contents shall be provided.<br><br>
You omitted the following:<br>
C15-0.1.23: Subnet Administration shall follow the following
additional<br>
rules concerning data access:<br><br>
Perhaps it is the language which is confusing and somewhat<br>
contradictory:<br><br>
C15-0-1.22 (IBA 1.1) and C15-0.2.1 (IBA 1.2) state "Subnet
Administrator<br>
shall return only data providing information about subject nodes
for<br>
which the requester shares a P_Key, with exceptions noted below in<br>
C15-0.1.23:."<br><br>
whereas:<br>
C15-0.1.23 states "Subnet Administration shall follow the
following<br>
additional rules concerning data access" and one of those rules
concerns<br>
MCMemberRecord.<br><br>
My interpretation is that the Pkey sharing is the first level
rule</font></blockquote><br>
P_Key sharing and access is the first rule - no endnode should be able to
acquire information unless it is authorized.<br><br>
Mike<br><br>
<blockquote type=cite class=cite cite=""><font size=3>before the
following is applied from C15-0.1.23:<br>
"MCMemberRecords shall always be provided with the PortGID, Join-
State<br>
and ProxyJoin components set to 0, except for the case of a trusted<br>
request, in which case the actual component contents shall be
provided."<br>
which is what you are citing to say you get all the multicast
records.<br><br>
-- Hal </font></blockquote></body>
</html>