Re: draft-yang-ib-subnet-management-mib-01.txt

Hi -

A few quick comments on<draft-yang-ib-subnet-management-mib-01.txt>,
through page 29.  I didn't go any further because the same problems were
recurring over and over and over again and again.

The various read-write objects in ibSmConfigTable should be read-create, since rows
can be manipulated using RowStatus.

ibSmConfigPriority: a TC would probably be appropriate.  Unconstrained INTEGER
is almost certainly not.

ibSmConfigSMKey:  the description makes this object sound like it's something other
than a key.  Is the default value really supposed to be a string of the ASCII character
"0"?

ibSmConfigOperStatus: the SYNTAX clause should identify the enum values.  Note that
there is work in the entity MIB working group that overlaps these semantics.  Please see
A DEFVAL would probably make sense, too.

ibSmConfigSweepInterval: needs UNITS.  The SYNTAX should be Unsigned32, and
it would probably make sense to put some bounds on it.

ibSmConfigResponseTimeout: needs UNITS.  Should be Unsigned32, and
range constraints would make sense.

ibSmConfigPortAgingTime: needs UNITS.  Should be Unsigned32 with range constraints.

ibSmConfigMinUnicastLID: isn't there a TC that this can use?  underlying syntax should be
Unsigned32 rather than INTEGER.  Would a DEFVAL make sense?

ibSmConfigMaxUnicastLID: isn't there a TC that this can use?  underlying syntax should be
Unsigned32 rather than INTEGER.  Would a DEFVAL make sense?

ibSmConfigDefaultLMC: should be Unsigned32.

ibSmConfigMasterPollInterval: needs UNITS.  Should be Unsigned32 with range constraints.

 ibSmConfigMasterPollRetries: needs UNITS.  Should be Unsigned32 with range constraints.
The DESCRIPTION is self-contradictory as to whether this is the number of retries or an interval.

ibSmConfigMKeyLeasePeriod: needs UNITS.  Should be Unsigned32 with range constraints.

ibSmNodeInfoBaseVersion: unconstrained INTEGER is almost certainly not what you want here.
ibSmNodeInfoClassVersion: ditto

ibSmNodeInfoType: emueration should be specified in SYNTAX as well as DESCRIPTION.

ibSmNodeInfoNumPorts: unless the architecture allows for a device with a negative
port count, this syntax should be Unsigned32.  If the architecture limits the number
of physical ports, range constraints would be appropriate.

ibSmNodeInfoSystemImageGUID:  what does "Set to zero" mean here?

ibSmNodeInfoPartitionCap: should be an Unsigned32 with range constraints.

ibSmNodeInfoLocalPortNum:  objects like this are difficult to implement reliably,
especially if subagent protocols are in use.  If the WG has a *very* persuasive reason
for wanting such an object, then at least use an appropriate TC for the SYNTAX.

ibSmNodeInfoVendorID: should be a bit more specific about where to look these up.

 ibSmNodeInfoDescription: if this is trluy limited to seven-bit ASCII, there should be
a good justification for this limitation.  If not limited to seven-bit ASCII, then UTF-8,
as in SnmpAdminString, would be more appropriate.

ibSmPortInfoSubnetPrefix: MAX-ACCESS should be not-accessible
ibSmPortInfoNodeGUID: should be not-accessible

ibSmPortInfoLocalPortNum: should be not-accessible, SYNTAX should probably
use a common TC, underlying type should be Unsigned32.

ibSmPortInfoMKey: these "key" things show up enough that a TC would be appropriate.

ibSmPortInfoLID: should use common TC, with underlying Unsiged32 syntax.
ibSmPortInfoMasterSmLID: ditto

ibSmPortInfoCapMask: data type should be BITS.

ibSmPortInfoDiagCode: the DESCRIPTION is not helpful.

ibSmPortInfoMKeyLeasePeriod: needs UNITS.  Should be Unsigned32.
DESCRIPTION is inconsistent about object semantics; last sentence indicates
that it's a timer rather than a period or interval.

ibSmPortInfoLinkWidthEnabled: enumeration values should be spelled out in SYNTAX
as well as DESCRIPTION.

ibSmPortInfoLinkWidthSupported: enumeration values should be specified in SYNTAX.
ibSmPortInfoLinkWidthActive: ditto (it may make sense to use a TC here)

ibSmPortInfoLinkSpeedSupported: this seems redundant with the information in
the interfaces table.  Why is this object needed?  In any case, enumerations should
be specified in SYNTAX.

ibSmPortInfoState:  enumeration values shoul be specified in SYNTAX as well as description.
ibSmPortInfoPhyState: ditto.  "legal" transitions should be defined.
ibSmPortInfoLinkDownDefState: ditto

ibSmPortInfoMKeyProtBits: syntax could be BITS, but it looks like a three-value enum
would make more sense.

 ibSmPortInfoLMC: TC time?  syntax should be Unsigned32.

 ibSmPortInfoLinkSpeedActive,   ibSmPortInfoLinkSpeedEnabled: should use common TC,
with enumeration spelled out in SYNTAX.  "legal transitions" should be defined or referenced.

ibSmPortInfoNeighborMTU: is it permitted to write a 6?  If so, what happens then?

ibSmPortInfoMasterSmSL: should use common TC with underlying Unsigned32 syntax.

ibSmPortInfoVLCap: DESCRIPTION should spell out what enumeration values mean.

ibSmPortInfoVLHighLimit: should be Unsigned32, probably use TC
ibSmPortInfoVLArbHighCap: ditto
ibSmPortInfoVLArbLowCap: ditto

ibSmPortInfoMTUCap: what does "reserved" mean?  It might make more sense
for this object to have a SYNTAX like Unsigned32 (256 | 512 | 1024 | 2048 | 4096)
with a UNITS clause.

ibSmPortInfoVLStallCount: should be Unsigned32 and have UNITS.

ibSmPortInfoHOQLife: should be Unsigned32 and have UNITS.  What does "0" mean?

ibSmPortInfoOperVL: DESCRIPTION  should spell out what each of the enum values means.

ibSmPortInfoMKeyViolation: the ZeroBasedCounter32 TC would be more appropriate here.  UNITS appropriate.
ibSmPortInfoPKeyViolation: ditto
ibSmPortInfoQKeyViolation: ditto

ibSmPortInfoGUIDCap: should be Unsigned32 with UNITS
ibSmPortInfoSubnetTimeout: ditto.  should explain what zero means.
ibSmPortInfoRespTime: ditto.
ibSmPortInfoLocalPhyError: ditto. should also be more precise in description.
strictly speaking, it currently says every error encountered after the threshold is
reached will trigger a local link integrity error.  I doubt that this is what you want.

ibSmPortInfoOverrunError: a big cumulative DITTO.  :-)

ibSmPortInfoInitType: syntax should probably be BITS.
In general, we frown on "Optional".  In any case, the DESCRIPTION
made no sense to me, so it probably needs some wordsmithing so
mortals can understand what this object is supposed to do.

ibSmPortInfoInitTypeReply: ditto

ibSmSwitchInfoSubnetPrefix: MAX-ACCESS should be not-accessible

ibSmSwitchInfoNodeGUID: should probably use common TC, MAX-ACCESS should be
not-accessible

ibSmSwitchInfoLinearFdbCap: should be Unsigned32 with appropriate constraints; UNITS would be nice.

 ibSmSwitchInfoRandomFdbCap: ditto

 ibSmSwitchInfoMcastFdbCap: ditto;  perhaps a common TC would make sense?

ibSmSwitchInfoLinearFdbTop: should be Unsigned32.

ibSmSwitchInfoDefaultPort: should use common TC, underlying Unsigned32.  Would a "bit-
bucket" value make sense?

ibSmSwitchInfoDefPriMcastPort: ditto

Randy