Re: hierarchical naming

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

Hi!

Andy> [...] First of all, hierarchical OIDs are important to retain
Andy> complex data relationships, such as the N:1 relationship between
Andy> attribute X and attribute Y for some arbitrary complex
Andy> object. This N:1 existence relationship shows up a lot in the
Andy> data we try to model in MIBs.

We start moving in circles: The power of a hierarchical data
model is not bound to any OID naming scheme. 


Andy> The new features of SMI-DS will require new code for developers
Andy> to fully realize their potential, just as new code was needed
Andy> to take advantage of Counter64 when we went from SMIv1 to SMIv2.
Andy> I think SMI-DS to SMIv2 translation is possible, just as a
Andy> Counter64 can be translated to 2 Counter32s in SMIv1. It's
Andy> not transparent, but it is possible.

But it's no win at all.  It needs manual translation and it's
completely incompatible.


Andy> I think advancing the state of the art will require some
Andy> advancement in tools, but the pain is worth the gain.

Not only in tools. The impact is enormous. See the examples we gave
(applications parsing MIBs at runtime (e.g. snmptable), MIB-specific
applications (which are built using SMIv2 MIB compilers), VACM).


Andy> The SMIng approach works reasonably well for unpacking a trivial struct
Andy> within another trivial struct. The SMI data model should support
Andy> more complex existence relationships than struct in struct.

Sure. See our examples given in another recent posting.


Andy> The SMI-DS naming scheme is compatible with SMIv2. Identical
Andy> semantics are named exactly the same way. Even for multiple
Andy> levels of nesting, SMI-DS puts all the columns IDs on the left,
Andy> so the registration points are totally compatible with existing
Andy> SNMP engine technology.

On the one hand, you're saying the new naming scheme is more powerful
and what people want to use. On the other hand, you're saying there is
way to remain compatible to SMIv2 and existing SNMP applications.
Unfortunately, these two viewpoints don't fit together in the current
SMI-DS naming scheme. I prefer to support both aspects in common.


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> I don't see the value of doing manual unfolding of hierarchical
Andy> structures into SMIv2 style rows. This is optimizing for a
Andy> handful of MIB toolkit developers at the expense of the massive
Andy> number of MIB readers and writers.

Well, switching to an non-flat OID naming to eliminate manual flating
by MIB writers at the expense of compatibillty to the massive number
of existing SNMP applications and their users is probably worse.


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> It's useful to maintain the OID structure for sub-aggregates without
Andy> any additional code footprint for OID translation rules.

I don't care a lot about minor additional code footprint. I guessed,
we were just talking about manual decoding/debugging. Anyway, a minor
issue.


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> Actually, VACM works much better in SMI-DS than SMIng. All the
Andy> object identifiers are on the left, consistent with SMIv2.
Andy> All instance components start in the same position, and are
Andy> common across all values. Some sub-aggregates will have additional
Andy> OIDCs to the right, and will be consistent no matter what aggregate
Andy> in which the sub-aggregate is embedded.

No!

 (a) SMI-DS cannot work better than SMIng. Proof: OIDs in SMIng are
     equal to the current SMIv2/SNMP architecture for which VACM is
     designed.

 (b) It's not true, that in SMI-DS all instance components start in
     the same position. E.g., look at your example at page 26 where
     the instance identifier `17' is NOT at the same postion for all
     attributes of the the ipXStats array. You would need a much more
     complicated VACM configuration to control the access on
     ipXStats[17]. But hey, VACM is complicated anyway. ;-)


Andy> [...] I think the protocol mappings should be done entirely with
Andy> rules specified in the SMI document, and not at all in the MIBs.
Andy> Burdening all MIB readers and writers with this task is not an
Andy> improvement to our current situation.

In general terms, I agree. Things like encoding rules don't belong
into any SMI module. A major task of protocol mapping is OID naming,
which both of our approaches do in the SMI module, yours more
implicitly but limited to SNMP, ours more explicitly and separeted
from the core data model allowing support for different protocol
mappings, e.g. COPS-PR as forced by our charter.


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.

Andy> They do cooperate as much as needed in the agent. The instrumentation
Andy> code for the FOO-MIB doesn't know how to interpret the complete
Andy> OIDs for the BAR-MIB. That is true in SMIv2, SMIng, and SMI-DS.

??? I guess, we were talking about SMI compatibility, not obvious MIB
(in)compatibility. You already know the examples of interoperability
problems, e.g. when an agent implements a MIB written in SMI-DS and a
manager like snmptable that's only aware to parse SMIv2 MIBs wants to
access it.


 -frank