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

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

I believe that we should write a small document creating new base
types to be added to SMIv2. This would result in SMIv2.1 (not
SMIv3). Then the leading MIB compilers can be updated, followed
by the others.
 
At 11:15 AM 8/27/2002 +0200, Juergen Schoenwaelder wrote:

>>>>>> C M Heard writes:
>
>[...]
>
>Mike> The stuff we did in RFC 2856 was supposed to be a temporary fix.
>Mike> draft-ietf-rmonmib-hc-alarm-mib-01.txt proposes to extend its
>Mike> questionalble practices.  Perhaps it would be best to avoid
>Mike> that.
>
>Whether the rule that Counters are read-only is a crappy little rule
>(CLR) or not is one thing. [It is however interesting to note that we
>have so far had no problems with this rule except that we now use
>Counter64 as a hack to get 64 bit numbers that are not really counters
>and thus it is not surprising that the Counter rules become
>problematic.]
>
>The other thing is that implementations follow what is written down in
>RFC 2578-2580. If there is general agreement that the read-only
>Counters rule is in general a CLR we can ignore, then someone should
>write a short document to explain why this is a CLR and which updates
>RFC 2578 by saying that this CLR does not apply anymore. This would
>then be a basis for implementors to change their code.
>
>Taking this into account, I think the best way to move forward is
>indeed to just let draft-ietf-rmonmib-hc-alarm-mib-01.txt break the
>rules with an understanding that SMIv3 will fix this with a clean
>solution. Just document why this document breaks the rules and move
>on. It is then the job of the implementors to find out whether their
>toolkits will cause problems or not - but it is also clear that not
>the toolkit vendors are to blame since the WG responsible for the
>document was in fact aware that they do break rules.
>
>/js

Regards,
/david t. perkins