Re: DECnet MIB question (3)

Art Berggreen <> Fri, 21 August 1992 19:01 UTC

Received: from by IETF.NRI.Reston.VA.US id ab05003; 21 Aug 92 15:01 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04999; 21 Aug 92 15:01 EDT
Received: from by NRI.Reston.VA.US id aa14221; 21 Aug 92 15:03 EDT
Received: by; id AA27043; Fri, 21 Aug 92 12:02:50 -0700
Received: by; id AA21612; Fri, 21 Aug 92 11:36:47 -0700
Received: by; id AA21608; Fri, 21 Aug 92 11:36:46 -0700
Received: by; id AA13555; Fri, 21 Aug 92 11:36:44 -0700
Received: by (4.1/SMI-4.0)id AA17487; Fri, 21 Aug 92 11:38:18 PDT
Date: Fri, 21 Aug 92 11:38:18 PDT
From: Art Berggreen <>
Message-Id: <>
Subject: Re: DECnet MIB question (3)

>I am not trying to find out or propose how a management instrumentation
>could/should  manage the adjacency table. 
>I am just trying to figure out which adjacency information should be returned
>to a management station for a get-next request.
>The INDEX specification is very important for that purpose. No matter how many
>different vendors routers is managed by a management station, it should get
>the similar response from all the DECnet routers. An agent is free to 
>implement and maintain the adjacency table in any manner it wants to but when
>responding to a management station's request, adjacency information has to
>be returned in a predefined manner. The management station should not have
>to rearrange the retrieved information based on which agent it is dealing with.


This comes down to whether the instance is defined to be an arbitrary, locally
defined indentifier or is composed of externally meaningful information (like
the tuple (circuit table index, adjacency address)).  If it is a unique,
local identifier, then (as currently written) there is no guaranteed order
amoung the adjacencies returned in a lexographic walk (get-next) of the
table.  We have agreed (I think) that if the instance has external meaning,
then it needs to contain both circuit index and adjacency address, to be
unique (making it a multi-part instance).  This format would be fine by me,
but others have  voiced a preference for a simpler instance.