Maybe the simplest approach would be to have IANA assign the equivalent of an enterprise ID to each working group, that is expected to produce a mib module, when the working group is created. How WGs manage the numbers under their ID is their decision, just as enterprises control how numbers are assigned within an enterprise branch.
dbh
> -----Original Message-----
> From: Andrew Smith [mailto:ah_smith@pacbell.net]
> Sent: Friday, January 18, 2002 12:08 AM
> To: C. M. Heard; mibs@ops.ietf.org
> Subject: RE: MIB module numbering for TBD MIB roots
>
>
> 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
>
>
>