Re: FR: Re: Draft MIB Question

Fred Baker <fred@cisco.com> Thu, 16 February 1995 21:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08567; 16 Feb 95 16:44 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08563; 16 Feb 95 16:44 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14833; 16 Feb 95 16:44 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08412; 16 Feb 95 16:44 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08408; 16 Feb 95 16:41 EST
Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa14769; 16 Feb 95 16:41 EST
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id NAA11459; Thu, 16 Feb 1995 13:41:52 -0800
X-Sender: fred@stilton.cisco.com
Message-Id: <v02110101ab697282e2b8@[171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 Feb 1995 13:41:55 -0800
To: comp.dcom.frame-relay@indiana.edu
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fred@cisco.com>
Subject: Re: FR: Re: Draft MIB Question
Cc: iplpdn@CNRI.Reston.VA.US

At 3:44 PM 2/16/95, Pat Calhoun wrote:
>     So then does this event increment the fault counter (frErrFaults)???
>     If so should I then get the time of the fault??? It seems that it
>     would be confusing to the administrator that the port is down yet the
>     MIB's FaultType states NoErrorsSinceReset (especially when the switch
>     came crashing down unexpectedly). Is it possible to extend the MIB to
>     include this error (it is after all in draft mode).
>
>     Anybody else agree???

It's a Proposed Standard, with deployed implementations. I'm a little loath
to change it without a good reason, and then only in a backward compatible
way. Your proposed change would not be backward compatible - some systems
would implement to RFC 1315 (same MIB, Proposed Standard), and some to the
newer, and the same object would return different values.  The step from
Proposed to Draft Standard has some flexibility to add or deprecate
objects, but it is not permitted to change the meaning of existing ones, in
view of backward compatibility.

The reason an internet draft exists at the moment is that we are going from
Proposed to Draft Standard. We added a couple of variables (a boolean to
control multicast capability, and another that escapes recall at the
moment) to it and translated it to the SNMP V2 SMI. I have also agreed to
add a "received DE" counter to the existing draft, which isn't there yet.

It seems that if the Interface is down, the administrator isn't going to go
to the frame relay protocol errors table to figure it out, he's going to go
to the RFC 1573 interface table, and the interface table will tell him

   IfEntry ::=
       SEQUENCE {
           ifIndex                 InterfaceIndex,
           ifDescr                 DisplayString,
           ifType                  IANAifType,
           ifMtu                   Integer32,
           ifSpeed                 Gauge32,
           ifPhysAddress           PhysAddress,
       ==> ifAdminStatus           INTEGER,
       ==> ifOperStatus            INTEGER,
       ==> ifLastChange            TimeTicks,
           ifInOctets              Counter32,
           ifInUcastPkts           Counter32,
       ==> ifInDiscards            Counter32,
       ==> ifInErrors              Counter32,
           ifInUnknownProtos       Counter32,
           ifOutOctets             Counter32,
           ifOutUcastPkts          Counter32,
           ifOutDiscards           Counter32,
           ifOutErrors             Counter32
       }

f you want to continue this discussion, I suggest that we move it to the
working group's list:

        discuss:        iplpdn@nri.reston.va.us
        add/delete:     iplpdn-request@nri.reston.va.us

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Howe's Law: Everyone has a scheme that will not work.