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 93 20:24:39 EST
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 :-)