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

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

Bert Wijnen wrote:

> Juergen stated:
> 
> > 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.
> > 
> I would rather see us do a document that describes all the CLRs that 
> we currently know of and what we want to do to deal with them or
> do away with them (meaning ignore them).


David T. Perkins countered:

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


I'm in complete agreement with this last suggestion:  instead of writing
a BCP or informational RFC stating why we ignore certain parts of STD 58,
let's write a standards-track document that updates it (and also parts of
the SNMP proto-ops document).  In retrospect, we should probably have
started on this as soon as the effort that led to RFCs 2578, 2579, and
2580 was completed.

I believe that the scope of this document should be limited to
the following items:

1.) Define one new SMI data type, Unsigned64.  This would update
several sections of RFC 2578.

2.) Specify that the on-the-wire data type mapping for Unsigned64
uses the same [APPLICATION 6] tag as Counter64.  This would update
Section 2.5 of RFC 1905bis (by which I mean the RFC that
<draft-ietf-snmpv3-update-proto-08.txt> eventually turns into).

3.) Re-affirm the (sensible) rules in RFC 2578 that are there because
of Counter64 semantics (in particular, no DEFVAL and MAX-ACCESS of
read-only or less).  Explicitly ban (in Standards Track MIB modules)
TCs that use Counter64 as a base type but which define types that
have semantics more appropriate for Unsigned64, but explicitly allow
the existing TCs in RFC 2856 and others like them to be brought into
compliance by changing the base type to Unsigned64.  The idea here is
to require that the MIB modules that used Counter64-based gauges and
the like be revised to define the TCs in question to use an Unsigned64
base type without requiring that the objects using those TCs be
deprecated or obsoleted (that would be pointless, since neither the
semantics nor the on-the-wire encoding would actually change). This
would obsolete RFC 2856 and mandate changes to some other RFCs and I-Ds.

4.) We should also document which of the recommendations in RFCs
2578, 2579, and 2580 really are CLRs (e.g., the recommendations to
start enums at 1 and to limit identifiers to 32 characters --
I, at least, routinely ignore these things in MIB reviews).
Depending on the list we agree on, this could update parts
of all three SMIv2 RFCs.

5.) Finally, document fixes for the things on the unofficial errata
list at http://www.ibr.cs.tu-bs.de/ietf/smi-errata/ that amount to
clarifications, omissions, or typographical errors.  Depending on
the list we agree on, this could update parts of all three SMIv2 RFCs.

Notice that I've omitted Integer64 from the list because of
the following concern raised by Randy:

> However, if these new base types get tags other than those
> of the existing base types, then we'd have a problem with
> both RFC 1905 and RFC 2741, because the the wire protocols
> would be different.

Integer64 does not fit into any existing on-the-wire encoding
without some extra work, so I propose that it wait for SMIv3.

Comments?

Mike