Re: if mapping
Anil Rijsinghani <anil@levers.enet.dec.com> Fri, 19 February 1993 01:59 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20009; 18 Feb 93 20:59 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20005; 18 Feb 93 20:59 EST
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa20145; 18 Feb 93 20:59 EST
Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12399; Thu, 18 Feb 93 20:27:09 -0500
X-Resent-To: fddi-mib@CS.UTK.EDU ; Thu, 18 Feb 1993 20:27:06 EST
Errors-To: owner-fddi-mib@CS.UTK.EDU
Received: from inet-gw-2.pa.dec.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12391; Thu, 18 Feb 93 20:27:02 -0500
Received: by inet-gw-2.pa.dec.com; id AA01457; Thu, 18 Feb 93 17:26:59 -0800
Received: by us1rmc.bb.dec.com; id AA16839; Thu, 18 Feb 93 20:24:26 -0500
Message-Id: <9302190124.AA16839@us1rmc.bb.dec.com>
Received: from levers.enet; by us1rmc.enet; Thu, 18 Feb 93 20:24:39 EST
Date: Thu, 18 Feb 1993 20:24:39 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Anil Rijsinghani <anil@levers.enet.dec.com>
To: ricci@mtunm.att.com
Cc: fddi-mib@cs.utk.edu
Apparently-To: fddi-mib@cs.utk.edu, ricci@mtunm.att.com
Subject: Re: if mapping
I agree with your argument for removing numbering restrictions on indices. > One last point - this about ghosts. Given a ghost resource, in SNMP it > seems improper to be able to retreive some variables and skip others that > have "gone away" because of ghosthood. It also appears to be improper to > assign "default" values to these shadow variables - although I think a good > case could be made for this type of operation. The most "correct" method, <groan> looks like this issue's back to haunt us.. here's another exorcism attempt.. Following is an extract from RFC-1368, the Repeater MIB produced by the hub working group. No special group structuring to accomodate has been attempted. (As mentioned earlier, a group may be a card which is part of a multi-card repeater.) The Chassis MIB people were doing something similar, last I saw their draft.. ================= rptrGroupOperStatus OBJECT-TYPE SYNTAX INTEGER { other(1), operational(2), malfunctioning(3), notPresent(4), underTest(5), resetInProgress(6) } ACCESS read-only STATUS mandatory DESCRIPTION "An object that indicates the operational status of the group. ... A status of notPresent(4) indicates that the group is temporarily or permanently physically and/or logically not a part of the repeater. It is an implementation-specific matter as to whether the agent effectively removes notPresent entries from the table. ================= My vote would be to stay consistent with these MIBs rather than structure the MIB along hardware present and not present lines. If not, I'd like to see a better reason than that it "appears to be improper". (note too as Ron pointed out there are some mandatory objects that simply can't be supported by ghosts) Anil ps: nice to see some life on this list.. if we're not careful we'll get this mib done yet :-)
- if mapping Anil Rijsinghani
- Re: if mapping dsiinc!rem
- Re: if mapping Anil Rijsinghani
- Re: if mapping dsiinc!rem
- Re: if mapping dsiinc!rem
- if mapping ricci
- Re: if mapping Anil Rijsinghani
- Re: if mapping CASE
- Re: if mapping Jason Perreault
- Re: if mapping dsiinc!rem