Adjacency index

[[e-mail]]

Well I stand corrected.  Given that, that leaves us with two choices, either
depricate the old table which would work (as in MIBII).  I think it is messy
though.  The other choice is to do what we had planned last week.  Just change
the description which was unclear - the semantics really do not change  The
index was the index value of the circuit (taken from the circuit table) over 
which the adjacency is realized.

/jon


------- Forwarded Message

Return-Path: [e-mail]
Received: by tcpjon.ogo.dec.com (5.57/ULTRIX-fma-071891);
	id AA03885; Tue, 25 Aug 92 13:00:47 -0400
Received: by inet-gw-2.pa.dec.com; id AA11599; Tue, 25 Aug 92 09:57:56 -0700
Received: from immer.synoptics.com by synoptics.com (4.1/SMI-4.1)id AA05039; Tue, 25 Aug 92 09:56:20 PDT
Received: by immer.synoptics.com (4.1/2.0N)   id AA29590; Tue, 25 Aug 92 09:56:21 PDT
Message-Id: <[e-mail]>
Date: Tue, 25 Aug 92 09:56:21 PDT
From: David Perkins <[e-mail]>
To: [e-mail], saperia
Subject: Re: DECnet MIB question (3) -- adjacency
Cc: [e-mail], [e-mail]

Jon,

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.

Sorry,
/dave perkins, synoptics, 408-764-1516

------- End of Forwarded Message