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

[Andy Bierman <abierman@cisco.com>]

At 04:51 PM 8/26/2002 -0700, C. M. Heard wrote:
>[ This note is bcc'd to SNMPv3 and RMONMIB lists as a courtesy, but
>  it is requested that followups be directed to mibs@ops.ietf.org ]
>
>On Sat, 24 Aug 2002, Wijnen, Bert (Bert) wrote, as part of
>his AD-review of: draft-ietf-rmonmib-hc-alarm-mib-01.txt:
>> - I get 2 SMIlint warnings too:
>> 
>>    305: warning: counter object `hcAlarmRisingThresholdAbsValue'
>>         must be `read-only' or `accessible-for-notify'
>>    352: warning: counter object `hcAlarmFallingThresholdAbsValue'
>>         must be `read-only' or `accessible-for-notify'
>> 
>>   Which I guess is explainable and acceptable.
>>   Maybe add a comment to explain it in the MIB close to these objects?
>>   Or maybe even put it in the DESCRIPTION clause, or maybe in the
>>   DESCRIPTION clause of the TC.
>
>I think that this issue deserves at least a little bit of exposure in
>the broader SNMP community.
>
>The objects that give rise to these warnings have a MAX-ACCESS of
>read-create and a SYNTAX of HcAbsoluteValue.  HcAbsoluteValue, in
>turn, is a TEXTUAL-CONVENTION with a SYNTAX of Counter64.  There
>is an ASN.1 comment that indicates that it is intended to be a
>semantic refinement of the CounterBasedGauge64 TC defined in
>RFC 2856, but unfortunately SMIv2 does not allow a TC to refine
>another TC :-(
>
>As those of you who were there may remember, there was considerable
>discussion on the SNMPv3 list from 30 August 1999 to 22 September
>1999 regarding the legitimacy of using Counter64 as a base type
>to define non-counter unsigned64 types.  In the rough consensus that
>emerged, there was agreement that TCs could be used for this purpose,
>but that they would be subject to the limitations documented in
>Section 2.2 of RFC 2856:
>
>2.2.  Limitations of the Textual Convention Approach
>
>   New unsigned data types with textual conventions based on the
>   Counter64 tag, instead of a new (or other existing) ASN.1 tag have
>   some limitations:
>
>   -  The MAX-ACCESS of the TC must be read-only, because the MAX-ACCESS
>      of the underlying Counter64 type is read-only.
>
>   -  No sub-range can be specified on the TC-derived types, because
>      sub-ranges are not allowed on Counter64 objects.
>
>   -  No DEFVAL clause can be specified for the TC-derived types,
>      because DEFVALs are not allowed on Counter64 objects.
>
>   -  The TC-derived types cannot be used in an INDEX clause, because
>      there is no INDEX clause mapping defined for objects of type
>      Counter64.
>
>RFC 2579 does not say anything specific about MAX-ACCESS or DEFVAL
>clauses of objects with SYNTAX clauses defined by TCs, but the rough
>consensus at the time the issue was discussed, embodied in the text
>above, was that any MAX-ACCESS or DEFVAL restrictions that apply to
>the base type are inherited by the new type defined by the TC.
>
>draft-ietf-rmonmib-hc-alarm-mib-01.txt now proposes to lift the first
>of these restrictions, i.e., that objects of the new type will inherit
>the MAX-ACCESS restrictions that are associated with the Counter64
>base type.  This seems to violate the rules of SMIv2.  Perhaps more
>important from a pragmatic standpoint, it is also possible that some
>implementations will always respond with an error if there is a Counter64
>value in a varBind of a SetRequest-PDU, and could not implement a MIB
>module with objects defined this way.
>
>If there were a really compelling reason why the objects in question --
>hcAlarmRisingThresholdAbsValue and hcAlarmFallingThresholdAbsValue --
>needed to have their values written atomically as a single operation
>on a single varBind, then it would perhaps be fair to go ahead with
>what draft-ietf-rmonmib-hc-alarm-mib-01.txt proposes to do.  However,
>the fact is that these columnar objects are set once when a row is
>created, and so there is no particular reason why they could not have
>the lower and upper 32 bits set via Unsigned32 types.  These values
>(along with the sign) would be combined and take effect when the row
>is activated.
>
>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.

I think we should let the HC-ALARM-MIB be published as it is,
because the rising and falling thresholds in question should
be modelled as 64-bit numbers, not a pair of 32-bit numbers.

We should not correct mistakes in the SMI with bad data modelling
practices.  It is somewhat absurd that we still do not have
64-bit numbers in the SMI, but that is the case.  Since we aren't
going to get them anytime soon, we have to continue using Counter64
as the base type for all types of 64 bit numbers.  

There is nothing in the SNMP protocol or the BER encoding of Counter64 
that depends on this read-only requirement.  This is just 
part of the initial mistake of defining a Counter64 without also 
defining an Unsigned64 and Integer64 data types.  This is just
another crappy little rule to enforce without reason. Tools written to
use the HC-ALARM-MIB are not going to break because there are 2 
read-create objects that have a base type of Counter64.  Generic 
tools such as MIB browsers do not create table rows.  

We need to differentiate between SMI rules that are needed for 
interoperability vs. SMI rules that just restrict usage because 
"we've always done it that way". We need to differentiate between 
the smilint tool (which should be as strict as possible identifying 
SMI issues) and an NMS application which is designed to provide alarm
threshold management for Counter64-based objects.


>Mike

Andy