Subject: RE: [Entmib] State, Status and URL info

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 4 Jul 2002 07:41:00 -0400

hi

I agree with Dave that the entity MIB needs state/status information.

When we discussed this last summer in London, I believe we
were thinking of a separate MIB with state extensions. Now
I'm beginning to think we might be more successful if we can
put a couple simple state objects in the existing MIB, especially
since it is currently being edited. By successful, I mean that 
the objects actually get implemented by managed elements and that
management tools are developed or enhanced to take advantage of
these objects - not that we define the perfect state MIB.

A minimalist approach would be to add an oper and admin state,
although a computed state based on the alarm state of the given
object and all of its subcomponents would be rather useful.

For those unfamiliar with the ITU model, here's a MIB I quickly
threw together last summer. It's rough, but it compiles.

-- Draft Version

ENTITY-STATE-MIB 

DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, Unsigned32
           FROM SNMPv2-SMI
       TEXTUAL-CONVENTION, DisplayString, TruthValue
           FROM SNMPv2-TC;

   entityStateMIB MODULE-IDENTITY
       LAST-UPDATED "000004260000Z"
       ORGANIZATION "IETF Entity MIB Working Group"
       CONTACT-INFO
               "  "

       DESCRIPTION
               "This MIB defines a state extension to the entity MIB " 
       REVISION    "200103250000Z"
       DESCRIPTION
           ""     
       ::= { mib-2 XX } 
  -- Textual conventions

   ItuAdminState  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the various possible administrative states 
               (ITU-T X.731)."
     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)."
     SYNTAX         INTEGER
                       {
                        disabled(1),
                        enabled(2)
                       }

   ItuUnknownStatusValue  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the unknown status value to be true / false (ITU-T
X.731). 
               This indicates whether the  management system is able to
               maintain OAM communications with the managed entity or not."
     SYNTAX         TruthValue 
                    --  INTEGER {true(1), false(2)} 

   ItuUsageState  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the possible values of usage states
               (ITU-T X.731)."
     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)."
           SYNTAX         INTEGER
                          {
                           under-repair(1),
                           critical(2),
                           major(3),
                           minor(4),
                           alarm-outstanding(5)
                          }

  ItuProcStatus  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the possible values of procedural status
               (ITU-T X.731)."

           SYNTAX         INTEGER
                          {
                           initialization-required(1),
                           not-initialized(2),
                           initializing(3),
                           reporting(4),
                           terminating(5)
                          }

  ItuAvailStatus  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the possible values of availability status
               (ITU-T X.731)."

           SYNTAX         INTEGER
                          {
                           in-test(1),
                           failed(2),
                           power-off(3),
                           off-line(4),
                           off-duty(5),
                           dependency(6),
                           degraded(7),
                           not-installed(8),
                           log-full(9)
                          }

  ItuControlStatus  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the possible values of control status
               (ITU-T X.731)."

           SYNTAX         INTEGER
                          {
                           subject-to-test(1),
                           part-of-services-locked(2),
                           reserved-for-test(3),
                           suspended(4)
                          }

   ItuStandbyStatus  ::=  TEXTUAL-CONVENTION
     STATUS         current
     DESCRIPTION
             " Represents the possible values of standby status
               (IU-T X.731)."

           SYNTAX         INTEGER
                          {
                           hot-standby(1),
                           cold-standby(2),
                           providing-service(3)
                          }      

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

     entityStateEntry OBJECT-TYPE
        SYNTAX      EntityStateEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION ""
        AUGMENTS       { entityPhysicaEntry }
        ::= { entityStateTable 1 }

     EntityStateEntry ::= SEQUENCE {
         entityStateAdmin 	ItuAdminState,
         entityStateOper    ItuOperState,
         entityStateUnknownValue  ItuUnknownStatusValue,
         entityStateUsage  	ItuUsageState,
         entityStateAlarm	ItuAlarmStatus,
         entityStateProc    ItuProcStatus,
         entityStateAvail 	ItuAvailStatus, 
         entityStateControl ItuControlStatus,
         entityStateStandby ItuStandbyStatus,
         entityStateComputed INTEGER
        }                      
        
 entityStateAdmin OBJECT-TYPE
        SYNTAX      ItuAdminState
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION ""
        ::= { entityStateEntry 1 }     
        
  entityStateOper OBJECT-TYPE
        SYNTAX      ItuOperState
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION ""
        ::= { entityStateEntry 2 }  
 
  entityStateUnknownValue OBJECT-TYPE
        SYNTAX      ItuUnknownStatusValue
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION ""
        ::= { entityStateEntry 3 }     
        
  entityStateUsage OBJECT-TYPE
        SYNTAX      ItuUsageState
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION ""
        ::= { entityStateEntry 4 } 
        
  entityStateAlarm OBJECT-TYPE
        SYNTAX      ItuAlarmStatus
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION ""
        ::= { entityStateEntry 5 }     
        
  entityStateProc OBJECT-TYPE
        SYNTAX      ItuProcStatus
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION ""
        ::= { entityStateEntry 6 } 
        
 entityStateAvail OBJECT-TYPE
        SYNTAX      ItuAvailStatus
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION ""
        ::= { entityStateEntry 7 }     
        
 entityStateControl OBJECT-TYPE
        SYNTAX      ItuControlStatus
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION ""
        ::= { entityStateEntry 8 }         
                
 entityStateStandby OBJECT-TYPE
   		SYNTAX ItuStandbyStatus
   		MAX-ACCESS read-only
   		STATUS current
   		DESCRIPTION ""
   ::= { entityStateEntry 9 }         
        
 entityStateComputed OBJECT-TYPE
 		SYNTAX INTEGER    {   
 		  other (1),
 		  clear (2),
 		  warning (3),
 		  minor (4),
 		  major (5),
 		  critical (6)
 		}
 		MAX-ACCESS read-only
 		STATUS current
 		DESCRIPTION
 		"The state of this physical entity computed from its
 		raw states and the raw state of its child entities"
 ::= { entityStateEntry 10 }     

END              

Sharon

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: Tuesday, April 09, 2002 2:22 PM
To: Keith McCloghrie; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Entmib] State, Status and URL info

HI,

The entity MIB for a long time has needed state and status info.
There are very complex models for this, and very simple models.
The below two objects seem a little too simple to me.

The third object looks like a "scratch pad object". It seems
very problematic when you consider how it would be used when
there are multiple managers.

Probably the best resources on this issue are the following
documents:
1)  Telcordia's GR-1093 - Generic State Requirements for Network Elements
    Issue 2, June 2000

2)  ISO/IEC 10164-2 (and ITU-T X.731) - State Management Functions
    August 1991

3)  ITU-T M.3100 - Generic Network Information Model 
    Version 2, 1995

Dave Sidor from the ITU-T community has made available the ITU-T documents
to the IETF community for no fee. But I do not know if Telcordia has
made available any of their documents, which have a fee, to the IETF
community for no fee.

In general, the IETF has a loosely defined generic model for state/status
that was (I believe) first used in the IF table based on admin state
and oper state. This model has been loosely copied to other MIB modules.

The ITU-T and Telcordia models are rigorously defined, and are different
from the IETF model in one important aspect. That is, in the IETF model,
the oper state "follows" (if possible) the the admin state; where in
the ITU-T model, the oper state is independent of the admin state.
The ITU-T model is richer than the IETF model. For example, it
supports redundancy. 

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Jul 2002 10:33:28 -0700

>I agree with Dave that the entity MIB needs state/status information.

I have no objections to a separate RFC for this MIB. Some comments:

The entityStateTable should be a sparse augments, not AUGMENTS, because
an agent should not be required to support this level of
status information for every physical entity. EntityStateAdmin
should be MIN-ACCESS read-only, because not every physical
component can be controlled with the 3 enums
                        locked(1),
                        shuttingDown(2),
                        unlocked(3)
(2) looks like an operState, not an adminState. I would also replace
(1) and (3) with enabled and disabled.  Looking through the MIB,
there are lots of enum values that do not appear to be generally
applicable to all entPhysicalClass values either. (This just means
lots of use case text needs to be included in the RFC.)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Jul 2002 10:33:28 -0700

Andy

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 9 Jul 2002 14:21:09 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Sharon Chisholm" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked], [email-masked]
> Subject: RE: [Entmib] State, Status and URL info
> Date: Thu, 4 Jul 2002 07:41:00 -0400 
...
>              " Represents the possible values of alarm status

This one should probably be BITS rather than INTEGER in order to
match the semantics in X.731 (clause 8.1.2.1); note that the
corresponding syntax in X.721 is a set type.  This might be
problematic. CMIP allows specific members of a SET to be added
or removed, thus avoiding multi-manager race conditions that
can happen with read-write BITS.

(Consider the case where manager sets "under-repair" for a
minor alarm, and "critical" is asserted between the read and
the write.)

>                            initialization-required(1),

Same problem.  Should be BITS; semantics in X.731 clause 8.1.2.2;
note that the corresponding syntax in X.721 is a set type.

>              " Represents the possible values of availability status

Same problem.  Should be BITS; semantics in X.731 clause 8.1.2.3;
note that the corresponding syntax in X.721 is a set type.

>                            part-of-services-locked(2),
...

Same problem.  Should be BITS; semantics in X.731 clause 8.1.2.4;
note that the corresponding syntax in X.721 is a set type.  This
might pose a problem; CMIP allows specific members of a SET to
be added or removed, thus avoiding multi-manager race conditions
that can happen with read-write BITS.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 9 Jul 2002 14:33:14 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Date: Thu, 04 Jul 2002 10:33:28 -0700
> To: "Sharon Chisholm" <[email-masked]>
> From: Andy Bierman <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked], [email-masked],
>         [email-masked]
> In-Reply-To: <[email-masked]
>  l.com>
...
...

No, these really are administrative controls.  Setting the
attribute to locked(1) kicks off any users of the service.
Setting the attributed to shuttingDown(2) prevents new users
from using the service, but does not kick off the current
users.  This way both graceful and abrupt shutdown are possible.
When the last user leaves, shuttingDown transitions automatically
to locked. Figure 6 in X.731 shows the relationship between the
administrative and usage states.  (Figure 4 gives a combined state
diagram that's really quite nice, if a bit harder to digest.)

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 9 Jul 2002 16:02:31 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> Date: Tue, 09 Jul 2002 15:47:21 -0700
> To: Randy Presuhn <[email-masked]>
> Cc: [email-masked]
> References: <[email-masked]>
...
> Well the enum names are misleading.  You mention that these
> are administrative states applied to services. In that case,
> how does this object (maybe the whole MIB) apply to
> physical entities?  It sounds like this should apply to
> logical entities.
...

I think X.731 clause 7.1 sums it up nicely:

| Three primary factors affect the management state of a managed
| object with regard to its corresponding rsources' availability.
| Some managed objects may not be affected by all three of these
| factors.  These are
|
|  - operability: whether or not the resource is physically
|    installed and working, if applicable;
|  - usage: whether or not the resource is actively in use at
|    a specific instant, and if so, whether or not it has spare
|    capacity for additional users at that instant.  A resource
|    is said to be "in use" when it has received one or more
|    requests for service that it has not yet completed or
|    otherwise discharged, or when some part of its capacity
|    has been allocated, and not yet recalimed, as a result of
|    a previous service request;
|  - administration: permission to use or prohibition against
|    using the resource, imposed through the management services.
|
| The state of a managed object does not affect its ability to
| respond to management operations.

As a practical matter, this means that these may be applicable
to both physical and logical entities, and there will be some
entities to which some of these may not apply.  I agree with
your earlier comment about the augmentation being sparse.

This is one of the reasons why X.731 clause 8.1.3 defines the
"state" attribute group.  This lets a CMIP manager ask an
object to return "whatever your state attribute(s) are".

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 10 Jul 2002 10:31:00 -0700 (PDT)

Hi -

> Date: Wed, 10 Jul 2002 18:36:33 +0200
> Message-Id: <[email-masked]>
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> In-reply-to: <[email-masked]> (message from Randy
> 	Presuhn on Tue, 9 Jul 2002 14:21:09 -0700 (PDT))
> References:  <[email-masked]>
> 
> 
> I am ignorant of the details in the X.731 / X.721 documents. So from
> the ignorant point of view, I am a bit puzzled...
> 
> Randy> Same problem.  Should be BITS; semantics in X.731 clause
> Randy> 8.1.2.2; note that the corresponding syntax in X.721 is a set
> Randy> type.
> 
> So I can be initializing(3) and terminating(5) at the same time? Or is
> there some state machine that defines which bits may be set?

Rec. X.731 clause 8.1.2.2 spells out constraints.

> In short: It would be extremely helpful for people like me if someone
> can provide a description of the model behind the proposal.
...

| The procedural status attribute is supported only by those classes
| of managed objects that represent some procedure (e.g., a test
| process) which progresses through a sequence of phases.  Depending
| upon the managed object class definition, the procedure may be
| required to reach certain phases for the resource to be operational
| and available for use (i.e. for the managed object to be enabled).
| Not all phases may be applicable to every class of managed object.
| If the value of this attribute is an empty set the managed object
| is ready, for example, the initialization is complete.

X.731 then provides more detailed descriptions of each of the
possible values in the set, along with their relationship to
the operational state attribute.  For example:

|  - terminating: The resource is in a termination phase.  If the
|    resource does not reinitialize itself autonomously, the
|    Initialization Required condition is also present and the
|    operational state is disabled.  Otherwise, the operational
|    state may be either disabled or enabled, depending on the
|    managed object class definition.

If the WG is seriously considering this proposal, it'd
be a good idea for participants to read through X.731,
since it goes into considerable detail about the model.
Pages 5-17 (in the 1992 version I have, sections 7 and 8
(model and generic definitions)) are the most important
for this discussion.  The document is available for (free)
download from the ITU web site http://www.itu.int/

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 10 Jul 2002 10:31:00 -0700 (PDT)

Hi -

...