ghosts.. last call

Anil Rijsinghani <> Wed, 24 February 1993 19:04 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa10573; 24 Feb 93 14:04 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10569; 24 Feb 93 14:04 EST
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa22112; 24 Feb 93 14:04 EST
Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22739; Wed, 24 Feb 93 13:31:04 -0500
X-Resent-To: fddi-mib@CS.UTK.EDU ; Wed, 24 Feb 1993 13:31:03 EST
Errors-To: owner-fddi-mib@CS.UTK.EDU
Received: from by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22731; Wed, 24 Feb 93 13:30:59 -0500
Received: by; id AA10669; Wed, 24 Feb 93 10:30:56 -0800
Received: by; id AA10363; Wed, 24 Feb 93 13:28:31 -0500
Message-Id: <>
Received: from levers.enet; by us1rmc.enet; Wed, 24 Feb 93 13:28:36 EST
Date: Wed, 24 Feb 93 13:28:36 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Anil Rijsinghani <>
Subject: ghosts.. last call


    I've communicated off-line with Sal Ricci on the subject of
    ghost resources, and show below the solution we have agreement
    upon.  Please speak up if there are any objections.

    In both the MAC and PORT groups, there will be a hardware-present
    object.  This will be used to deal with the ghost problem in
    a similar way as the Repeater MIB uses GroupOperStatus.

    In effect the only change will be addition of the following wording
    to the HardwarePresent object description (or something along these

    "..If the value of this object is 'notpresent', the reporting of
    this entry is handled in an implementation-specific manner."

    Ghosts are an elusive enough problem that this gives the maximum
    flexibility in dealing with them: exactly as many objects are
    implemented as make sense in any given scenario for something that's
    not physically present.  We also enforce SNMP's "group is a unit of
    conformance" rule by requiring implementation of all objects if the
    resource is physically present.