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