RE: Mib transition

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

On Sun, 9 Oct 2005, Romascanu, Dan (Dan) wrote:
> I agree with Juergen that requests for changes in the IEEE 802.1
> MIB modules may happen more often in the future that we want to
> believe. However, solution (a) (continue to publish updates to
> the relevant 802 MIB under IETF control) proved to be
> unpractical because there is no longer any consistent
> constituency in the IETF to do this work, while solution (b)
> (the IETF officially transfers the control of the top level OIDs
> used by these MIBs over to the IEEE) is not what the IEEE 802.1
> WG wants. The solution to me seems to be in assisting the IEEE
> 802.1 to create new MIB extensions at the required quality in
> their own OID space, while obsolescing gradually the IETF
> documents as needed without further adding anything new.

Does the 802.1 WG want to _replace_ the IETF bridging-related MIB
modules with essentially identical objects registered under their
own OID tree?  That is the impression I get from Dan's message above
and also from the following paragraph in Dave's I-D
draft-harrington-8021-mib-transition-00.txt:

| [discuss] Tony's expectation would be that in time the 802.1-related
| MIB modules will all migrate to arcs under the 802 registration tree,
| so he would expect them to be defined in a new related table under
| the IEEE branch.  What makes the most sense in terms of supporting
| the MIB modules from the users point of view?  Seems it would be the
| least intrusive to keep the existing trees in place, and supplement
| them with IEEE objects in IEEE arcs.

If this impression is accurate, we ought to do whatever we can to
discourage them from doing taking this course.  While we can't stop
them if they are determined, we can at least explain that it will
result in a complete lack of interoperability between
implementations of the IETF MIB modules and their replacements.  I
hope that it is obvious to everyone why that is not a good thing
(otherwise this whole discussion is a waste of time).

If what they want to do is to retain the IETF objects that make
sense, register all new objects under their own OID trees, and to
have the authority to obsolete superseded IETF objects and make new
conformance groups, then I have no argument with them.  But in order
to do this they would still have to get change control over the top
level OIDs used by the IETF bridging-related MIB modules.

Mike