From: Menachem Dodge [mailto:Menachem.Dodge <at> ecitele.com]
Sent: Tuesday, July 31, 2007 12:23
To: Moti Morgenstern; narendranath.nair <at> wipro.com; 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: narendranath.nair <at> wipro.com; EdwardB <at> actelis.com
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: narendranath.nair <at> wipro.com [mailto:narendranath.nair <at> wipro.com]
Sent: Monday, July 30, 2007 7:58 PM
To: EdwardB <at> actelis.com; 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:Menachem.Dodge <at> ecitele.com]
Sent: Monday, July 30, 2007 5:58 PM
To: adslmib <at> ietf.org
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 **; adslmib <at> ietf.org
Cc: EdwardB <at> actelis.com; 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:dromasca <at> avaya.com]
Sent: Monday, July 16, 2007 11:59 PM
To: Wijnen, Bert (Bert); NAIR,NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Cc: EdwardB <at> actelis.com; 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:bwijnen <at> alcatel-lucent.com]
Sent: Monday, July 16, 2007 11:38 PM
To: NAIR,NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Cc: EdwardB <at> actelis.com; Moti.Morgenstern <at> ecitele.com
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: narendranath.nair <at> wipro.com [mailto:narendranath.nair <at> wipro.com]
Sent: Monday, July 16, 2007 10:22 AM
To: adslmib <at> ietf.org; Wijnen, Bert (Bert)
Cc: Moti.Morgenstern <at> ecitele.com; EdwardB <at> actelis.com
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

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 4:46 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

My understanding of the phrase is that one SHOULD NOT assign the MODULE-IDENTITY value by him/herself but rather ask IANA to do the assignment.

In this particular case IANA would assign both the gBondMIB root value and all the branches under it, so there's no delegation of assignment authority from IANA to the working group (the NOT RECOMMENDED practice).

About overloading IANA with another procedure - all we are asking IANA to do is to assign one new value under mib-2 and then 3 new values under it. Personally I don't see a big difference for IANA if, in theoretical case of a new technology under G.Bond, the new MODULE-IDENTITY value for it would be assigned under mib-2 or under mib-2.gBondMIB, exactly the same way as they are asked to assign new values under mib-2 or mib-2.transmission or mib-2.rmon today.

 

Here's an example of a sub-section in the "IANA considerations" section on how to request a new MODULE-IDENTITY value under gBondMIB, modeled after section 3 of RFC 3737:

 

How to request a new assignment for a MIB module When anyone is writing a internet-draft for which a new assignment is needed/wanted under the gBondMIB OID, then the proper way to do so is as follows: EXAMPLE-MIB DEFINITIONS ::= BEGIN IMPORTS gBondMIB FROM GBOND-MIB .. other imports .. exampleMIB MODULE-IDENTITY ... other normal MODULE-IDENTITY stuff ... ::= { gBondMIB nnn } -- IANA: please assign nnn -- RFC-Editor: replace nnn with IANA-assigned -- number and remove this note IANA will assign the number as part of the RFC publication process.

 

Regards,

-E.

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 12:04
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] 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: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 17:20
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Ed,

 

By asking IANA to allocate addresses under mib-2.gBondMIB you are practically asking them to allocate and administer a register of OIDs under this root. IANA know how to allocate OIDs under mib-2, somebody needs to define them rules for OIDs under mib-2.gBondMIB, for example they need to know what to do when another request for an OID under this node is received. The practice to allocate under OIDs like mib-2.transmission and mib-2.rmon led to a number of problems in the past and this is why RFC 4181 considers this practice NOT RECOMENDED. You need a strong justification to go against this recommendation, and you did not provide yet any explanation on this respect.

 

Dan

 

 

 

 

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 4:46 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

My understanding of the phrase is that one SHOULD NOT assign the MODULE-IDENTITY value by him/herself but rather ask IANA to do the assignment.

In this particular case IANA would assign both the gBondMIB root value and all the branches under it, so there's no delegation of assignment authority from IANA to the working group (the NOT RECOMMENDED practice).

About overloading IANA with another procedure - all we are asking IANA to do is to assign one new value under mib-2 and then 3 new values under it. Personally I don't see a big difference for IANA if, in theoretical case of a new technology under G.Bond, the new MODULE-IDENTITY value for it would be assigned under mib-2 or under mib-2.gBondMIB, exactly the same way as they are asked to assign new values under mib-2 or mib-2.transmission or mib-2.rmon today.

 

Here's an example of a sub-section in the "IANA considerations" section on how to request a new MODULE-IDENTITY value under gBondMIB, modeled after section 3 of RFC 3737:

 

How to request a new assignment for a MIB module When anyone is writing a internet-draft for which a new assignment is needed/wanted under the gBondMIB OID, then the proper way to do so is as follows: EXAMPLE-MIB DEFINITIONS ::= BEGIN IMPORTS gBondMIB FROM GBOND-MIB .. other imports .. exampleMIB MODULE-IDENTITY ... other normal MODULE-IDENTITY stuff ... ::= { gBondMIB nnn } -- IANA: please assign nnn -- RFC-Editor: replace nnn with IANA-assigned -- number and remove this note IANA will assign the number as part of the RFC publication process.

 

Regards,

-E.

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 12:04
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] 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:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 5:54 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

The reasons were listed in Naren's original letter:

 

A G.Bond system implementing one (or more) of the G.Bond technologies would need to provide a common gBondMIB together with a technology specific gBondXXXMIB module(s), where XXX is Atm, Eth or Tdim. Putting the technology specific MIB OIDs under the gBondMIB OID emphasizes this hierarchical relationship between the common and specific module(s), providing a visual clue (in graphical MIB browsers) to the fact that gBondAtmMIB, gBondEthMIB and gBondTdimMIB modules are related alternative technologies under the common umbrella of gBondMIB.

 

Putting the technology specific MIB modules at the same hierarchical level as the common module (under mib-2) may confuse the users, hiding the relationship between the modules and the need to use both common and specific MIB module in conjunction.

 

This problem would intensify if a new gBond technology would be created in the future, in which case its OID value would be located far away from the original gBondXXXMIB values (IANA would surely allocate tons of OIDs under mib-2 by that time).

 

Regards,

-E.

 

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 17:20
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Ed,

 

By asking IANA to allocate addresses under mib-2.gBondMIB you are practically asking them to allocate and administer a register of OIDs under this root. IANA know how to allocate OIDs under mib-2, somebody needs to define them rules for OIDs under mib-2.gBondMIB, for example they need to know what to do when another request for an OID under this node is received. The practice to allocate under OIDs like mib-2.transmission and mib-2.rmon led to a number of problems in the past and this is why RFC 4181 considers this practice NOT RECOMENDED. You need a strong justification to go against this recommendation, and you did not provide yet any explanation on this respect.

 

Dan

 

 

 

 

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 4:46 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

My understanding of the phrase is that one SHOULD NOT assign the MODULE-IDENTITY value by him/herself but rather ask IANA to do the assignment.

In this particular case IANA would assign both the gBondMIB root value and all the branches under it, so there's no delegation of assignment authority from IANA to the working group (the NOT RECOMMENDED practice).

About overloading IANA with another procedure - all we are asking IANA to do is to assign one new value under mib-2 and then 3 new values under it. Personally I don't see a big difference for IANA if, in theoretical case of a new technology under G.Bond, the new MODULE-IDENTITY value for it would be assigned under mib-2 or under mib-2.gBondMIB, exactly the same way as they are asked to assign new values under mib-2 or mib-2.transmission or mib-2.rmon today.

 

Here's an example of a sub-section in the "IANA considerations" section on how to request a new MODULE-IDENTITY value under gBondMIB, modeled after section 3 of RFC 3737:

 

How to request a new assignment for a MIB module When anyone is writing a internet-draft for which a new assignment is needed/wanted under the gBondMIB OID, then the proper way to do so is as follows: EXAMPLE-MIB DEFINITIONS ::= BEGIN IMPORTS gBondMIB FROM GBOND-MIB .. other imports .. exampleMIB MODULE-IDENTITY ... other normal MODULE-IDENTITY stuff ... ::= { gBondMIB nnn } -- IANA: please assign nnn -- RFC-Editor: replace nnn with IANA-assigned -- number and remove this note IANA will assign the number as part of the RFC publication process.

 

Regards,

-E.

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 12:04
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] 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: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 18:20
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Ed,

 

But an OID is just a number that goes on the wire. If there are any real functional dependencies like one module should run with another, those must be reflected by the MODULE-COMPLIANCE clauses. Otherwise you can describe the relationship in the text of the RFCs and reflect them in the naming conventions which are human readable. It gives you nothing to create a hierarchy of numbers that is understood only by machines.

 

I would kindly require the Working Group to consider again following a root OID allocation procedure that is consistent with the one that was followed for all standard MIB modules that were approved after the publication of RFC 4181 (and by the majority of the MIB modules before).

 

Dan

 

 

 

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 5:54 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

The reasons were listed in Naren's original letter:

 

A G.Bond system implementing one (or more) of the G.Bond technologies would need to provide a common gBondMIB together with a technology specific gBondXXXMIB module(s), where XXX is Atm, Eth or Tdim. Putting the technology specific MIB OIDs under the gBondMIB OID emphasizes this hierarchical relationship between the common and specific module(s), providing a visual clue (in graphical MIB browsers) to the fact that gBondAtmMIB, gBondEthMIB and gBondTdimMIB modules are related alternative technologies under the common umbrella of gBondMIB.

 

Putting the technology specific MIB modules at the same hierarchical level as the common module (under mib-2) may confuse the users, hiding the relationship between the modules and the need to use both common and specific MIB module in conjunction.

 

This problem would intensify if a new gBond technology would be created in the future, in which case its OID value would be located far away from the original gBondXXXMIB values (IANA would surely allocate tons of OIDs under mib-2 by that time).

 

Regards,

-E.

 

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 17:20
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Ed,

 

By asking IANA to allocate addresses under mib-2.gBondMIB you are practically asking them to allocate and administer a register of OIDs under this root. IANA know how to allocate OIDs under mib-2, somebody needs to define them rules for OIDs under mib-2.gBondMIB, for example they need to know what to do when another request for an OID under this node is received. The practice to allocate under OIDs like mib-2.transmission and mib-2.rmon led to a number of problems in the past and this is why RFC 4181 considers this practice NOT RECOMENDED. You need a strong justification to go against this recommendation, and you did not provide yet any explanation on this respect.

 

Dan

 

 

 

 

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 4:46 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

My understanding of the phrase is that one SHOULD NOT assign the MODULE-IDENTITY value by him/herself but rather ask IANA to do the assignment.

In this particular case IANA would assign both the gBondMIB root value and all the branches under it, so there's no delegation of assignment authority from IANA to the working group (the NOT RECOMMENDED practice).

About overloading IANA with another procedure - all we are asking IANA to do is to assign one new value under mib-2 and then 3 new values under it. Personally I don't see a big difference for IANA if, in theoretical case of a new technology under G.Bond, the new MODULE-IDENTITY value for it would be assigned under mib-2 or under mib-2.gBondMIB, exactly the same way as they are asked to assign new values under mib-2 or mib-2.transmission or mib-2.rmon today.

 

Here's an example of a sub-section in the "IANA considerations" section on how to request a new MODULE-IDENTITY value under gBondMIB, modeled after section 3 of RFC 3737:

 

How to request a new assignment for a MIB module When anyone is writing a internet-draft for which a new assignment is needed/wanted under the gBondMIB OID, then the proper way to do so is as follows: EXAMPLE-MIB DEFINITIONS ::= BEGIN IMPORTS gBondMIB FROM GBOND-MIB .. other imports .. exampleMIB MODULE-IDENTITY ... other normal MODULE-IDENTITY stuff ... ::= { gBondMIB nnn } -- IANA: please assign nnn -- RFC-Editor: replace nnn with IANA-assigned -- number and remove this note IANA will assign the number as part of the RFC publication process.

 

Regards,

-E.

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 12:04
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] 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

 

 

 

 

Smart guys give up, they say

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 7:51 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

I give up.

-E.

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 18:20
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Ed,

 

But an OID is just a number that goes on the wire. If there are any real functional dependencies like one module should run with another, those must be reflected by the MODULE-COMPLIANCE clauses. Otherwise you can describe the relationship in the text of the RFCs and reflect them in the naming conventions which are human readable. It gives you nothing to create a hierarchy of numbers that is understood only by machines.

 

I would kindly require the Working Group to consider again following a root OID allocation procedure that is consistent with the one that was followed for all standard MIB modules that were approved after the publication of RFC 4181 (and by the majority of the MIB modules before).

 

Dan

 

 

 

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 5:54 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

The reasons were listed in Naren's original letter:

 

A G.Bond system implementing one (or more) of the G.Bond technologies would need to provide a common gBondMIB together with a technology specific gBondXXXMIB module(s), where XXX is Atm, Eth or Tdim. Putting the technology specific MIB OIDs under the gBondMIB OID emphasizes this hierarchical relationship between the common and specific module(s), providing a visual clue (in graphical MIB browsers) to the fact that gBondAtmMIB, gBondEthMIB and gBondTdimMIB modules are related alternative technologies under the common umbrella of gBondMIB.

 

Putting the technology specific MIB modules at the same hierarchical level as the common module (under mib-2) may confuse the users, hiding the relationship between the modules and the need to use both common and specific MIB module in conjunction.

 

This problem would intensify if a new gBond technology would be created in the future, in which case its OID value would be located far away from the original gBondXXXMIB values (IANA would surely allocate tons of OIDs under mib-2 by that time).

 

Regards,

-E.

 

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 17:20
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Ed,

 

By asking IANA to allocate addresses under mib-2.gBondMIB you are practically asking them to allocate and administer a register of OIDs under this root. IANA know how to allocate OIDs under mib-2, somebody needs to define them rules for OIDs under mib-2.gBondMIB, for example they need to know what to do when another request for an OID under this node is received. The practice to allocate under OIDs like mib-2.transmission and mib-2.rmon led to a number of problems in the past and this is why RFC 4181 considers this practice NOT RECOMENDED. You need a strong justification to go against this recommendation, and you did not provide yet any explanation on this respect.

 

Dan

 

 

 

 

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 4:46 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

My understanding of the phrase is that one SHOULD NOT assign the MODULE-IDENTITY value by him/herself but rather ask IANA to do the assignment.

In this particular case IANA would assign both the gBondMIB root value and all the branches under it, so there's no delegation of assignment authority from IANA to the working group (the NOT RECOMMENDED practice).

About overloading IANA with another procedure - all we are asking IANA to do is to assign one new value under mib-2 and then 3 new values under it. Personally I don't see a big difference for IANA if, in theoretical case of a new technology under G.Bond, the new MODULE-IDENTITY value for it would be assigned under mib-2 or under mib-2.gBondMIB, exactly the same way as they are asked to assign new values under mib-2 or mib-2.transmission or mib-2.rmon today.

 

Here's an example of a sub-section in the "IANA considerations" section on how to request a new MODULE-IDENTITY value under gBondMIB, modeled after section 3 of RFC 3737:

 

How to request a new assignment for a MIB module When anyone is writing a internet-draft for which a new assignment is needed/wanted under the gBondMIB OID, then the proper way to do so is as follows: EXAMPLE-MIB DEFINITIONS ::= BEGIN IMPORTS gBondMIB FROM GBOND-MIB .. other imports .. exampleMIB MODULE-IDENTITY ... other normal MODULE-IDENTITY stuff ... ::= { gBondMIB nnn } -- IANA: please assign nnn -- RFC-Editor: replace nnn with IANA-assigned -- number and remove this note IANA will assign the number as part of the RFC publication process.

 

Regards,

-E.

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 12:04
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] 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: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 20:01
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: adslmib <at> ietf.org; Moti Morgenstern; NAIR,NARENDRANATH (NARENDRANATH)** CTR **
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Smart guys give up, they say

 

If the WG agrees, can you make sure that this is reflected in the edits?

 

Dan

 

 

 

 

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 7:51 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

I give up.

-E.

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 18:20
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Ed,

 

But an OID is just a number that goes on the wire. If there are any real functional dependencies like one module should run with another, those must be reflected by the MODULE-COMPLIANCE clauses. Otherwise you can describe the relationship in the text of the RFCs and reflect them in the naming conventions which are human readable. It gives you nothing to create a hierarchy of numbers that is understood only by machines.

 

I would kindly require the Working Group to consider again following a root OID allocation procedure that is consistent with the one that was followed for all standard MIB modules that were approved after the publication of RFC 4181 (and by the majority of the MIB modules before).

 

Dan

 

 

 

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 5:54 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

The reasons were listed in Naren's original letter:

 

A G.Bond system implementing one (or more) of the G.Bond technologies would need to provide a common gBondMIB together with a technology specific gBondXXXMIB module(s), where XXX is Atm, Eth or Tdim. Putting the technology specific MIB OIDs under the gBondMIB OID emphasizes this hierarchical relationship between the common and specific module(s), providing a visual clue (in graphical MIB browsers) to the fact that gBondAtmMIB, gBondEthMIB and gBondTdimMIB modules are related alternative technologies under the common umbrella of gBondMIB.

 

Putting the technology specific MIB modules at the same hierarchical level as the common module (under mib-2) may confuse the users, hiding the relationship between the modules and the need to use both common and specific MIB module in conjunction.

 

This problem would intensify if a new gBond technology would be created in the future, in which case its OID value would be located far away from the original gBondXXXMIB values (IANA would surely allocate tons of OIDs under mib-2 by that time).

 

Regards,

-E.

 

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 17:20
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Ed,

 

By asking IANA to allocate addresses under mib-2.gBondMIB you are practically asking them to allocate and administer a register of OIDs under this root. IANA know how to allocate OIDs under mib-2, somebody needs to define them rules for OIDs under mib-2.gBondMIB, for example they need to know what to do when another request for an OID under this node is received. The practice to allocate under OIDs like mib-2.transmission and mib-2.rmon led to a number of problems in the past and this is why RFC 4181 considers this practice NOT RECOMENDED. You need a strong justification to go against this recommendation, and you did not provide yet any explanation on this respect.

 

Dan

 

 

 

 

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Monday, August 06, 2007 4:46 PM
To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] RE: Positioning of gBondATM, Eth and TDIM MIB modules

Dan,

My understanding of the phrase is that one SHOULD NOT assign the MODULE-IDENTITY value by him/herself but rather ask IANA to do the assignment.

In this particular case IANA would assign both the gBondMIB root value and all the branches under it, so there's no delegation of assignment authority from IANA to the working group (the NOT RECOMMENDED practice).

About overloading IANA with another procedure - all we are asking IANA to do is to assign one new value under mib-2 and then 3 new values under it. Personally I don't see a big difference for IANA if, in theoretical case of a new technology under G.Bond, the new MODULE-IDENTITY value for it would be assigned under mib-2 or under mib-2.gBondMIB, exactly the same way as they are asked to assign new values under mib-2 or mib-2.transmission or mib-2.rmon today.

 

Here's an example of a sub-section in the "IANA considerations" section on how to request a new MODULE-IDENTITY value under gBondMIB, modeled after section 3 of RFC 3737:

 

How to request a new assignment for a MIB module When anyone is writing a internet-draft for which a new assignment is needed/wanted under the gBondMIB OID, then the proper way to do so is as follows: EXAMPLE-MIB DEFINITIONS ::= BEGIN IMPORTS gBondMIB FROM GBOND-MIB .. other imports .. exampleMIB MODULE-IDENTITY ... other normal MODULE-IDENTITY stuff ... ::= { gBondMIB nnn } -- IANA: please assign nnn -- RFC-Editor: replace nnn with IANA-assigned -- number and remove this note IANA will assign the number as part of the RFC publication process.

 

Regards,

-E.

From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 12:04
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] 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: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Monday, August 06, 2007 12:04
To: Edward Beili; Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Subject: RE: [Adslmib] 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:EdwardB <at> actelis.com]
Sent: Thursday, August 02, 2007 4:12 PM
To: Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org; 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:bwijnen <at> alcatel-lucent.com]
Sent: Tuesday, July 31, 2007 16:39
To: Edward Beili; Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org; dromasca <at> avaya.com
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:EdwardB <at> actelis.com]
Sent: Tuesday, July 31, 2007 2:44 PM
To: Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; Wijnen, Bert (Bert); adslmib <at> ietf.org; dromasca <at> avaya.com
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:Menachem.Dodge <at> ecitele.com]
Sent: Tuesday, July 31, 2007 12:23
To: Moti Morgenstern; narendranath.nair <at> wipro.com; 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: narendranath.nair <at> wipro.com; EdwardB <at> actelis.com
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: narendranath.nair <at> wipro.com [mailto:narendranath.nair <at> wipro.com]
Sent: Monday, July 30, 2007 7:58 PM
To: EdwardB <at> actelis.com; 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:Menachem.Dodge <at> ecitele.com]
Sent: Monday, July 30, 2007 5:58 PM
To: adslmib <at> ietf.org
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 **; adslmib <at> ietf.org
Cc: EdwardB <at> actelis.com; 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:dromasca <at> avaya.com]
Sent: Monday, July 16, 2007 11:59 PM
To: Wijnen, Bert (Bert); NAIR,NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Cc: EdwardB <at> actelis.com; 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:bwijnen <at> alcatel-lucent.com]
Sent: Monday, July 16, 2007 11:38 PM
To: NAIR,NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Cc: EdwardB <at> actelis.com; Moti.Morgenstern <at> ecitele.com
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: narendranath.nair <at> wipro.com [mailto:narendranath.nair <at> wipro.com]
Sent: Monday, July 16, 2007 10:22 AM
To: adslmib <at> ietf.org; Wijnen, Bert (Bert)
Cc: Moti.Morgenstern <at> ecitele.com; EdwardB <at> actelis.com
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

From: Edward Beili [mailto:EdwardB <at> actelis.com]
Sent: Thursday, August 02, 2007 4:12 PM
To: Wijnen, Bert (Bert); Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org; 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:bwijnen <at> alcatel-lucent.com]
Sent: Tuesday, July 31, 2007 16:39
To: Edward Beili; Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org; dromasca <at> avaya.com
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:EdwardB <at> actelis.com]
Sent: Tuesday, July 31, 2007 2:44 PM
To: Menachem Dodge
Cc: Moti Morgenstern; NAIR, NARENDRANATH (NARENDRANATH)** CTR **; Wijnen, Bert (Bert); adslmib <at> ietf.org; dromasca <at> avaya.com
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:Menachem.Dodge <at> ecitele.com]
Sent: Tuesday, July 31, 2007 12:23
To: Moti Morgenstern; narendranath.nair <at> wipro.com; 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: narendranath.nair <at> wipro.com; EdwardB <at> actelis.com
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: narendranath.nair <at> wipro.com [mailto:narendranath.nair <at> wipro.com]
Sent: Monday, July 30, 2007 7:58 PM
To: EdwardB <at> actelis.com; 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:Menachem.Dodge <at> ecitele.com]
Sent: Monday, July 30, 2007 5:58 PM
To: adslmib <at> ietf.org
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 **; adslmib <at> ietf.org
Cc: EdwardB <at> actelis.com; 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:dromasca <at> avaya.com]
Sent: Monday, July 16, 2007 11:59 PM
To: Wijnen, Bert (Bert); NAIR,NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Cc: EdwardB <at> actelis.com; 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:bwijnen <at> alcatel-lucent.com]
Sent: Monday, July 16, 2007 11:38 PM
To: NAIR,NARENDRANATH (NARENDRANATH)** CTR **; adslmib <at> ietf.org
Cc: EdwardB <at> actelis.com; Moti.Morgenstern <at> ecitele.com
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: narendranath.nair <at> wipro.com [mailto:narendranath.nair <at> wipro.com]
Sent: Monday, July 16, 2007 10:22 AM
To: adslmib <at> ietf.org; Wijnen, Bert (Bert)
Cc: Moti.Morgenstern <at> ecitele.com; EdwardB <at> actelis.com
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