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

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Friday, October 17, 2003 3:47 PM
> Subject: Re: FW: Discuss on draft-ietf-adslmib-hc-tc-06.txt
...
> 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).

I don't see the how difference in the cases is relevant.
I *can* understand why Gauge32 would be preferable to Integer32 here.
What are the arguments for using Integer32 instead of Gauge32 for
TCs like these, ignoring for the moment 3593?

> > 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 a recommendation (much less a SHOULD or a RECOMMENDED)
in RFC 3593.   The closest I can find there is  "Use of these TCs assumes the
following", which honestly sounds much stronger, as though these TCs won't
work if a module using them doesn't follow the patterns.   I read it as a limit
on the applicability of the TCs, rather than a requirement on other modules,
but can see that the practical effect could be the same.

Probably the sensible thing to do would be to send it back to the adlsmib WG
to see whether changing the datatype for alignment with RFC 3593 would
be acceptable.  It hardly seems fair to make a change that drastic without
WG involvement.

Randy