Subject: Re: [Hubmib] WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt

From: Keith McCloghrie <[email-masked]>
Date: Tue, 17 Oct 2006 09:09:32 -0700 (PDT)

> 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-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Clay Sikes" <[email-masked]>
Date: Tue, 17 Oct 2006 17:10:53 -0400

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:

Keith.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 17 Oct 2006 19:16:51 -0700

Hi -

> From: "Clay Sikes" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, October 17, 2006 2:10 PM
> Subject: Re: [Hubmib] WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt
...
> (A RowStatus that is read-only seems a bit strange to me).
...

It seems rather strange to me as well.
Does someone recall why RowStatus was used here?

Randy

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 18 Oct 2006 07:40:44 -0700 (PDT)

> 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-masked]]
> > Sent: Tuesday, October 17, 2006 23:11
> > To: [email-masked]
> > Cc: [email-masked]
> 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
>