Re: hierarchical naming

[Andy Bierman <abierman@cisco.com>]

At 06:52 AM 3/19/2002, Frank Strauss wrote:
>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. 

We are obviously not going to change each other's opinions
of the value of hierarchical naming, so I think we should
just agree to disagree, and let other people in the WG
voice their opinions on this work. 

It's unfortunate that we don't have a coordinated effort between 
EOS and SMING, because the biggest advantage of this naming scheme is
the ability to create protocol technology that can move any type of 
sub-aggregate. I believe these protocol enhancements will exist some day,
but only if the SMING WG lays the groundwork first.

Andy




>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