Re: if mapping

Anil Rijsinghani <> Fri, 19 February 1993 01:59 UTC

Received: from 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 by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12391; Thu, 18 Feb 93 20:27:02 -0500
Received: by; id AA01457; Thu, 18 Feb 93 17:26:59 -0800
Received: by; id AA16839; Thu, 18 Feb 93 20:24:26 -0500
Message-Id: <>
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 <>
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 {
       ACCESS    read-only
       STATUS    mandatory
               "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)


    ps: nice to see some life on this list.. if we're not careful we'll
    get this mib done yet :-)