Discuss on draft-ietf-adslmib-hc-tc-06.txt

[Margaret.Wasserman@nokia.com]

I have entered a discuss on draft-ietf-adslmib-hc-tc-06.txt.
Please see my comments below.  

Margaret

DISCUSS comments on draft-ietf-adslmib-hc-tc-06.txt:

>   This document presents a set of High Capacity Textual Conventions 
>   for use in MIB modules which require performance history based upon 
>   15 minute intervals.  The Textual Conventions defined in this 
>   document extend the conventions presented in RFC 3593 to 64 bit 
>   resolution using the conventions presented in RFC 2856.

This isn't really true.  This document takes an entirely
different approach from RFC 3593, which only specifies two
TCs, and provides a template for three variables that 
every MIB must contain that uses the RFC 3593 TCs.  I
believe that the 32-bit and 64-bit mechanisms for handling
15-minute counters should be consistent.

IMO, both this document and RFC 3593 are overly restrictive.
Why are "15 minutes" or "96 intervals" magic numbers?  Do
they come from some telecommunications requirements?

>    hcPerfHistTCMIB MODULE-IDENTITY
[...]
>           In certain cases (e.g., in the case where the agent is a 
>           proxy) it is possible that some intervals are unavailable.  
>           In this case, this interval is the maximum interval number 
>           for which data is available."

There is no explanation for why the use of a proxy would 
cause information for some intervals to be unavailable
and/or how the agent would know that a proxy was in use,
so that it could report a different value.  Please explain.

EDITORIAL COMMENTS on draft-ietf-adslmib-hc-tc-06.txt:

>Since RFC 3593 was only published in Sept 2003, I wonder
>the authors of this document decided to depart so far from
>it.
>
>    HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION
>        STATUS  current
>        DESCRIPTION
>           "The number of near end intervals for which no data is 

The term "near end intervals" isn't meaningful to me.  Is
this a technical term from another context?  If so, a reference
might be helpful.

>             This count represents a non-negative integer, which
>             may increase or decrease, but shall never exceed 2^64-1
>             (18446744073709551615 decimal), nor fall below 0. 

It seems unnecessary to define the range that an unsigned
64-bit integer can assume, and it is especially wordy to 
do this in three separate places in this MIB.