Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 2 Nov 2012 11:13:02 +0000

Juergen,

Agreed, Thanks this is really a TimeStamp object - TimeTicks measures the time between epochs (which would be the window length).  

sysUpTime shall be reset when the device is rebooted, the table is also destroyed and a new table shall be created when the device is rebooted.

Thanks
Mouli

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, October 25, 2012 4:23 PM
To: [email-masked]
Cc: Mouli Chandramouli (moulchan); [email-masked]
Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt

My point here was that TimeTicks does not imply sysUpTime. I did not
look at the object in question. Now that I do that, I read:

        eoEnergyCollectionStartTime OBJECT-TYPE
            SYNTAX          TimeTicks
            UNITS           "hundredths of seconds"
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
               "The time (in hundredths of a second) since the
               network management portion of the system was last
               re-initialized, as specified in the sysUpTime [RFC3418].
               This object is useful for reference of interval periods
               for which the energy is measured."
           ::= { eoEnergyEntry 1 }

This really seems to be a TimeStamp object. I do agree that using
sysUpTime as an epoch needs to be carefully thought through since any
discontinuity that resets sysUpTime makes the value of this object
meaningless. I am also not sure I understand the meaning of "for
reference of interval periods".

/js

On Thu, Oct 25, 2012 at 07:25:26PM +0900, [email-masked] wrote:
> Hello Juergen,
> 
> I see I did not understand correctly about TimeTicks.
> In EoEnergyCollectionStartTime, it begins from 0 at the time of an
> observation start.  What I just wanted to say is that if there is an entry
> that updated maximum 16 months ago in the table, old and new index may exist.
> Is it too strict?
> 
> Best regards,
> Minoru
> --
> Minoru Teraoka
> Yokogawa Electric Corporation
> 
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> > [mailto:[email-masked]]
> > Sent: Thursday, October 25, 2012 5:56 PM
> > To: Teraoka, Minoru ([email-masked])
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [eman] I-D Action:
> > draft-ietf-eman-energy-monitoring-mib-03.txt
> >
> > On Thu, Oct 25, 2012 at 05:49:43PM +0900, [email-masked]
> > wrote:
> > > Hello Mouli,
> > >
> > > Thank you for your comments.  I understood the operation of the table.
> > > By the way, I'm concerned about using eoEnergyCollectionStartTime
> > > (SYNTAX TimeTicks) as an index of eoEnergyTable.
> > > Description of the eoEnergyParametersIntervalNumber object says that
> > > when the eoEnergyMaxConsumed and/or eoEnergyMaxProduced are in (one
> > > of) the two oldest measurement(s), they are left untouched and the
> > > next oldest measurement is replaced.  When sysUpTime wraps, it may be
> > > possible that a value of eoEnergyCollectionStartTime repeats.
> > > I'm sorry if I have not been clear.
> > >
> >
> > RFC 2578:
> >
> > 7.1.8.  TimeTicks
> >
> >    The TimeTicks type represents a non-negative integer which represents
> >    the time, modulo 2^32 (4294967296 decimal), in hundredths of a second
> >    between two epochs.  When objects are defined which use this ASN.1
> >    type, the description of the object identifies both of the reference
> >    epochs.
> >
> >    For example, [3] defines the TimeStamp textual convention which is
> >    based on the TimeTicks type.  With a TimeStamp, the first reference
> >    epoch is defined as the time when sysUpTime [5] was zero, and the
> >    second reference epoch is defined as the current value of sysUpTime.
> >
> > Note that TimeTicks itself is not linked to sysUpTime. TimeStamp is but
> > TimeTicks is not.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 
> -----
> CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Nov 2012 23:09:23 +0100

> sysUpTime shall be reset when the device is rebooted, the table is also destroyed and a new table shall be created when the device is rebooted.

Note that sysUpTime may be reset at other occasions as well.

/js