Re: MIB module numbering for TBD MIB roots

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Harrington, David writes:

David> You can view my suggestion as over-engineering; I view it as
David> trying to solve the root problem, which is partly that people
David> must use unassigned OIDs because they can't get OID assignments
David> on a timely basis.

My point is that you do not need an assigned OID to write a MIB or to
validate a MIB. Tools should just work fine at this stage of
development - and agreement on some little conventions might make
tools even smarter about handling this nicely.

You only need an assigned OID when you implement it _and_ you want to
interoperate with other implementations. If you do not want to
interoperate, you can just pick a branch in your enterprise name space
or whatever. If you want to interoperate, you will sooner or later run
into problems anyway because IDs are work in progress and different
versions won't work together. (You will end up assigning different
top-level OIDs for each revision of the MIB.)

I certainly do not want to discourage people to implement MIBs while
the MIB module is designed - this is indeed good practice and very
helpful in my experience. But trying to achieve interoperability at
this point in the process seems in most cases to go too far and has
the potential risk that the work in progress MIB with the experimental
assignement ends up being shipped in products, thus causing
interoperability problems with implementations that use the final
OID assignement.

I think I have expressed my position and I will step out of this
discussion now.

/js