Re: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt

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

On Fri, 17 Oct 2003, Randy Presuhn wrote:
> I don't see the case for changing them from Gauge32 to INTEGER,
> particularly when the corresponding examples in the MIB review
> guidelines use Gauge32.

I think there is maybe a little bit of confusion here.  The
MIB review guidelines mentions the following TCs in Appendix B:

   PerfCurrentCount            Gauge32
   PerfIntervalCount           Gauge32
   PerfTotalCount              Gauge32

and the main text refers to these TCs while discussing "counters"
which regularly reset themselves to zero.  There are a number of
such things in RFC 3592 (formerly 2558), for example:

                  sonetSectionCurrentESs      PerfCurrentCount
                  sonetSectionCurrentSESs     PerfCurrentCount
                  sonetSectionCurrentSEFSs    PerfCurrentCount
                  sonetSectionCurrentCVs      PerfCurrentCount

                  sonetSectionIntervalESs     PerfIntervalCount
                  sonetSectionIntervalSESs    PerfIntervalCount
                  sonetSectionIntervalSEFSs   PerfIntervalCount
                  sonetSectionIntervalCVs     PerfIntervalCount

(with similar stuff for other layers and directions).

But what Margaret's DISCUSS comment was about wasn't the resetting
counter objects, it was the ancillary objects like these:

            sonetMediumTimeElapsed        Integer32
            sonetMediumValidIntervals     Integer32
            sonetMediumInvalidIntervals   Integer32

and I don't think that the MIB review guidelines could be construed
as saying anything about that (not directly, anyway).

> The "templates" Margaret refers to are just ASN.1 comments describing
> the conventions used within RFC 3593.

Actually, they describe conventions recommended for MIB modules that
use the TCs defined therein.

> I don't see how there would be a compliance requirement between
> an ASN.1 comment in that document and this one.

The concern (as I understand it) is that it's possible (and may be
reasonable) to have in the same table some objects with SYNTAX
values of PerfCurrentCount, PerfIntervalCount, or PerfTotalCount and
to have others with SYNTAX values of HCPerfCurrentCount,
HCPerfIntervalCount, or HCPerfTotalCount, and in that case it would
be best if ancillary objects that accompany the HC* objects defined
using the HCPerfTimeElapsed, HCPerfValidIntervals, and
HCPerfInvalidIntervals TCs follow the recommendations in RFC
3593.  That's what a change from Gauge32 to Integer32 would accomplish.

On the other hand, I do agree that it would be fair to say that even
without the proposed SYNTAX change ancillary objects defined with
these TCs satisfy the spirit of those recommendations in RFC 3593 if
not the letter.  On that basis I suppose that some explanatory text
(without a change from Gauge32 to Integer32) would suffice to
address the concerns.

Mike