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

Hi Menachem, 

 

Ed, Moti and I are discussing this point. We will respond with our view
shortly.

 

Regards,

Naren

--

Narendranath Nair

Cell: +91 99 00 12 96 29

Track me at:http://beta.plazes.com/user/nnair/

________________________________

From: Menachem Dodge [mailto:[email protected]] 
Sent: Monday, July 30, 2007 5:58 PM
To: [email protected]
Subject: FW: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB
modules

 

Hello,

 

    I haven't seen any response on this issue. 

 

    Naren do you still wish to put the specific MIB modules under the
common MIB?

 

As Bert pointed out, if we do this there will be a need to write an
additional RFC explaining the OID

assignments (as was done by RMONMIB WG RFC 3737). In addition, one or
two people will always need to be available to advise the IANA should
new OID assignments be required in the future. If MIB modules are placed
under MIB-II then 

the IANA provides this service.

 

    Thoughts?

 

    Best Regards,

    Menachem

 

________________________________

From: Menachem Dodge 
Sent: Tuesday, July 17, 2007 9:45 AM
To: 'Romascanu, Dan (Dan)'; 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

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