Re: "Holes" in oid sequence.

On Wed, 2005-09-14 at 16:26 -0400, Robert Story wrote:
> 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.

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 COL1 directly to the start of COL3, then suddenly inserting a new
COL2 might well confuse the poor dear.



Paul> Maybe you just need to account for it in the MIB, but not 
Paul> associate 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).

Paul>                                         Maybe mark it as 
Paul> NOT-ACCESSIBLE or something until at which time you 
Paul> need 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
COL2 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 DESCRIPTION,
        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!


Or 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: http://sourceforge.net/geronimo.php
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users