Subject: [Ipoverib] comments on draft-ietf-ipoib-subnet-mgmt-agent-mib-05.txt pages 15-33

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

Hi -

Additional comments on <draft-ietf-ipoib-subnet-mgmt-agent-mib-05.txt>
from bottom of page 15 to page 33:

ASN.1 comment about SwitchInfo Scalars Group erroneously talks
about a table.

ibSmaSwRandomFdbTableNum:
ibSmaSwLinearFdbTableNum: should be Gauge32 or Unsigned32,
depending on whether the 49151 (what a strange number!) is
an architectectural limit or simply the largest value reported,
even if the actual number is larger.  It would be better if
the description didn't say "count".

ibSmaSwMulticastFdbTableNum:
should be Gauge32 or Unsigned32,
depending on whether the 16383 is
an architectectural limit or simply the largest value reported,
even if the actual number is larger.  It would be better if
the description didn't say "count".

ibSmaSwLinearFdbTop: should be Gauge32 or Unsigned32, as above.
I can't find a definition for LinearFdbCap in this document.

ibSmaSwDefMcastPriPort:
ibSmaSwDefMcastNotPriPort:
ibSmaSwDefaultPort: should be Unsigned32.
The part of the description reading
       If this object is set to a non-existent port, subsequent
       responses may contain any non-existent port number."
is baffling, since these are read-only objects.

ibSmaSwLifeTimeValue:  needs a UNITS clause, and should be
Unsigned32.  The DESCRIPTION should say "reports" rather than
"sets", since this is a read-only object.  The description also
seems to be saying that all values from 19 to 31 mean "infinite".
If so, what's the point of permitting so many values?

ibSmaSwPortStateChange: this should probably be a TruthValue rather
than an Integer32, though the description leaves me wondering how
this could possibly be of any use.  The part about "This object is
set to 0 when the SMA writes a 1; writing a 0 is ignored" is also
baffling, since the MIB doesn't say how one would get the SMA to
write a 1 (or what that 1 would be written to).

ibSmaSwLidsPerPort should be Unsigned32.  Acronym LMC should
be expanded.

ibSmaSwPartitionEnforceNum should be Unsigned32.

ibSmaGuidInfoTable: are the contents of this table persistent
across reboots?  Under what conditions are entries added to this table?
Under what conditions are entries removed (e.g. hot swap)?  How does
a management system learn whether this table's contents have changed?
If an entry is removed, are other entries for that port renumbered?

ibSmaGuidIndex:  should be Unsigned32.  The SYNTAX and DESCRIPTION
are at odds: SYNTAX sets an upper bound of 255, but description says
it's implementation dependent.  I *think* you meant to say that the
upper bound is implementation independent, but is architecturally
prohibited from being greater than 255.  If so, the description
should say so.  Also what exactly is meant by "a 0 value"?  This
object is not accessible, and its syntax doesn't permit a value of
zero.
Suggestion: a simpler way to deal with ports for which GUIDs have
not been defined is to simply leave them out of the table.

ibSmaGuidVal: if I've understood the intent of this table correctly,
old:
      "The Global Unique Identifier (GUID) for this port entity."
new:
      "A Global Unique Identifier (GUID) for this port entity."
(since there may be 1..255 entries)

This part looks like it should have been split up and tweaked
as part of some long-ago reorganization of the Module:

|--****************************************************************
|-- The Port Info Group
|--****************************************************************
|ibSmaMgmtPortInfo         OBJECT IDENTIFIER ::= { ibSmaObjects 4 }
|
|ibSmaDataPortInfo         OBJECT IDENTIFIER ::= { ibSmaObjects 5 }

Suggest updating the ASN.1 comment, and moving ibSmaDataPortInfo to
where it belongs.

ibSmaPortMKey: it looks like this should figure prominently in the
Security Considerations section.
The description says there is one of these per port, but this is
a scalar.  What gives?  If it's *just* for the management port,
then the description needs some tweaking.

ibSmaPortLid  should be Unsigned32.

ibSmaPortMasterSmLid ibSmaPortLid  should be Unsigned32.

ibSmaPortIsSubnetManager
ibSmaPortIsNoticeSupported
ibSmaPortIsTrapSupported
ibSmaPortIsAutoMigrateSupported
ibSmaPortIsSlMappingSupported
ibSmaPortIsMKeyNvram
ibSmaPortIsPKeyNvram
ibSmaPortIsLedInfoSupported
ibSmaPortIsSmDisabled
ibSmaPortIsSysImgGuidSupported
ibSmaPortIsPKeyExtPortTrapSup
ibSmaPortIsCommManageSupported
ibSmaPortIsSnmpTunnelSupported
ibSmaPortIsReinitSupported
ibSmaPortIsDevManageSupported
ibSmaPortIsVendorClassSupported
ibSmaPortIsCapMaskNoticSupported
ibSmaPortIsBootMgmtSupported: You should consider the pros and cons
of combining all these into a single BITS object.
Also, in light of the naming guideines, you should consider using
either "Sup" or "Supported" in the names, but not both.

ibSmaPortMKeyLeasePeriod  should be Unsigned32

ibSmaPortMKeyProtectBits: the description should explain what each
of the enumeration values means.  The part about "must have a
non-zero value" is utterly pointless, since the SYNTAX prohibits zero.

ibSmaPortMasterSmSl should be Unsigned32.

Service Level:  several objects are defined in terms of "Service Level"
e.g., ibSmaNodeServiceLevel, ibSmaPortMasterSmSl, and
ibSmaServiceLevelIndex.  Suggest defining a common TC for these.

ibSmaPortInitTypeLoad
ibSmaPortInitTypeContent
ibSmaPortInitTypePresence
ibSmaPortInitTypeResuscitate
ibSmaPortInitNoLoadReply
ibSmaPortInitPreserveContReply
ibSmaPortInitPreservePresReply: you might consider the pros and
cons of combining these into a single BITS, particularly since
their semantics are intertwinded.

ibSmaPortMKeyViolations: this MUST be changed; this is *not*
an appropriate usage of Guage32.  Recommend Counter32 or,
if necessary, ZeroBasedCounter32.  Needs UNITS.

ibSmaPortQKeyViolations: this MUST be changed; this is *not*
an appropriate usage of Guage32.  Recommend Counter32 or,
if necessary, ZeroBasedCounter32.  Needs UNITS.

ibSmaPortNumGuid: should be Unsigned32.  The DESCRIPTION should
refer to the ibSmaGuidInfoTable, rather than some mysterious
attribute that's not defined here.

ibSmaPortSubnetTimeout  should be Unsiged32, and needs UNITS.
SubnTraps() is not defined anywhere.

ibSmaPortResponseTimeValue  should be Unsigned32 and needs UNITS.

ibSmaPortInfoTable: do entries in this table persist across reboots?
under what conditions are new entries created?  deleted?  how does
a management system learn that the table's contents have changed?

Randy

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