Ghosts and other semi-corporeal networking topics

ricci@mtunm.att.com Fri, 19 February 1993 21:17 UTC

Errors-To: owner-fddi-mib@CS.UTK.EDU
Message-Id: <9302192045.AA05852@CS.UTK.EDU>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: ricci@mtunm.att.com
Date: Fri, 19 Feb 1993 15:42:00 -0500
Original-From: ricci@mtunm.lincroftnj.ncr.com
To: anil@levers.enet.dec.com
Cc: fddi-mib@cs.utk.edu, mtunm!ricci@gatech.edu
Subject: Ghosts and other semi-corporeal networking topics

Anil writes:

    *<groan> looks like this issue's back to haunt us.. here's another
    * exorcism attempt.."

Sorry if I'm dredging up old issues but I haven't seen a concrete proposal
that address this issue in a satisfactory mannor.

    *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)

  I'm not sure if what you've presented can be adopted to FDDI given the way
things are done in SMT.  I haven't reviewed the Repeater MIB, however, and
the portion shown above is presented out of context, so it's rather
difficult to judge its suitability.  If you could put together an example
for, say, the MAC group in FDDI then we would have something concrete that
could be commented on.  Without this, its rather hard (at least for me) to
endorse what your proposing.
  As for my comments regarding the "properness" of methods, I wasn't trying
to provide explanations and/or justify the techniques; I was trying to be
brief since I believed these issues to have already been discussed and
understood.  Perhaps my assumptions were incorrect.  All I can say is that
if you give me a concrete example to examine I promise that all my responses
will be appropriately detailed.


   Regards,

    Sal Ricci
    AT&T/NCR Network Products Development
    908-576-6337

Ghosts and other semi-corporeal networking topics ricci