RE: Alternative procedure for updating MIB modules

["David B Harrington" <ietfdbh@comcast.net>]

Hi,

I have some concerns about how we keep things in sync with these incremental
updates. We need to be sure incremental updates don't conflict with each
other, or change the original in ways that makes other updates incompatible.

I agree that once documents reach the same status, they should be merged and
republished at the shared status. 

In the IEEE, I think they have a limit to the number of incremental updates
allowed without republishing an integrated revision. I think most companies
have rules about how many incremental backups can be done since the last
full backup. 

I suggest the IETF also have such a limit, and four incremental updates
seems a reasonable limit. A fifth incremental update would require that one
of the previous four be advanced to the status of the original, or dropped
from the standards track.

An alternative would be to require that the second incremental update
incorporate the first incremental update. This could, of course, keep the
increments always at proposed so they never reach the status of the
original, which doesn't strike me as a good thing.

I suggest that separately-published incremental updates be limited to only
APPENDED objects, TCs, compliances, etc. Changes to the original mib (such
as changing the enumerations of existing objects or modifying textual
conventions) would require an integrated republication (and subsequent
obsoletion of the original status).

Dbh
Dave Harrington
dbharrington@comcast.net
 

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> Sent: Monday, May 24, 2004 1:09 PM
> To: 'C. M. Heard'; Mreview (E-mail)
> Subject: RE: Alternative procedure for updating MIB modules 
> 
> 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
>