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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 18 Oct 2006 17:44:49 +0200

In fact I now looked in some more detail to that MIB module,
and it seems to me that they better use a TrutValue as SYNTAX.

Bert

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2006 15:45
> To: Wijnen, Bert (Bert)
> Cc: MIB Doctors (E-mail)
> Subject: Re: [MIB-DOCTORS] Is this a valid re-use of RowStatus TC
> 
> 
> Wijnen, Bert (Bert) wrote:
> > 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
> 
> 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
> 
> > 
> > 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
> 
> 

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