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

I'll do that.
-E.


  _____  

	From: Romascanu, Dan (Dan) [mailto:[email protected]] 
	Sent: Monday, August 06, 2007 20:01
	To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
	Cc: [email protected]; Moti Morgenstern; NAIR,NARENDRANATH (NARENDRANATH)** CTR **
	Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules
	
	
	Smart guys give up, they say :-)
	 
	If the WG agrees, can you make sure that this is reflected in the edits?
	 
	Dan
	 
	 
	 
	 


  _____  

		From: Edward Beili [mailto:[email protected]] 
		Sent: Monday, August 06, 2007 7:51 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,
		I give up.
		-E.


  _____  

			From: Romascanu, Dan (Dan) [mailto:[email protected]] 
			Sent: Monday, August 06, 2007 18: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,
			 
			But an OID is just a number that goes on the wire. If there are any real functional dependencies like one module should run with another, those must be reflected by the MODULE-COMPLIANCE clauses. Otherwise you can describe the relationship in the text of the RFCs and reflect them in the naming conventions which are human readable. It gives you nothing to create a hierarchy of numbers that is understood only by machines. 
			 
			I would kindly require the Working Group to consider again following a root OID allocation procedure that is consistent with the one that was followed for all standard MIB modules that were approved after the publication of RFC 4181 (and by the majority of the MIB modules before). 
			 
			Dan
			 
			 
			 


  _____  

				From: Edward Beili [mailto:[email protected]] 
				Sent: Monday, August 06, 2007 5:54 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,
				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