Is it "legal" to define a MIB with holes in the oid numbering to
allow for features that are unknown today to be added at a later date?
I.e., a table with oids:
.1.3.6.123.1.1
.1.3.6.123.1.2
.1.3.6.123.1.3 <- 4,5,6,7,8,9 skipped.
.1.3.6.123.1.10
.1.3.6.123.1.11
I tried it for kicks, and I got the following in snmpd.log.
unknown column 4 in
unknown column 5 in
unknown column 6 in
I understand that just because I got the above message doesn't mean
it's illegal, but it did make me take notice. I tried to read up on it,
and I couldn't find anywhere that it wasn't ok. Does anyone know? If
it's not ok, what is the proper way to future-proof your MIB?
Thanx, tom.c
CNFIDENTIALITY NTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
SF.Net email is Sponsored by the Better Software Conference & EXP
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Net-snmp-users mailing list
Net-snmp-users (AT) lists (DOT) sourceforge.net
Please see the following page to unsubscribe or change other options:

Tue, 2005-09-13 at 09:15 -0700, Tom Cumming wrote:
Is it "legal" to define a MIB with holes in the oid numbering

Yes.
Relatively unusual, but perfectly legal.

to allow for features that are unknown today to be added
at a later date?

Another way this can arise is when dropping obsolete (and/or
broken) MIB objects. The cardinal rule of MIB design is that
you should never have two definitions with different behaviour
sharing the same ID. If you change the behaviour of a MIB
object, you should change the ID as well. This will typically
leave a gap where the old MIB object used to be.

I tried it for kicks, and I got the following in snmpd.log.

unknown column 4 in
unknown column 5 in
unknown column 6 in

How did you register the RaidControllerTable?
The simplest form of specifying the valid columns in a
'' structure is to give
the first and last columns:

tinfo->min_column = MY_FIRST;
tinfo->max_column = MY_LAST;

But this structure also includes a field

netsnmp_column_info *valid_columns;

This can be used to specify more complex arrangements of
which columns are valid. I haven't actually used this
myself, so I'm not quite sure exactly how it works.
But take a look at the definition of this data structure
(in <net-snmp/agent/table.h>) and have a play.

Dave

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:

Net-snmp-users mailing list
Net-snmp-users (AT) lists (DOT) sourceforge.net
Please see the following page to unsubscribe or change other options:

Dave Shield wrote:

The cardinal rule of MIB design is that you should never have two
definitions with different behaviour sharing the same ID.

We're continually adding new features to our product, and that's in
conflict with the cardinal rule above. The process that I'm considering
is to leave holes in the ID sequence, and new features will use those
holes. Dropped features will also leave holes in the ID's. I can't ever
want to use them again (because I'm sure someone out there will assume
it's the old feature, not a new one).

Does this make sense? Is it the "right" way to do it?

>How did you register the RaidControllerTable?
>The simplest form of specifying the valid columns in a
>'' structure is to give
>the first and last columns:
>
tinfo->min_column = MY_FIRST;
tinfo->max_column = MY_LAST;

Won't work, because some of my missing columns are in the, "middle"
of a sequence. This is because I group like features together (say, a
battery backup feature will be followed by some missing ID's so that
new battery backup features can be added).

>But this structure also includes a field
>
netsnmp_column_info *valid_columns;

I didn't know about this guy. I'll follow up on it.

BTW., I guess it would be legal to put, "filler" ID's in the MIB
definition that aren't accessible. What would be even cooler, would be
to have mib2c (I'm using mfd) to understand the filler ID definition's,
and automatically invalidate those columns.

Thanx!!!!!

tom.c

CNFIDENTIALITY NTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

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:

Net-snmp-users mailing list
Net-snmp-users (AT) lists (DOT) sourceforge.net
Please see the following page to unsubscribe or change other options:

Wed, 2005-09-14 at 16:26 -0400, Robert Story wrote:
Wed, 14 Sep 2005 09:01:50 +0100 Dave wrote:
DSTue, 2005-09-13 at 09:15 -0700, Tom Cumming wrote:
DSIs it "legal" to define a MIB with holes in the oid numbering
DS
DSYes.
DSRelatively unusual, but perfectly legal.

Actually, I don't think that's right.

No - it is perfectly legal to define a MIB with holes in
the column numbering. The text you quote:

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

raises doubts over whether it's possible to subsequently *fill* those
holes, but it doesn't forbid having such holes in the first place.

(Well spotted, by the way - I'd never noticed that
particular implication!)

If I were a pernickety-minded sort of chap, I'd ask what exactly is
meant by "the end of the row" (not clearly defined anywhere AFAICS),
and whether the SEQUENCE definition necessarily has to run in strict
numeric column order. There's nothing about this in RFC 2578, but it
might be buried somewhere in the depths of the ASN.1 specification.

But I'm not, so I won't :-)

The main argument against adding such new "internal" column objects
is the implications for an application that walked the table (serially
rather than in parallel). If it was expecting to move from the end
of CL1 directly to the start of CL3, then suddenly inserting a new
CL2 might well confuse the poor dear.

PaulMaybe you just need to account for it in the MIB, but not
Paulassociate any specific value with it.

Yes - I think that's probably the safest approach (apart from
adding new columns at the end).
If you defined a placeholder column object, then any applications
developed to use that MIB would know to be prepared to receive
values for it (even if only to skip the column altogether).

PaulMaybe mark it as
PaulNT-ACCESSIBLE or something until at which time you
Paulneed to actually define it.

But I don't think that's valid.

The list of acceptable revisions that Robert referred to
doesn't include mention of changing the MAX-ACCESS value.
If an application was developed on the understanding that
CL2 was not-accessible, then changing this visibility
would break the application (just as above).

No - if you want to have internal placeholder objects,
then I think you need to:

a) document that they're not currently implemented
(either in the column object DESCRIPTIN,
or via a suitable AGENT-CAPABILITIES statement
(or both))

and (possibly)

b) document the expected behaviour of that object
(at least in fairly general terms). Refining
that description would be covered by 10.2 (8)
Replacing a null description with the expected
behaviour might be regarded as stretching this a bit!

else just add the new columns to the end of the
table. It doesn't really matter which order the
columns appear in - your management applications can
display the results in whatever form is most appropriate.

Dave

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:

Net-snmp-users mailing list
Net-snmp-users (AT) lists (DOT) sourceforge.net
Please see the following page to unsubscribe or change other options: