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