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

Hi,
 
    Looking at the minutes from IETF-68, this matter was intended to be
raised with the MIB Doctors as a question. So have the editors had
second thoughts.
 
    I would like to see where everyone on the WG stands on this issue.
 
    Best Regards,
    Menachem.    

________________________________

From: Romascanu, Dan (Dan) [mailto:[email protected]] 
Sent: Monday, July 16, 2007 11:59 PM
To: Wijnen, Bert (Bert); NAIR,NARENDRANATH (NARENDRANATH)** CTR **;
[email protected]
Cc: [email protected]; Moti Morgenstern
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB
modules


Yes. Frankly speaking, it is not clear to me why would the WG adopt a
policy of assigning root OIDs that 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
 
 
 
 


________________________________

	From: Wijnen, Bert (Bert) [mailto:[email protected]] 
	Sent: Monday, July 16, 2007 11:38 PM
	To: NAIR,NARENDRANATH (NARENDRANATH)** CTR **; [email protected]
	Cc: [email protected]; [email protected]
	Subject: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB
modules
	
	
	I guess, this is up to Dan (AD) to decide.
	If you want to keep your own tree under a common gbond
tree/branch,
	then I suggest you would need a document aka RFC3737 and then
	Let IAN do the registration.
	 

	Bert Wijnen 

	 


________________________________

		From: [email protected]
[mailto:[email protected]] 
		Sent: Monday, July 16, 2007 10:22 AM
		To: [email protected]; Wijnen, Bert (Bert)
		Cc: [email protected]; [email protected]
		Subject: Positioning of gBondATM, Eth and TDIM MIB
modules
		
		

		Hi,
		
		In IETF-68, Bert had mentioned that gBondATM, Eth and
TDIM should be under mib-2 in addition to the gBond MIB modules. This
was according to the RFC4181 guideline on MODULE-IDENTITY (page number
13):
		
		    "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."
		
		However, in the design of gBond MIBs we chose to have
the ATM, Eth and TDIM specific MIB modules under gBond (common) MIB. The
reason for such a design was the following:
		
		a) gBond common MIB module cannot exist on its own; for
any system to implement bonding MIB, it would need to implement the
common mib as well of the specific technology that it intends to
support.
		
		b) It does not make sense to put managed objects for all
technologies into one MIB module, as a system might need to implement
managed objects for only a subset of the technologies viz. ATM, Eth and
TDIM.
		
		In the particular case of the gBond MIB, the editors'
view is that there exist valid reasons for placing the technology
specific MIB modules under gBond MIB subtree.
		
		Therefore, I would like to request the working group
members to comment on this point, so that the case is carefully
considered.
		
		regards,
		Naren
		
		


The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.

www.wipro.com

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