Re: Re- portDown/portUp

James Reeves <james_reeves@engtwomac.synoptics.com> Mon, 26 October 1992 21:40 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa22365; 26 Oct 92 16:40 EST
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa22361; 26 Oct 92 16:40 EST
Received: from CS.UTK.EDU by NRI.Reston.VA.US id aa07231; 26 Oct 92 16:40 EST
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA17035; Mon, 26 Oct 92 16:03:42 -0500
Received: from mvis1.synoptics.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA17031; Mon, 26 Oct 92 16:03:37 -0500
Received: from engtwomac.synoptics.com by synoptics.com (4.1/SMI-4.1) id AA25520; Mon, 26 Oct 92 13:02:31 PST
Message-Id: <9210262102.AA25520@synoptics.com>
Date: Mon, 26 Oct 1992 14:14:51 -0000
Sender: ietf-archive-request@IETF.NRI.Reston.VA.US
From: James Reeves <james_reeves@engtwomac.synoptics.com>
Subject: Re: Re- portDown/portUp
To: fddi-mib@cs.utk.edu

         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