Chassis MIB Proposal

dan@lannet.com (Dan Romascanu) Wed, 12 August 1992 09:25 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA04844; Wed, 12 Aug 92 05:25:42 -0400
Received: from [192.84.3.7] by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA04702; Wed, 12 Aug 92 05:25:03 -0400
Received: from moon.lannet.com ([149.49.50.12]) by lannet.com (4.1/3.1.090690-Lannet Data Communications) id AA14501; Wed, 12 Aug 92 09:49:47 IDT
Received: by moon.lannet.com (4.1/SMI-4.1) id AA27841; Wed, 12 Aug 92 09:49:44 IDT
Date: Wed, 12 Aug 92 09:49:44 IDT
Message-Id: <9208120649.AA27841@moon.lannet.com>
From: dan@lannet.com (Dan Romascanu)
To: chassismib@cs.utk.edu
Subject: Chassis MIB Proposal


Hi,

1. I would break chasSlotEmpty into two:
   - chasSlotEmptyAccessible (or ..Available)
   - chasSlotEmptyNotAccessible.
This would solve part of the problem brought by jason@coral.com (FRU
residing in another slot, obstructing this slot).

2. chasEntityAdminStatus

gallagher@quiver.enet.dec.com proposes:
> restoreToDefaults(5) - setting this object to this state
> restore all of its non-volatile parameters to their
> factory default state and resets the module (see reset(4)).

Seems to me pretty dangerous, but I can live with it in the MIB
(and never use it).

I would add:
  programLoadCommand(6) - setting this object to this state initiates
  a software loading (or update) procedure on the given entity.

3. chasEntityOperStatus

  a. I do not undestand the meaning of invalid(2). Can somebody explain?
  b. I would break error(5) into three: 
     - warning
     - nonFatalError
     - fatalError
  c. I agree with the proposal of gallagher@quiver.enet.dec.com for
     - needProgramLoad
     - loading
  
  4. chasEntityFunction

a. 
> chasEntityFunction is defined for those entities that may have 
> multiple functions. Perhaps we should adopt the policy that
> an entity has a single function. In which case
> chasEntityFunction would no longer be needed.

I wouldn't do that. On the contrary, I would extend the range of the
devices which are described. Anyway we have exceeded the 0..255 range.
(2^8 = 256, so that a power supply doesn't fit into 0..255).

b. In the previous proposal repeater and concentrator were separated.
I think it is more correct. I hardly can see why an FDDI concentrator
should be described as a repeater.

c. I would add netMonitoring and netServer to the list.

d. The example in the DESCRIPTION text is mistaken. Value should be 
12 (2^2 + 2^3).
  
  5. What about the Power Supply MIB? We had some discussions on the list
a few weeks ago and I had the feeling enogh material exists for a 
proposal to be forwarded.
 
dan@lannet.com

Dan Romascanu
Systems Group Manager

LANNET Data Communications Ltd.
Tel Aviv, Israel

Voice: 972-3-6458414
Fax:   972-3-5447146