Hi Frank,
I participate regularly in my company's mib committee, and in reviewing mibs for Bert. When we have an inexperienced mib writer develop a mib, we frequently have problems because the underlying implementation that is being instrumented by the mib is not designed as a bunch of flat tables. I think every modern programming language supports multiple-level nesting in one form or another.
By having a mib specification language that cannot properly represent the programming language constructs used in the actual implementation, we make it much harder for people to develop mibs. This shows up in the quality of the design of mibs.
I know your attitude is that we should design an SMI that allows for nesting, and then use tools to convert the mib from nested structures into flat tables for 'on-the-wire' usage.
I think that approach misses some important points.
1) it may not be very easy to "unroll" complex structures into flat tables automatically, and then convert the flat tables back into nested structures for agent processing;
2) extra layers of conversion can significantly impact the performance of agents and applications;
3) operators have spoken out strongly against applications that have to do a lot of "conversion" of the data stream to make it understandable, because when they are debugging, they don't want to add yet another potentially-buggy layer of interpretation between them and the raw data; and
4) SMIv3 will presumably have some conceptual richness that cannot be converted back to SMIv2. I expect much of that richness to be in the ability to nest structures.
Many people argued that C++ was nothing more than a superset of C, and they tried to use it just as they would C. Others recognized that the object-oriented nature of C++ was tremendously powerful, and that power was only accessible to those who accepted the paradigm shift between object-oriented and procedural thinking. Backwards compatibility with C should be used primarily as a transition mechanism; C code really needs to be restructured to capture the full power of C++. I think that if we restructure existing mibs, then we're really changing the mib so much it isn't the same thing anymore.
I don't want to lose all those objects that we have already standardized, but I don't want our efforts to be constrained by them. Dave Perkins made an interesting observation about one of the proposals (I think for XML) - the apparent improvement was not the result of the language being used, it was the result of the re-engineering given 20/20 hindsight.
I propose that in the move to SMIv3, we consider restructuring the useful existing mibs to take advantage of the object-oriented conceptual power of SMIv3. Since SMIv2 is purely data driven, and SMI3 is supposed to become somewhat object-oriented, I expect that we might move data elements defined in existing mibs into class-like structures. I propose a field in the data definitions contained in our SMIv3 "class" definitions that provide a reference back to the equivalent SMIv2 object OID. I think there would need to be two types of references - a pointer and a derivation. For example (forgive my notation; I'm only trying to present the concept),
// an SMIv3 structure to manage interfaces
smiv3InterfaceClass {
ifAdminStatus
derived-from { ifEntry 7 }
[or SMIv2-instance { ifEntry 7 } ]
:: = { smiv3InterfaceClass 4 }
}
The derived-from represents a unique instance of the object for each class that is instantiated; the SMIv2-instance is a reference to the same instance that would be used for an SMIv2 request.
Using something like this would allow us to re-engineer the existing mibs and provide a transition mechanism between the paradigms.
dbh
> -----Original Message-----
> From: Frank Strauss [mailto:strauss@ibr.cs.tu-bs.de]
> Sent: Wednesday, September 18, 2002 10:12 AM
> To: Harrington, David
> Cc: 'sming@ops.ietf.org'
> Subject: Re: Nesting levels in existing mibs
>
>
> Hi!
>
> Thank you very much, David, for your response!
>
> David> I believe it is important for existing applications to be able
> David> to continue to work with the existing mibs. As a goal, the
> David> members of the meeting seemed happy with the approach that
> David> existing mibs do not get extended with the new functionality.
>
> I understand and agree to this position.
>
> David> If you add SMIv2-incompatible extensions to existing mibs, then
> David> they may not work properly unless the applications are
> David> modified; if they require modification to understand when n>1
> David> then they are no longer the existing applications.
>
> That's what I don't like about SMI-DS. I support a solution that
> allows to make use of new features like nested data structures without
> the need for an n>1 layering in the naming when data is transported.
> This would, e.g., allow to have an agent developed based on the new
> data structures communicating to a manager built with a traditional
> SMIv2 based toolkit. Generating the SMIv2 MIB from a MIB in the new
> format could be completely automated.
>
> David> Andy's proposal for OID indexing to n>1 levels was also found
> David> to be a reasonable approach by the members of the meeting. I
> David> don't know what you have in mind.
>
> If COPS support would still be one goal, then the current NMRG-based
> proposal is quite close to what I have in mind, and that's why there
> has not been the need to write something new down, so far.
>
> If we really drop COPS support from the charter, then I would migrate
> the OID naming back to the core of SMIng (and I would really like to
> have a single module again for a single target MIB). In this case, the
> process of flatting the n levels of contained structures to
> traditional tables could be based on an implied sequence of
> column-identifying sub-ids starting at 1 in the order given by the
> containment tree's pre-order. Problems occur when new attributes are
> added to contained structs. Then the ordering of columns in the
> containing flattened table must not change. This could probably be
> assured by recognizing the version's LAST-UPDATED clauses of the
> affected MIBs.
>
> David> I don't mind supporting such a thing if it would be not delay
> David> the development of SMIv3, and would be easy to understand for
> David> human mib readers and mib writers.
>
> David> I certainly see that mib-writers working on existing SMIv2 mibs
> David> could easily make a mistake of adding an SMIv3 feature to an
> David> SMIv2 mib and cause problems for existing applications. A
> David> solution as simple as "an SNMPv1 agent doesn't recognize
> David> Counter64 typed objects for an SNMPv1 request" would suit me.
>
> Then, what would the future look like in 5 year, assuming SMI-DS is
> the new successful SMIv3? I would expect that we would have a majority
> of, say, 80% SMIv2 MIBs (maybe they are labeled SMIv3 after a
> revision, but in fact they cannot make use of the SMIv3 features that
> would make them reusable, more readable, easier to understand and
> easier to implement) and 20% SMIv3 MIBs.
>
> David> But before I throw behind my support such a goal, I need to be
> David> convinced it is feasible; can you elaborate on your proposal of
> David> how to achieve it within the scope of Andy's OID nesting?.
>
> David> Can you explain how we can
> David> 1) use Andy's approach to OID nesting
> David> 2) add nesting levels to existing mibs
> David> 3) allow existing applications, without modifications, to
> David> continue to work with existing mibs that have been extended?
>
> First of all, when people design information models and when they
> derive data models thereof they usually don't think in OIDs. They
> think in class names and attribute names. Attributes can be simple
> types or in turn complex types (no matter whether we name them classes
> or structs or whatever at this point). The point where OIDs appear
> should - in my opinion - remain limited to the the protocol. Of course
> this requires that OIDs appear in the mapping from the data model
> to the protocol.
>
> How nesting would look like is described for example in
> draft-ietf-sming-inet-modules, where, e.g., class
> InetTransportEndpoint contains an attribute of class
> InetNetworkEndpoint and an attribute of type InetPortNumber. Mapping
> such classes to SNMP tables is described in draft-ietf-sming-snmp.txt.
>
> I assume, that we all don't really like to have a split of core
> definitions and SNMP mappings, but this is - as far as I can tell -
> the best approach to achieve the charter's goal to support SNMP as
> well as COPS-PR. Since it seems now quite obvious that the WG will
> drop COPS-PR support, I would remove the need for the SNMP mapping
> statements and integrate the necessary naming stuff as `oid'
> sub-statements to the class and classes' attribute statements. I know,
> a more detailed scheme is required here. But I think this is doable.
> I cannot come up with a concrete proposal, but I think it's more
> important to first make sure whether the WG prefers the new SMI-DS
> naming (as it looked like to me during the past months, hence I
> refrained from working on changes in the draft-ietf-sming-*
> documents).
>
>
> -frank
>