portDown/portUp Traps...

"For every vision, there is an equal and opposite revision." <pariseau@quiver.enet.dec.com> Tue, 27 October 1992 19:04 UTC

Message-Id: <9210271810.AA02993@enet-gw.pa.dec.com>
Date: Tue, 27 Oct 1992 10:19:28 -0800
Sender: ietf-archive-request@IETF.NRI.Reston.VA.US
From: "For every vision, there is an equal and opposite revision." <pariseau@quiver.enet.dec.com>
To: fddi-mib@cs.utk.edu
Cc: pariseau@quiver.enet.dec.com
Apparently-To: fddi-mib@cs.utk.edu
Subject: portDown/portUp Traps...

    I agree with James that IF we want Traps we should work with the
    notifications defined in SMT.

    But the next issue is which notifications?  It seems to me that
    PeerWrapCondition and LerCondition are as important as PathChange.
    
    Or should we forget Traps and use RMON.

    Luc



From:	US1RMC::"james_reeves@engtwomac.synoptics.com" "James Reeves" 26-OCT-1992 16:30:45.55
To:	fddi-mib@cs.utk.edu
Subj:	Re: Re- portDown/portUp

         Reply to:   RE>Re: portDown/portUp

> Agree with Paul and Anil, but if we go further, because of the
> same reason we may need some other traps (Duplicate address found
> for example?)

I believe we should be working from the set of events that are already defined
in the SMT document. The PortDown/Up can be derived from information in the
Path Change event. It is not enough to say that a port went down. The port may
have been changed to a local or secondary path; in which case it is has
effectively disappeared.

James

portDown/portUp Traps... For every vision, there is an equal and opposite revision.