RE: Alternative procedure for updating MIB modules

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

Inline

Thanks,
Bert 

> -----Original Message-----
> From: David B Harrington [mailto:ietfdbh@comcast.net]
> Sent: maandag 24 mei 2004 22:30
> To: 'Wijnen, Bert (Bert)'; 'C. M. Heard'; 'Mreview (E-mail)'
> Subject: RE: Alternative procedure for updating MIB modules 
> 
> 
> 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.
> 
Sure

> I agree that once documents reach the same status, they 
> should be merged and republished at the shared status. 
> 
OK, seems we are in sync

> 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.
> 
I don't think we have seen this problem at all yet. 
So is it just a theoretical issue you want covered, or do you have
exmamples of where we were getting close to 4 incremenral updates?

> 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).
> 
Mmm... in the rmon case we explicitly had added enumerations.
In fact I would expect that that is one of the more common cases where
we might want this, namely a few added enumerations with a few additional
objects to go along with the new enumerations.

Bert
> Dbh
> Dave Harrington
> dbharrington@comcast.net