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