Re: DECnet MIB question (3)

[Art Berggreen <[e-mail]>]

>3.  The index for adjacencies.
>
>Mark Sylor points out that: In DECNet Phase IV, (at least in the NICE
>protocol and in the NCP utility) an adjacency does have what corresponds
>to two indices. One is the name of the circuit, one is the node address
>of the adjacent node.
>
>I just wanted to underscore what John had sent in a previous note about
>the adjacency index.  I believe that this was discussed (either on the
>mailing list or at one of our working group meetings - don't remember
>which).  The simple, single index does allow for unique identification,
>if not as tidy as the tuple would be - and does have the advantages that
>John Shriver pointed out.  It is clear the current description should be
>reworded to be:
>
>	"A unique index value for each known adjacency."

If you are saying that the object phivAdjCircuitIndex should be defined
as a unique identifier across all adjacencies, then I think we need a
new object which specifies which DECnet Circuit the adjacency has been
formed across.

If you are just refering to the instantiation of the adjacency table
members, then the INDEX clause needs to refer to something other than
phivAdjCircuitIndex.  There could be a new object (say phivAdjIndex)
which relects this value.

Either a purely local index or an instance composed of circuit ID and
adjacency node ID will work.  The major advantage of a structured instance,
is during partial table references.  If one wants to find the adjacencies
on a particular circuit, the unique identifier requires a full table scan.
Also, if the circuit ID and Adjacency node ID are known, and just objects
in one row of the table are desired, the unique entry identifier must be
known.  This requires at least one full scan of the table and caching of
the indexing information.  For a router on several LANs, the adjacecy
table could be rather large.

Art