RE: Alternative procedure for updating MIB modules

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Thanks for the review Mike.
Answers/comments inline.

Other MIB Doctors, pls speak up as well.
I need your input (and hopefully consensus) by Thursday
noon my time (Europe).

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: maandag 24 mei 2004 17:33
> To: Mreview (E-mail)
> Subject: Re: Alternative procedure for updating MIB modules 
> 
> 
> 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).
> 
I am sill under the impression indeed that we have (at least rough) 
consensus that the alternative procedure makes sense.
If people agree with Mike, please speak up now.

> > ----------------
> > 
> > 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.
> 
Thanks I stand corrected that there was additional reasoning.
I think the reason I list was also one of them (maybe that made an
impression on me cause I hate to see more pages printed than needed).

But you are right, there was also some of the "confusion about
having two levels of the same mib module on the stds track".
The alternative procedure basically still causes the multiple levels
to be present though.

> > 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.

There is now also a similar example in the ADSLMIB WG

   draft-ietf-adslmib-gshdslbis-00.txt


> > 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.
> 

Other peoples opinions please!

> Thanks,
>
> Mike

Bert