Re: FWD: Restart ifmib WG?

Juergen Schoenwaelder wrote:

> >>>>> C M Heard writes:
> 
> C> If you add these new objects to the IF-MIB then it will have to
> C> recycle at proposed.  That would prevent any MIB modules that
> C> depend on the IF-MIB in a normative way -- and there are plenty of
> C> those -- from advancing past proposed standard.  It might,
> C> therefore, be better to put these things into a supplemental IF MIB
> C> module.
> 
> While I understand the logic here, I believe that for many people
> outside of the IETF, this approach is just confusing. Most people I
> have seen simply want the latest IF-MIB and not an ever growing set of
> IF-MIBs (due to the way we apply the IETF standards process rules).

[ ... ]

> >>>>> C M Heard writes:
> 
> Mike> Are you suggesting that we should treat MIB modules as BCPs
> Mike> instead of putting them on the standards track?
> 
> No. I think we should allow the publication of RFCs that update MIB
> modules published in other RFCs. An official repository, probably
> maintained by IANA, must be established that holds the latest merged
> versions of the MIB modules. Once updates have progressed and reached
> the same status of the original MIB document, things might be merged
> into a subsequent RFC which describes the whole thing in one piece.
> 
> I think we do exactly this with other protocols. Why should this not
> work with MIBs as well? I think the RMON update to support high
> capacity counters is a good example that there are cases where it is
> not really practicable to put all changes in separate modules.

The point is well-taken, but I think that we'd still need to publish
two IF-MIB documents.  One would be an RFC containing the IF-MIB 
module with the corrections pointed out by Andy but without any
new objects.  It would become the Internet Standard IF-MIB RFC.  The
second document would be an incremental update with the new objects.
It would become a proposed standard RFC.  The on-line version of the
IF-MIB would contain the merged version with the new objects.  Note
that its conformance statements would have to be written to be 100%
backward compatible with the Standard IF-MIB.  In particular, the
ifCompliance3 compliance statements (assuming that it remains as
is in the Standard IF-MIB) would, in the merged MIB module, remain
in place with its STATUS current and with its meaning unchanged.

Mike