Subject: [IETFMIBS] mib root ?

From: Hans Sjöstrand <[email-masked]>
Date: Fri, 20 Feb 2009 12:02:47 +0100

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 22 Feb 2009 15:16:15 +0100

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hans Sj?strand
> Sent: Friday, February 20, 2009 1:03 PM
> To: [email-masked]
> Cc: [email-masked]
> 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;
> _______________________________________________
> IETFMIBS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietfmibs
>