Re: Nesting levels in existing mibs

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

David> I participate regularly in my company's mib committee, and in
David> reviewing mibs for Bert. When we have an inexperienced mib
David> writer develop a mib, we frequently have problems because the
David> underlying implementation that is being instrumented by the mib
David> is not designed as a bunch of flat tables. I think every modern
David> programming language supports multiple-level nesting in one
David> form or another.

David> By having a mib specification language that cannot properly
David> represent the programming language constructs used in the
David> actual implementation, we make it much harder for people to
David> develop mibs. This shows up in the quality of the design of
David> mibs.

David> I know your attitude is that we should design an SMI that
David> allows for nesting, and then use tools to convert the mib from
David> nested structures into flat tables for 'on-the-wire' usage.


David> I think that approach misses some important points. 

David> 1) it may not be very easy to "unroll" complex structures into
David> flat tables automatically, and then convert the flat tables
David> back into nested structures for agent processing;

I agree, but IMHO this is that kind of conversion, that we agreed that
it happens infrequently by SNMP toolkit and MIB compiler developers.
It is not the intention of the language design to make explicitly this
job easy (though it would not be a disadvantage :-).

David> 2) extra layers of conversion can significantly impact the
David> performance of agents and applications;

I don't think so. At first glance, I would expect this to happen by a
MIB compiler generated switch statement.

David> 3) operators have spoken out strongly against applications that
David> have to do a lot of "conversion" of the data stream to make it
David> understandable, because when they are debugging, they don't
David> want to add yet another potentially-buggy layer of
David> interpretation between them and the raw data; and

Manually decoding a column identifier to the right attribute in a
union in a structure (for example) would not be trivial. I agree.
But I would expact that operator rely on the MIB awareness of tools
like tcpdump or ethereal. At least this is what I do already right
now, when I do such dubugging.

David> 4) SMIv3 will presumably have some conceptual richness that
David> cannot be converted back to SMIv2. I expect much of that
David> richness to be in the ability to nest structures.

Converting even nested structures back to SMIv2 is at least easier if
the mapping to the protocol does not differ from what we have now.


David> Many people argued that C++ was nothing more than a superset of
David> C, and they tried to use it just as they would C. Others
David> recognized that the object-oriented nature of C++ was
David> tremendously powerful, and that power was only accessible to
David> those who accepted the paradigm shift between object-oriented
David> and procedural thinking. Backwards compatibility with C should
David> be used primarily as a transition mechanism; C code really
David> needs to be restructured to capture the full power of C++. I
David> think that if we restructure existing mibs, then we're really
David> changing the mib so much it isn't the same thing anymore.

Hm, yes, probably the win for revised MIBs would be very limited.

David> I don't want to lose all those objects that we have already
David> standardized, but I don't want our efforts to be constrained by
David> them. Dave Perkins made an interesting observation about one of
David> the proposals (I think for XML) - the apparent improvement was
David> not the result of the language being used, it was the result of
David> the re-engineering given 20/20 hindsight.

[Sorry, I'm not sure I understand the meaning of the last phrase.]  I
think, making real steps forward would mean to rethink the whole
management framework in a much much broader scope, like it's currently
being done for the XMLCONF work and in the NMRG and by other non-IETF
organizations. On the other hand, SNMP is quite successful and I would
suggest to do changes only in a range that does not cause too severe
consequences.

To bring this to the C/C++ analogy: There are many very mature
libraries written in C during the past 30 years. Though C++ has some
significant advantages, there are by far less well supported mature
C++ libraries. Whether we regard it as a consequence of this split or
not, there are also much more application developed in C and based on
C libraries than in C++. If people nowadays want to benefit from the
object-oriented paradigm they typically use Java, a system that more
consequently resigned from C compatibility. On the other hand, C still
evolved in rather small steps to ISO C 99, which (at least in my
opinion) is of more interest than C++ today.

David> I propose that in the move to SMIv3, we consider restructuring
David> the useful existing mibs to take advantage of the
David> object-oriented conceptual power of SMIv3. [...]

I agree (without commenting your concrete proposal at this time).

 -frank