|
RFC4181 may be helpfull states:
4.6.1.3. CounterBasedGauge64 SMIv2 unfortunately does not provide 64-bit integer base types. In order to make up for this omission, the CounterBasedGauge64 textual convention is defined in HCNUM-TC [RFC2856]. This TC uses Counter64 as a base type, but discards the special counter semantics, which is allowed under the generally accepted interpretation of RFC 2579 Section 3.3. It does inherit all the syntactic restrictions of that type, which means that it MUST NOT be subtyped and that objects defined with it MUST NOT appear in an INDEX clause, MUST NOT have a DEFVAL clause, and MUST have a MAX-ACCESS of read-only or accessible-for-notify. This TC SHOULD be used for object definitions that require a 64-bit unsigned data type with gauge semantics. If a 64-bit unsigned data type with different semantics is needed, then a different TC based on Counter64 MUST be used, since one TC cannot refine another (cf. RFC 2579 Section 3.5). But since this type of solution does not allow for read-write,
I wonder how we can help
IEEE 802.1 with the below question:
The syntax checking tools bleat if I try to define an Unsigned64 TC or even
a FqtssUnsigned64 - viz: FqtssUnsigned64 ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An unsigned integer in the range 0..18446744073709551615." 111 SYNTAX INTEGER (0..18446744073709551615) (5) warning: use Integer32 instead of INTEGER in SMIv2 (2) range limits must be `lower-bound .. upper-bound' Any ideas? Regards, Tony |