Adjacency index

"John A. Shriver" <> Thu, 27 August 1992 17:00 UTC

Received: from by IETF.NRI.Reston.VA.US id aa05647; 27 Aug 92 13:00 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05643; 27 Aug 92 13:00 EDT
Received: from by NRI.Reston.VA.US id aa15133; 27 Aug 92 13:02 EDT
Received: by; id AA27737; Thu, 27 Aug 92 10:00:43 -0700
Received: by; id AA11826; Thu, 27 Aug 92 09:09:35 -0700
Received: by; id AA11822; Thu, 27 Aug 92 09:09:33 -0700
Received: by; id AA24807; Thu, 27 Aug 92 09:09:31 -0700
Received: from by (5.65/1.8)id AA22427; Thu, 27 Aug 92 12:09:45 -0400
Received: by (3.2/SMI-3.2)id AA15196; Thu, 27 Aug 92 12:09:03 EDT
Date: Thu, 27 Aug 92 12:09:03 EDT
From: "John A. Shriver" <>
Message-Id: <>
In-Reply-To: Bob Stewart's message of Wed, 26 Aug 92 10:52:10 -0500 <>
Subject: Adjacency index

The protocol is broken.  Just redefining the index the way Xyplex did
does not solve the whole problem.  Then you have no idea which circuit
an adjacency is on.  This is mandatory information in debugging DECnet
routing problems.  A SNMP MIB that does not allow hop-by-hop debugging
of the routing is busted.  While the routing table is the primary
information, you really need to know where the adjacencies are to
debug failures.

As for the order of entries in a table, it really does not matter what
values and arbitrary index takes.  The station can just search the
table.  It would not be the only MIB table with a "meaningless" index,
although that is certainly not the desired design.

As for the endcoding of the address, I had brought that up a long time
ago.  I had proposed that the DECnet addresses be coded as two ASN.1
intergers, area and node.  It wasn't defined that way (I think for
consistency with NICE), and is instead one opaque integer.

I hadn't realized that the opaque integer (octet string) was going to
get decomposed into two 1-byte indices.  Ouch.