From Minoru.Teraoka@jp.yokogawa.com Mon May 7 02:51:17 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234E021F84C3 for ; Mon, 7 May 2012 02:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.504 X-Spam-Level: *** X-Spam-Status: No, score=3.504 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqy9iPBnOnPZ for ; Mon, 7 May 2012 02:51:16 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by ietfa.amsl.com (Postfix) with ESMTP id 06F9421F845A for ; Mon, 7 May 2012 02:51:15 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (localhost.localdomain [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.13.8/8.13.8) with ESMTP id q479pEHT015582 for ; Mon, 7 May 2012 18:51:14 +0900 Received: from zex001-0m9025.jp.ykgw.net (zex001-0m9025.jp.ykgw.net [10.0.11.44]) by zns001-0m9001.yokogawa.co.jp (8.13.8/8.13.8) with ESMTP id q479pExi015579 for ; Mon, 7 May 2012 18:51:14 +0900 Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9025.jp.ykgw.net ([10.0.11.44]) with mapi; Mon, 7 May 2012 18:51:14 +0900 From: To: Date: Mon, 7 May 2012 18:47:36 +0900 Thread-Topic: The need for simultaneous measurement using multiple windowing schemes Thread-Index: Ac0sNtl2CMXmtQXgRtCsfzG4CeVrAA== Message-ID: <92A5C8A0221B31479EB7913C528ACC59017DA34DFE6B@EXMAIL01.jp.ykgw.net> Accept-Language: en-US, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, ja-JP Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [eman] The need for simultaneous measurement using multiple windowing schemes X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 09:51:17 -0000 Hi Mouli, At present it is possible to define multiple interval modes in eman-energy-monitoring-mib. I would like to clarify the necessity for multiple modes (periodic, total, sliding). The purpose essentially differs between TOTAL and PERIOD. The purpose of TOTAL makes it possible to acquire an integrated value to arbitrary timing. Even if the TOTAL polling interval is far more than a few hours, it may be not permitted that there are several minutes error. As for the time interval of PERIOD, 15 minutes, 30 minutes, and or 60 minutes are assumed. Time accuracy cannot be collateralized when trying substitution of the value of TOTAL with the value of PERIOD. When both an integrated value and a periodic value are required, I think that it is necessary to collect each individually. Best regards, Minoru -- Minoru Teraoka Yokogawa Electric Corporation From moulchan@cisco.com Mon May 14 04:45:28 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475C221F86EB; Mon, 14 May 2012 04:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3HvXwpOQfxK; Mon, 14 May 2012 04:45:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5D21F86C3; Mon, 14 May 2012 04:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1999; q=dns/txt; s=iport; t=1336995927; x=1338205527; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rzZin9MibtR5iXtvXlXGLTPE3SYLVNjUFGdJCYA3LgA=; b=UFsc9l84Q4z1QCO2FzXFTzB20BjedoYOpLASdA5h3rEMvsCymbA34uN7 jD8tlapDOfJvgPXaKZHdmOG6eRTc5uTYga4mtz+ERaORA6unUhDiwkoF+ wLIK6xyvt/ar4qsD4s5T3ZJ7Yxbi+U5BdP8YQanplAUuP7kEKyVn3Drqt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACrvsE+tJXG8/2dsb2JhbABBA7NygQeCFQEBAQQSAR0KNAsMAgICAQgOAgEEAQELBhcBBgEaKwkIAQEEEwgBGYdsC5pIn14EixYZgkSCSGMEiGSbcIFpgweBQQ X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="82981702" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 14 May 2012 11:45:27 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4EBjQuM029108; Mon, 14 May 2012 11:45:26 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 06:45:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 06:45:23 -0500 Message-ID: In-Reply-To: <20120419102636.GA62360@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0eFuflLDb/jU6rTQOFpBkt1QAgMQTr03aA References: <20120419085405.GB61803@elstar.local> <20120419102636.GA62360@elstar.local> From: "Mouli Chandramouli (moulchan)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 14 May 2012 11:45:26.0689 (UTC) FILETIME=[0E023110:01CD31C7] Cc: eman@ietf.org, MIB Doctors Subject: Re: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:45:28 -0000 Hello all, Thanks for the responses - which seem to address how we can handle the questions (wrt to ENTITY MIB) that came back at the WG meeting. =20 >From a process point of view, will there be an informational rfc - that lists the new requirements and the how those can be addressed within ENTITY-MIB framework ?=20 Thanks Mouli=20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, April 19, 2012 3:57 PM To: Mouli Chandramouli (moulchan) Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org Subject: Re: [eman] Entity MIBv4? On Thu, Apr 19, 2012 at 04:42:11AM -0500, Mouli Chandramouli (moulchan) wrote: =20 > > > - representation of UUID compliant with rfc 4122 ? > >=20 > > Not 100% sure what this means. entPhysicalUris can contain an RFC 4122 > > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > > object. If so, I am not sure you need the extra URN verbosity. > >=20 > [[DR]] This is the only issue that seems open in my view - meaning the > slides and discussions at the meeting did not seem to lead to a > conclusion. Do we expect cases where both a RFC 4122 compliant UUID > representation and also another entPhysicalUri format will be needed? >=20 > [ycm] Two possible approaches for UUID representation as given in the > mailing list and slides=20 > [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html The question is whether it is wise to encode a UUID, which is essentially 16 binary octets, in a representation that requires 45 octets. I am pretty optimistic that a DISPLAY-HINT definition can be provided that renders 16 binary octets into something like "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Mon May 14 05:03:05 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4264E21F861E; Mon, 14 May 2012 05:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.457 X-Spam-Level: X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXYkp+ixw2xf; Mon, 14 May 2012 05:03:04 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id DA5FF21F8642; Mon, 14 May 2012 05:03:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAK3zsE/GmAcF/2dsb2JhbABBA7NygQeCFQEBAQECARIeCjQLBQcCAgIBCA0DAQQBAQEKBgwLAQYBGisJCAEBBAESCAEZh2cFC51FnGoEixYZgkSCSGMEnBSKKYJrgV0 X-IronPort-AV: E=Sophos;i="4.75,585,1330923600"; d="scan'208";a="306342632" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 May 2012 08:01:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 May 2012 08:01:28 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 14:02:57 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0eFuflLDb/jU6rTQOFpBkt1QAgMQTr03aAAACuLFA= References: <20120419085405.GB61803@elstar.local> <20120419102636.GA62360@elstar.local> From: "Romascanu, Dan (Dan)" To: "Mouli Chandramouli (moulchan)" , "Juergen Schoenwaelder" Cc: MIB Doctors , eman@ietf.org Subject: Re: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 12:03:05 -0000 Do we need an informational RFC? I thought that having a 'Changes from RFC4133' section in the text part of the rfc4133bis document that lists the changes and the motivation for the changes would be sufficient.=20 Dan > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Monday, May 14, 2012 2:45 PM > To: Juergen Schoenwaelder > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: RE: [eman] Entity MIBv4? >=20 > Hello all, >=20 > Thanks for the responses - which seem to address how we can handle the > questions (wrt to ENTITY MIB) that came back at the WG meeting. >=20 > From a process point of view, will there be an informational rfc - > that lists the new requirements and the how those can be addressed > within ENTITY-MIB framework ? >=20 > Thanks > Mouli >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, April 19, 2012 3:57 PM > To: Mouli Chandramouli (moulchan) > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: Re: [eman] Entity MIBv4? >=20 > On Thu, Apr 19, 2012 at 04:42:11AM -0500, Mouli Chandramouli (moulchan) > wrote: >=20 > > > > - representation of UUID compliant with rfc 4122 ? > > > > > > Not 100% sure what this means. entPhysicalUris can contain an RFC > 4122 > > > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > > > object. If so, I am not sure you need the extra URN verbosity. > > > > > [[DR]] This is the only issue that seems open in my view - meaning > the > > slides and discussions at the meeting did not seem to lead to a > > conclusion. Do we expect cases where both a RFC 4122 compliant UUID > > representation and also another entPhysicalUri format will be needed? > > > > [ycm] Two possible approaches for UUID representation as given in the > > mailing list and slides > > [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html >=20 > The question is whether it is wise to encode a UUID, which is > essentially 16 binary octets, in a representation that requires 45 > octets. I am pretty optimistic that a DISPLAY-HINT definition can be > provided that renders 16 binary octets into something like > "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From moulchan@cisco.com Mon May 14 05:05:47 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C5421F8655; Mon, 14 May 2012 05:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaSgJy3UClKU; Mon, 14 May 2012 05:05:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 48BC021F861E; Mon, 14 May 2012 05:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2925; q=dns/txt; s=iport; t=1336997146; x=1338206746; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CJr9DSil2YTRmPGasgBO8xXQya6ftWZjb9IwOB1kNMY=; b=Qr6JZ2PdYNYcBfQJHuE0stcZ7V26RcnqpPoKsPbB536ETNuJrYl4HGRR 3HrfFzzx7JHNwLgGyln439p5DoGmbpdeivWzx5FWq5fzy5n0DHakBpRQe aATNrfFKkBqMsEcQvWuUsWR9D5szisMNg9uXh3fjhUw2UJ5bkG9vhnJvV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAD0sE+tJXHB/2dsb2JhbABBA7NygQeCFQEBAQMBEgEdCjQLBQcCAgIBCBABBAEBAQoGFwEGARorCQgBAQQBEggBGYdnBQuaUJ9iBIsWGYJEgkhjBIhkm3CBaYMHgUE X-IronPort-AV: E=Sophos;i="4.75,584,1330905600"; d="scan'208";a="82944235" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 14 May 2012 12:05:46 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q4EC5j10028452; Mon, 14 May 2012 12:05:45 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 07:05:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 07:05:39 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Entity MIBv4? Thread-Index: Ac0eFuflLDb/jU6rTQOFpBkt1QAgMQTr03aAAACuLFAAAC58gA== References: <20120419085405.GB61803@elstar.local> <20120419102636.GA62360@elstar.local> From: "Mouli Chandramouli (moulchan)" To: "Romascanu, Dan (Dan)" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 14 May 2012 12:05:42.0955 (UTC) FILETIME=[E2F5A7B0:01CD31C9] Cc: MIB Doctors , eman@ietf.org Subject: Re: [eman] Entity MIBv4? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 12:05:47 -0000 Thanks Dan. Your suggestion of rfc4133bis makes sense.=20 Regards Mouli=20 -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Monday, May 14, 2012 5:33 PM To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder Cc: MIB Doctors; eman@ietf.org Subject: RE: [eman] Entity MIBv4? Do we need an informational RFC? I thought that having a 'Changes from RFC4133' section in the text part of the rfc4133bis document that lists the changes and the motivation for the changes would be sufficient.=20 Dan > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Monday, May 14, 2012 2:45 PM > To: Juergen Schoenwaelder > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: RE: [eman] Entity MIBv4? >=20 > Hello all, >=20 > Thanks for the responses - which seem to address how we can handle the > questions (wrt to ENTITY MIB) that came back at the WG meeting. >=20 > From a process point of view, will there be an informational rfc - > that lists the new requirements and the how those can be addressed > within ENTITY-MIB framework ? >=20 > Thanks > Mouli >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, April 19, 2012 3:57 PM > To: Mouli Chandramouli (moulchan) > Cc: Romascanu, Dan (Dan); MIB Doctors; eman@ietf.org > Subject: Re: [eman] Entity MIBv4? >=20 > On Thu, Apr 19, 2012 at 04:42:11AM -0500, Mouli Chandramouli (moulchan) > wrote: >=20 > > > > - representation of UUID compliant with rfc 4122 ? > > > > > > Not 100% sure what this means. entPhysicalUris can contain an RFC > 4122 > > > UUID URN. Perhaps you are asking for a separate entPhysicalUuid > > > object. If so, I am not sure you need the extra URN verbosity. > > > > > [[DR]] This is the only issue that seems open in my view - meaning > the > > slides and discussions at the meeting did not seem to lead to a > > conclusion. Do we expect cases where both a RFC 4122 compliant UUID > > representation and also another entPhysicalUri format will be needed? > > > > [ycm] Two possible approaches for UUID representation as given in the > > mailing list and slides > > [ycm] http://www.ietf.org/mail-archive/web/eman/current/msg01287.html >=20 > The question is whether it is wise to encode a UUID, which is > essentially 16 binary octets, in a representation that requires 45 > octets. I am pretty optimistic that a DISPLAY-HINT definition can be > provided that renders 16 binary octets into something like > "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From moulchan@cisco.com Tue May 15 22:22:31 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A6B21F8616 for ; Tue, 15 May 2012 22:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUQ0BxD+IHbX for ; Tue, 15 May 2012 22:22:30 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3D92621F8615 for ; Tue, 15 May 2012 22:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=778; q=dns/txt; s=iport; t=1337145750; x=1338355350; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=GfLVoiSHQFkQ/PlY3TJZ0EGlX9LiZOKlDh1cN40bgmk=; b=LdUFMY+kIZEoawG7PeJs5HqA57r4Uazw5YAFZQhdYocFQAkkphbJndKc bhZhMgQ2lIMDRfrK+lX7H/yh6xCFTOnHcoU9ejMEcicfFBj4cWOegMUUL TzO33sok6IpjyI15MMOXw/5JKp9Rpz8v7iONlsRZNcDsVB3ZfT5LENhB9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKA4s0+tJV2c/2dsb2JhbABEtASBB4IWAQEEEgEdCk8CASoGGAYBVgEBBBsah2wLmx6gF4s4ghaCQ2MEiGSOKo1GgWmDBw X-IronPort-AV: E=Sophos;i="4.75,600,1330905600"; d="scan'208";a="83637454" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 16 May 2012 05:22:30 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q4G5MToE008878 for ; Wed, 16 May 2012 05:22:29 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 00:22:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: R6c= Aiwr A2u8 B8fP CvAt DNj9 FPVh Fe+P Gw+H HDJk IIWg I3LN JZ4P Jc7q KAz3 LDoZ; 1; ZQBtAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {BE028AD4-9BCA-4A73-927C-EC1AD33AFAC4}; bQBvAHUAbABjAGgAYQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 16 May 2012 05:22:25 GMT; UABlAHIAcwBpAHMAdABlAG4AYwBlACAAbwBmACAAdABpAG0AZQAgAHMAZQByAGkAZQBzAA== MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {BE028AD4-9BCA-4A73-927C-EC1AD33AFAC4} Content-class: urn:content-classes:message Date: Wed, 16 May 2012 00:22:24 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Persistence of time series Thread-Index: Ac0eFuflLDb/jU6rTQOFpBkt1QAgMQTr03aAAACuLFAAAC58gABV/sJA References: <20120419085405.GB61803@elstar.local><20120419102636.GA62360@elstar.local> From: "Mouli Chandramouli (moulchan)" To: X-OriginalArrivalTime: 16 May 2012 05:22:30.0053 (UTC) FILETIME=[E3B14550:01CD3323] Subject: [eman] Persistence of time series X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 05:22:31 -0000 As of now, the EMAN requirements has persistence of identifiers of the Energy Object which would remain constant even after restart - Requirement 4.3. http://tools.ietf.org/html/draft-ietf-eman-requirements-06 One of the comments during the IETF83 EMAN WG meeting was on the need (if any) for the persistence of time series measurements of energy, power that are being considered.=20 If the use case is revenue grade energy meters, used for billing, persistence could be important. =20 One possible scenario is, if the meter readings are read/collected by an EMS/NMS, then the historical measured meter readings would be stored.=20 Then potential loss of data would be the residual data since the last data retrieval.=20 Any thoughts.=20 Thanks Mouli=20 From bnordman@lbl.gov Wed May 23 12:45:15 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CD311E808A for ; Wed, 23 May 2012 12:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt5PVYLrhj4n for ; Wed, 23 May 2012 12:45:14 -0700 (PDT) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5201A11E8076 for ; Wed, 23 May 2012 12:45:14 -0700 (PDT) X-Ironport-SBRS: 3.8 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsBACs9vU/RVaA0imdsb2JhbABAA4JFqDABiS8IIgEBAQoJDQcSBiOCFQEBAQMBAQEBDwJaCwULCwQHOyIFDQEFARwGEyKHZgULnDwJA54zin0bgWqDGwOIP4xZgQ+NBj2EKA X-IronPort-AV: E=Sophos;i="4.75,645,1330934400"; d="scan'208";a="76102875" Received: from mail-pb0-f52.google.com ([209.85.160.52]) by ironport3.lbl.gov with ESMTP; 23 May 2012 12:45:13 -0700 Received: by mail-pb0-f52.google.com with SMTP id ro8so13541875pbb.39 for ; Wed, 23 May 2012 12:45:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=dtfi17v21M0d9O4kRaeqUGWoMRStXxLuqAgNhH5TP3Q=; b=HjLI/Npgrtlovut40N6+OB9rTdKzdwGrlcZb4GVLPupgU2iEZY/VIvpseG9wLzZSjp 15BnloiIr/vx9NSicENVf6wdmozUF2lECn0lo9cOZt7bNuG7oVMgLLqdwV9XTJ2f5EXh HLAFD0LW8QGsIHk4hdD3Q0kLWBVd7MetE74RumJlwki7DbIYM4EqwNM41zgpHcEn+9bq gnFfrNnu0MpLK4EWzOjctgS0wvauTwoPY8Besf1Tb3zo5FeuOIvc8RfsnG2gV26XOwH9 f/w+v1zmuybr3TvDaycYZUFBZF17CKzL0GLCnTvZe4LaVUdioqwhNp9lI7fh0r1UC3IU YtcQ== MIME-Version: 1.0 Received: by 10.68.212.67 with SMTP id ni3mr7633355pbc.136.1337802313507; Wed, 23 May 2012 12:45:13 -0700 (PDT) Received: by 10.68.28.97 with HTTP; Wed, 23 May 2012 12:45:13 -0700 (PDT) In-Reply-To: References: <20120419085405.GB61803@elstar.local> <20120419102636.GA62360@elstar.local> Date: Wed, 23 May 2012 12:45:13 -0700 Message-ID: From: Bruce Nordman To: "Mouli Chandramouli (moulchan)" Content-Type: multipart/alternative; boundary=e89a8ff1ca56ad22a604c0b95ffd X-Gm-Message-State: ALoCoQkVG1t8F8MwBzzF3QbRKZmvK0nnc/AwY+HTfYHvvtu1IjkQRee/HOlSiGDDvmJspOTG141a Cc: eman@ietf.org Subject: Re: [eman] Persistence of time series X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 19:45:15 -0000 --e89a8ff1ca56ad22a604c0b95ffd Content-Type: text/plain; charset=ISO-8859-1 I don't think the requirements need to say anything about persistence other than the identifier. Thus, devices would not be required to persist other data through power cycles, though would not be prohibited from doing so. I think the requirements text is OK as-is. I don't foresee EMAN being used for utility revenue grade metering, and I think we do not mention this in the Applicability Statement. Even if it was, the same organization would be carefully specifying the meter and the data collection system. I do think it possible that a utility meter could report EMAN data to the building as a second path, distinct from the billing reporting to the utility. I can imagine EMAN being used within a building for billing, as to commercial building tenants, but this would not be utility metering. Losing track of small amounts of energy through very occasional system restarts does not seem to be a problem to me. Thanks, --Bruce On Tue, May 15, 2012 at 10:22 PM, Mouli Chandramouli (moulchan) < moulchan@cisco.com> wrote: > As of now, the EMAN requirements has persistence of identifiers of the > Energy Object which would remain constant even after restart - > Requirement 4.3. > http://tools.ietf.org/html/draft-ietf-eman-requirements-06 > > One of the comments during the IETF83 EMAN WG meeting was on the need > (if any) for the persistence of time series measurements of energy, > power that are being considered. > If the use case is revenue grade energy meters, used for billing, > persistence could be important. > > One possible scenario is, if the meter readings are read/collected by an > EMS/NMS, then the historical measured meter readings would be stored. > Then potential loss of data would be the residual data since the last > data retrieval. > > Any thoughts. > > Thanks > Mouli > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > -- *Bruce Nordman* Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --e89a8ff1ca56ad22a604c0b95ffd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think the requirements need to say anything about persistenceother than the identifier.=A0 Thus, devices would not be required to
p= ersist other data through power cycles, though would not be
prohibited f= rom doing so.=A0 I think the requirements text is OK as-is.

I don't foresee EMAN being used for utility revenue grade metering,=
and I think we do not mention this in the Applicability Statement.
E= ven if it was, the same organization would be carefully specifying the
meter and the data collection system.=A0 I do think it possible that a
u= tility meter could report EMAN data to the building as a second path,
di= stinct from the billing reporting to the utility.
I can imagine EMAN bei= ng used within a building for billing, as to
commercial building tenants, but this would not be utility metering.
Los= ing track of small amounts of energy through very occasional
system rest= arts does not seem to be a problem to me.

Thanks,

--Bruce

On Tue, May 15, 2012 at 10:22 PM, Mouli Chan= dramouli (moulchan) <moulchan@cisco.com> wrote:
As of now, the EMAN requirements has persistence of identifiers of the
Energy Object which would remain constant even after restart -
Requirement 4.3.
http://tools.ietf.org/html/draft-ietf-eman-requirements-06

One of the comments during the IETF83 EMAN WG meeting was on the need
(if any) for the persistence of time series measurements of energy,
power that are being considered.
If the use case is revenue grade energy meters, used for billing,
persistence could be important.

One possible scenario is, if the meter readings are read/collected by an EMS/NMS, then the historical measured meter readings would be stored.
Then potential loss of data would be the residual data since the last
data retrieval.

Any thoughts.

Thanks
Mouli



_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bru= ce Nordman
Lawrence Berkel= ey National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--e89a8ff1ca56ad22a604c0b95ffd--