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.20020903151228.0b2f2aa8@fedex.cisco.com>
> Date: Tue, 03 Sep 2002 15:30:13 -0700
> To: Randy Presuhn <rpresuhn@dorothy.bmc.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
...
> >Tagging doesn't help the code generation process AT ALL.
> 
> Then why create different data type tags for Unsigned32 and
> Counter32?  (Unless this was a misguided mistake in the SMI!)

My point exactly.

...
> I think it's a bad idea for instrumentation developers to
> tightly couple their code to a particular version of a 
> particular toolset.  They would have to know exactly which
> checks are being done automatically.  This would make it
> much harder to ever change the toolkit.

Unlike the situation with, say, C compilers, there is nothing
even approaching a standard for what toolkits should do.
The very structure of the APIs is so different that trying to
do things "portably" ends up being counter-productive.  I know
of at least one company that tried to do things this way, and
they ended up regretting the decision.  It forces developers
to write all the code that could have been automatically
generated, and begs the question of why they bothered using
a toolkit at all.  Indeed, if humans are writing all these
checks, why bother with a machine-readable DEFVAL or subtype
notation?  Indeed, why should machine-readability be a SMIng
requirement?

> 
> >> 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.
> 
> The auto-generated validation code is usually such a small
> subset of the total instrumentation code, that it's not
> wasting that much time to replicate the checks.  

You raised the point, not I.

>                                                  Why is testing
> for a set on a counter important?  

Why is testing for protocol violations important?  If the protocol
says that a particular error code must be returned when someone
tries to set an object which is not settable, and if the SMI
specifies that all objects of a particular type are by definition
not settable, the requirement for a conformant implementation
is pretty clear.

>                                    How are the bits transferred
> in a Counter32 varbind different the bits transferred in an
> Unsigned32 varbind?  

Except for the tag, they're not, and we agree that there's little
point (other than history) for the tagging to be different.

>                      How would the instrumentation code break if
> it interpreted a varbind tagged as Counter32 as an Unsigned32?

If it accepts a set request, it's violating the protocol IF the
object type defintion's SYNTAX clause resolves to Counter32.  If
it resolves to something else that just happens to have the same
tag, there's no problem. (Remember, the semantics come from the
object identified, NOT the tag!)

As I've said before, I have no problem with a new typeref
identically tagged that doesn't have the "no sets allowed"
semantic.  Sure, it's a tiny compiler tweak, but since your
folks apparently are hand-coding access methods anyway,
it shouldn't matter to you.

> The data type tagging isn't important in this case, and the
> same instrumentation code could interpret a Counter64 as an
> Unsigned64 without a problem.

True if the compiler can be convinced to treat the object
as settable.  If the compiler uses the typeref graph to
bind semantics, it's easy.  If the compiler uses the resolved
tag (not a good idea, in my opinion) it'd be a pain.

>                                As you and Juergen pointed out,
> the real problem is that the SMI data types are kind of a mess.
> The SMI should never have added Counter64 without also adding Unsigned64.
...

Agreed, and more: The SMI shouldn't have tagged all these
things that are simply INTEGERs.

 ------------------------------------------------------
 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.
 ------------------------------------------------------