DECnet IV MIB issues...

"John A. Shriver" <jas@proteon.com> Fri, 16 April 1993 16:40 UTC

Date: Fri, 16 Apr 1993 11:11:57 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "John A. Shriver" <jas@proteon.com>
Message-Id: <9304161511.AA01476@ironside.proteon.com>
To: don@coral.com
Cc: phiv-mib@pa.dec.com
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.