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

I hve not completely studied this specific RowStatus issue yet.
But I tend to agree that the way it is used here is not as was (in my view)
intended in RFC2579. The intetion is to control row creation/modification/deletion.
And clearly that is not the way it is used here.
 
I am checking with the MIB doctors team as to what their view is... so bear with
me for a little while, after which I will come back to this topic.
 
Bert

-----Original Message-----
From: Clay Sikes [mailto:[email protected]]
Sent: Tuesday, October 17, 2006 23:11
To: [email protected]
Cc: Keith McCloghrie; [email protected]
Subject: Re: [Hubmib] 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 <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] <mailto:[email protected]> 

https://www1.ietf.org/mailman/listinfo/hubmib <https://www1.ietf.org/mailman/listinfo/hubmib>

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