Re: RE: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64 bitcounter when valid value is 0 .. 899

Hi -

> From: "Ray, Robert" <[email protected]>
> To: "Ambiga Karthikeyan" <[email protected]>; <[email protected]>
> Cc: <[email protected]>
> Sent: Thursday, November 03, 2005 9:24 AM
> Subject: [Adslmib] RE: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64 bitcounter when valid value is 0 .. 899
..
> When writing that MIB, I didn't want to mix high-capacity textual
> conventions with similar though 32-bit textual conventions from RFC3593.
> That is, I'm a big fan of monophyly when writing software (and
> specifications for same).  In terms of what is "on the wire", the high
> capacity data types, when encoded in asn.1, require no more bits than
> their 32-bit equivalents as the significant information is an integer
> value in the range 0..899.   
>
> From a programmer's standpoint, you need not store 64 bits internally
> for your counters, simply encode them for transmission that way.  Hope
> this helps.  
...

Though I have some sympathy for this argument, I'm not able to get
the MIB review guidelines to support it, no matter how hard I squint.

Though the review guidelines relax the RFC 2578 "wrap in less than
one hour" limitation on the use of Counter64, RFC 4181 (page 16)
permits them when it "makes sense" to do so.  In this particular case,
the semantics of the object strongly suggest that this shouldn't even
be a Counter type, much less Counter64.  Page 15 of RFC 4181
suggests that Unsigned32 would be the correct type in this case.

Randy