Re: DECnet MIB question (3) -- adjacency

David Perkins <> Tue, 25 August 1992 17:01 UTC

Received: from by IETF.NRI.Reston.VA.US id aa03889; 25 Aug 92 13:01 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03885; 25 Aug 92 13:01 EDT
Received: from by NRI.Reston.VA.US id aa11483; 25 Aug 92 13:02 EDT
Received: by; id AA11724; Tue, 25 Aug 92 10:00:31 -0700
Received: by; id AA13878; Tue, 25 Aug 92 09:59:39 -0700
Received: by; id AA13852; Tue, 25 Aug 92 09:58:48 -0700
Received: by; id AA26423; Tue, 25 Aug 92 09:58:06 -0700
Received: from by (4.1/SMI-4.1)id AA05039; Tue, 25 Aug 92 09:56:20 PDT
Received: by (4.1/2.0N) id AA29590; Tue, 25 Aug 92 09:56:21 PDT
Message-Id: <>
Date: Tue, 25 Aug 92 09:56:21 PDT
From: David Perkins <>
Subject: Re: DECnet MIB question (3) -- adjacency


There are only a few characteristics about MIB
items that can be changed once the MIB is published.
You can change the DESCRIPTION text as long as the semantics
are not changed. You can change the REFERENCE text to fix
typo's, bugs, etc. But you can not change the indexing,
or syntax. So, the question from Phil was a good one.

	Phil asks:

	>>Can you change the index on a table without deprecating
	>>the old one and creating a new and different one
	>>(particularly if an RFC has been published)?

        Jon's response....

	>>>The answer in this case is yes.  My interpretation of this
	>>>is that the documnet is currently at proposed standard status.
	>>>Before it could be moved forward as a draft, people have
	>>>to work on implementations.  The change to the index is 
	>>>a result of people looking at the problem a bit more closely.
	>>>So I see this as a normal part of the evolution.

	>>>I also do not think it is a major change.  If others on
	>>>the list really wanted to keep the other and deprecate
	>>>it I suppose we could. I do not feel very strongly about
	>>>this - so if there is a big press to deprecate the old and
	>>>essentially copy it with a couple of very minor changes
	>>>(not from a coding perspective as John would point out)
	>>>I will do it. 

This response is not correct. The proper way to "fix" the
problem is to obsolete/deprecate the old table (and all the "columns")
and to create a new table (and "columns").  This is why writing MIBs
is such a difficult task, since it it not valid to correct certain
classes of bugs by simply republishing the document with the
change once the document has been published. These types of fixes
are hopefully caught before the MIB starts on the standards track.

/dave perkins, synoptics, 408-764-1516