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

> The reason I changed the syntax of ifCapStackStatus and 
> ifInvCapStackStatus objects from a new enum to the RowStatus was to 
> emphasize the similarity between the ifCapStackTable/ifInvCapStackTable 
> and ifStackTable/ifInvStackTable as well as to try to reuse an existing 
> textual convention instead of inventing yet another enum.
 
The motivation is good but it's only valid if the semantics match.

> I don't think making the ifCapStackStatus/ifInvCapStackStatus to be 
> read-only is illegal or problematic - the ifInvStackStatus object from 
> IF-INV-STACK-MIB with a RowStatus syntax is read-only as well.
 
The ifInvStackTable table has exactly the same structure and content,
and exactly the same number of rows as the ifStackTable.  Semantically,
ifInvStackStatus *could* be read-create, but if it were, a SetRequest
to ifStackStatus and a SetRequest to ifInvStackStatus would have
exactly the same result, i.e., to make it read-create would be
redundant because it would provide two means of achieving the same
behaviour.  So, making it read-only is a simplification.

> I would also argue that overloading of NotInService value is ok - this 
> value is defined as:
> "- 'NotInService', which indicates that the conceptual row exists in the 
> agent, but is unavailable for use by the managed device".

'notInService' is "unavailable for use by the managed device" because
it normally requires an SNMP operation on a RowStatus object to make it
available.  Normally, the necessary operation is on the same RowStatus
object but in the case of ifInvStackStatus (see above comment on
simplification), the operation needs to be on ifStackStatus.  In
contrast,

             notInService(2) - the sub-layer interfaces cannot be
                              connected temporarily due to
                              unavailability of the interface(s), 

The semantics are different here.  It is not an SNMP operation on a
RowStatus object which prevents this row from being "available for use
by the managed device".

> Since these tables are static (read-only) there is no question of 
> resource consumption - these rows are never deleted and thus can stay in 
> NotInService state indefinitely. RFC2579 states that "It is the 
> responsibility of the DESCRIPTION clause of the status column to 
> indicate what an abnormally long period of time would be." I can add a 
> sentence in the DESCRIPTION clause saying that an 
> ifCapStackStatus/ifInvCapStackStatus may be in the NotInService state 
> indefinitely, formally complying with RFC2579.
 
ifInvStackStatus *could* semantically be read-create, but is read-only
so as to remove redundancy.  In contrast, it is the semantics of
ifCapStackStatus and ifInvCapStackStatus which prevent them from being
read-create.

Keith.

> However I'm not bent on staying with RowStatus - I'll move back to the 
> enum if the group feels it is best.
> 
> Regards,
> -E.
> 
>   _____ 
> 
> > From: Clay Sikes [mailto:[email protected]]
> > Sent: Tuesday, October 17, 2006 23:11
> > To: [email protected]
> > Cc: [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
> > > >    
> 
> > > 
> > >       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
> > >