Re: hierarchical naming

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

Hi!


>> What do you think are the advantages? How does hierarchical naming in
>> the OIDs reduce the costs of implementing agents with current protocol
>> operations?

Andy> 1) Hierarchical naming allows more powerful and comprehensive
Andy>    data structures to exist. If the OIDs are flattened out,
Andy>    then you can't represent embedded ARRAYs. [...]

Please don't mix up the feature of hierarchical data structures, which
Juergen and I do like and support in SMIng as well, with the question
about the naming used to transport data via SNMP. With respect to these
issues, the goal of SMIng is to

 (a) support a `rich' data model that complies to many user aspects much
     better than the SMIv2 data model, and
 (b) support a protocol mapping to SNMP so that applications developed by
     using SMIng MIBs are completely compatible with old SNMP applications.

It's not our intention to care about (b) at the expense of (a).


Maybe, we should take a step backwards and talk about what we mean by
`naming'? My understanding of naming is to give data objects and
instances thereof well defined `names' or `addresses' so that they can
be referred within a specific environment, e.g. by OID in SNMP, or by the
name of a variable or a typed pointer in a program fragment. The
intuitive naming at the level of SMI definitions leads to expressions
like `myCounter.c32pair.c32low' and `ifTable[17].ifIndex', which is
fine with me. The naming in C or Java code generated by a MIB compiler
would probably be quite similar (maybe translating `-' to `_' and
using some prefixes or suffixes). The question is, what the naming on
the level of SNMP (thus, the OID mapping) should look like. I think, it
should be equal to the existing OID naming scheme for compatibility
reasons. And I don't think that this affects the benefits we want to
achieve at the level of SMI definitions of data structures.


Andy> 2) Manual flattening of complex data structures will likely be 
Andy>    labor-intensive and error-prone. A MIB writer will have to
Andy>    recursively iterate through all the levels of the data
Andy>    structure and create sequential OID assignments for them.

Doing this flat OID assignment is very easy. However, mistakes can easily
be detected by a MIB compiler. Compatibilty to existing SNMP applications
is much more important.


Andy> 3) It is difficult to analyze OIDs by inspection, but this has to be
Andy>    done for debugging. A complex data structure which is flattened
Andy>    out somewhat arbitrarily will be difficult to reconstruct by hand.

Looking at the examples in the SMI-DS I-D I had much more problems to
decode OIDs than with the old simple flat OID structure. I must admit
that this is probably due to our habits of the past 10 years, but I
don't think that this would change significantly. Anyway, I think this
is just a minor criterion.


Andy> 4) Agent instrumentation and engine code will be able to dispatch
Andy>    by subtree, allowing for more modularized implementation. Using
Andy>    the ACL example, if the array of ACL rules if aclList.4, then
Andy>    that subroot can be dispatched to a single modular handler that
Andy>    processes the rules, even if the rule is made up of multiple
Andy>    attributes. The handler for the ACL name (e.g. aclList.2)
Andy>    does not need to know anything about the structure or indexing
Andy>    of the ACL rules. This is one of the goals of data abstraction.

But in practice, we do have things like VACM! And, e.g., there are VACM
configurations giving access to a specific user on all objects of an
array (table). This relies on a prefix which contains a fixed-length
column identifier part that can be wildcarded at the VACM setup. With
your naming scheme, VACM could no longer be used this way. 


Andy> The current SMIng drafts require manual and explicit unfolding,
Andy> flattening, and mapping of the natural data structure into an
Andy> SMIv2-style row.
>> 
>> Yes.
>> 
Andy> I don't see how SW will efficiently take advantage of the
Andy> hierarchical nature of the data structures once this is
Andy> done.

Primarily, SMIng MIB compilers read SMIng class and type definitions,
not just the protocol mapping stuff. They are completely aware of the
hierarchical structure and other relationships.

OID flatting is done as part of the SNMP mapping so that the data
shipped via SNMP is compatible with existing SNMP applications.


Andy> [...]  Both SMIng and SMI-DS agent code will easily co-exist
Andy> with SMIv2 agent code, because the <oidBase> structure is
Andy> identical, and SNMP engines dispatch by a longest <oidBase>
Andy> match of the registered instrumentation handlers.

Well, as far as I understand your naming scheme, they would co-exist,
but they would not co-operate. ;-) See the VACM example above.


 -frank