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

Bert,
I would like to have 2 values - one for possibility and the other, for "possible but not available", e.g. if the interface is unplugged.
I guess I would return back to the way it was done in the -05 version - a new enum with 2 values.

Regards,
-E.

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]]
> Sent: Wednesday, October 18, 2006 5:45 PM
> To: Edward Beili
> Cc: [email protected]; Keith McCloghrie; [email protected]
> Subject: RE: [Hubmib] 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-m
> ib-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
> > > >  
>