RE: MIB module numbering for TBD MIB roots

["C. M. Heard" <heard@pobox.com>]

On Thu, 17 Jan 2002, Andrew Smith wrote:
> How about some lateral thinking here: just make the problem go away by being
> sensible about allocating OIDs *during* the proposed-standardisation process
> instead of at the end of it.

I'm not convinced that's a good idea;  more below.

> 1. Enterprise assignments are of no concern to us here - they are for each
> enterprise to manage and it's not IETF's job to stop implementors shooting
> themselves in the foot with their own gun.

That is completely correct.
 
> 2. As soon as a draft MIB is adopted by an IETF WG as a work item, assign it
> a root under mib-2 at some appropriate level. If a WG-adopted MIB is later
> dropped then either give back the OID to the free pool or else deprecate it
> in IANA's list (these are not really a scarce resource).

[Small side issues: in some cases a MIB module may be assigned a root node
other than { mib-2 x } (e.g., { transmission x }).]
 
> The current situation where you have to wait for IESG approval of the draft
> as an RFC is quite unnecessary: it still does not stop the not-infrequent
> cases where an implementor ships a product prematurely and does not bother
> to check what MIBs crept in; it does not handle versioning (i.e. changes to
> a previously approved MIB) which is an issue that SMIng needs to tackle.

The problem is that the structure of a MIB module can (and often does)
change while it is a work in progress.  If OID assignments were made
prior to publication, then (it seems to me) the probability of that a
vendor would actually ship a draft version of a work in progress would
increase.  As things now stand we make sure that the first version, at
least, of a a MIB module in an Internet Draft won't compile, and it's
quite clear that it's not ready to ship.  Admittedly, this "protection"
typically does not exist for maintenance revisions.

Mike