RE: MIB module numbering for TBD MIB roots

["Andrew Smith" <ah_smith@pacbell.net>]

Mike,
...
> 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 }).]

[Andrew] Yes, that's what I meant by "under mib-2 at some appropriate
level".

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

[Andrew] That's not our problem (see earlier remark about foot-shooting).
There is a general "versioning" problem that, perhaps, some new version of
SMI might help with. "Work in progress" continues throughout the standards'
process, through PS, DS and S: allocating an OID at the PS stage is, at
best, arbitrary.

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.

[Andrew] Ditto, not our problem.

Admittedly, this "protection"
typically does not exist for maintenance revisions.

[Andrew] It's not a very good protection. This is a general "maintenance of
evolving data structure over time" problem.

Mike

Andrew