RE: Alternative procedure for updating MIB modules

["C. M. Heard" <heard@pobox.com>]

On Mon, 31 May 2004, Wijnen, Bert (Bert) wrote:
Bert> > > > I also agree with Mike that publishing the complete
Bert> > > > updated module should be a MUST.  Piecing MIB modules
Bert> > > > together from deltas is a bit too bewildering for
Bert> > > > non-experts.
Bert> > > >
Bert> > > You did you see what the proposal was? I must assume you
Bert> > > did, but then maybe I was not clear. The proposal includes
Bert> > > a "merged" mib module to be available at the I-D
Bert> > > repository during WG process and at rfc-editor site when
Bert> > > [the] RFC [is published]. So the non-expert never has to
Bert> > > do the pasting from deltas.
Bert> > ...
Bert> > 
Bert> > With some of the IANA-maintained MIB modules [we're] already
Bert> > there, but it still bothers me that the "official" module
Bert> > might not be exactly what is published in the RFC.  For
Bert> > example, if module X is extended by non-overlapping deltas
Bert> > published in RFCs Y and Z, does a vendor's claim of support
Bert> > for "RFC Z" imply support for "Y", or will this have to be
Bert> > handled by *very* carefully written conformance material in
Bert> > the RFCs?
Bert> > 
Bert> Yep... I am not aware we have been in a "too difficult"
Bert> situation yet.  So I am willing to go for it.  We'll see how
Bert>it goes and if wee need additional rules/guidelines.

Well, there are a couple of things that Andy mentioned earlier that
I would very much like to see included in the written alternative
procedure for updating MIB modules.  The first is from the second
bullet in his "Pros" for this procedure in the HC-RMON case:

On Tue, 25 May 2004, Andy Bierman wrote:
Andy>- HC-RMON (RFC 3273, sec. 3) includes enum updates to RMON (STD
Andy>  59) and RMON2 (RFC 2021).  
Andy>  Pros:
Andy>     - It is clear to the HC-RMON developer what needs to be done
Andy>       to add HC TopN report capability to RMON and RMON2.
Andy>     - HC stuff is related only to HC-RMON document and does not
Andy>       impact conformance or semantics of existing RMON and RMON2
Andy>       whatsoever (IMO, prerequisite for this delta approach)
------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Andy>     - STD 59 did not have to be republished to add the HC-related
Andy>       enums
Andy>     - The updated modules are available (FTP) so authors do not
Andy>       have to patch these MIB modules themselves

My specific suggestion is this:  the delta-MIB approach should be
allowed ONLY when the conformance statements in the original MIB
module remain valid and in force.  That was the case for the updates
in RFC 3273 (and note that OBJECT clauses were inserted into the
merged RMON and RMON2 modules on the ftp site in order to keep the
semantics equivalent to the originals).

Consider the following situation:  a WG adds some small deltas (like
additional enums) to an existing MIB module, it wishes to require
that these deltas must be implemented to claim conformance, and it
wants to deprecate or obsolete the old conformance statements.  In
this case I would suggest that the delta approach should not be
used. In other words, status changes to conformance statements
should probably be a threshold that requires republication of the
whole MIB module in a new RFC.

The other thing I'd like to see in the written rules is a statement
of what is supposed to happen to the MIB modules on the RFC Editor
site when they are superseded.  This is motivated by the second
bullet in Andy's "Cons" for this procedure in the HC-RMON case:

Andy>  Cons:
Andy>     - RFC 3273 doesn't have the normative version of these 
Andy>       *TopNControlRateBase objects.  Neither does the FTP version.
Andy>       (Yet, section 3 of RFC 3273 is normative -- oops.)
Andy>       It just so happens that RMON2 is about to be republished.
Andy>       The update <draft-ietf-rmonmib-rmon2-v2-01.txt> contains all 
Andy>       the HC enums.  Soon all the 'RMON2' related text in RFC 3273 
Andy>       (and the FTP version rmon2.mib) will be obsolete.  IMO, this
Andy>       will cause some confusion.
Andy>     - This approach doesn't scale at all.  I don't even think N=2
Andy>       is manageable.

My suggestion would be that when the RFC containing the new RMON2-MIB
becomes available, then the existing FTP version rmon2.mib should be
_replaced_ either by the updated RMON2-MIB module extracted from the
RFC, or else by a note with a pointer to the RFC stating that the
ftp version is obsolete.  The same disposition would apply in the
general case.

Mike