Subject: [Ipoverib] more detail on SMA -05 through page 15

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 23 Oct 2003 14:12:16 -0700

Hi -

Additional comments on <draft-ietf-ipoib-subnet-mgmt-agent-mib-05.txt>
through page 15:

Section 4.3:
current:
   (Summary) from InfiniBand Architecture Release 1.1. Vol 1.
needs bracketed reference

MODULE-IDENITTY:
1) WG mailing list information belongs in CONTACT-INFO; see
draft-ietf-ops-mib-review-guidelines-02.txt section 4.5
2) Revision clauses should be collapsed into the "initial
version" (guidelines page 12)
3) Needs MIB IPR text as in section 3.8 of the guidelines.

Object Identifiers:
1) I've already raised the "experimental" issue
2) a RECOMMENDED hierarchy is provided in appendix D of the
MIB review guidelines, which would shorten the length of
notification identifiers.  (I don't see anything *wrong*
with what you have; this is just an FYI.)

ibSmaNodeString: is this really architecturally limited to
an ASCII subset?  If names are permitted in languages for
which 7-bit ASCII is not sufficient, then this really should
use the SnmpAdminString textual convention or something like
it.  Otherwise, should add some explanatory text why this
object is not appropriate for internationalization.

ibSmaNodeBaseVersion, ibSmaNodeClassVersion:
the guidelines (page 13) would RECOMMEND
Unsigned32 rather than Integer32 here, since negative values
are architecturally impossible.

ibSmaNodeType: the DESCRIPTION and the SYNTAX clauses aren't
quite aligned.  The DESCRIPTION should identify 4 as "other",
and remove 4 from the "reserved" range.  Is the plan to add
values to this enumeration in future updates to this module?

ibSmaNodeNumPorts: why is it impossible for a node to have
more than 254 physical ports?  If it *is* possible, but you
want to limit the maximum reported to 254, this should be a
Gauge32.  If it isn't, this should be Unsigned32 since negative
values clearly are impossible.  Why is the value zero excluded?
(I'm thinking about systems which support a capability through
hot-swappable plugins.)

ibSmaNodePortGuid: when it says "of this port", which port
is it talking about?  This description left me baffled.

ibSmaNodePartitionTableNum: syntax should be Unsigned32.
I'm assuming that the 65535 is an architectural limit of
the Infiniband protocol.  (If it isn't, then this bound
needs to be fixed.)

ibSmaNodeLocalPortNumOrZero: syntax should be Unsigned32.
Upper bound: same questions as with ibSmaNodeNumPorts.
The DESCRIPTION makes no sense to me as a long-time
agent developer.  In most environments, the SNMP agent
has little or no idea what port a UDP packet arrived on.
In an AgentX environment, there is no mechanism for
getting this information to a subagent.  And, of course,
there's that nagging question of "why on earth would you
want to do this?"  I can't see why any developer would
bother returning any value other than zero.

ibSmaNodeVendorId, ibSmaNodeRevision, ibSmaNodeDeviceId:
What does "device" refer to here?  Is then intent to
architecturally prohibit systems from having Infiniband
interfaces from more than one vendor?

ibSmaNodeLid:  should be Unsigned32.  Assume limit is
architectural limit of protocol.

ibSmaNodeMethod: should be Unsigned32.  Assume limit
is architectural limit of protocol.

ibSmaNodeLid2: should be Unsigned32.  Assume limit is
architectural limit of protocol.  The name is terrible.  :-)

ibSmaNodeServiceLevel: should be Unsigned32.

ibSmaNodeQueuePair1: should be Unsinged32.

ibSmaNodeQueuePair2: should be Unsigned32.

ibSmaNodeGid2 & ibSmaNodeGid1: when it says "this value will be 0"
does it mean to say that they will be all zeros?

ibSmaNodeSwitchLid: should be Unsigned32

ibSmaNodeDataValid: this really should be BITS rather than OCTET STRING.

Randy

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib