RE: Alternative procedure for updating MIB modules

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

> > In the IEEE, I think they have a limit to the number of incremental 
> > updates allowed without republishing an integrated 
> revision. [...] I suggest the IETF also have such a limit, [...]
> > 
> 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?
> 
I am suggesting that we learn from a similar organization that uses
incremental updates, and has a technique to help manage synchronization and
integration. 

Is it a theoretical issue? In the IETF it is a theoretical issue because we
have not had an official process for synchronizing incremental updates in
the past. 

When incremental mib updates have been done, the synchronization has been
handled on a case-by-case basis, with some attendant problems.

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

I agree that will be a common case, and that's what concerns me. 

As multiple incremental updates to common mibs and TCs are done by different
working groups, they may assign conflicting enumeration values. WGs have
created conflicting assignments before.

At the same time we introduce incremental mib updates, we are working to
"close down" long-time WGs, and we are encouraging other SDOs (that have few
or no snmp experts) to develop mibs and even to update some existing IETF
mibs. Often what they will want to update are enumerations, and add a few
objects to go along with the new enumerations. We cannot expect that these
other SDOs will be fully aware of all mib work going on in the IETF, nor
that they hold up their development processes to let the IETF O&M Area dole
out new numbers for them (except those that are IANA controlled).

Having updates span two or more files across multiple development groups
increases the potential for conflict. I suggest the span should be limited
(by a forced-synchronization CLR), or lists of IETF-subtree enumerations and
OIDs should be IANA-published (which would probably be best for cross-SDO
coordination).

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