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

Having looked at the MIB itself now, it seems to me that
the object
      ifCapStackStatus  OBJECT-TYPE
        SYNTAX      RowStatus
would be much better represented by 
      ifCapStackPossible  OBJECT-TYPE
        SYNTAX      TruthValue
where 'true' means it CAN be stacked this way and 'false' means
it cannot. That way you re-use an existing TC, and you can 
exactly represent what you need, no?

Same for ifInvCapStackStatus

Bert


> -----Original Message-----
> From: Keith McCloghrie [mailto:[email protected]]
> Sent: Wednesday, October 18, 2006 16:41
> To: [email protected]
> Cc: [email protected]; [email protected]; [email protected]; 
> [email protected]
> Subject: Re: [Hubmib] 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
> > >