Re: [IETFMIBS] mib root ?

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Sun, 22 February 2009 14:16 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: ietfmibs@core3.amsl.com
Delivered-To: ietfmibs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65963A6AC3; Sun, 22 Feb 2009 06:16:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.018
X-Spam-Level:
X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQckgJfeXo7Y; Sun, 22 Feb 2009 06:16:21 -0800 (PST)
Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 88BE43A6AB4; Sun, 22 Feb 2009 06:16:21 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,249,1233550800"; d="scan'208";a="153107265"
Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 22 Feb 2009 09:16:37 -0500
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Feb 2009 09:16:37 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 22 Feb 2009 15:16:15 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401418E53@307622ANEX5.global.avaya.com>
In-Reply-To: <FDE730FF0FC8FF418E96A281037F0D279BA315@tmnt04.transmode.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IETFMIBS] mib root ?
Thread-Index: AcmTSsN5w1e+QuqfQ66TrSbvoWg8ywBrB1Mg
References: <FDE730FF0FC8FF418E96A281037F0D279BA315@tmnt04.transmode.se>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Hans Sjöstrand <hans.sjostrand@transmode.com>, ietfmibs@ietf.org
Cc: mip4@ietf.org
Subject: Re: [IETFMIBS] mib root ?
X-BeenThere: ietfmibs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF MIB Discussion list <ietfmibs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietfmibs>
List-Post: <mailto:ietfmibs@ietf.org>
List-Help: <mailto:ietfmibs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Feb 2009 14:16:23 -0000

Hi Hasse,

As you are undertaking the task of writing a new MIB module we strongly recommend that you read carefully RFC 4181 and try to implement as much of its recommendations. 

In section 4.5 of RFC 4181 you will find the following text: 

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

So the recommendation in RFC 4181 is for direct allocation under mib-2 (this is not a media specific module). Some of the reasons for this recommendation are simplifying the IANA task, creating a standard layout for management applications to work with and not delegating such allocations for future work in the Working Groups which could lead to different kinds of mistakes or inconsistencies. 

My recommendation is to follow this unless you plan to revise the whole mipMIB. 

Other recommendations in RFC 4181 are also worth following. 

I hope this helps. 

Regards,

Dan


> -----Original Message-----
> From: ietfmibs-bounces@ietf.org 
> [mailto:ietfmibs-bounces@ietf.org] On Behalf Of Hans Sj?strand
> Sent: Friday, February 20, 2009 1:03 PM
> To: ietfmibs@ietf.org
> Cc: mip4@ietf.org
> Subject: [IETFMIBS] mib root ?
> 
> Hi,
> 
> In the mip4 group we are adding mib support for the RFC3519 
> "Mobile IP Traversal of Network Address Translation (NAT) 
> Devices" to the mip mib. We decided not to extend the 
> RFC2006bis with it, but instead write a extension mib, 
> http://tools.ietf.org/html/draft-ietf-mip4-udptunnel-mib-01
> 
> The question is where this mib is best rooted. The intention 
> was to root it under the assigned mipMIB OID { mib-2 44 } and 
> then hand over the administration of that OID to IANA. 
> Somewhat like it was done in MPLS , 
> ...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166) in 
> http://www.iana.org/assignments/smi-numbers
> 
> But this seams not to be the most common way to take, more 
> common is to root also extensions of existing wg mibs 
> directly under mib-2. 
> 
> The questions are;
> - What are the advantages and disadvantages with the two approaches ? 
> - Which is your recommendation (Or is there even a preferred 
> third variant) ? 
> 
> Best regards
> /// Hasse
> 
> _______________________________________________
> IETFMIBS mailing list
> IETFMIBS@ietf.org
> https://www.ietf.org/mailman/listinfo/ietfmibs
>