RE: RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,
The reasons were listed in Naren's original letter:
 
A G.Bond system implementing one (or more) of the G.Bond technologies would need to provide a common gBondMIB together with a technology specific gBondXXXMIB module(s), where XXX is Atm, Eth or Tdim. Putting the technology specific MIB OIDs under the gBondMIB OID emphasizes this hierarchical relationship between the common and specific module(s), providing a visual clue (in graphical MIB browsers) to the fact that gBondAtmMIB, gBondEthMIB and gBondTdimMIB modules are related alternative technologies under the common umbrella of gBondMIB.
 
Putting the technology specific MIB modules at the same hierarchical level as the common module (under mib-2) may confuse the users, hiding the relationship between the modules and the need to use both common and specific MIB module in conjunction.
 
This problem would intensify if a new gBond technology would be created in the future, in which case its OID value would be located far away from the original gBondXXXMIB values (IANA would surely allocate tons of OIDs under mib-2 by that time).
 
Regards,
-E.

 

  _____  

	From: Romascanu, Dan (Dan) [mailto:[email protected]] 
	Sent: Monday, August 06, 2007 17:20
	To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
	Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; [email protected]
	Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules
	
	
	Ed,
	 
	By asking IANA to allocate addresses under mib-2.gBondMIB you are practically asking them to allocate and administer a register of OIDs under this root. IANA know how to allocate OIDs under mib-2, somebody needs to define them rules for OIDs under mib-2.gBondMIB, for example they need to know what to do when another request for an OID under this node is received. The practice to allocate under OIDs like mib-2.transmission and mib-2.rmon led to a number of problems in the past and this is why RFC 4181 considers this practice NOT RECOMENDED. You need a strong justification to go against this recommendation, and you did not provide yet any explanation on this respect. 
	 
	Dan
	 
	 
	 
	 


  _____  

		From: Edward Beili [mailto:[email protected]] 
		Sent: Monday, August 06, 2007 4:46 PM
		To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
		Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; [email protected]
		Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules
		
		
		Dan,
		My understanding of the phrase is that one SHOULD NOT assign the MODULE-IDENTITY value by him/herself but rather ask IANA to do the assignment.
		In this particular case IANA would assign both the gBondMIB root value and all the branches under it, so there's no delegation of assignment authority from IANA to the working group (the NOT RECOMMENDED practice).
		About overloading IANA with another procedure - all we are asking IANA to do is to assign one new value under mib-2 and then 3 new values under it. Personally I don't see a big difference for IANA if, in theoretical case of a new technology under G.Bond, the new MODULE-IDENTITY value for it would be assigned under mib-2 or under mib-2.gBondMIB, exactly the same way as they are asked to assign new values under mib-2 or mib-2.transmission or mib-2.rmon today.
		 
		Here's an example of a sub-section in the "IANA considerations" section on how to request a new MODULE-IDENTITY value under gBondMIB, modeled after section 3 of RFC 3737:
		 
		
		How to request a new assignment for a MIB module
		
		   When anyone is writing a internet-draft for which a new assignment is
		   needed/wanted under the gBondMIB OID, then the proper way to do so is as
		   follows:
		
		      EXAMPLE-MIB DEFINITIONS ::= BEGIN
		
		      IMPORTS
		        gBondMIB          FROM GBOND-MIB
		
		        .. other imports ..
		
		      exampleMIB  MODULE-IDENTITY
		
		        ... other normal MODULE-IDENTITY stuff ...
		
		      ::= { gBondMIB nnn }  -- IANA: please assign nnn
		                            -- RFC-Editor: replace nnn with IANA-assigned
		                            --             number and remove this note
		
		   IANA will assign the number as part of the RFC publication process.
		 
		Regards,
		-E.
		
		

  _____  

			From: Romascanu, Dan (Dan) [mailto:[email protected]] 
			Sent: Monday, August 06, 2007 12:04
			To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
			Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; [email protected]
			Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules
			
			
			Ed,
			 
			Strictly speaking you are correct about the SHOULD in RFC 4181 . You are however ignoring the other phrase in the same paragraph that has the same weight as a SHOULD (or SHOULD NOT) and which is: 
			 
			  In the past,
			  some IETF working groups have made their own assignments from
			  subtrees delegated to them by IANA, but that practice has proven
			  problematic and is NOT RECOMMENDED.
			 
			What is the strong justification for going against this recommendation? Without such a strong justification I will oppose having this MIB module follow a practice which is not consistent with RFC 4181 and with the current practice followed by other WGs and is overloading IANA with a new procedure and the management of another sub-branch. 
			 
			Dan

_______________________________________________
Adslmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/adslmib