Re: Should a TC be allowed to remove the MAX-ACCESS restrictions of its base type?

[Randy Presuhn <rpresuhn@dorothy.bmc.com>]

Hi -

> Message-Id: <4.3.2.7.2.20020903121332.0b315d20@fedex.cisco.com>
> Date: Tue, 03 Sep 2002 12:32:01 -0700
> To: "C. M. Heard" <heard@pobox.com>
> From: Andy Bierman <abierman@cisco.com>
> Subject: Re: Should a TC be allowed to remove the MAX-ACCESS 
>   restrictions of its base type?
> Cc: mibs@ops.ietf.org
> In-Reply-To: <Pine.LNX.4.10.10209021934400.13880-100000@shell4.bayarea.n
>  et>
> References: <4.3.2.7.2.20020902170459.0b307938@fedex.cisco.com>
...
> it for.  The lamest part is that these CLRs are there to
> benefit the 3 to 6 toolkit developers on the planet, at the expense
> of all the MIB readers, MIB writers, and MIB developers.  

Some of those CLRs (like not permitting TCs to be defined in
terms of other TCs, limiting OID lengths, etc.) actually make
things harder for toolkit developers, too.

> As for the value of tagging data types in detail, so code generators
> can enforce CLRs in a generic manner, this is also broken by design.

Tagging doesn't help the code generation process AT ALL.

> These toolkits should not bother doing some limited number of
> validation checks on the varbind list. It is much better design
> to have the instrumentation code completely validate the varbind
> list.

This depends on how much of the "instrumentation" code is generated
by the toolkit.  In my opinion, everything that is machine-readable
should be fair game for code generation.

>        This is better for robustness and portability across
> toolkits, since the instrumentation developer can't be sure
> which checks will actually be performed across toolkits.

If your developers are approaching the problem this way,
then it's pretty obvious why SNMP is not more widely used
for configuration: they're coding for the toolkits that do
the least automatic code generation.  If this is true, then
the SMIng effort is a waste of time, since much of its value
comes from the ability to automate more code generation.

> Since one cannot assume a check is made, and risk crashing
> the router, these validation checks end up getting done twice,
> which wastes CPU time and memory.  It is especially useless
> to generically check that the data type for a Set PDU varbind
> is not Counter32 or Counter64.  This is mindless enforcement
> of a CLR taken to an extreme.
...

The protocol library shouldn't be doing this, but just as
a read-only object-type's "set" method will refuse to permit
a set request to succeed, the same should apply for Counter
types.  If your tools aren't making these basic checks, your
developers are wasting their time.  Relying on humans to do
automatable tasks invites error.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San Jose, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------