Subject: [MIB-DOCTORS] Is this a valid re-use of RowStatus TC

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 18 Oct 2006 14:46:58 +0200

Keith commented on a WG Last Call for a HUBMIB WG document.

I personally tend to agree with Keith here. But I would like
to hear opinions of other MIB-Doctors.

Besides the overloading of notInService, the TC seems to be used
for showing some status, not for row creation/deletion as I think
the TCs intended use was/is.

Comments/viewpoints please

Bert (acting in my role as new HUBMIB WG chair).

-----Original Message-----
From: Keith McCloghrie [mailto:[email-masked]]
Sent: Tuesday, October 17, 2006 18:10
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Hubmib] WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt

> 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.

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Oct 2006 06:45:15 -0700

> Comments/viewpoints please

They took a standard TC with a handful of enums.
Then they threw out all but 2 of the values.
Then they inappropriately redefined half the remaining enums.
Gee -- tough call :-)

The syntax should not be RowStatus.
They should make up their own TC instead.

Andy

---

From: "Michael MacFaden" <[email-masked]>
Date: Thu, 19 Oct 2006 23:48:27 -0700

>          "The status of the 'cross-connect capability' relationship

I believe the TC RowStatus is just simple machinery for row maintenance.
If ever another state is ever needed this won't work.

Mike MacFaden

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 25 Oct 2006 11:41:22 +0100

I find that a number of MIB modules are trying to extend existing
T-Cs, removing existing functionality or adding new functionality. I
think it is important to get the message to people that T-Cs are
supposed to be used as defined, not modified, and not used as a "base
definition" to be extended.

dbh 

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Wednesday, October 18, 2006 1:47 PM
> To: MIB Doctors (E-mail)
> Subject: [MIB-DOCTORS] Is this a valid re-use of RowStatus TC
> 
>