Re: hierarchical naming

[Andy Bierman <abierman@cisco.com>]

At 05:39 AM 3/14/2002, Juergen Schoenwaelder wrote:

>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.

agreed


>(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).

I don't think this is a significant factor.
One could claim many years ago that no existing applications
understand Counter64 (or even Unsigned32) so these data types
cannot be added. Applications have to change to use brand new
features. IMO, the advantages of hierarchical naming outweigh
the disadvantages.


>(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).

The same is true for SMIv2, SMIng, or SMI-DS. Macros for
not-accessible constructs cannot be transported.  The
purpose of the SMI is to express management information
in the most efficient and interoperable manner possible.
I don't see what ProtoOps have to do with the evaluation
of different SMI approaches.


>(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.

I don't think it's reasonable to assume the SNMP engine/toolkit
will efficiently rearrange nested sub-aggregates, to allow for
the same type of reusability that could be achieved if instances
of the same complex data type were named in a consistent (hierarchical)
manner. The engine may not know where the instance OIDCs start,
but the reusable code to validate a specific data type does.


>(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.

I think the ease-of-use factor is important. The current SMIng drafts
require manual and explicit unfolding, flattening, and mapping
of the natural data structure into an SMIv2-style row. I don't
see how SW will efficiently take advantage of the hierarchical
nature of the data structures once this is done. This important
relationship should be self-describing (like XML). I think new
applications that wish to take advantage of new SMI features
will be more hindered than helped by flattening complex data
objects.  Both SMIng and SMI-DS agent code will easily co-exist 
with SMIv2 agent code, because the <oidBase> structure is identical,
and SNMP engines dispatch by a longest <oidBase> match of the 
registered instrumentation handlers.


>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.

I guess it's a judgement call as to which type of new code
is easier to write, and which will have a smaller footprint.
We seem to agree on the value of hierarchical data structures, 
but not how they should be mapped to OIDs. This is significantly 
further along than we were at the last IETF.


>/js

Andy