RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disab led - correct ive action required?

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

Hi

As we've heard no interest in supporting a dual-mode oper status I propose
we keep things the way they are and close this issue (entstate-77). Note
that the improved object descriptions should help people better understand
the externally expected behaviour.

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Saturday, November 22, 2003 1:18 PM
To: [e-mail]
Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled -
correct ive action required?


Hi

Hmmm. The problem is then that there are two different ways to interpret the
state of the entity by reading the same values for those three objects. I'd
suggest one of the following then
	1) Always force people to use the states as described. Then even if
the internal 
        state model is as you described, the externally visible behaviour
would be as 
        described in section 2.2.
      2) Support two behaviours for oper state and provide a type object to
tell you 
         which one is being  used. These would be INTEGER {
operIndependentAdmin, 
         operFollowsAdmin (2) }. I'm not sure about this approach, but I
suspect it would
         make some people happy.

Sharon

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[e-mail]] 
Sent: Friday, November 21, 2003 2:53 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]; [e-mail]
Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State
Disabled - correct ive action required?


2.2.2 is fine.

It looks to me that what is not covered in the current version of 2.2.1 is
the case of these devices that are modeled in their state machine so that
the operStatus follows a adminStatus transition to down, although no fault
was detected on the respective interface. These interfaces will never be in
the state described by 2.2.2. For these cases, when adminStatus transitions
back to up is enough to re-establish operStatus as well. 

(I used the IETF MIB-II terminology that I am more familiar with)

Regards,

Dan




> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Sharon Chisholm
> Sent: 21 November, 2003 9:35 PM
> To: [e-mail]
> Subject: RE: [Entmib] FW: [psg.com #77] AutoReply:
> Operational State Disabled - correct ive action required?
> 
> 
> Hi
> 
> Well, the difference between 2.2.1 and 2.2.2 is that one can be made 
> operational simply by enabling the administrative state while one 
> requires some corrective action AND someone to enable the 
> administrative state. I think this covers all the cases you are 
> referring to. Or am I missing something?
> 
> Sharon
> 
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> Sent: Friday, November 21, 2003 2:13 PM
> To: Chisholm, Sharon [CAR:0S00:EXCH]; [e-mail]
> Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State
> Disabled - correct ive action required?
> 
> 
> Sharon,
> 
> You are correct about the section number. The text I was commenting on
> is in Section 2.2.1
> 
> 2.2.1 Admin State Locked, Operational State Disabled and Usage State
> Idle
> 
>    The entity is totally inoperable, it is not servicing any entities
>    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.
> 
> I still believe that there is no need for a corrective action in all
> cases. In some cases restoring management permission by setting
> the admin state to unlock should be enough. The suggested text:
> 
>  The entity is totally inoperable, it is not servicing any entities
>    and it is also administratively prohibited from use. To make it
>    available for use, management permission (and in some cases
> corrective
>    action) are necessary. This is similar to an ifAdminStatus of down
>    and ifOperStatus of down.
> 
> Regards,
> 
> Dan
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On Behalf 
> > Of Sharon Chisholm
> > Sent: 21 November, 2003 8:38 PM
> > To: [e-mail]
> > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State 
> > Disabled - correct ive action required?
> > 
> > 
> > Hi
> > 
> > Proposed Resolution to ent-state-77:
> > 
> > Actually, I believe what you are describing is in section 2.2.2.
> > 
> > I propose that no change is required as a result of this comment.
> > 
> > 
> > -----Original Message-----
> > From: entity-state [mailto:[e-mail]]
> > Sent: Tuesday, July 15, 2003 4:24 AM
> > To: Chisholm, Sharon [CAR:0S00:EXCH]
> > Subject: [psg.com #77] AutoReply: Operational State Disabled
> > - corrective
> > action required?
> > 
> > <clip>
> > 
> > --------------------------------------------------------------
> > -----------
> > Romascanu, Dan (Dan) [[e-mail]]
> > 
> > "Section 2.2.1 in [in version 01]- A corrective action is not 
> > necessary in all cases to make an entity available for use. In some 
> > cases setting the admin state to unlock should be enough."
> > 
> > _______________________________________________
> > Entmib mailing list
> > [e-mail] https://www1.ietf.org/mailman/listinfo/entmib
> > 
> 
> _______________________________________________
> Entmib mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/entmib
> 

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

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