RE: Mib transition

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> Sent: Sunday, October 09, 2005 10:22 PM
> To: MReview
> Subject: RE: Mib transition
> 
> 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:

No, I do not believe that this is what the IEEE 802.1 wants and this is
not what I meant to say. 

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

This is indeed the path that makes more sense, and I believe the IEEE
802.1 would get an advice to follow this path. 


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

Hopefully, we will find the way to solve the registration and ownership
issues. Quoting Bert from a different e-mail:

' But I think it is better taht we get such right explicitly transfered
to IEEE 802, or at least get something documented in an RFC or some
formal record (like IESG meeting decisions or some such).'

Regards,

Dan



> 
> Mike
> 
> 
>