Re: WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt

Hi,

I have run into an issue with the ifCapStackStatus and
ifInvCapStackStatus objects. Although the ifCapStackMIB passes
smilint, I have seen compilation issues with these objects. It seems
that the root cause is the combination RowStatus syntax and the
read-only max-access (A RowStatus that is read-only seems a bit strange
to me). The compiler does not generate all the code that is required.
Although there may or may not be an issue with the compiler, I would
beg that the objects be changed from a RowStatus syntax to a
enumeration like what was in the -05 version of the ID. This may
resolve Keith's issue as well.

Thoughts?

Thanks,

Clay

On 10/17/2006 12:09 PM, Keith McCloghrie wrote:

This is a formal WG Last Call for
http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-06.txt

ifCapStackStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of the 'cross-connect capability' relationship
between two sub-layers. The following values can be returned:
active(1) - indicates that the sub-layer interface,
identified by the ifStackLowerLayer MAY
be connected to run 'below' the sub-layer
interface, identified by the
ifStackHigherLayer index.
notInService(2) - the sub-layer interfaces cannot be
connected temporarily due to
unavailability of the interface(s), e.g.
one of the interfaces is located on a
pluggable module which is absent.

I suggest this is an ill-advised overloading of 'notInService'.
RFC 2579 says:

If the management station is prevented from setting the
status column to `active' (e.g., due to management station
or network failure) the conceptual row will be left in the
`notInService' or `notReady' state, consuming resources
indefinitely. The agent must detect conceptual rows that
have been in either state for an abnormally long period of
time and remove them. It is the responsibility of the
DESCRIPTION clause of the status column to indicate what an
abnormally long period of time would be. This period of
time should be long enough to allow for human response time
(including `think time') between the creation of the
conceptual row and the setting of the status to `active'.
In the absence of such information in the DESCRIPTION
clause, it is suggested that this period be approximately 5
minutes in length. This removal action applies not only to
newly-created rows, but also to previously active rows which
are set to, and left in, the notInService state for a
prolonged period exceeding that which is considered normal
for such a conceptual row.

In other words, the 'notInService' of RowStatus is for a temporary
delay in a management station setting it to `active'. The "temporary"
situation of a "pluggable module which is absent" is liable to be
much longer than the 5 minutes before the agent is required to delete
the row.

Keith.

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib