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


________________________________

	From: Edward Beili [mailto:[email protected]] 
	Sent: Thursday, August 02, 2007 4:12 PM
	To: Wijnen, Bert (Bert); Menachem Dodge
	Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR
**; [email protected]; Romascanu, Dan (Dan)
	Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM
MIB modules
	
	
	Bert,
	It is my understanding that the "SHOULD" in the quoted text
directs us to put the MODULE-IDENTITY value under the mgmt subtree, as
opposed to the experimental one.
	It does not specify the exact location under the mgmt, saying
(for example) that it could be under mgmt/mib-2, or
mgmt/mib-2/transmission or anything else under mgmt/ for that matter.
	I don't see any deviation from that recommendation in the
proposed assignments:
	 
	mgmt/mib-2/gBondMIB                          - this value is
assigned by IANA
	mgmt/mib-2/gBondMIB/gBondAtmMIB    - this value is assigned by
IANA
	
	mgmt/mib-2/gBondMIB/gBondEthMIB     - this value is assigned by
IANA
	mgmt/mib-2/gBondMIB/gBondTdimMIB   - this value is assigned by
IANA
	 
	That is - all new MODULE-IDENTITY OIDs are under the mgmt
subtree and assigned by IANA.
	 
	I will explicitly specify in the IANA considerations section how
and when the new MODULE-IDENTITY values under gBondMIB should be
assigned.
	
	Regards,
	-E.

________________________________

		From: Wijnen, Bert (Bert)
[mailto:[email protected]] 
		Sent: Tuesday, July 31, 2007 16:39
		To: Edward Beili; Menachem Dodge
		Cc: Moti Morgenstern; NAIR, NARENDRANATH
(NARENDRANATH)** CTR **; [email protected]; [email protected]
		Subject: RE: [Adslmib] 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
				 

________________________________

				From: [email protected]
[mailto:[email protected]] 
				Sent: Monday, July 30, 2007 7:58 PM
				To: [email protected]; 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 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

				 


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