RE: EFM MIB Internet-Drafts, WG Meetings

The later Ethernet MIB module that went under review got the following structure, as result of the MIB Doctor comments:
 
powerEthernetMIB MODULE-IDENTITY
          ::= { mib-2 XXX }
   -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice

   pethNotifications OBJECT IDENTIFIER ::= { powerEthernetMIB 0 }
   pethObjects       OBJECT IDENTIFIER ::= { powerEthernetMIB 1 }
   pethConformance   OBJECT IDENTIFIER ::= { powerEthernetMIB 2 }
 
Accordingly, I would say that we need to plan for our three MIB modules to be placed under MIB-II, and probably separatily, do that dependencies are reduced to the possible extent. 
 
Rergards,
 
Dan
 


In particular, one big nagging question is how these new MIBs are organized within the existing MIB heirarchy.  For the common stuff, does it get a new mib-2 branch, or do we somehow hang it under the dot3 branch as something under the Ethernet tree?  
 
Hoping some of you MIB experts can lend some guidance.