Re: Nesting levels in existing mibs

[Andy Bierman <abierman@cisco.com>]

At 08:53 AM 9/18/2002 -0400, Harrington, David wrote:

>Hi Frank, 
>
>I believe it is important for existing applications to be able to continue to work with the existing mibs. As a goal, the members of the meeting seemed happy with the approach that existing mibs do not get extended with the new functionality. 
>
>If you add SMIv2-incompatible extensions to existing mibs, then they may not work properly unless the applications are modified; if they require modification to understand when n>1 then they are no longer the existing applications.
>
>Andy's proposal for OID indexing to n>1 levels was also found to be a reasonable approach by the members of the meeting. I don't know what you have in mind. 
>
>I don't mind supporting such a thing if it would be not delay the development of SMIv3, and would be easy to understand for human mib readers and mib writers. 
>
>I certainly see that mib-writers working on existing SMIv2 mibs could easily make a mistake of adding an SMIv3 feature to an SMIv2 mib and cause problems for existing applications. A solution as simple as "an SNMPv1 agent doesn't recognize Counter64 typed objects for an SNMPv1 request" would suit me.

It shouldn't be that hard. First of all, SMIv3 would not prohibit
a MIB designer from adding more nesting to the converted version
of an SMIv2 table.  This would be a policy decision to minimize
the impact on existing tools and applications, during a transition
period from SMIv2 to SMIv3.  We used the same sort of policy 
during the transition period from SMIv1 to SMIv2, if you remember.
The simple rule for SMIv3 would be "Only SCALAR data types can
be added to an ARRAY which represents a converted SMIv2 table."

The new SMI features have to be defined before they are deployed
in tools and applications.  We should define features that actually
advance the state of the art. We don't have to use them on Day One.

I don't believe the manual unfolding of nested constructs advances
the state of the art.  It only works for the simplest of examples,
like unfolding a small struct of scalars (InetAddress,Type) within
another struct or a  simple SMIv2 table.  It falls apart quickly
if the nesting gets more complex.  More importantly, it is
impossible to unfold a nested array because the SMIv2 style table
requires that all objects exist at the same nest level. (You can't
have foo.I and bar.I.J in the same table.) 

Andy



>But before I throw behind my support such a goal, I need to be convinced it is feasible; can you elaborate on your proposal of how to achieve it within the scope of Andy's OID nesting?.
>
>  
>Can you explain how we can 
>1) use Andy's approach to OID nesting 
>2) add nesting levels to existing mibs 
>3) allow existing applications, without modifications, to continue to work with existing mibs that have been extended? 
>
>dbh 
>
>> -----Original Message----- 
>> From: Frank Strauss [<mailto:strauss@ibr.cs.tu-bs.de>mailto:strauss@ibr.cs.tu-bs.de] 
>> Sent: Wednesday, September 18, 2002 3:14 AM 
>> To: Andy Bierman 
>> Cc: 'sming@ops.ietf.org'; Durham, David 
>> Subject: Re: SMIng consensus issues restated, call for consensus ends 
>> Septembe r 18, 2002 
>> 
>> 
>> Hi! 
>> 
>> I think we move in circles. The major point in which we have separate 
>> opinions is that 
>> 
>>  - you clearly separate between existing MIBs (that cannot benefit 
>>    from some new SMI-DS features when they are revised) and new MIBs, 
>>    while 
>> 
>>  - I prefer a change from which both cases can benefit, but with the 
>>    disadvantage that the data structures at levels > 1 cannot be 
>>    addressed explicitly. 
>> 
>> Do you agree, Andy? 
>> 
>> I would also really appreciate comments on my reservations from other 
>> WG members. 
>> 
>>  -frank 
>>