hierarchical naming

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

Andy> I think it is better to have automatic reuse of the hierarchical
Andy> naming (for ease-of-use and reusable code generation) than to
Andy> manually flatten out every layer into a SMIv2 table. This goes
Andy> against the very purpose of data abstraction.

Here is my view on this:

(a) The SNMP protocol operations defined in RFC 1905 operate on a
    lexicographic ordered list of variables and thus they do not care
    whether the conceptual model behind them is a table, nested object
    structures or something else.

(b) All existing SNMP applications and tools (except primitive
    snmpwalk tools) are based on the notion of conceptual tables and a
    "flat" OID space. They won't work with SMI-DS nested naming. To
    make them work, you have to "unfold tables" (as you say in section
    8.3 in your ID).

(c) Since SMI-DS assumes RFC 1905 protocol operations, you can't
    get/set "complex" objects. You still ship lists of varbinds of the
    leaf attributes - the same list of attributes you would be
    shipping with SMIng or SMIv2. Only the OIDs differ (usually making
    the messages a bit longer, but that is not relevant here).

(d) So the question boils down to: What do you gain by having
    hierarchical names in the OIDs (under the assumption of RFC 1905
    protocol operations)? I did not yet find a good convincing answer
    to this question. Note that a code generator which understands
    SMIng does know the data organization of the nested structures
    before they were flattened out and thus it can generate code to
    reconstruct the nested data structure from the varbind list
    without requiring the nesting information to be present in the
    OID. I did not find a way to do the same thing dynamically at
    run-time since you generally do not know where the OID nesting
    ends and the instance identifier starts.

(e) The SMI-DS ID says in section 5.5 that hierarchical naming can
    help to reduce implementation complexity for agent and application
    developers for SNMP Set operations. The only benefit I can see is
    that you can reduce a few RowStatus objects by the expense of
    having larger set operations. I do not see how the hierarchical
    naming scheme affects the complexity of having to support
    arbitrariluy ordered and arbitrary complex set operations and the
    issues with createAndWait and notInService states.

With my current understanding (which might miss important pieces - if
so, please correct me), weighting (b) against (d) and (e), I think
that the current SMIng approach provides a much better transition path
since we can continue to use all existing tools but we can improve
them to be much smarter in efficiently handling complex (reused) data
structures.

Sure, if you break (a) by defining new protocol operations which do
not anymore operate on a list of lexicographic variables but on
structured objects, things will be much different. But we do not have
such a protocol nor do we have proposals underway in EOS nor does the
charter tell me that we should work under the assumption that we have
such a protocol.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>