Re: DECnet MIB question (3) -- adjacency

Debasis Dalapati <> Fri, 21 August 1992 20:00 UTC

Received: from by IETF.NRI.Reston.VA.US id aa07004; 21 Aug 92 16:00 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07000; 21 Aug 92 16:00 EDT
Received: from by NRI.Reston.VA.US id aa15832; 21 Aug 92 16:02 EDT
Received: by; id AA00332; Fri, 21 Aug 92 13:01:46 -0700
Received: by; id AA22213; Fri, 21 Aug 92 12:21:26 -0700
Received: by; id AA22209; Fri, 21 Aug 92 12:21:25 -0700
Received: by; id AA28110; Fri, 21 Aug 92 12:21:24 -0700
Received: by bagate.BELL-ATL.COM (/\==/\ Smail3.1.25.1 #25.29)id <m0mLeZW-0000aSC@bagate.BELL-ATL.COM>; Fri, 21 Aug 92 15:22 EDT
Received: by (4.1/SMI-4.1)id AA11141; Fri, 21 Aug 92 15:33:04 EDT
Date: Fri, 21 Aug 92 15:33:04 EDT
From: Debasis Dalapati <>
Message-Id: <>
Subject: Re: DECnet MIB question (3) -- adjacency

> (John A. Shriver) wrote:
>The reality of the DECnet specification is that there is an index into
>the adjacency array.  However, it is just an arbitrary number in the
>range 1 to NC+NR+NBEA, which probably is sparsely populated.  Using
>this index is fine, jsut so long as it is unique for each adjacency.
>If your database is based on the DEC spec, this index is much easier
>to manilute than a double-index of circuit and node address.  It's
>going to run faster in the router, which can be an issue in SNMP.
>All that most agents do with tables like this is grovel through them
>with a get next anyways, so the index is relatively moot...


I am writing an agent and just trying to figure out what should a get-next
mean for adjacency table. 
I feel comfortable in knowing the existence of such agents and I am also
getting a sense of what I can get away with in my design of the agent :-)