RE: question on PIB and Counter32/Counter64

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

My concerns are:

- The statement that Counter32 and Counter64 cannot be used in SPPI,
  I think is false.

- as far as I can tell the new Usage32 and Usage64 TCs are (very) 
  similar to ZerobasedCounter32/64 so why not re-use them?
 
Am I worrying too much?

Thanks,
Bert 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: donderdag 19 december 2002 16:00
> To: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: RE: question on PIB and Counter32/Counter64
> 
> 
> Bert,
> 
> Can you explain your concern? Is this about whether the 
> additional semantics is needed? Should we not rely on the 
> judgment of the authors? Assuming it is, do you have a 
> proposal for an alternate way of providing it? Also, is there 
> a problem to use these TCs in MIBs? 
> 
> Thanks,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: Thursday, December 19, 2002 4:30 PM
> > To: Mreview (E-mail)
> > Subject: question on PIB and Counter32/Counter64
> > 
> > 
> > If you could take a quick look at 
> > 
> >   
> > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr
> > -pib-04.txt
> > 
> > section 3.2, then you can read:
> > 
> > 
> >    The SPPI does not support the Counter32/64 textual 
> > conventions (TC) 
> >    of SNMP - for feedback collection two similar textual 
> conventions 
> >    have been defined in this PIB: Usage32 and Usage64. 
> >  
> >    In addition to the differential functionality of 
> 'Counter', where 
> >    only the difference between two samples generally carries 
> >    information, a single value of a 'Usage' attribute usually 
> > provides 
> >    absolute information, since 
> >    - its initial value is known (0) 
> >    - no wrap-around events should occur 
> >    - the time or event when the initial value was set should be    
> >      available directly or indirectly from other objects. 
> >     
> >    When 'Usage' attributes are defined in a PRC, events that could 
> >    cause a reset of the attribute to it's initial value should be 
> >    defined in the description as well as the mechanism that 
> > allows the 
> >    PDP to detect the time of the last reset. 
> >     
> >    No usual COPS activity however should cause the reset of a Usage 
> >    attribute. In the case of a suspension of monitoring activity 
> >    (frwkFeedbackActionIndicator set to 
> > 'suspendMonitoringAndReports'), 
> >    'Usage' attributes should keep their values and continue 
> counting 
> >    after monitoring is resumed. 
> >     
> > 
> > I don't agree with that and I worry about them defining Usage32 
> > and Usage64 TCs to be used instead of Counter32/64 and/or
> > ZeroBasedCounter32/64
> > 
> > Any comments?
> > 
> > Thanks,
> > Bert 
> > 
> > 
>