RE: Mib transition

["David B Harrington" <dbharrington@comcast.net>]

Hi,



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

No. The 802.1 WG does NOT want to do this. That topic recently came up
because an editor of the MSTP-MIB (the 802.1s MIB) thought copying all
the BRIDGE-MIB objects into "his" MIB made sense; We set him straight.

> 
> | [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.
> 
The mib transition document is largely cobbled together from email
discussions we have been having during the transition period (a year
or more). 

I believe Tony's "expectation" is that, over a long period of time, it
may be necessary to migrate, little-by-little, the IETF MIBs into the
IEEE arc because changes to technology ultimately may require enough
changes that little will be left of the original Bridge-MIB design.
But that a LONG-TERM view.

I have this paragraph marked as a [discuss] because I do not believe
there is a consensus among the other people in the discussion that
this will be neceesary. 

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

I disagree that they need to have change control over the IETF MIB
modules. They can write a compliance clause that says to use the newer
object, without having to obsolete the existing objects and existing
compliance clauses. In RFC4188, we defined a compliance clause for
bridgeCompliance1493 and one for bridgeCompliance4188, and both are
current.

I believe most 802.1 work can be handled in a similar manner, and thus
does not require 802.1 to declare portions of the IETF MIB module
standards to be obsolete.

Therefore, they don't need change control over the IETF Bridge
documents.

If a case arises where they believe they do need to change the IETF
standard, then we can discuss potential alternative ways of handling
the problem (as we did when discussing PathCost32), and if we deterine
that it really is necessary, then either we can make the change within
the IETF (where we might hit a manpower issue or process delay) or we
can transfer the rights at that time.
> 
> Mike
> 
> 
>