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
- Re: Re- portDown/portUp James Reeves