>>> [EMAIL PROTECTED] 09/14/05 4:26 PM >>> > On Wed, 14 Sep 2005 09:01:50 +0100 Dave wrote: > DS> On Tue, 2005-09-13 at 09:15 -0700, Tom Cumming wrote: > DS> > Is it "legal" to define a MIB with holes in the oid numbering > DS> > DS> Yes. > DS> Relatively unusual, but perfectly legal. > > Actually, I don't think that's right. per RFC 2578, Section 10.2: > > Object Definitions > > An object definition may be revised in any of the following ways: > > [...] > > (7) A conceptual row may be augmented by adding new columnar objects at > the end of the row, and making the corresponding update to the > SEQUENCE definition. > > This says you can't go back and fill holes. I'm not sure they they considered > leaving holes, so this was written with the assumption that there wouldn't be > any. At any rate, it appears to rule out new object in the middle (though I > can't think of a good reason why).
Unless you consider pre-made, undefined objects holes. I would consider an object that has been defined as future expansion to not be a hole, but a pre-defined unallocated OBJECT-TYPE (or whatever). Maybe you just need to account for it in the MIB, but not associate any specific value with it. Maybe mark it as NOT-ACCESSIBLE or something until at which time you need to actually define it. Paul ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users