Re: Alternative procedure for updating MIB modules

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

On Mon, 17 May 2004, Wijnen, Bert (Bert) wrote:
> MIB doctors. We have done this in the past with the two 
> rmon MIB modules. Currently the ADSLMIB is following the 
> same procedure. 
> 
> I am trying to writeup the procedure (for the IESG secretariat)
> for this alternative procedure. I will discuss it in IESG also
> to get IESG consensus on this procedure.
> 
> Pls check my wording below and let me know if you agree or if
> you have any concerns or possibly better wording.
> 
> Thanks,
> Bert 

As I stated during the discussion when this was being done for
the RMON modules I don't agree that this procedure is a good
idea, and I would prefer to see its use minimized.  That said,
I understand I am on the wrong side of the consensus and so I
will try to offer some constructive comments in-line (assuming
that it is not too late to do so).

> ----------------
> 
> Alternative procedure for updating MIB modules 
> 
> The normal process for updating a MIB module is to create an
> internet draft that contains the new/updated MIB module.
> Such an internet draft, when published as RFC, will then 
> obsolete an earlier RFC. For example, RFC 2863 (IF-MIB module)
> obsoletes RFC 2233.
> 
> But in some cases, there are just very small changes or additions
> to a specific MIB module. It would waste a lot of pages of RFC text
> if one needs to repeat the whole MIB module in order to just make
> a few small changes. 

This was not the reason for doing the RMON updates this way, at
least if I remember the history.  The reason was that we had an
RMON module going for full standard, and some IESG members felt
that it would be confusing to have two published versions of the
module, on at full standard and one at PS.  So the incremental
changes were published separately to make it clear that it was
just the changes that were at PS.  I think the wording above should
reflect this.

> So, as an altenative procedure, one can create a short internet draft
> that describes the few updates/additions to the MIB Module. The
> changes to the MIB module itself can then be provided in a separate
> MIB module. The way to do so is to have a ptr in the internet draft
> in the form of (if your I-D is named draft-ietf-wgname-somename-nn.txt):
> 
>   For convenience, an updated MIB module containing these (changed/new) 
>   objects may be found at:
>   http://www.ietf.org/internet-drafts/draft-ietf-wgname-somename-nn-modulename.mib
> 
>   Note to RFC-Editor:
>        above MIB mdoule to be moved and link in this document to be
>        updated to RFC-Editor location
>               ftp://ftp.rfc-editor.org/in-notes/mibs/current.mibs/ 
>        when RFC-is published.
> 
> An example of a RFC that has followed this method is RFC 3273, page 6.

OK, this just documents the procedure used for the RMON modules.

> This procedure can also be followed if some MIB module (as published in
> an RFC) has already advanced to DS or STD. The new RFC will have to
> start at PS of course. By the time the new RFC comes to the same level
> of standardization (certainly at STD level) it might be better to
> include the full MIB module again. However, the above procedure also
> works and is acceptable.

I would STRONGLY SUGGEST that the integrated MIB module be published
in a document of its own once everything gets to the same level on
that standards track.  Thus, I suggest to delete the last sentence
and modify the previous one to REQUIRE consolidation.

Thanks,

Mike