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

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

Hi -

> Date: Mon, 26 Aug 2002 16:51:41 -0700 (PDT)
> From: "C. M. Heard" <heard@pobox.com>
> To: mibs@ops.ietf.org
> Subject: Should a TC be allowed to remove the MAX-ACCESS restrictions of its
>  base type? 
> In-Reply-To: <A451D5E6F15FD211BABC0008C7FAD7BC0EC613C5@nl0006exch003u.nl.lucent.com>
> Message-ID: <Pine.LNX.4.10.10208261441080.4219-100000@shell4.bayarea.net>
...
> The stuff we did in RFC 2856 was supposed to be a temporary fix.
> draft-ietf-rmonmib-hc-alarm-mib-01.txt proposes to extend its
> questionalble practices.  Perhaps it would be best to avoid that.
...

As you noted, RFC 2856 takes pains to ensure that nothing shows
up on the wire that would violate the SMI rules.  What we
have here is more than "extending questionable practices."
It's a good example of how those constraints on setting 64-bit
integers (if we had such a base type) in the SMI were a mistake.

Even though settable counters are generally a bad idea,
I think making them illegal crossed the line into CLR-dom,
and this MIB is just one more example of why this is so.
Having an Integer64 base type might reduce the pressure,
but it doesn't really address the philosophical question of
the extent to which our data modeling language should try to
protect MIB writers from doing silly things.

That said, I know our code generator would refuse to generate
an access method to handle a protocol SET-request of anything
derived from a Counter32 or Counter64 base type.

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