comments on draft-ietf-ipoib-subnet-mgmt-agent-mib-05.txt pages 33-45

"Randy Presuhn" <[email protected]>
Newsgroups gmane.ietf.ipoib
Message-ID <000501c399cc$df2aad40$7f1afea9@oemcomputer>
Hi -

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

ibSmaPortLinkWidthEnabled: the enum list and the DESCRIPTION don't
match.  In any case, the NOP value makes no sense at all for a
read-only object.

ibSmaPortLinkWidthSupported: the enum list and DESCRIPTION don't
match.  Are the "reserved" values for future use?

ibSmaPortLinkSpeedSupported: the enum list and its DESCRIPTION
contradict each other.

ibSmaPortLinkState: the enum list and the DESCRIPTION contradict
each other.  "No change" does not make sense for a read-only object.

ibSmaPortPhysState: the enum list and the DESCRIPTION contradict
each other.  Furthermore, "no change" is not a meaningful state,
and not a sensible value for a read-only object to have.

ibSmaPortLinkDownDefaultState: the enum list a DESCRIPTION contradict
each other.

ibSmaPortLidMaskCount: it sounds like this should be a Gauge32,
but the word "count" in the DESCRIPTION isn't helpful in figuring
out what this object does.

ibSmaPortLinkSpeedActive: the SYNTAX and the DESCRIPTION say
different things.

ibSmaPortLinkSpeedEnabled: the SYNTAX and the DESCRIPTION say
different things.  Furthermore, the DESCRIPTION makes it sounds
like this is a read-write control, rather than a read-only status.

ibSmaPortNeighborMtu: the SYNTAX and DESCRIPTION differ on what
"6" means.

ibSmaPortVirtLaneSupport: it seems odd to use "other" to collapse
all other possibilities, when every possible configuration could
be represented in a fifteen-bit BITS.

ibSmaPortVlHighPriorityLimit: should be Unsigned32, and needs
a UNITS clause.


ibSmaPortVlArbHighCapacity: The DESCRIPTION should explain what
is meant by VLArbitration table; I *think* it's ibSmaHiPriVlArbTable
but would like it spelled out.  Should be Unsigned32 and needs UNITS.

ibSmaPortVlArbLowCapacity: needs to be clear what table it refers
to.  Should be Unsigned32 and needs UNITS.

ibSmaPortMtuCapacity SYNTAX and DESCRIPTION disagree about 6.

ibSmaPortVlStallCount: should be Unsigned32, needs UNITS, "Count"
in descriptor is somewhat misleading.

ibSmaPortHeadOfQueueLife  should be Unsigned32, needs UNITS.
Why does it need a dozen different values that all mean "infinite"???

ibSmaPortOperationalVls SYNTAX and DESCRIPTION don't match up.
It seems odd to use "other" to collapse all other
possibilities, when every possible configuration could be
represented in a fifteen-bit BITS.

ibSmaPortPartEnforceInbound,
ibSmaPortPartEnforceOutbound,
ibSmaPortFilterRawPktInbound,
ibSmaPortFilterRawPktOutbound: one *could* put these all in a single
BITS if management bandwidth were an issue.

ibSmaPortLocalPhysErrorThreshold:  should be Unsigned32, needs UNITS.
Once this threshold is exceeded, what must occur before it can be
triggered again?  (for example, if the threshold is two, would
four consecutive errors cause it to trigger more than once?)  Normally
a threshold is in term of some number of events per some kind of context,
such as time or bits or packets.

ibSmaPortOverrunErrorThreshold should be Unsigned32, needs UNITS.
If the threshold is two, and four overrrun errors occur in the
period, does it trigger once, twice, or three times?  Is the
interval discrete or a sliding window?  (I think the former
is intended, but I want to be really sure.)

ibSmaPKeyIBAPortIndex: the last sentence of the DESCRIPTION is
mystifying.

ibSmaPKeyTable: are these persistant?  when do they come into
existence?  when do they go away?  how does a management system
detect changes to the table?

ibSmaPKeyIndex: is there a reason for making this one-based rather
than reflecting what the protocol does?  Should be Unsigned32.
Should name the MIB object that reflects the upper bound.

ibSmaPKeyBase should be Unsigned32.

ibSmaSL2VLMapTable: are these persistent?  when do entries appear?
when do they go away?  how does management know something's changed?

Randy
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.