Subject: [Adslmib] RE: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64 bit counter when valid value is 0 .. 899

From: "Ray, Robert" <[email-masked]>
Date: Thu, 3 Nov 2005 11:24:21 -0600

Hi.
 
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.  
 
Regards,
Bob Ray
 
________________________________

From: Ambiga Karthikeyan [mailto:[email-masked]] 
Sent: Thursday, November 03, 2005 11:04 AM
To: [email-masked]
Cc: Ray, Robert; [email-masked]
Subject: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64 bit counter
when valid value is 0 .. 899

Dear RFC3728 editors,

     I am working on implementing Vdsl MIBs and while reviewing RFC
3728, I found that the following mib variables in 

vdslPerfDataTable and vdslPerfIntervalTable  defined as
HCPerfCurrentCount which is 64 bit counter.

           vdslPerfDataCurr15MinLofs          HCPerfCurrentCount,

           vdslPerfDataCurr15MinLoss          HCPerfCurrentCount,

           vdslPerfDataCurr15MinLprs          HCPerfCurrentCount,

           vdslPerfDataCurr15MinLols          HCPerfCurrentCount,

           vdslPerfDataCurr15MinESs           HCPerfCurrentCount,

           vdslPerfDataCurr15MinSESs          HCPerfCurrentCount,

           vdslPerfDataCurr15MinUASs          HCPerfCurrentCount,

           vdslPerfDataCurr15MinInits         HCPerfCurrentCount,

          vdslPerfIntervalLofs               HCPerfIntervalCount,

          vdslPerfIntervalLoss               HCPerfIntervalCount,

          vdslPerfIntervalLprs               HCPerfIntervalCount,

          vdslPerfIntervalLols               HCPerfIntervalCount,

          vdslPerfIntervalESs                HCPerfIntervalCount,

          vdslPerfIntervalSESs               HCPerfIntervalCount,

          vdslPerfIntervalUASs               HCPerfIntervalCount,

          vdslPerfIntervalInits              HCPerfIntervalCount

Here is the definition of one of them:

   vdslPerfDataCurr15MinLofs OBJECT-TYPE

       SYNTAX       HCPerfCurrentCount

       UNITS        "seconds"

       MAX-ACCESS   read-only

       STATUS       current

       DESCRIPTION

           "Count of seconds during this interval that there

           was Loss of Framing."

       REFERENCE    "T1E1.4/2000-009R3, Part 1, common spec"

       ::= { vdslPerfDataEntry 12 }

>From the description, it is the number of seconds in the 15 Min interval
which had Loss of Frame event and so it can be from 0 to 899 only. So
why do we need 64 bit counter value here ?

Am I missing something?

Thank you very much,

Ambiga

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 3 Nov 2005 19:48:18 -0800

Hi -

> From: "Ray, Robert" <[email-masked]>
> To: "Ambiga Karthikeyan" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, November 03, 2005 9:24 AM
> Subject: [Adslmib] RE: RFC3728: vdslPerfDataCurr15MinLofs etc - why 64 bitcounter when valid value is 0 .. 899
..
> for your counters, simply encode them for transmission that way.  Hope
...

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