Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

From: "Edward Beili" <[email-masked]>
Date: Mon, 6 Aug 2007 17:54:14 +0300

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-masked]] 
	Sent: Monday, August 06, 2007 17:20
	To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
	Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; [email-masked]
	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-masked]] 
		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-masked]
		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-masked]] 
			Sent: Monday, August 06, 2007 12:04
			To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
			Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; [email-masked]
			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-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 6 Aug 2007 17:19:44 +0200

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-masked]] 
	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-masked]
	Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM
MIB modules

	Dan,
	 
	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-masked]] 
		Sent: Monday, August 06, 2007 17:20
		To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
		Cc: Moti Morgenstern; NAIR, NARENDRANATH
(NARENDRANATH)** CTR **; [email-masked]
		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-masked]] 
			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-masked]
			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:

			   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:

			      IMPORTS
			        gBondMIB          FROM GBOND-MIB
			
			        .. other imports ..

			        ... 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-masked]] 
				Sent: Monday, August 06, 2007 12:04
				To: Edward Beili; Wijnen, Bert (Bert);
Menachem Dodge
				Cc: Moti Morgenstern; NAIR, NARENDRANATH
(NARENDRANATH)** CTR **; [email-masked]
				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