DECnet IV MIB issues...
"John A. Shriver" <email@example.com> Fri, 16 April 1993 16:40 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09478;
16 Apr 93 12:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09474; 16 Apr 93 12:40 EDT
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa18722; 16 Apr 93 12:40 EDT
Received: by inet-gw-2.pa.dec.com; id AA18677; Fri, 16 Apr 93 09:33:43 -0700
Received: by nsl.pa.dec.com; id AA01937; Fri, 16 Apr 93 08:12:48 -0700
Received: by nsl.pa.dec.com; id AA01930; Fri, 16 Apr 93 08:12:17 -0700
Received: by inet-gw-2.pa.dec.com; id AA13844; Fri, 16 Apr 93 08:12:12 -0700
Received: from ironside.proteon.com by monk.proteon.com (5.65/1.8) id AA06650; Fri, 16 Apr 93 11:20:12 -0400
Received: by ironside.proteon.com (4.1/SMI-4.1) id AA01476; Fri, 16 Apr 93 11:11:57 EDT
Date: Fri, 16 Apr 93 11:11:57 EDT
From: "John A. Shriver" <firstname.lastname@example.org>
In-Reply-To: Don Dewar's message of Fri, 16 Apr 93 07:30:54 EDT <9304161130.AA08682@atlantis.coral.com>
Subject: DECnet IV MIB issues...
The distinction between Circuit and Line MAC address in DECnet is that the Circuit address is the "computed" DECnet MAC address (AA-00-04-...), and the Line address is the PROM MAC address. For instance, on our VAX: NCP>show line mna-0 char Line Volatile Characteristics as of 16-APR-1993 10:59:24 Line = MNA-0 Receive buffers = 6 Controller = normal Protocol = Ethernet Service timer = 4000 Hardware address = 08-00-2B-17-ED-46 Device buffer size = 1498 Now, the Line portion of the DECnet Phase IV MIB is somewhere between small and non-existent. The reason is that almost everything in it is duplicated by the core MIB-II, so there's no reason to export it again. Of course, I presume that MIB-II wants you to display the current MAC address, not the PROM MAC address. Whether you have really "set" the physical address of your promiscuous Ethernet interface to AA-00-04-..., you do have to use that as the source address of all your DECnet packets. (Yes, some DECnet implementations verify those MAC addresses to protect users from their own errors.) As for phivLineState versus phivCircuitCommonState, again, the LINE is the global state for the physical interface, for all protocols. It just happens to be managed via NCP. However, in the SNMP world, you would not manage it that way, that control is offered in the dot3 MIB (for anyone who wants to go through the pain of offering independent control of transmit and recieve enable). The DECnet MIB only manages the DECnet aspects of the interface, thus only phivCircuitCircuitCommonState is read/write. As for why the DECnet MIB doesn't cover any of the extensions, well, it's a faithful translation of the NICE protocol to SNMP. DEC does not offer filters in their DECnet products! Since DEC has taken the lead on this, I can't blame them for having a certain DEC-centricism. (Also, I suspect that all of the proprietary filters are adequeately different that one MIB could not describe them.) I've seen that some very recent MIBs allow for multiple instances, like the one that Novell is promulgating for NLSP. This is certainly a change. I wonder if that's really the way to go, or whether there should be a more global concept of instances.