Out of Office AutoReply: Sexy

Menachem, · Ed,

_______________________________________________
Adslmib=20
        mailing=20
        =
list
Adslmib@ietf.org
https://www1.ietf.org/mailman/listinfo/adslmi=
b

_______________________________________________
Adslmib=20
        mailing=20
        =
list
Adslmib@ietf.org
https://www1.ietf.org/mailman/listinfo/adslmi=
b

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

This is a formal WG Last =
Call for=20
  http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-=
06.txt

=20
      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
Hubmib@ietf.org
https://www1.ietf.=
org/mailman/listinfo/hubmib

This is a formal WG Last =
Call for=20
  http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mi=
b-06.txt

=20
      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
Hubmib@ietf.org
https://www1.ietf=
.org/mailman/listinfo/hubmib