Re: Adjacency index

Debasis Dalapati <> Fri, 28 August 1992 18:39 UTC

Received: from by IETF.NRI.Reston.VA.US id aa05397; 28 Aug 92 14:39 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05393; 28 Aug 92 14:39 EDT
Received: from by NRI.Reston.VA.US id aa13363; 28 Aug 92 14:41 EDT
Received: by; id AA13524; Fri, 28 Aug 92 11:37:14 -0700
Received: by; id AA11596; Fri, 28 Aug 92 11:30:40 -0700
Received: by; id AA11592; Fri, 28 Aug 92 11:30:39 -0700
Received: by; id AA13136; Fri, 28 Aug 92 11:30:37 -0700
Received: by bagate.BELL-ATL.COM (/\==/\ Smail3.1.25.1 #25.29)id <m0mOB7G-0000ZnC@bagate.BELL-ATL.COM>; Fri, 28 Aug 92 14:32 EDT
Received: by (4.1/SMI-4.1)id AA24207; Fri, 28 Aug 92 14:38:38 EDT
Date: Fri, 28 Aug 92 14:38:38 EDT
From: Debasis Dalapati <>
Message-Id: <>
Subject: Re: Adjacency index

>No problem, Chuck sent me a note which echo's what you say:
>>This question is easy. OIDS are NEVER EVER EVER reassigned and used
>>for another purpose. So, the current OIDs must continue to refer
>>(forever) to the table that you are going to obsolete. You must
>>allocate new OIDs to name the objects in the new-and-improved version
>>of this table. I would suggest that you define the adjacency group at
>>one place in the MIB document.  It should include two tables: the old
>>one (for which the names of the objects are the old OIDs and for which
>>the status of the objects is "obsolete") and the new table (for which
>>the names of the objects are all new OIDs and the status of the
>>objects is "mandatory").
>[stuffs deleted]
>OK lets use phivAdjCircuitIndex The DESCRIPTION of this would be:
>  	       "A unique index value for each known circuit.  This
>               value is the same as phivCircuitIndex and identifies the
>               circuit over which the adjacency is realized."
>Is this what everyone expects??
>I am going around on this so that everyone is comfortable with the change and
>understands what it means (including myself).

Could you repeat once more what the "INDEX" specification would look like for
phivAdjEntry object ?

If the old table is to be maintained with the new one then I think the
textual names of the objects within the table also need change. Any idea?
My suggestion is to add just the letter "n" after the string "phivAdj" in
all the current textual names. As an example, "phivAdjBlockSize" becomes
"phivAdjnBlockSize". Please, whatever names you give, derive them from the
existing names.

debasis dalapati