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

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

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

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>