Impressions of Bierman proposal

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

I just finished a first pass of the Bierman proposal. If you haven't
read it, then I suggest that you do so. It sets aside a long followed
convention in identifying SNMP management information, and by doing so
makes real progress in reducing the gap between the data structures
used by the software in managed devices and their representation
in MIB modules. By reducing the gap, I believe that more designers
of software in managed devices will choose SNMP-based management
over other approaches, and the quality of the SNMP support will
improve.

I learned in the proposal a new approach for creating a discriminated
union. (All unions are ultimately discriminated!) Interesting...
So, now there are four ways to specify the discriminator, which are:
  1) a value in a separate object (an efficient approach when
       there are many unions that share the same discriminator,
       but has the problems of how to tie the discriminator to the
       each object, and enforcing update/create consistency)
  2) the data type of the value acts as the discriminator (which
       restricts the members of the union, and, thus, the usefulness
       of the union, and typically results in falling back to
       #1 approach)
  3) make the value of member of the union to always be a two member
       sequence, where the first member is the discriminator and
       the second member is the "real" value (this is my favorite
       because it makes the relationship explicit with a downside 
       of being slightly more complex and doesn't allow sharing of 
       the discriminator)
  4) (AndyB's innovation) the discriminator is part of the identification
       of the object (that is, part of the OID value that names the
       object instance) (Anyone want to take a shot at listing the
       pros and cons of this approach)

The proposal addresses an area that I didn't realize was an outstanding
problem, which is essentially, "how does one add columns to a table (when
you don't own the definition of the table) and have the OID value
for each column "close" to the OID value used for columns in the
original table?" This doesn't seem like such a big problem and the
solution a big win, until you realize that it's really a building
block that is used to create templates (defined with the proposal's
TYPEDEF construct) for aggregates of values, which is a BIG innovation.

That's it for now. It will be interesting working through all the
details and making a decision over the next few quarters.

Regards,
/david t. perkins