RE: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin St ate

["Sharon Chisholm" <[e-mail]>]

Hi

I'm distilling two things from this email

1. It would be good to better understand the relationship between the admin
state and the usage state to ensure there are no issues

2. There is discussion again about containment, which should be explained by
the text in section 2.1

Sharon

-----Original Message-----
From: David T. Perkins [mailto:[e-mail]] 
Sent: Thursday, February 12, 2004 4:50 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]; [e-mail]
Subject: Re: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin
State


HI,

I also find several problems with the current definition of the value
"shuttingDown" for AdminState.

First, the definition of usageState was radically changed in the current
draft of the document. From the DESCRIPTION clause of object entStateUsage
(with comments in "<...>"): " <text cut>

  Note that in the context of a physical entity, this
  <this is sort of silly to say "in the context of
   a physical entity", since this MIB module is
   describing physical entities>     
  object refers to an entity's ability to service more    
  physical entities in a containment hierarchy. A value   
  of 'idle' means this entity is able to contain other    
  entities but that no other entity is currently          
  contained within this entity, as would have been        
  demonstrated by a value  of entPhysicalContainedIn      
  that referenced this entity.                            
                                                        
  A value of 'active' means that at least one entity is   
  contained within this entity and therefore has a value  
  of entPhysicalContainedIn that references this entity,  
  but that it could handle more. A value of 'busy' means  
  that the entity is unable to handle any additional      
  entities being contained in it, as demonstrated by      
  having a value of entPhysicalContainedIn that refers to 
  this entity.                                            
                                                        
  Some entities will exhibit only a subset of the         
  usage state values. Entities that are unable to ever    
  service any entities within a containment hierarchy will
  always have a usage state of 'busy'. Some entities will 
  only ever be able to support one entity within its      
  containment hierarchy and will therefore only exhibit
  values of 'idle' and 'busy'."                        

Given the above, I don't know how to apply the value of "shuttingDown". But
first, let's look at the values.

Secondly, the X.731 document models the admin characteristic as with a 3
state diagram. The states are "unlocked", "shutting down", and "locked". The
"shutting down" state is meant to represent a graceful shutdown of an
"object". The event "shutdown" is a state transition from "unlocked" to
"shutting down". Another transition occurs from state "shutting down" to
"lock" when event "the last user quits" occurs. Now, if I were to model this
in SNMP's SMI, I would have an "action/state" object with values:
  locked - a state and action
  unlocked - a state and action
  shutDown - an action (a write only value) (on a SET with no
               error, a read would return either value "locked"
               or "shuttingDown")
  shuttingDown - a state (a read only value)

However, given the change of definition of the meaning of usage state, I'm a
little confused as to how to "update" the TC (and object type) definitions.
In general, I'm not sure that there is a need for a "graceful" and "force"
administrative shutdown action values. 
If "graceful" shutdown is added, then I suggest that the value of
"shuttingDown" be return until the value of "operState" is no longer
"enabled". This removes the confusing "user" terminology. (See section
3.1.13 of RFC 2863)

Thirdly, object IF-MIB::ifAdminStatus has a value of "testing". I don't know
it maps to values for AdminState. This was not covered in the document.
 
Finally, neither the IF MIB document nor X.731 describe the relationship
between the admin values and admin (and oper) values of "contained" objects.
And thus, this document does not cover this topic. It can be one of:
  1) there is no relationship
  2) the relationship is implementation defined
  3) there is no relationship between admin values, but there
      is a weak relationship between oper values (more on this
      in message about #309 (oper state values))

At 01:59 PM 2/11/2004 -0500, Sharon Chisholm wrote:
>The following is the proposed resolution to entstate-308. The issue 
>will be considered closed with no changes made to the document.
>
>The following explanations were provided and no questions were raised.
>
>"
>1. Is shutting down really more an operational state?
>
>The state refers more to whether your administrative model allows
>systems to be shut down gracefully or not. The idea being that if it 
>does, you would still have the options to bring it down less 
>gracefully. We have allowed in the description of the object for 
>systems that don't support this value for the state.
>
>2. Would 'noNewUsage' be a better term.
>
>Well, except that the idea is that once all the existing 'users' are
>gone, the system will shut down. The term 'noNewUsage' does not really 
>reflect that."
>
>Sharon
>
>
>-----Original Message-----
>From: entity-state [mailto:[e-mail]]
>Sent: Tuesday, January 13, 2004 2:55 AM
>To: Chisholm, Sharon [CAR:0S00:EXCH]
>Subject: [psg.com #308] AutoReply: Shutting Down Admin State
><clip>
>
>-----------------------------------------------------------------------
>--
>Keith McCloghrie [[e-mail]]
>
>"
>
>the term 'shuttingDown' suggests that the action of shutting down is
>>   in progress, which of course is an operational condition, not an
>admin
>>   state.  A term more reflective of what the AdminState DESCRIPTION
>appears
>>   to define would be 'noNewUsage'.  In any case, this concept
>of 'usage'
>>   is almost always a higher-level usage (e.g., a new ATM connection
>on an
>>   ATM interface, a new Unix login on a cpu module, etc.) and thus
>don't
>>   belong at the physical layer (i.e., don't apply to 
>> entPhysicalIndex).
>"
Regards,
/david t. perkins 


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