more detail on SMA -05 through page 15
"Randy Presuhn" <[email protected]>
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <000501c399aa$56873f20$7f1afea9@oemcomputer> |
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