Subject: [Entmib] Entity MIB State Extensions

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 23 Oct 2002 15:49:16 -0400

hi

This took a little longer than expected, but hopefully Andy still as
time to get out another version of the Entity MIB before the Atlanta
cut-off to give us something to poke sticks at.

N Entity State

N.1 Overview

The goal in adding state objects to the Entity MIB was to define a useful 
subset of the possible state attributes that could be tracked for a given 
entity that both fit into the existing IETF model, as well as leveraged 
existing well deployed models.  The entStateTable contains state objects 
that are a subset of ITU's X.731 state objects. Objects are defined to 
capture administrative, operational and usage states. In addition there 
are further state objects defined to provide additional information for 
these three basic states.

The terms state and status are used interchangeably in this memo.

Administrative state indicates permission to use or
prohibition against using the entity and is imposed through the
management services. The administrative state defined for an entity is 
independent of administrative states in its containment hierarchy. 
This means that administratively locking an entity does not 
automatically lock its children in the containment hierarchy.

Operational state indicates whether or not the entity is 
physically installed and working. The operational state defined 
for an entity is indirectly dependent on the operational state of 
the entities in which it is contained. If its parent entities in 
its containment hierarchy are disabled, and therefore totally inoperable,
then it is unlikely that the given entity will be operable.

Usage state indicates whether or not the entity is in use at a 
specific instance, and if so, whether or not it currently has 
spare capacity.

N.2 State Relationships

The following section outlines all of the combinations of the three
basic states - administrative, operational and usage - and
briefly describes what each of these combination of states means. It also 
compare this combination of states to that of the ifAdminStatus 
and ifOperStatus objects of the Interfaces Group MIB [RFC2863] to 
both provide insight to those familiar with these status objects as 
well as to clarify the relationship between entities and interfaces, 
as indicated by entAliasLogicalIndexOrZero.

N.2.1 Admin State Locked, Operational State Disabled and Usage State Idle

The entity is totally inoperable, it is not servicing any users and it is 
also administratively prohibited from use. To make it available for use, 
both management permission and some corrective 
action are necessary. This is similar to an ifAdminStatus of down 
and ifOperStatus of down.

N.2.2 Admin State Locked, Operational State Enabled and Usage State Idle

The entity is partially or fully operable, it is not servicing any users 
but is administratively prohibited from use. To make it available for use, 
only management permission is required. This is similar to an ifAdminStatus 
of down and ifOperStatus of down.	

N.2.3 Admin State Shutting Down, Operational State Enabled and Usage State
Active

The entity is partially or fully operable and in use, but usage is
administratively 
limited to current instances of use. For an additional user to gain access,
management 
permission is required. Otherwise, when all current users have terminated
their use 
of the resource, the managed object will automatically transit to the
locked, enabled, and idle state.
This is similar to the situation described in [RFC2863] where ifAdminStatus
transitions to down, 
but the ifOperStatus's transition does not occur immediately, but rather
after a small time lag to 
complete certain operations before going "down".	

N.2.4 Admin State Shutting Down, Operational State Enabled and Usage State
Busy

The entity is partially or fully operable and in use, but usage is
administratively 
limited to current instances of use. In addition, it has no spare capacity
to 
provide for additional users. For an additional user to gain access, beside
waiting 
for an existing user to terminate, management permission is also required. 
Otherwise, when all current users have terminated their use of the resource,

the managed object will automatically transit to the locked, enabled, idle
state.
This is similar to the situation described in [RFC2863] where ifAdminStatus
transitions to down, 
but the ifOperStatus's transition does not occur immediately, but rather
after a small time lag to 
complete certain operations before going "down".

N.2.5 Admin State Unlocked, Operational State Enabled and Usage State Idle
	
The entity is partially or fully operable, it is not actually in use and is 
not administratively prohibited from use. This is similar to an
ifAdminStatus of up 
and ifOperStatus of up if the interface is able to pass packets. If the
interface
is found to be operable, but the interface is waiting for other,  external,
events 
to occur before it can transmit or receive  packets, then this is similar to
an ifAdminStatus of up and a ifOperStatus of dormant.

N.2.6 Admin State Unlocked, Operational State Enabled and Usage State Active

The entity is partially or fully operable, it is currently in use and is not

administratively prohibited from use. It has sufficient spare capacity to
provide 
for additional users. This is similar to an ifAdminStatus of up and
ifOperStatus of up.	

N.2.7 Admin State Unlocked, Operational State Enabled and Usage State Busy

The entity is partially or fully operable, it is currently in use and it is
not 
administratively prohibited from use. Currently it has no spare capacity to 
provide for additional users. For an additional user to gain access, it is 
necessary to wait for an existing user to terminate or for some capacity 
increase to occur.  This is similar to an ifAdminStatus of up and
ifOperStatus of up.

N.2.8 Admin State Unlocked, Operational State Disabled and Usage State Idle

The entity is totally inoperable, it is servicing no users but it is not 
administratively prohibited from use. To make it available for use, 
some corrective action is required. This is similar to an ifAdminStatus 
of up and ifOperStatus of down. If the cause of the interface being down
is because of a lower layer being down, then this is similar to
an ifAdminStatus of up and an ifOperStatus of lowerLayerDown.

N.3 Relation to Alarm MIB

The entStateAlarm objects indicates whether or not there are any
active alarms against this entity. If there are active alarms, then
the alarmActiveTable should be searched for alarmActiveResourceId
that match this entPhysicalIndex

M. Definitions 

...

  -- Textual conventions

   ItuAdminState  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the various possible administrative states 
               (ITU-T X.731).
               
               A value of locked means the resource is administratively
               prohibited from use. A value of shuttingDown means that
               usage is administratively limited to current instances of
use.
               A value of unlocked means the resource is not
administratively
               prohibited from use."
     SYNTAX         INTEGER
               {
               locked(1),
               shuttingDown(2),
               unlocked(3)
               }

   ItuOperState  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the possible values of operational states 
               (ITU-T X.731). 
               
               A value of disabled means the resource is totally inoperable.
               A value of enabled means the resource is partially or fully
               operable."
     SYNTAX         INTEGER
               {
               disabled(1),
               enabled(2)
               }

   ItuUsageState  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the possible values of usage states
               (ITU-T X.731).
               
               A value of idle means the resource is servicing no users.
               A value of active means the resource is currently in use
               and it has sufficient spare capacity to provide for 
               additional users. A value of busy means the resource is 
               currently in use, but it currently has no spare capacity to 
               provide for additional users."
     SYNTAX         INTEGER
               {
               idle(1),
               active(2),
               busy(3)
               }

  ItuAlarmStatus  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the possible values of alarm status
               (ITU-T X.731).
               
              When no values of this attribute are set, then none of the
status 
              conditions described below are present. When the value of
under repair 
              is set, the resource is currently being repaired. 
              
              When the value of critical is set, one or more critical alarms
are active 
              against the resource. When the value of major is set, one or
more major 
              alarms are active against the resource. When the value of
minor is set, 
              one or more minor alarms are active against the resource.

              When the value of alarm outstanding is set, one or more alarms
is active
              against the resource. The fault may or may not be disabling. "
           SYNTAX         BITS
              {
              under-repair(1),
              critical(2),
              major(3),
              minor(4),
              alarm-outstanding(5), 
              warning (6), -- Not defined in X.731  
              indeterminate (7) -- Not defined in X.731
              }

   ItuStandbyStatus  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the possible values of standby status
               (IU-T X.731).
               
               A value of hotStandby means the resource is not providing
service, 
               but is will be immediately able to take over the role of the
resource to 
               be backed-up, without the need for initialization activity,
and will 
               contain the same information as the resource to be backed up.
A value of  
               coldStandy means that the resource is to back-up another
resource, but
               will not be immediately able to take over the role of a
resource to be
               backed up, and will require some initialization activity. A
value of 
               providingService means the resource is providing service.
               "

           SYNTAX         INTEGER
             {
             hotStandby(1),
             coldStandby(2),
             providingService(3)
             }

   -- Entity State      

   entStateTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF EntStateEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of information about state/status of entities.
         "
    ::= { entStateMIB 1 }

     entStateEntry OBJECT-TYPE
        SYNTAX      EntStateEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION ""
        AUGMENTS       { entPhysicaEntry }
        ::= { entStateTable 1 }

     EntStateEntry ::= SEQUENCE {
         entStateAdmin 	   ItuAdminState,
         entStateOper      ItuOperState,
         entStateUsage     ItuUsageState,
         entStateAlarm	   ItuAlarmStatus,
         entStateStandby   ItuStandbyStatus
        }                      
        
 entStateAdmin OBJECT-TYPE
        SYNTAX      ItuAdminState
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION "The administrative state for this entity."
        ::= { entStateEntry 1 }     
        
  entStateOper OBJECT-TYPE
        SYNTAX      ItuOperState
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION "The operational state for this entity."
        ::= { entStateEntry 2 }  
           
  entStateUsage OBJECT-TYPE
        SYNTAX      ItuUsageState
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION "The usage state for this entity."
        ::= { entStateEntry 3 } 
        
  entStateAlarm OBJECT-TYPE
        SYNTAX      ItuAlarmStatus
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION "The alarm state for this entity. It does not include 
        the severity of alarms raised on child components."
        ::= { entStateEntry 4 }             
                      
 entStateStandby OBJECT-TYPE
   		SYNTAX ItuStandbyStatus
   		MAX-ACCESS read-only
   		STATUS current
   		DESCRIPTION "The standby status for this entity."
   ::= { entStateEntry 5 }         

...

Sharon Chisholm	
Portfolio Integration		
Nortel Networks
Ottawa, Canada
_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 24 Oct 2002 10:38:55 -0400

hi

Oops. I referred to entAliasLogicalIndexOrZero when I should have
referred to entAliasMappingIndentifier.

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:NM50:EXCH] 
Sent: Wednesday, October 23, 2002 3:49 PM
To: Entity Mib
Subject: [Entmib] Entity MIB State Extensions

hi

This took a little longer than expected, but hopefully Andy still as time to
get out another version of the Entity MIB before the Atlanta cut-off to give
us something to poke sticks at.

N Entity State

N.1 Overview

Administrative state indicates permission to use or
prohibition against using the entity and is imposed through the management
services. The administrative state defined for an entity is 
independent of administrative states in its containment hierarchy. 
This means that administratively locking an entity does not 
automatically lock its children in the containment hierarchy.

N.2 State Relationships

The following section outlines all of the combinations of the three basic
states - administrative, operational and usage - and briefly describes what
each of these combination of states means. It also 
compare this combination of states to that of the ifAdminStatus 
and ifOperStatus objects of the Interfaces Group MIB [RFC2863] to 
both provide insight to those familiar with these status objects as 
well as to clarify the relationship between entities and interfaces, 
as indicated by entAliasLogicalIndexOrZero.

The entity is partially or fully operable and in use, but usage is
administratively 
limited to current instances of use. For an additional user to gain access,
management 
permission is required. Otherwise, when all current users have terminated
their use 
of the resource, the managed object will automatically transit to the
locked, enabled, and idle state. This is similar to the situation described
in [RFC2863] where ifAdminStatus transitions to down, 
but the ifOperStatus's transition does not occur immediately, but rather
after a small time lag to 
complete certain operations before going "down".	

the managed object will automatically transit to the locked, enabled, idle
state. This is similar to the situation described in [RFC2863] where
ifAdminStatus transitions to down, 
but the ifOperStatus's transition does not occur immediately, but rather
after a small time lag to 
complete certain operations before going "down".

interface is found to be operable, but the interface is waiting for other,
external, events 

The entity is totally inoperable, it is servicing no users but it is not 
administratively prohibited from use. To make it available for use, 
some corrective action is required. This is similar to an ifAdminStatus 
of up and ifOperStatus of down. If the cause of the interface being down is
because of a lower layer being down, then this is similar to an
ifAdminStatus of up and an ifOperStatus of lowerLayerDown.

The entStateAlarm objects indicates whether or not there are any active
alarms against this entity. If there are active alarms, then the
alarmActiveTable should be searched for alarmActiveResourceId that match
this entPhysicalIndex

M. Definitions 

...

  -- Textual conventions

               

               

 

           SYNTAX         INTEGER
             {
             hotStandby(1),
             coldStandby(2),
             providingService(3)
             }

   -- Entity State      

        
        
  entStateOper OBJECT-TYPE
        SYNTAX      ItuOperState
        MAX-ACCESS  read-only
        STATUS      current

                      

...

Sharon Chisholm	
Portfolio Integration		
Nortel Networks
Ottawa, Canada

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 24 Oct 2002 10:38:55 -0400

hi

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:NM50:EXCH] 
Sent: Wednesday, October 23, 2002 3:49 PM
To: Entity Mib
Subject: [Entmib] Entity MIB State Extensions

hi

N Entity State

N.1 Overview

N.2 State Relationships

	

M. Definitions 

...

  -- Textual conventions

               

               

 

           SYNTAX         INTEGER
             {
             hotStandby(1),
             coldStandby(2),
             providingService(3)
             }

   -- Entity State      

        
        
  entStateOper OBJECT-TYPE
        SYNTAX      ItuOperState
        MAX-ACCESS  read-only
        STATUS      current

                      

...

Sharon Chisholm	
Portfolio Integration		
Nortel Networks
Ottawa, Canada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Oct 2002 22:54:21 -0700

>cut-off to give us something to poke sticks at.

I read through this, and I'm having trouble figuring out how
I would apply it to most of the physical entities in our products.
At best, it might be a sparse augmentation of the entPhysicalEntry,
not a real AUGMENTS.

I don't remember ever talking about a read-write admin object as
part of this table.  I don't want to put in any writable admin status
object for physical entities.

I'm not convinced we need 4 objects to describe the operational
state of a physical entity.  Well, 3 if you consider standby state
as a separate attribute.  Can you describe some usage scenarios
for specific entPhysicalClass values for which this ITU model
is appropriate and useful? These states seem to apply to
logical services more than physical entities -- even for a
module or a cpu.

thanks,
Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Oct 2002 22:54:21 -0700

thanks,
Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 25 Oct 2002 10:57:08 -0400

hi

We seem less convinced than I remember. Should I throw this
proposal into an individual submission and then we can
merge it with the Entity MIB after Atlanta when we are all
hopefully more convinced?  The deadline is Monday morning,
but if I basically cut and paste the email, I think I can
make it.

We can talk about a sparse augments, but I kind of like the
information being available for all components - even if
some components may only be able to support a subset of 
possible values.

From my perspective, I am more interested in seeing if something
is administratively disabled than actually disabling it myself,
so if consensus is read-only objects I can certainly live with that.

You raise a good question about the usage scenarios. One
use for states in general is management systems that use the state of
components in a device's physical component hierarchy as a health 
indicator for the overall system. Another is in fault management where it
is necessary to be able to differentiate between a physical component
not functioning because of a problem or it being administratively
disabled. I would also expect this to be useful to confirm configuration
and to help debug problems.

As for using the ISO/ISO/ITU states in particular, I see the benefit
of this, aside from the wide deployment of these models, is the
ability to tell whether or not a physical component has more capacity.
For example, Does your chassis have any more empty slots that I could
plug a card into? 

Here is some further discussion of the states for each of the 
various physical classes:

N.4 Physical Classes and States

N.4.1 Chassis

A value of unlocked for entStateAdmin means that this system is on.
A value of shuttingDown for entStateAdmin means that this system
is in the process of shutting down. A value of enabled for entStateOper
indicates that basic functions of this system are functioning. A
value of disabled for entStateOper indicates a problem with basic
functions on the system. A value of idle for entStateUsage may not
make sense since responding to a SNMP query may constitute service.
A value of active for entStateUsage indicates the system is functioning,
but is able to provide more services. A value of busy for entStateUsage
indicates that the system is functioning at maximum capacity and is 
unable to provide more services at the present time.

A value of hotStandby for enStateStandby indicates that the entire
system contained within this chassis is running as a hot standby for
another complete system, possibly contained within the same stack.
A value of coldStandby for enStateStandby indicates that the entire
system contained within this chassis is running as a cold standby for
another complete system, possibly contained within the same stack.
A value of providingService for enStateStandby indicates that the entire
system contained within this chassis is currently providing service.

If this chassis is not contained in within a stack, the alarm counts
indicated by entStateAlarm will be those alarms that are against the
general system, as appose sub-components within the containment hierarchy.

N.4.2 BackPlane

A value of unlocked for entStateAdmin means that the backplane is not 
administratively prevented from aggregating and forwarding network 
traffic. A value of shutting down for entStateAdmin means that the backplane
will finish aggregating and forwarding the network traffic is currently
handling, but then transition to be administratively locked. A value of
locked for entStateAdmin means that backplane is administratively prohibited
from aggregating and forwarding any network traffic. A value of enabled
for entStateOper means that the backplane is partially or fully capable
of aggregating and forwarding network traffic. A value of disabled for
entStateOper means that the backplane is unable to aggregate and forward
any network traffic. A value of idle for entStateUsage means that the
backplane is not currently aggregating and forwarding any network traffic.
A value of active for entStateUsage means that the backplane is currently
aggregating and forwarding some network traffic, but has capacity to 
handle more traffic. A value of busy for entStateUsage means that the
backplane is aggregating and forwarding network traffic at full capacity.

A value of hotStandby for enStateStandby indicates that the 
backplane is running as a hot standby for
another backplane within this system. A value of coldStandby for 
enStateStandby indicates that the backplane is running as 
a cold standby for another backplane, possibly within this system.
A value of providingService for enStateStandby indicates that the backplane
is currently providing service. Looking at the 
entStateAlarm gives a convenient way to see if there are any alarms 
currently active against this backplane.

N.4.3 Container

A value of unlocked for entStateAdmin means it is administratively
possible to insert things into this container. A value of 
shuttingDown for entStateAdmin could be used to reflect that inserting 
objects into this container is administratively prohibited. This value
could also be used for systems that do not support hot insertion of
components. 

The container physical class could be used to indicate,
among other things, chassis slots or daughter-card holders.
If the container is empty, for example it has no modules in
its slots, then entStateUsage would have a value of idle.
If the container is partially used, for example it has modules
in some but now all of its slots, then entStateUsage would have
a value of busy. If the container is full, for example it has no 
empty slots, then entStateUsage would have a value of busy.

If it is not possible to raise alarms against this chassis, the
entStateAlarm will have no alarms set. It may not make sense for
the entStateOper to have values other than enabled.

N.4.4 PowerSupply

If this power supply is the currently providing power to the system,
then entStateStandyby would have a value of providing service. If this
power supply is serving as a backup to a primary power supply, then 
entStateStandyby would have a value of hotstandby.

A value of locked for entStateAdmin means that the power supply has been 
turned off. This only makes sense in the situation where there is a 
backup power supply. A value of unlocked for entStateAdmin means that
the power supply is turned on. A value of enabled for entStateOper means
that the power supply is operational. A value of disabled for entStateOper
means that the power supply is not functioning. A value of idle for
entStateUsage means that the power supply is providing no power to the 
system. A value of active for entStateUsage means that the power supply
is providing power to the system, but could possibly provide more. A value
of busy for entStateUsage means that the power supply is providing the
maximum power to the system that it is capable of. Looking at the 
entStateAlarm gives a convenient way to see if there are any alarms 
currently active against this power supply.

N.4.5 Fan

If this fan is serving as a backup to a primary fan, then entStateStandyby 
would have a value of hotstandby.
If this fan is the currently providing service to the system,
then entStateStandyby would have a value of providing service. A value of
idle for entStateUsage would indicate that the fan was not actually running.
A value of active for entStateUsage would indicate that the fan was 
running, but not at its maximum capacity. A value of busy for entStateUsage
would indicate that the fan was running at maximum capacity. 

Looking at the entStateAdmin and entStateOper provide useful information
to determine why a fan is not running. A value of locked for entStateAdmin
means that the fan is not running because it has been administratively
disabled. A value of disabled for the entOperStatus indicates that the
fan itself is not operational. A value of enabled for the entOperStatus
indicates that the fan is working in theory and that cause of it not
operator may lie elsewhere. Looking at the entStateAlarm gives a
convenient way to see if there are any alarms currently active against
this fan.

N.4.6 Sensor

A value of unlocked for entStateAdmin indicates that the sensor is not
administratively
prohibited from sensing. A value of shutting down for entStateAdmin
indicates that
the sensor will complete its current readings and then shut down. A value of
locked for
entStateAdmin indicates that the sensor is administratively prohibited from
sensing.
A value of enabled for entStateOper indicates that the sensor is functioning
properly.
A value of disable for entStateOper indicates that the sensor is totally
inoperable.
A value of idle for entStateUsage indicates that the sensor is not currently
sensing.
A value of active for entStateUsage indicates that the sensor is currently
sensing things,
but could sense more, more often or other types of information for example.
A value of
busy for entStateUsage indicates that the sensor is sensing everything it
knows how to
sense and at its fastest possible rate.

Looking at the entStateStandby indicates whether this sensor is currently
providing service
or acting as a backup for another sensor. Looking at the entStateAlarm gives
a convenient 
way to see if there are any alarms currently active against this sensor.

N.4.7 Module

For modules that support the functionality of being administratively
disabled, entStateAdmin object indicates whether the module is
administratively locked (disabled) or unlocked (enabled). Modules
that do not support disabling will always have a value of unlocked
for entStateAdmin. A value of enabled for entStateOper indicates
that this module is partially or fully operational. A value of disabled
for entStateOper indicates that this module is totally inoperable.
A value of idle for entStateUsage indicates that this module is currently
not performing any functions. A value of active entStateUsage indicates 
that this module is currently performing functions, but capable of 
performing more. A value of busy for entStateUsage indicates that the
module is functioning at full capacity and unable to perform further
functions
at this current time.

Looking at the entStateStandby indicates whether this module is currently 
providing service or acting as a backup for another module. Looking at the 
entStateAlarm gives a convenient way to see if there are any alarms 
currently active against this module.

N.4.8 Port

A value of enabled for entStateAdmin means the port is not administratively
prohibited from passing network traffic. A value of shutting down for
entStateAdmin indicates that the port will pass its current traffic and
then transition to the locked state. A value of locked for entStateAdmin
indicates that the port is administratively prohibited from passing 
network traffic. A value of enabled for entStateOper means that the
port is partially or fully capable of forwarding network traffic. A value
of disabled for entStateOper means that the port is totally unable to 
forward network traffic. A value of idle for entStateUsage indicates that
the port is not currently forwarding any network traffic. A value of 
active means that the port is currently forwarding network traffic, but
has capacity to forward more. A value of busy for entStateUsage indicates
that the port is forwarding network traffic at its maximum capacity.

Looking at the entStateStandby indicates whether this port is currently 
providing service or acting as a backup for another port. Looking at the 
entStateAlarm gives a convenient way to see if there are any alarms 
currently active against this port.

N.4.9 Stack

A value of unlocked for entStateAdmin means that this system is on.
A value of shuttingDown for entStateAdmin means that this system
is in the process of shutting down. A value of enabled for entStateOper
indicates that basic functions of this system are functioning. A
value of disabled for entStateOper indicates a problem with basic
functions on the system. A value of idle for entStateUsage may not
make sense since responding to a SNMP query may constitute service.
A value of active for entStateUsage indicates the system is functioning,
but is able to provide more services. A value of busy for entStateUsage
indicates that the system is functioning at maximum capacity and is 
unable to provide more services at the present time.

A value of hotStandby for enStateStandby indicates that the entire
system contained within this stack is running as a hot standby for
another complete system, possibly contained within the same parent
stack. A value of coldStandby for enStateStandby indicates that 
the entire system contained within this stack is running as a 
cold standby for another complete system, possibly contained within the 
same parent stack. A value of providingService for enStateStandby indicates 
that the entire system contained within this chassis is currently 
providing service.

If this stack is not contained in within a parent stack, the alarm counts
indicated by entStateAlarm will be those alarms that are against the
general system, as appose sub-components within the containment hierarchy.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, October 25, 2002 1:54 AM
To: Chisholm, Sharon [CAR:NM50:EXCH]
Cc: Entity Mib
Subject: Re: [Entmib] Entity MIB State Extensions

I read through this, and I'm having trouble figuring out how
I would apply it to most of the physical entities in our products. At best,
it might be a sparse augmentation of the entPhysicalEntry, not a real
AUGMENTS.

I don't remember ever talking about a read-write admin object as part of
this table.  I don't want to put in any writable admin status object for
physical entities.

I'm not convinced we need 4 objects to describe the operational state of a
physical entity.  Well, 3 if you consider standby state as a separate
attribute.  Can you describe some usage scenarios for specific
entPhysicalClass values for which this ITU model is appropriate and useful?
These states seem to apply to logical services more than physical entities
-- even for a module or a cpu.

thanks,
Andy

>Administrative state indicates permission to use or prohibition against 
>using the entity and is imposed through the management services. The 
>administrative state defined for an entity is independent of 
>administrative states in its containment hierarchy. This means that 
>administratively locking an entity does not automatically lock its 
>children in the containment hierarchy.
>
>basic states - administrative, operational and usage - and briefly 
>describes what each of these combination of states means. It also 
>compare this combination of states to that of the ifAdminStatus and 
>ifOperStatus objects of the Interfaces Group MIB [RFC2863] to both 
>provide insight to those familiar with these status objects as well as 
>to clarify the relationship between entities and interfaces, as 
>indicated by entAliasLogicalIndexOrZero.
>

>N.2.3 Admin State Shutting Down, Operational State Enabled and Usage 
>State Active
>
>administratively limited to current instances of use. For an additional 
>user to gain access, management
>N.2.4 Admin State Shutting Down, Operational State Enabled and Usage 
>State Busy
>
>administratively limited to current instances of use. In addition, it 
>has no spare capacity to
>the managed object will automatically transit to the locked, enabled, 
>idle state. This is similar to the situation described in [RFC2863] 
>where ifAdminStatus transitions to down,
>administratively prohibited from use. It has sufficient spare capacity 
>to provide for additional users. This is similar to an ifAdminStatus of 
>up and
>ifOperStatus of up.     
>
>The entity is partially or fully operable, it is currently in use and 
>it is not administratively prohibited from use. Currently it has no 
>spare capacity to provide for additional users. For an additional user 
>to gain access, it is necessary to wait for an existing user to 
>terminate or for some capacity increase to occur.  This is similar to 
>an ifAdminStatus of up and ifOperStatus of up.
>
>alarmActiveTable should be searched for alarmActiveResourceId that 
>match this entPhysicalIndex
>
>M. Definitions
>
>...
>
>  -- Textual conventions
>                      
>
>               usage is administratively limited to current instances 
>of use.
>              When no values of this attribute are set, then none of 
>the status
>              When the value of critical is set, one or more critical 
>alarms are active
>              against the resource. When the value of major is set, one 
>or more major
>              When the value of alarm outstanding is set, one or more 
>alarms is active
>               A value of hotStandby means the resource is not 
>providing service,
>               but is will be immediately able to take over the role of 
>the resource to
>               be backed-up, without the need for initialization 
>activity, and will
>               contain the same information as the resource to be 
>backed up. A value of

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 25 Oct 2002 10:57:08 -0400

hi

N.4.1 Chassis

N.4.2 BackPlane

N.4.3 Container

N.4.4 PowerSupply

N.4.5 Fan

N.4.6 Sensor

N.4.7 Module

N.4.8 Port

N.4.9 Stack

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, October 25, 2002 1:54 AM
To: Chisholm, Sharon [CAR:NM50:EXCH]
Cc: Entity Mib
Subject: Re: [Entmib] Entity MIB State Extensions

thanks,
Andy

>is not

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Oct 2002 09:44:53 -0700

>but if I basically cut and paste the email, I think I can 

 From a design POV, I think it would be better if there
was a separate ENTITY-STATUS-MIB module that was not merged
back into the ENTITY-MIB module.  There is sufficient 
complexity and page count to warrant a separate RFC.

>some components may only be able to support a subset of 

Since you added a lot of detail about what a developer
should do for each class of physical entity, it's okay
with me if this table is a full augmentation, instead
of a sparse one.

>so if consensus is read-only objects I can certainly live with that. 

MAX-ACCESS read-write, MIN-ACCESS read-only would be okay.
Also, an agent may selectively support read-write for
some components, and read-only for others.  E.g., I doubt
we will allow an entire chassis to be turned off with this object,
and never allow fans to be controlled by the administrator,
and wouldn't have any ability to administratively control
a specific container.

>and to help debug problems. 

I'm withdrawing my concerns with the understanding that
the RFC will explain what subsets of each object are
appropriate and expected for each entPhysicalClass value.

Andy

>A value of unlocked for entStateAdmin indicates that the sensor is not administratively 
>prohibited from sensing. A value of shutting down for entStateAdmin indicates that 
>the sensor will complete its current readings and then shut down. A value of locked for 
>entStateAdmin indicates that the sensor is administratively prohibited from sensing. 
>A value of enabled for entStateOper indicates that the sensor is functioning properly. 
>A value of disable for entStateOper indicates that the sensor is totally inoperable. 
>A value of idle for entStateUsage indicates that the sensor is not currently sensing. 
>A value of active for entStateUsage indicates that the sensor is currently sensing things, 
>but could sense more, more often or other types of information for example. A value of 
>busy for entStateUsage indicates that the sensor is sensing everything it knows how to 
>Looking at the entStateStandby indicates whether this sensor is currently providing service 
>or acting as a backup for another sensor. Looking at the entStateAlarm gives a convenient 
>module is functioning at full capacity and unable to perform further functions 
>at this current time. 
>
>From: Andy Bierman [<mailto:[email-masked]>mailto:[email-masked]] 
>I would apply it to most of the physical entities in our products. At best, it might be a sparse augmentation of the entPhysicalEntry, not a real AUGMENTS.
>
>I don't remember ever talking about a read-write admin object as part of this table.  I don't want to put in any writable admin status object for physical entities.
>
>I'm not convinced we need 4 objects to describe the operational state of a physical entity.  Well, 3 if you consider standby state as a separate attribute.  Can you describe some usage scenarios for specific entPhysicalClass values for which this ITU model is appropriate and useful? These states seem to apply to logical services more than physical entities -- even for a module or a cpu.
>
>thanks, 
>Andy 
>
>
>>N Entity State 
>> 
>>N.1 Overview 
>> 
>><https://www1.ietf.org/mailman/listinfo/entmib>https://www1.ietf.org/mailman/listinfo/entmib

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Oct 2002 09:44:53 -0700

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 26 Oct 2002 13:56:04 -0400

hi

I've very quickly thrown together an ID called "Entity State MIB"
based on my recent emails. I've just submitted it and as the
deadline for -00 drafts is Monday morning, it looked like I've made
the cut-off. It should give us something a bit more official than
email to, as I said before, poke sticks at.

I still prefer the idea of adding the state information into the
actually Entity MIB draft. It is, after all, one little table with
five objects. The actual page count of the work is longer than
it needs to be for two reasons:
	1) I have defined separate textual conventions for the state
         objects in case someone wanted to re-use them elsewhere.
	2) I explained things in a lot more detail than is probably
          necessary and I think ended up repeating myself.

Sharon Chisholm	
Portfolio Integration		
Nortel Networks
Ottawa, Canada

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 26 Oct 2002 13:56:04 -0400

hi

Sharon Chisholm	
Portfolio Integration		
Nortel Networks
Ottawa, Canada

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Oct 2002 12:50:42 -0500

Hi Sharon,

Thanks!

Your document should serve as a useful strawman for discussion,
and we can merge the table into the Entity MIB document once we
have rough consensus on what it should look like.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 27 Oct 2002 12:50:42 -0500

Hi Sharon,

Thanks!

Margaret