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

The "SHOULD" in the quoted text means that that is where assignments
should be made
and that you must have a STRONG and WELL JUSTIFIED reason to deviate.
 
And again, if you decide to keep the gBond tree/branch, then you MUST
also add more 
to the IANA considerations and explain how and when IAN can assign new
values under
that branch. Do they require standard track documents?
 
Or can I as an individual define gBondBWijnenMIB or some such?
Or can alcatel-lucent (just as an example) define an enterprise specific
gBondALUMIB module and have it registered under gBond??
 
I guess the latter two are not intended. So IANA must know and
understand that.
And IANA will want/need an expert to help them decide (they are not MIB
experts
nor experts in all sorts of possible gBond technologies.
 
Again, your AD will decide. But you will need good arguments, and a well
written
IANA considerations section that answers all of the above questions (and
possibly
many more similar questions). Just trying to help you understand why
RFC4181 
does NOT RECOMMEND this practice.
 

Bert Wijnen 

 


________________________________

	From: Edward Beili [mailto:[email protected]] 
	Sent: Tuesday, July 31, 2007 2:44 PM
	To: Menachem Dodge
	Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR
**; Wijnen, Bert (Bert); [email protected]; [email protected]
	Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM
MIB modules
	
	
	Menachem,
	 
	Let's look at the relevant paragraph from RFC 4181 again:
	
	- The value assigned to the MODULE-IDENTITY descriptor MUST be
unique
	  and (for IETF standards-track MIB modules) SHOULD reside under
the
	  mgmt subtree [RFC2578].  Most often it will be an
IANA-assigned
	  value directly under mib-2 [RFC2578], although for
media-specific
	  MIB modules that extend the IF-MIB [RFC2863] it is customary
to use
	  an IANA-assigned value under transmission [RFC2578].  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.
	The words "most often" and "customary" can hardly be considered
as recommendations,
	so there's no hard requirement for the location of the
MODULE-IDENTITY OIDs, i.e. it does not
	have to be placed directly under mib-2.
	The NOT RECOMMENDED practice is a non-IANA assignment of
MODULE-IDENTITY
	descriptors under a delegated subtree.
	Therefore I suggest we keep the existing MIB hierarchy, but
instead
	of assigning the 1st 3 module OIDs ourselves, we ask IANA to
assign
	them to be completely compliant to the spirit of RFC 4181, that
is,
	the MODULE-IDENTITY for each of the G.Bond schemes would be
declared
	as:
	gBondAtmMIB MODULE-IDENTITY  ... ::= { gBondMIB XXX }
	gBondEthMIB MODULE-IDENTITY  ... ::= { gBondMIB YYY }
	gBondTdimMIB MODULE-IDENTITY ... ::= { gBondMIB ZZZ }
	with an editor's note asking IANA to allocate the XXX, YYY and
ZZZ numbers.
	Regards,
	-E.
	
	 


________________________________

		From: Menachem Dodge [mailto:[email protected]]

		Sent: Tuesday, July 31, 2007 12:23
		To: Moti Morgenstern; [email protected];
Edward Beili
		Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth
and TDIM MIB modules
		
		
		    That's fine, but Dan has requested a stong argument
if we intend to go down this path, which is NOT RECOMMENDED by RFC 4181.

		 
		"In case the WG intents to require such a policy I
suggest that you prepare a strong argument that shows what problems
would be created by following RFC 4181." (Dan's email 16/7/07).
		 
		    What are the problems that would incur if we follow
RFC 4181?  (Please explain this on the mailing list)
		 
		    Best Regards,
		    Menachem

________________________________

		From: Moti Morgenstern 
		Sent: Tuesday, July 31, 2007 11:58 AM
		To: [email protected]; [email protected]
		Cc: Menachem Dodge
		Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth
and TDIM MIB modules
		
		
		Hi Naren,
		 
		I agree. Putting the technology specific MIBs under the
common MIB is preferred.
		 
		Regards,
		Moti Morgenstern

_______________________________________________
Adslmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/adslmib