Re: DECnet MIB question

[Art Berggreen <[e-mail]>]

>
>   Date: Mon, 10 Aug 92 18:57:49 EDT
>   From: [e-mail] (Debasis Dalapati)
>
>   Hi,
>
>   I am looking at the document "DECnet Digital Network Architecture
>   Phase IV, Routing layer Functional Specification, December 1983"
>   and not sure how the following management information is modeled in
>   the Phase IV mib specification.
>
>   1) page 38-39, adjacency database.  Adjacencies are for broadcast
>   circuits, neighbors on non-broadcast circuits, all router
>   adjacencies on the ethernets and endnodes in the home-area.
>
>      In the RFC1289, page 50 for Adjacency group, PhivAdjEntry is
>      INDEXed by phivAdjCircuitIndex. The DESCRIPTION for
>      phivAdjCircuitIndex is "A unique index value for each known
>      circuit".
>
>I suspect that the wording is a little off here.  I suspect that the
>index is unique for each adjacency.  Each adjacency on a line can be
>viewed as a circuit.  The wording of the RFC probably needs to be
>fixed here.

Looking at RFC-1289, it certainly appears to be documented as using
the circuit index for instantiation.  There is no table object which
would represent a unique identifier for each adjacency.

>      This is fine if only the broadcast circuit adjacencies are of
>      management interest.  Are the broadcast router adjacencies and
>      endnode adjacencies are of no management interest? Why? Is it
>      because they are of transient nature based on the hello timer?
>      If all kind of adjacencies at a given point of time are of
>      management interest, should not the INDEXing be through
>      phivAdjNodeAddr with some way of identifying the multiple
>      broadcast circuit adjacencies?
>
>You don't want to use the node address because you'd need to double
>index, because you can have multiple adjacencies with the same node.
>Double indexed tables are a bitch.

Hmm, this must be implementation dependent.  We don't find compound
instances much more difficult that simple instances.  For adjacencies,
I'd rather use an instance of {phivAdjCircuitIndex,phivAdjNodeAddr}
because that maps directly into how our data structures are organized.

>   2) In the RFC1289, page 53-59 talks about line table and
>   non-broadcast line table.  In the UNIX environment, these tables
>   may be initialized from the kernel.  In the non-UNIX environment,
>   at least for my target environment, it is other way; the drivers (
>   at least the non-broadcast ones) start by reading these table. In
>   other words, these tables are populated at initialization.
>
>      Would it be appropriate to define a new ACCESS type that brings
>      out the
>      fact that some objects are writable at initialization only and
>      then they are read-only?
>
>SNMP has never given a clear mapping of what an SNMP write does.  Eg.,
>is an SNMP write the same as an NCP SET or qan NCP DEFINE?  To the
>best of my knowledge, the typical mapping is "SET", eg. only affect
>volatile database.

I definitely agree that SET behavior is one of less well defined parts
of both SNMP and most MIB specifications.

>   3) IfIndex is so specific to UNIX environment and it is used to
>   describe few objects in the MIB spec! A non-UNIX person just asked
>   me the question after looking at the MIB spec?
>
>Huh?  IfIndex was derived in the router environment, which was, after
>all, the first SNMP target.  It corresponds quite closely with the
>interface numbers in our router.

While I agree, that there is nothing very Unix specific in IfIndex, I've
always felt that the Unix networking code had a strong impact on the
original MIB definitions.  There are still no good answers for what IfIndex
should represent in some of the more complex stacks which can be found
under the routing layers.

Art