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