Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

From: "Edward Beili" <[email-masked]>
Date: Tue, 31 Jul 2007 15:44:12 +0300

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-masked]] 
	Sent: Tuesday, July 31, 2007 12:23
	To: Moti Morgenstern; [email-masked]; 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-masked]; [email-masked]
	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

  _____  

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Monday, July 30, 2007 7:58 PM
	To: [email-masked]; Moti Morgenstern
	Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

	Moti, Ed,

	What is your opinion? In my view, putting them all under mib-2 might be confusing. I prefer the technology specific MIBs to be grouped under the common MIB. 

	Thanks,

	naren

	--

	Narendranath Nair

	Cell: +91 99 00 12 96 29

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

  _____  

	From: Menachem Dodge [mailto:[email-masked]] 
	Sent: Monday, July 30, 2007 5:58 PM
	To: [email-masked]
	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-masked]
	Cc: [email-masked]; 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-masked]] 
	Sent: Monday, July 16, 2007 11:59 PM
	To: Wijnen, Bert (Bert); NAIR,NARENDRANATH (NARENDRANATH)** CTR **; [email-masked]
	Cc: [email-masked]; 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-masked]] 
		Sent: Monday, July 16, 2007 11:38 PM
		To: NAIR,NARENDRANATH (NARENDRANATH)** CTR **; [email-masked]
		Cc: [email-masked]; [email-masked]
		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-masked] [mailto:[email-masked]] 
			Sent: Monday, July 16, 2007 10:22 AM
			To: [email-masked]; Wijnen, Bert (Bert)
			Cc: [email-masked]; [email-masked]
			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

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-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 31 Jul 2007 15:46:48 +0200

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-masked]] 
	Sent: Tuesday, July 31, 2007 2:44 PM
	To: Menachem Dodge
	Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR
**; Wijnen, Bert (Bert); [email-masked]; [email-masked]
	Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM
MIB modules

	Menachem,

	- 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.

________________________________

		Sent: Tuesday, July 31, 2007 12:23
		To: Moti Morgenstern; [email-masked];
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-masked]; [email-masked]
		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

---

From: "Menachem Dodge" <[email-masked]>
Date: Tue, 31 Jul 2007 20:47:46 +0300

Edward,
 
The SIP MIB RFC 4780 has a TC-MIB, a common MIB and 
then a specific MIB for the User Agent and another specific MIB for the
SIP server.
Each of these MIBs are placed directly and consecutively under MIB-2.
 
    If we receive consecutive assignments for the gBond MIBs would that
be adequate?
What would be the problems that would occur as a result of this?
 
    Best Regards,
    Menachem

From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2007 4:47 PM
To: Edward Beili; Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **;
[email-masked]; [email-masked]
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB
modules

 

Bert Wijnen 

	Menachem,

		 
		 
		    Best Regards,
		    Menachem

		From: Moti Morgenstern 

		Hi Naren,

		Regards,
		Moti Morgenstern