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

["C. M. Heard" <heard@pobox.com>]

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

Mike