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
- Chassis MIB Proposal Dan Romascanu
- Re: Chassis MIB Proposal Pablo Brenner
- Re: Chassis MIB Proposal dan
- Chassis MIB Proposal {3COM/PDD/PeteW}
- Chassis MIB Proposal {3COM/PDD/PeteW}
- Chassis MIB Proposal {3COM/PDD/PeteW}
- Chassis MIB Proposal {3COM/PDD/PeteW}
- Chassis MIB Proposal {3COM/PDD/PeteW}
- Chassis MIB Proposal {3COM/PDD/PeteW}
- Chassis MIB Proposal {3COM/PDD/PeteW}
- Chassis MIB Proposal {3COM/PDD/PeteW}
- Chassis MIB Proposal {3COM/PDD/PeteW}