From bclaise@cisco.com Thu Dec 1 10:07:32 2011 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 D9C371F0CB1 for ; Thu, 1 Dec 2011 10:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.817, BAYES_00=-2.599] 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 3l4+X4bgQp3F for ; Thu, 1 Dec 2011 10:07:32 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2380D1F0C7B for ; Thu, 1 Dec 2011 10:07:31 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB1I2OLc025737 for ; Thu, 1 Dec 2011 19:02:24 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB1I2KNZ011974 for ; Thu, 1 Dec 2011 19:02:21 +0100 (CET) Message-ID: <4ED7C12C.8020201@cisco.com> Date: Thu, 01 Dec 2011 19:02:20 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: eman mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] draft minutes for the EMAN meeting 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: Thu, 01 Dec 2011 18:07:33 -0000 Dear all, Here are our draft minutes. http://www.ietf.org/proceedings/82/minutes/eman.txt Please send any corrections or improvements to us. Regards, Bruce and Benoit. From bclaise@cisco.com Fri Dec 2 07:39:39 2011 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 7643521F8C73 for ; Fri, 2 Dec 2011 07:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 RxginHCxvHwz for ; Fri, 2 Dec 2011 07:39:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 936DB21F8C66 for ; Fri, 2 Dec 2011 07:39:38 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB2FdVTK016333; Fri, 2 Dec 2011 16:39:31 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB2FdUUB015819; Fri, 2 Dec 2011 16:39:31 +0100 (CET) Message-ID: <4ED8F132.4050501@cisco.com> Date: Fri, 02 Dec 2011 16:39:30 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "John Parello (jparello)" , Ira McDonald , "Mielke, William F (Bill)" , eman@ietf.org References: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250CB8807B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <20111117055703.GA26230@elstar.local> <791AD3077F94194BB2BDD13565B6295D24F9139C@Polydeuces.office.hd> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250CB884B6@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <791AD3077F94194BB2BDD13565B6295D24F96A8C@Polydeuces.office.hd> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250CC21A0C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <20111123192746.GA12356@elstar.local> In-Reply-To: <20111123192746.GA12356@elstar.local> Content-Type: multipart/alternative; boundary="------------050707010006010702050605" Subject: Re: [eman] Terminology: power state 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: Fri, 02 Dec 2011 15:39:39 -0000 This is a multi-part message in MIME format. --------------050707010006010702050605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I've been following this email thread with interest. Now, let me try to refocus the discussion. As Juergen said, the "power indicator coding" doesn't apply to us. Even if I understand the value of re-using an exisiting defintion, we can't really copy IEEE 1621 verbatim... This leaves two options: Option 1: Our own EMAN definition: A Power State is defined as a power setting of an Energy Object that influences the power consumption, the available functionality, and the responsiveness of the Energy Object. Examples of Power States include: on, off, sleep, and hibernate. Option 2: adapted from IEEE1621 (Just remove "power indicator coding" from the definition) power state: A condition or mode of a device that broadly characterizes its capabilities, power consumption, and responsiveness to input. Regards, Benoit. > On Wed, Nov 23, 2011 at 10:15:52AM -0800, John Parello (jparello) wrote: > >> My preference in writing the definition is to go with verbatim or quoted >> definitions from a source. So I prefer the IEEE 1621 definition. > I do not see how "power indicator coding" applies to us (and this is > part of the verbatim IEEE 1621 definition as far as I have been told). > > To me, it seems the definition emerging out of this (lengthy) > discussion is slowly but surely getting better than what IEEE 1621 > offers (and mind you that IEEE 1621 is a standard for "User Interface > Elements in Power Control" and as such it is OK that it talks about > "power indicator coding" - but that just means it is not necessarily > the authoritative source for a generic power state definition). > > /js (my last words on this thread) > --------------050707010006010702050605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I've been following this email thread with interest. Now, let me try to refocus the discussion.
As Juergen said, the "power indicator coding" doesn't apply to us.
Even if I understand the value of re-using an exisiting defintion, we can't really copy IEEE 1621 verbatim...

This leaves two options:
Option 1: Our own EMAN definition:
    A Power State is defined as a power setting of an Energy Object
    that influences the power consumption, the available functionality, and the
    responsiveness of the Energy Object.  Examples of Power States
    include: on, off, sleep, and hibernate.
Option 2: adapted from IEEE1621 (Just remove "power indicator coding" from the definition)
power state: A condition or mode of a device that broadly characterizes its capabilities, power consumption, and responsiveness to input.
Regards, Benoit.


On Wed, Nov 23, 2011 at 10:15:52AM -0800, John Parello (jparello) wrote:


My preference in writing the definition is to go with verbatim or quoted
definitions from a source. So I prefer the IEEE 1621 definition.

I do not see how "power indicator coding" applies to us (and this is
part of the verbatim IEEE 1621 definition as far as I have been told).

To me, it seems the definition emerging out of this (lengthy)
discussion is slowly but surely getting better than what IEEE 1621
offers (and mind you that IEEE 1621 is a standard for "User Interface
Elements in Power Control" and as such it is OK that it talks about
"power indicator coding" - but that just means it is not necessarily
the authoritative source for a generic power state definition).

/js (my last words on this thread)

--------------050707010006010702050605-- From bnordman@lbl.gov Fri Dec 2 11:18:44 2011 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 8DEAF1F0C5A for ; Fri, 2 Dec 2011 11:18:44 -0800 (PST) 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 xnu2D+Z4mdzx for ; Fri, 2 Dec 2011 11:18:43 -0800 (PST) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 88F3A21F8C82 for ; Fri, 2 Dec 2011 11:18:40 -0800 (PST) X-Ironport-SBRS: 5.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhABAD8k2U7RVdy0mGdsb2JhbABAA4JNn1gBh3wIIgEBAQEBCAkNBxQlgXIBAQEDAQEBAQ8CWhALCwsNLiIFDQEFARwZCBqHZQiZfQqdB4gHgxoEiCuML41gPYQY X-IronPort-AV: E=Sophos;i="4.71,285,1320652800"; d="scan'208";a="59036223" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport3.lbl.gov with ESMTP; 02 Dec 2011 11:18:31 -0800 Received: by mail-vx0-f180.google.com with SMTP id fo14so4136581vcb.39 for ; Fri, 02 Dec 2011 11:18:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.90.171 with SMTP id bx11mr10408466vdb.26.1322853511560; Fri, 02 Dec 2011 11:18:31 -0800 (PST) Received: by 10.220.181.12 with HTTP; Fri, 2 Dec 2011 11:18:31 -0800 (PST) In-Reply-To: <4ED8F132.4050501@cisco.com> References: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250CB8807B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <20111117055703.GA26230@elstar.local> <791AD3077F94194BB2BDD13565B6295D24F9139C@Polydeuces.office.hd> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250CB884B6@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <791AD3077F94194BB2BDD13565B6295D24F96A8C@Polydeuces.office.hd> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250CC21A0C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <20111123192746.GA12356@elstar.local> <4ED8F132.4050501@cisco.com> Date: Fri, 2 Dec 2011 11:18:31 -0800 Message-ID: From: Bruce Nordman To: eman@ietf.org Content-Type: multipart/alternative; boundary=20cf3071c97ca57f4904b320d5a8 Subject: Re: [eman] Terminology: power state 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: Fri, 02 Dec 2011 19:18:44 -0000 --20cf3071c97ca57f4904b320d5a8 Content-Type: text/plain; charset=ISO-8859-1 I do hope that we wrap up this discussion soon, as I think it is clear that no implementation or use of EMAN will be changed by the choice of words for this definition. We do have a lot of substantive issues to resolve. The Definitions draft - draft-parello-eman-definitions-03 - already contains the concept of "adapting" definitions, and a number of the ones listed already do this, including the very first one. So, this does not seem to be a problem. IEEE 1621 is appropriate in several regards - it applies to a broad set of devices -- ANY electronic device that people may interact with, which covers nearly all electricity use, and well matches the target devices for EMAN. Also, it is about exposing the internal power state to an external entity via a standard interface, which is exactly what EMAN is about. The very name of the standard specifies that "Power Control" is its focus. Also, people are often the ultimate recipients of the power state information. The coding phrase we should drop is about how to map internal states to a standard schema, which is exactly what our power state sets do. What I still do not understand is what is the significant difference in intended meaning between the definition crafted over the last few weeks and the IEEE one? If there is one or more significant differences, these should be clarified. If not, then what are we trying to accomplish? If someone can suggest a different existing standard definition that is as least as applicable and works better, that could be fine. Thanks much and have a great weekend, --Bruce On Fri, Dec 2, 2011 at 7:39 AM, Benoit Claise wrote: > Dear all, > > I've been following this email thread with interest. Now, let me try to > refocus the discussion. > As Juergen said, the "power indicator coding" doesn't apply to us. > Even if I understand the value of re-using an exisiting defintion, we > can't really copy IEEE 1621 verbatim... > > This leaves two options: > Option 1: Our own EMAN definition: > > A Power State is defined as a power setting of an Energy Object > that influences the power consumption, the available functionality, and the > responsiveness of the Energy Object. Examples of Power States > include: on, off, sleep, and hibernate. > > Option 2: adapted from IEEE1621 (Just remove "power indicator coding" from > the definition) > > power state: A condition or mode of a device that broadly characterizes > its capabilities, power consumption, and responsiveness to input. > > Regards, Benoit. > > > > On Wed, Nov 23, 2011 at 10:15:52AM -0800, John Parello (jparello) wrote: > > > My preference in writing the definition is to go with verbatim or quoted > definitions from a source. So I prefer the IEEE 1621 definition. > > I do not see how "power indicator coding" applies to us (and this is > part of the verbatim IEEE 1621 definition as far as I have been told). > > To me, it seems the definition emerging out of this (lengthy) > discussion is slowly but surely getting better than what IEEE 1621 > offers (and mind you that IEEE 1621 is a standard for "User Interface > Elements in Power Control" and as such it is OK that it talks about > "power indicator coding" - but that just means it is not necessarily > the authoritative source for a generic power state definition). > > /js (my last words on this thread) > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --20cf3071c97ca57f4904b320d5a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do hope that we wrap up this discussion soon, as I think it is clear that= no implementation
or use of EMAN will be changed by the choice of words= for this definition.
We do have a lot of substantive issues to resolve.=

The Definitions draft - draft-parello-eman-definitions-03 - already con= tains the concept
of "adapting" definitions, and a number of t= he ones listed already do this, including
the very first one.=A0 So, thi= s does not seem to be a problem.

IEEE 1621 is appropriate in several regards - it applies to a broad set= of devices -- ANY
electronic device that people may interact with, whic= h covers nearly all electricity use,
and well matches the target devices= for EMAN.=A0 Also, it is about exposing the internal
power state to an external entity via a standard interface, which is exactl= y what EMAN
is about.=A0 The very name of the standard specifies that &q= uot;Power Control" is its focus.
Also, people are often the ultimat= e recipients of the power state information.
The coding phrase we should drop is about how to map internal states to a s= tandard
schema, which is exactly what our power state sets do.

Wh= at I still do not understand is what is the significant difference in inten= ded meaning
between the definition crafted over the last few weeks and the IEEE one?=A0= If there is
one or more significant differences, these should be clarif= ied.=A0 If not, then what are we
trying to accomplish?

If someone= can suggest a different existing standard definition that is as least as applicable and works better, that could be fine.

Thanks much and hav= e a great weekend,

--Bruce

On Fri,= Dec 2, 2011 at 7:39 AM, Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Dear all,

I've been following this email thread with interest. Now, let me tr= y to refocus the discussion.
As Juergen said, the "power indicator coding" doesn't app= ly to us.
Even if I understand the value of re-using an exisiting defintion, we can't really copy IEEE 1621 verbatim...

This leaves two options:
Option 1: Our own EMAN definition:

    A Power State is defined as a power setting of an Energy Objec=
t
    that influences the power consumption, the available functionality, and=
 the
    responsiveness of the Energy Object.  Examples of Power States
    include: on, off, sleep, and hibernate.
Option 2: adapted from IEEE1621 (Just remove "power indicator coding" from the definition)

power state: A condition or mode of a device that broadly characterizes its capabilities, power consumption, and responsiveness to input.
Regards, Benoit.



On Wed, Nov 23, 2011 at 10:15:52AM -0800, John Parello (jparello=
) wrote:


My preference in writing the definition is to go with verbatim=
 or quoted
definitions from a source. So I prefer the IEEE 1621 definition.

I do not see how "power indicator coding" applies to u=
s (and this is
part of the verbatim IEEE 1621 definition as far as I have been told).

To me, it seems the definition emerging out of this (lengthy)
discussion is slowly but surely getting better than what IEEE 1621
offers (and mind you that IEEE 1621 is a standard for "User Interface
Elements in Power Control" and as such it is OK that it talks about
"power indicator coding" - but that just means it is not necessar=
ily
the authoritative source for a generic power state definition).

/js (my last words on this thread)


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




--
Bruce Nordman
Lawrence = Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--20cf3071c97ca57f4904b320d5a8-- From jparello@cisco.com Fri Dec 2 17:08:32 2011 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 318AE21F8B15 for ; Fri, 2 Dec 2011 17:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 j-kZsnQpvtNz for ; Fri, 2 Dec 2011 17:08:31 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9492921F8B1B for ; Fri, 2 Dec 2011 17:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=516; q=dns/txt; s=iport; t=1322874511; x=1324084111; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=WrTPOK75wxww13jnbN8cHKDa3eClnQQ0w6XUp7VWF2k=; b=XPo1DOxXIJAlX5Kouo2PWTLzVv8VOQ+qkH4wKx+krQLs5RDmKSGdULYF WdAWlKNWvL2Rjx98iy3LKLgEKjJhGThHW49487995Pehn5w+oavSMlJYK Tl5hesqcnlbMkosdqD57EEpXwUvRBSRIU7V6RttJcJbUuQ2VhcBSkVAEu 0=; X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; d="scan'208";a="17548141" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 03 Dec 2011 01:08:27 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pB318RnK020242; Sat, 3 Dec 2011 01:08:27 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 17:08:27 -0800 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: Fri, 2 Dec 2011 17:07:05 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New Version Notification for draft-parello-eman-definitions-01.txt Thread-Index: AQHMlAuHHDGC5n4j7keBOZybj4xgF5WPkpiAgACSrICAGZcUkIABN4GAgB6TsAA= References: From: "John Parello (jparello)" To: "Juergen Quittek" , "Benoit Claise (bclaise)" X-OriginalArrivalTime: 03 Dec 2011 01:08:27.0635 (UTC) FILETIME=[10581C30:01CCB158] Cc: eman mailing list Subject: Re: [eman] New Version Notification for draft-parello-eman-definitions-01.txt 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: Sat, 03 Dec 2011 01:08:32 -0000 >What, if an EO from one energy management domain reports on an energy=20 >object from another energy management domain? >Is this impossible by definition? > =20 >[jp] Right now yes. I see no reason to make that impossible by=20 >definition though. We'd have to make sure that the IDs as defined would >be universal. So as defined yes but I have no problem changing that as=20 >that's a design issue. I agree on the IDs. Is the "may" in your definition a "MAY"? [jp] Yes changed to MAY From jparello@cisco.com Fri Dec 2 17:11:28 2011 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 1DFC311E80A6 for ; Fri, 2 Dec 2011 17:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NnR+pTRKxDfl for ; Fri, 2 Dec 2011 17:11:27 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 66AEC11E8083 for ; Fri, 2 Dec 2011 17:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=2322; q=dns/txt; s=iport; t=1322874687; x=1324084287; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=Ag2JeR5sLNlbCV4aqi4myYrJw5H+suOYXAxeJ1tahUg=; b=S/k1RaT+MUZiqobWor2ZcxMC4YjyQX68EQZss/GXSDgtdsSbpztgpEx0 atcU2Q+ZTAI9D+ovKsgYyOUwkyprGU7w2awMVrtSwNDiR1XrE8rFL2ulN s/FaFk+aEiZvaa3bZar6cpYktD31LFGZJWsv8fhygWmFuOpRCcF0CNp9q M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgAAKZ22U6rRDoJ/2dsb2JhbABDmgWQKYEFgXIBAQEEEgEUCUITBgEIEQQBAQsGFwEHRQkJAQQBEggaoBYBniuKPmMEh3c0nmQ X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; d="scan'208";a="15779770" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 03 Dec 2011 01:11:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pB31BRlW007541; Sat, 3 Dec 2011 01:11:27 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 17:11:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Dec 2011 17:10:01 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Comments on draft-parello-eman-definitions-03 Thread-Index: AcyxWEf0F1vzbpL4Qf+agD9UflNp2A== From: "John Parello (jparello)" To: "Mielke, William F (Bill)" , X-OriginalArrivalTime: 03 Dec 2011 01:11:27.0032 (UTC) FILETIME=[7B45EB80:01CCB158] Subject: Re: [eman] Comments on draft-parello-eman-definitions-03 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: Sat, 03 Dec 2011 01:11:28 -0000 Hi Bill, See inline thanks... -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Mielke, William F (Bill) Sent: Monday, November 14, 2011 3:59 AM To: eman@ietf.org Subject: [eman] Comments on draft-parello-eman-definitions-03 Below are my initial comments on draft-parello-eman-definitions-03. = Mostly these are minor wording changes, but I may have additional = comments after I finish reading the remaining documents. In general I = think things look reasonable. Section 1: Last paragraph - "there were all included" -> "these were all included" Section 2: Energy management - "system congruent to" -> "management domain which is = congruent to" Energy management system - "poll energy from" -> "poll energy readings = from" [jp] ACK on all above=20 General Comment - These relationships seem somewhat arbitrary General Comment - The phrase "Energy Object Relationship capability" is = unclear to me. What do we actually mean by this, especially the word = "capability" in this context? [jp] See new version I think I cleared that up. Power state - I propose to change the definition to "Power States are a = generalized way to classify the operational settings on an Energy Object = which affect the Energy Object's rate of energy consumption. A Power = State denotes one specific setting from among a group of several such = settings (e.g. on, off, or sleep)." [jp] AS per consensus went with IEEE definition added the convergence = from the list to a NOTE Name plate power - "can support" -> "will consume under normal = operations"=20 Name plate power - "required for operating the device" -> "the Energy = Object will require under normal operations" Name plate power - General Comment - This definition seems too narrow, = or perhaps additional terms may be missing? =A0For example, the name = plate frequently defines a range of allowable voltages and/or current = ranges which a device can be safely operated under. How or where should = these types of values be accounted for, and how do they affect or relate = to the term "name plate power"? [jp] I left a very short definition in. If you have a suggestion on a = reference or some note can you provide one. Thanks Jp From jparello@cisco.com Fri Dec 2 17:13:02 2011 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 C5EAA11E80AE for ; Fri, 2 Dec 2011 17:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, 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 89AH6zYd6l4Y for ; Fri, 2 Dec 2011 17:13:02 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14111E8083 for ; Fri, 2 Dec 2011 17:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=9409; q=dns/txt; s=iport; t=1322874782; x=1324084382; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=eUpzIsw//xho8dq5+nZXHFGLlNX5BFtcxzuKwSxJG5w=; b=Jxj9NtkwPLlq/RNHknFax9/5IZYWGdLWVJwkZnepGWwgvUeQD9i5zwgf C4AIM25kBhTpNbC+tr6/QGwQCOE/Lnb1BYd/yjAOCyHxzADwHrzx0GzmE hIH1B4fKDf6RwwID/0+EY+kGwjATYtkj55oFo747aYIWrybKRd3pElN2l I=; X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; d="scan'208,217";a="17548581" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 03 Dec 2011 01:13:02 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB31D2kI008336; Sat, 3 Dec 2011 01:13:02 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 17:13:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCB158.B36A133D" Date: Fri, 2 Dec 2011 17:11:36 -0800 Message-ID: In-Reply-To: <4ED8F132.4050501@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: power state Thread-Index: AcyxCJeGMLRY+iK6RC2MxkAFdkKw+AAT7Ttw References: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250CB8807B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <20111117055703.GA26230@elstar.local> <791AD3077F94194BB2BDD13565B6295D24F9139C@Polydeuces.office.hd> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250CB884B6@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <791AD3077F94194BB2BDD13565B6295D24F96A8C@Polydeuces.office.hd> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250CC21A0C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <20111123192746.GA12356@elstar.local> <4ED8F132.4050501@cisco.com> From: "John Parello (jparello)" To: "Benoit Claise (bclaise)" , "Ira McDonald" , "Mielke, William F (Bill)" , X-OriginalArrivalTime: 03 Dec 2011 01:13:01.0946 (UTC) FILETIME=[B3D8A5A0:01CCB158] Subject: Re: [eman] Terminology: power state 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: Sat, 03 Dec 2011 01:13:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB158.B36A133D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I put in Option 2 as the definition. The Option 1 is listed in the Notes for that definition. =20 In general next draft will contain a single definition(as per consensus from IETF 82) and any alternatives I had in the draft I moved to a listing of NOTES or deleted. =20 New draft (4) will be published shortly. =20 Jp =20 From: Benoit Claise (bclaise)=20 Sent: Friday, December 02, 2011 7:40 AM To: John Parello (jparello); Ira McDonald; Mielke, William F (Bill); eman@ietf.org Subject: Re: [eman] Terminology: power state =20 Dear all, I've been following this email thread with interest. Now, let me try to refocus the discussion. As Juergen said, the "power indicator coding" doesn't apply to us. Even if I understand the value of re-using an exisiting defintion, we can't really copy IEEE 1621 verbatim...=20 This leaves two options: Option 1: Our own EMAN definition: A Power State is defined as a power setting of an Energy Object that influences the power consumption, the available functionality, and the responsiveness of the Energy Object. Examples of Power States include: on, off, sleep, and hibernate. Option 2: adapted from IEEE1621 (Just remove "power indicator coding" from the definition) power state: A condition or mode of a device that broadly characterizes its capabilities, power consumption, and responsiveness to input.=20 Regards, Benoit. On Wed, Nov 23, 2011 at 10:15:52AM -0800, John Parello (jparello) wrote: =20 My preference in writing the definition is to go with verbatim or quoted definitions from a source. So I prefer the IEEE 1621 definition. =20 I do not see how "power indicator coding" applies to us (and this is part of the verbatim IEEE 1621 definition as far as I have been told). =20 To me, it seems the definition emerging out of this (lengthy) discussion is slowly but surely getting better than what IEEE 1621 offers (and mind you that IEEE 1621 is a standard for "User Interface Elements in Power Control" and as such it is OK that it talks about "power indicator coding" - but that just means it is not necessarily the authoritative source for a generic power state definition). =20 /js (my last words on this thread) =20 =20 ------_=_NextPart_001_01CCB158.B36A133D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I put in Option 2 as the definition. The Option 1 is listed in the = Notes for that definition.

 

In general next draft will contain a single definition(as per = consensus from IETF 82) and any alternatives I had in the draft I moved = to a listing of NOTES or deleted.

 

New draft (4) will be published shortly.

 

Jp

 

From: Benoit Claise (bclaise)
Sent: Friday, December 02, 2011 = 7:40 AM
To: John Parello (jparello); Ira McDonald; Mielke, = William F (Bill); eman@ietf.org
Subject: Re: [eman] = Terminology: power state

 

Dear = all,

I've been following this email thread with interest. Now, = let me try to refocus the discussion.
As Juergen said, the = "power indicator coding" doesn't apply to us.
Even if I = understand the value of re-using an exisiting defintion, we can't really = copy IEEE 1621 verbatim...

This leaves two options:
Option 1: = Our own EMAN definition:

    A =
Power State is defined as a power setting of an Energy =
Object
    that influences the power =
consumption, the available functionality, and =
the
    responsiveness of the Energy =
Object.  Examples of Power =
States
    include: on, off, sleep, =
and hibernate.

Option 2: adapted = from IEEE1621 (Just remove "power indicator coding" from the = definition)

power state: A condition = or mode of a device that broadly characterizes its capabilities, power = consumption, and responsiveness to input.

Regards, Benoit.



On =
Wed, Nov 23, 2011 at 10:15:52AM -0800, John Parello (jparello) =
wrote:
 
My preference in =
writing the definition is to go with verbatim or =
quoted
definitions from a source. So I prefer the =
IEEE 1621 =
definition.
 
I do not see how "power indicator coding" applies to us (and = this is
part of the verbatim IEEE 1621 definition =
as far as I have been =
told).
 
To me, it seems =
the definition emerging out of this =
(lengthy)
discussion is slowly but surely getting =
better than what IEEE 1621
offers (and mind you =
that IEEE 1621 is a standard for "User =
Interface
Elements in Power Control" and as =
such it is OK that it talks about
"power =
indicator coding" - but that just means it is not =
necessarily
the authoritative source for a generic =
power state =
definition).
 
/js (my =
last words on this =
thread)
 

 

------_=_NextPart_001_01CCB158.B36A133D-- From jparello@cisco.com Fri Dec 2 17:34:22 2011 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 EF8751F0C45 for ; Fri, 2 Dec 2011 17:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 0t3S8c192TnP for ; Fri, 2 Dec 2011 17:34:22 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAC31F0C38 for ; Fri, 2 Dec 2011 17:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=2446; q=dns/txt; s=iport; t=1322876062; x=1324085662; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Mw2+vfGC1og1Vxt56J1zzkTGMw9gbvfg2L9ZcJmjFQI=; b=mBsDk+b+kL951sEuVbuGfLv2Igv9sWpHB0ySfGozNWfQrsbfIo8TytHe Z8gJ4htxGpUw+uNH+BIxAyd7zx/ZGdrEKQksp9VtCVSnazFA7TW9xot/a hpRe0/F2Wk2I0iswyqvAsHJZe7rgijCXAe7aQorpcdPmnTnXzZHgV+/k3 E=; X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; d="scan'208";a="17550884" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 03 Dec 2011 01:34:22 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB31YMQZ024903; Sat, 3 Dec 2011 01:34:22 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 17:34:21 -0800 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: Fri, 2 Dec 2011 17:32:56 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New Version Notification fordraft-parello-eman-definitions-01.txt Thread-Index: AQHMlAuHHDGC5n4j7keBOZybj4xgF5WPkpiAgACSrICAGZcUkIAf0j9A References: <4EA8758F.3060208@cisco.com> From: "John Parello (jparello)" To: "Juergen Quittek" , "Benoit Claise (bclaise)" X-OriginalArrivalTime: 03 Dec 2011 01:34:21.0969 (UTC) FILETIME=[AECCA810:01CCB15B] Cc: eman mailing list Subject: Re: [eman] New Version Notification fordraft-parello-eman-definitions-01.txt 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: Sat, 03 Dec 2011 01:34:23 -0000 HI JQ, In order to address your feedback I added new parent/child definitions. Will followup in separate thread. Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello) Sent: Saturday, November 12, 2011 11:38 AM To: Juergen Quittek; Benoit Claise (bclaise) Cc: eman mailing list Subject: Re: [eman] New Version Notification fordraft-parello-eman-definitions-01.txt Hi JQ, -----Original Message----- From: Juergen Quittek [mailto:Quittek@neclab.eu] Sent: Wednesday, October 26, 2011 10:49 PM To: Benoit Claise (bclaise) Cc: John Parello (jparello); eman mailing list; Juergen Quittek Subject: Re: [eman] New Version Notification for draft-parello-eman-definitions-01.txt Hi John, Here is a comment on another Term: Energy Object Relationship > "Energy Object Relationships > =20 > Energy Objects may have functional relationships to each other > within an Energy Management Domain. What, if an EO from one energy management domain reports on an energy object from another energy management domain? Is this impossible by definition? =20 [jp] Right now yes. I see no reason to make that impossible by definition though. We'd have to make sure that the IDs as defined would be universal. So as defined yes but I have no problem changing that as that's a design issue. > NOTE 1: One Energy Object will provide a capability or > functional value in the relationship and another will be the > receiver of the capability. Why "receiver"? =20 The "receiver of the capability" is the energy management system for which the providing energy objects makes the job and to which it provides its capabilities. The other energy object may not at all be aware that a meter spying at its power supply line reports its power values to a management system. In such a case it definitely does not receive anything. Instead of "receiver", "object" would be a good term if we weren't using it already as part of object-oriented design terminology. What about using=20 "concerned energy object" instead of=20 "receiver of the capability"? [jp] Any paring would be ok. (parent,child) (producer,consumer) or (source,destination) Jp _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Fri Dec 2 17:38:50 2011 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 CC33E1F0C49 for ; Fri, 2 Dec 2011 17:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 3pIG5xry0PCG for ; Fri, 2 Dec 2011 17:38:50 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28A1F0C38 for ; Fri, 2 Dec 2011 17:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=706; q=dns/txt; s=iport; t=1322876330; x=1324085930; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=JyKfwfTOTW/VM9A711GPdlICh8LWKPHglc5s4SSYfg8=; b=m75vQtWUI33vBdSvtxkM2YdTsp6C3ELyG5eKd+GMnhjW67/bcxO6zBzI YhuCjgpL3/8ewbQgvXlJNdvV9QxEcdmjttKWaKoOybgGo9G0Tb1gTgqPq CG6xoPHGGhoBzGZQIFNE58+LmQYIFycMBAlQFaZputhQ60TX6gWy95Iq7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFV92U6rRDoH/2dsb2JhbABEqi2BBYF0AQEDEgEdCjgZASoGGAdXAQQbGp53gSYBni2IDIIyYwSIK55l X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; d="scan'208";a="17551322" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 03 Dec 2011 01:38:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB31cn3X027523 for ; Sat, 3 Dec 2011 01:38:49 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 17:38:49 -0800 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: Fri, 2 Dec 2011 17:37:24 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Definitions for Relationship/Parent/Child Thread-Index: AcyxXBcGPP4/WaJSTj6f/8wkH7B1Hw== From: "John Parello (jparello)" To: X-OriginalArrivalTime: 03 Dec 2011 01:38:49.0704 (UTC) FILETIME=[4E61C680:01CCB15C] Subject: [eman] Definitions for Relationship/Parent/Child 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: Sat, 03 Dec 2011 01:38:50 -0000 HI, Consolidating feedback I revised the relationship and parent child definitions as follows: What do you all think? Energy Object Relationship An Energy Objects Relationship is a functional association between one or more Energy Objects : (then there's definitions for each relationship type) . Energy Object Parent An Energy Object Parent is an Energy Object that participates in an Energy Object Relationships and is considered as providing the capabilities in the relationship. Energy Object Child An Energy Object Child is an Energy Object that participates in an Energy Object Relationships and is considered as receiving the capabilities in the relationship. Jp =20 From jparello@cisco.com Sun Dec 4 13:06:10 2011 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 94EBD21F84A9 for ; Sun, 4 Dec 2011 13:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 cGwazzh2eL42 for ; Sun, 4 Dec 2011 13:06:10 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 00F4A21F84A3 for ; Sun, 4 Dec 2011 13:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=479; q=dns/txt; s=iport; t=1323032770; x=1324242370; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=POKafY1Y6XDxH4wnry/XFgAh7JPxcUqybeZEkToABAU=; b=JFKMdTRACj4438IJE1vKlXdjwkosDwYRyo1OHuIxZiPHq5FJEAJ89Tz+ woDo4M+uhqKITvw/gS4pr2F4cVa+hstJJ/w+p+zIM61zeRyg5ZaXR1Za4 oeJfqjg46UMd4yDWC0i3UdY24Bqu3Tulf6wVaMJ/6KhAIIOHqDeXZqthE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPff206rRDoI/2dsb2JhbABEqjKBBYF0AQQSAR0KUQEqBhgHVwEEGxqdW4EmAZ1EiAyCMmMEiC2eaA X-IronPort-AV: E=Sophos;i="4.71,294,1320624000"; d="scan'208";a="17754177" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 04 Dec 2011 21:06:09 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB4L69ZC005890 for ; Sun, 4 Dec 2011 21:06:09 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 4 Dec 2011 13:06:09 -0800 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: Sun, 4 Dec 2011 13:04:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Draft draft-parello-eman-definitions-04.txt Thread-Index: AcyyyDtiYNZf1TbzTwin5DkAoWp1Ag== From: "John Parello (jparello)" To: X-OriginalArrivalTime: 04 Dec 2011 21:06:09.0455 (UTC) FILETIME=[8BBD63F0:01CCB2C8] Subject: [eman] New Draft draft-parello-eman-definitions-04.txt 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: Sun, 04 Dec 2011 21:06:10 -0000 HI, I've updated the draft. I sent a few previous emails on specific points. In general. 1) As per consensus at IETF-82, picked one definition per term. Any other definitions form other standards I placed in the notes as reference. 2) Put in power state definition. Went with modified IEEE and put the wording from the list in the notes. 3) Made a more concise parent/child definition form feedback 4) other minor edits from review. Thanks everyone! Jp From bclaise@cisco.com Mon Dec 5 09:07:44 2011 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 3BAB211E80AB for ; Mon, 5 Dec 2011 09:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_55=0.6] 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 IRFeHFe5Du4w for ; Mon, 5 Dec 2011 09:07:42 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E8C7011E80A2 for ; Mon, 5 Dec 2011 09:07:41 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB5Gr7Gs008597; Mon, 5 Dec 2011 17:53:08 +0100 (CET) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB5Gr3AM018106; Mon, 5 Dec 2011 17:53:04 +0100 (CET) Message-ID: <4EDCF6EF.5010606@cisco.com> Date: Mon, 05 Dec 2011 17:53:03 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: hiroto.ogaki@alaxala.com References: <4EC69011.1060203@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060707000107020105000203" Cc: eman@ietf.org Subject: Re: [eman] Feedback regarding the EMAN monitoring 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, 05 Dec 2011 17:07:44 -0000 This is a multi-part message in MIME format. --------------060707000107020105000203 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hiroto-san, (Mouli, there are some changes for the draft in line) Thanks for your review. See inline > Hi, Benoit > cc Mouli > > Thank you for providing me with the opportunity to talk with you. > I enjoyed newcomer's meeting and had a good time with you. > > Following are the minutes which we discuss about. > > 1, > Discussion > Why the following object is Counter64? > ・eoPowerStateEnterCount It's true that, at first glance, 4294967295, i.e. Counter32, should be enough Any other view? I reviewed http://www.ietf.org/rfc/rfc4181.txt, and I could not find a guideline such as: "always use Counter64, just in case!" > > Actions/Decisions > Ask Mouli. > > 2, > Discussion > How to update eoEnergyIntervalMaxConsumed(periodical). I found an issue with the draft: the " Figure 2: UML diagram for the powerQualityMIB" doesn't contain the eoEnergyParametersTable. For example: eoEnergyIntervalMaxConsumed > ・eoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period, > 　　 Would that be OK? Yes. Note that we have two maxima now: eoEnergyIntervalMaxConsumed and eoEnergyIntervalMaxProduced We need to updated the draft OLD: eoEnergyParametersIntervalNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of intervals maintained in the eoEnergyTable. Each interval is characterized by a specific eoEnergyIntervalStartTime, used as an index to the table eoEnergyTable . Whenever the maximum number of entries is reached, the measurement over the new interval replaces the oldest measurement , except if the oldest measurement were to be the maximum eoEnergyIntervalMax, in which case the measurement the measurement over the next oldest interval is replaced." DEFVAL { 10 } NEW: eoEnergyParametersIntervalNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of intervals maintained in the eoEnergyTable. Each interval is characterized by a specific eoEnergyIntervalStartTime, used as an index to the table eoEnergyTable . Whenever the maximum number of entries is reached, the measurement over the new interval replaces the oldest measurement. There is one exception to this rule: when the eoEnergyIntervalMaxConsumed and/or eoEnergyIntervalMaxProduced are in (one of) the two oldest measurement(s), they are left untouched and the next oldest measurement is replaced." DEFVAL { 10 } I believe that the integration of your figures (updated with the two maxima) would be a useful addition to the document. > ・Does eoEnergyParametersIntervalNumber indicate the number of intervals maintained in eoEnergyTable > such as fig.2-A and fig.2-B? Yes. > > > ・eoEnergyParametersIntervalMode : period > 　 　 ・eoEnergyIntervalStartTime : see fig.1 > ・eoPowerIndex : 100 > ・eoEnergyParametersIntervalNumber : 3 > > > | | | =========== | > |============ | | | > | | | | > 　 　　 | |============ | | ・・・・・ > | | | | > |<--- L ---> |<--- L ---> |<--- L ---> | > | | | | > S1 S2 S3 S4 > > Period eoEnergyParametersIntervalMode > > > eoPowerIndex | StartTime | MaxConsumed | EnergyCons > -------------------------------------------------------- > 100 | S1 | 390 | 390 > 100 | － | | 0 > 100 | － | | 0 > -------------------------------------------------------- > ↓ > eoPowerIndex | StartTime | MaxConsumed | EnergyCons > -------------------------------------------------------- > 100 | S1 | 390 | 390 > 100 | S2 | 380 | 380 > 100 | － | 0 | 0 > -------------------------------------------------------- > ↓ > eoPowerIndex | StartTime | MaxConsumed | EnergyCons > -------------------------------------------------------- > 100 | S1 | 390 | 390 > 100 | S2 | 380 | 380 > 100 | S3 | 420 | 420 > -------------------------------------------------------- > ↓ > eoPowerIndex | StartTime | MaxConsumed | EnergyCons > -------------------------------------------------------- > 100 | S2 | 380 | 380 > 100 | S3 | 420 | 420 > 100 | S4 | 490 | 490 > -------------------------------------------------------- > > The oldest measurement were not to be the maximum eoEnergyIntervalMaxConsumed. > > > > pmPowerIndex | StartTime | MaxConsumed | EnergyCons > -------------------------------------------------------- > 100 | S1 | 490 | 490 > 100 | － | 0 | 0 > 100 | － | 0 | 0 > -------------------------------------------------------- > ↓ > pmPowerIndex | StartTime | MaxConsumed | EnergyCons > -------------------------------------------------------- > 100 | S1 | 490 | 490 > 100 | S2 | 380 | 380 > 100 | － | 0 | 0 > -------------------------------------------------------- > ↓ > pmPowerIndex | StartTime | MaxConsumed | EnergyCons > -------------------------------------------------------- > 100 | S1 | 490 | 490 > 100 | S2 | 380 | 380 > 100 | S3 | 420 | 420 > -------------------------------------------------------- > ↓ > pmPowerIndex | StartTime | MaxConsumed | EnergyCons > -------------------------------------------------------- > 100 | S1 | 490 | 490 > 100 | S3 | 420 | 420 > 100 | S4 | 390 | 390 > -------------------------------------------------------- > > The oldest measurement were to be the maximum eoEnergyIntervalMaxConsumed. > > Actions/Decisions > ・eoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period, > 　　 Would that be OK? > → Yes > ・Does eoEnergyParametersIntervalNumber indicate the number of intervals maintained in eoEnergyTable > such as fig.2-A and fig.2-B? > → Yes Good, I'm still consistent with what I said during the newcomer meeting ;-) > > 3, > Discussion > How to update eoEnergyIntervalMaxConsumed(total). > 　　・eoEnergyIntervalMaxConsumed is updated below (fig.4) in case eoEnergyParametersIntervalMode is total, > 　　　Would that be OK? > 　 ・Does eoEnergyIntervalMaxConsumed have an entry in the eoEnergyTable when eoEnergyIntervalMode is total? 　　 > ・Besides, the value of eoEnergyIntervalMaxConsumed equals to that of eoEnergyIntervalEnergyConsumed? 　 > 　 > > ・eoEnergyParametersIntervalMode : total > 　　 ・eoEnergyIntervalStartTime : see fig.3 > ・eoPowerIndex : 100 > ・eoEnergyParametersIntervalNumber : 1 > > | | > |========================= | > | | > | | > | | > |<--- Total length ---> | > | | > S1 > > Total eoEnergyParametersIntervalMode > > pmPowerIndex | StartTime | MaxConsumed | EnergyCons > --------------------------------------------------------- > 100 | S1 | 11,290 | 11,290 > --------------------------------------------------------- > > Updating the eoEnergyIntervalMaxConsumed when Mode is total. > > Actions/Decisions > 　　・eoEnergyIntervalMaxConsumed is updated below (fig.4) in case eoEnergyParametersIntervalMode is total, > 　　　Would that be OK? > → Yes > 　 ・Does eoEnergyIntervalMaxConsumed have an entry in the eoEnergyTable when eoEnergyIntervalMode is total? 　　 > → Yes > ・Besides, the value of eoEnergyIntervalMaxConsumed equals to that of eoEnergyIntervalEnergyConsumed? > → Yes Still yes, but let's pay attention that we now have eoEnergyIntervalMaxConsumed eoEnergyIntervalMaxProduced. Again, a useful addition to the draft. > > 4, > Discussion > MIBObject has a tabel missing. > ・"energyObjectMibObjects 3" can be non-existent? > > eoPowerStateTable OBJECT-TYPE > ::= { energyObjectMibObjects 2 } > > eoEnergyParametersTable OBJECT-TYPE > ::= { energyObjectMibObjects 4 }. > > eoPowerStateEntry has a object missing. > ・"eoPowerStateEntry 2" can be non-existent? > > eoPowerStateIndex OBJECT-TYPE > ::= { eoPowerStateEntry 1 } > > eoPowerStateMaxPower OBJECT-TYPE > ::= { eoPowerStateEntry 3 } > > Actions/Decisions > Yes, both of them are mistakes. > Mouli shall correct those texts. > > 5, > Discussion > eoEnergyTable about when Read-Create objects are modified. > ・An Object whose syntax is Read-Create such as eoEnergyParametersIntervalLength is changed by snmp manager, > eoEnergyTable is reset once? Found an editorial mistake in eoPowerMeasurementCaliber OBJECT-TYPE SYNTAX INTEGER { unavailable(1) , unknown(2), actual(3) , estimated(4), presumed(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies how the usage value reported by eoPower was obtained: - unavailable(1): Indicates that the usage is not available. In such a case, the eoPower value must be 0 For devices that can not measure or report power this option can be used. Replace "For" by "for" > > > Actions/Decisions > maybe yes, > 　　Confirm to mouli. I would still say yes, but the document is not clear, so it requires a clarification. Good catch. See eoEnergyParametersStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. The eoEnergyParametersStatus is used to start or stop energy usage logging. An entry status may not be active(1) unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated usage-data logged into the eoEnergyTable will be deleted. The data can be destroyed by setting up the eoEnergyParametersStatus to destroy(2)." I read again the RowStatus TC in http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/SNMPv2-TC, as read-create is always a difficult mattter. Anyway, the goal is that, one of the parameters need to be changed in eoEnergyParametersTable, then eoEnergyParametersStatus must be set to "destroy" first. The only exception might be eoEnergyParametersIntervalNumber, as we might want to extend the number while keeping the current values. Note: we want to specifically mention this in the MIB module. For reference in this discussion: ForyoeoEnergyParametersTable eoEnergyParametersIntervalLength TimeInterval, eoEnergyParametersIntervalNumber Integer32, eoEnergyParametersIntervalMode Integer32, eoEnergyParametersIntervalWindow TimeInterval, eoEnergyParametersSampleRate Integer32, eoEnergyParametersStatus RowStatus > > 6, > Discussion > Power State about whole chassis. > 　　・Following case, How do I define Power State of whole chassis? > > - whole chassis includes two line cards. > - each of line cards is different Power State, such as high(Power on) and sleep(Power off). > > Actions/Decisions > It's depends on implementation. Regards, Benoit (as a contributor) > > > Best regards, > Hiroto > > --------------------------------- > Hiroto Ogaki > ALAXALA Networks, Corp. > E-mail:hiroto.ogaki@alaxala.com > URL:http://www.alaxala.com > --------------------------------- > >> Hiroto-san, >> >> As we discussed, can you please post your feedback on the list. >> >> Regards, Benoit. >> --------------060707000107020105000203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hiroto-san,

(Mouli, there are some changes for the draft in line)

Thanks for your review.
See inline
Hi, Benoit
cc  Mouli

Thank you for providing me with the opportunity to talk with you.
I enjoyed newcomer's meeting and had a good time with you.

Following are the minutes which we discuss about. 

1,
Discussion
  Why the following object is Counter64? 
  ・eoPowerStateEnterCount
It's true that, at first glance, 4294967295, i.e. Counter32, should be enough
Any other view?
I reviewed http://www.ietf.org/rfc/rfc4181.txt, and I could not find a guideline such as: "always use Counter64, just in case!"
 

Actions/Decisions      
  Ask Mouli.

2, 
Discussion
  How to update eoEnergyIntervalMaxConsumed(periodical).
I found an issue with the draft: the " Figure 2: UML diagram for the powerQualityMIB" doesn't contain the eoEnergyParametersTable. For example: eoEnergyIntervalMaxConsumed 

    

      
  ・eoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period, 
　　 Would that be OK?

    

    Yes.

    Note that we have two maxima now: eoEnergyIntervalMaxConsumed and
    eoEnergyIntervalMaxProduced

    

    We need to updated the draft

    OLD:

    
eoEnergyParametersIntervalNumber OBJECT-TYPE
            SYNTAX          Integer32
            MAX-ACCESS      read-create
            STATUS          current
            DESCRIPTION
               "The number of intervals maintained in the eoEnergyTable.
               Each interval is characterized by a specific
               eoEnergyIntervalStartTime, used as an index to the table
               eoEnergyTable . Whenever the maximum number of entries is
               reached, the measurement over the new interval replaces
               the oldest measurement , except if the oldest measurement
               were to be the maximum eoEnergyIntervalMax, in which case
               the measurement the measurement over the next oldest
               interval is replaced."
             DEFVAL { 10 }

NEW:
eoEnergyParametersIntervalNumber OBJECT-TYPE
            SYNTAX          Integer32
            MAX-ACCESS      read-create
            STATUS          current
            DESCRIPTION
               "The number of intervals maintained in the eoEnergyTable.
               Each interval is characterized by a specific
               eoEnergyIntervalStartTime, used as an index to the table
               eoEnergyTable . Whenever the maximum number of entries is
               reached, the measurement over the new interval replaces
               the oldest measurement. There is one exception to this rule:
               when the eoEnergyIntervalMaxConsumed and/or eoEnergyIntervalMaxProduced
               are in (one of) the two oldest measurement(s), they are left untouched
               and the next oldest measurement is replaced."
             DEFVAL { 10 }


    

    I believe that the integration of your figures (updated with the two
    maxima) would be a useful addition to the document.

    

      
  ・Does eoEnergyParametersIntervalNumber indicate the number of intervals maintained in eoEnergyTable 
   such as fig.2-A and fig.2-B? 

    

    Yes.

    

      

      <condition>
      ・eoEnergyParametersIntervalMode   : period 
 　  　 ・eoEnergyIntervalStartTime        : see fig.1
      ・eoPowerIndex                     : 100
      ・eoEnergyParametersIntervalNumber : 3


          |             |             | =========== |
          |============ |             |             |
          |             |             |             |
  　   　　  |             |============ |             | ・・・・・
          |             |             |             |
          | <--- L ---> | <--- L ---> | <--- L ---> |
          |             |             |             |
         S1            S2            S3             S4 
             
         <fig.1> Period eoEnergyParametersIntervalMode


        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons  
       --------------------------------------------------------
              100     |      S1     |     390     |      390
              100     |      －     |             |        0
              100     |      －     |             |        0
       --------------------------------------------------------
                                  ↓
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons  
       --------------------------------------------------------
              100     |      S1     |     390     |      390
              100     |      S2     |     380     |      380
              100     |      －     |       0     |        0
       --------------------------------------------------------
                                  ↓
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons  
       --------------------------------------------------------
              100     |      S1     |     390     |      390
              100     |      S2     |     380     |      380
              100     |      S3     |     420     |      420
       --------------------------------------------------------
                                  ↓
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons  
       --------------------------------------------------------
              100     |      S2     |     380     |      380
              100     |      S3     |     420     |      420
              100     |      S4     |     490     |      490
       --------------------------------------------------------
                                  
       <fig.2-A> The oldest measurement were not to be the maximum eoEnergyIntervalMaxConsumed.



        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons  
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      －     |       0     |        0
              100     |      －     |       0     |        0
       --------------------------------------------------------
                                  ↓
        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons  
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      S2     |     380     |      380
              100     |      －     |       0     |        0
       --------------------------------------------------------
                                  ↓
        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons  
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      S2     |     380     |      380
              100     |      S3     |     420     |      420
       --------------------------------------------------------
                                  ↓
        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons  
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      S3     |     420     |      420
              100     |      S4     |     390     |      390
       --------------------------------------------------------
                                  
       <fig.2-B> The oldest measurement were to be the maximum eoEnergyIntervalMaxConsumed. 

Actions/Decisions      
  ・eoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period, 
　　 Would that be OK?
  → Yes
  ・Does eoEnergyParametersIntervalNumber indicate the number of intervals maintained in eoEnergyTable 
   such as fig.2-A and fig.2-B?
  → Yes

    

    Good, I'm still consistent with what I said during the newcomer
    meeting ;-)

    

      

3,
Discussion
  How to update eoEnergyIntervalMaxConsumed(total).
　　・eoEnergyIntervalMaxConsumed is updated below (fig.4) in case eoEnergyParametersIntervalMode is total, 
　　　Would that be OK?
　 ・Does eoEnergyIntervalMaxConsumed have an entry in the eoEnergyTable when eoEnergyIntervalMode is total? 　　
  ・Besides, the value of eoEnergyIntervalMaxConsumed equals to that of eoEnergyIntervalEnergyConsumed?   　 
 　
      <condition>
      ・eoEnergyParametersIntervalMode   : total 
 　　   ・eoEnergyIntervalStartTime        : see fig.3
      ・eoPowerIndex                     : 100
      ・eoEnergyParametersIntervalNumber : 1

        |                          |
        |========================= |
        |                          |
        |                          |
        |                          |
        |  <--- Total length --->  |
        |                          |
        S1
             
        <fig.3> Total eoEnergyParametersIntervalMode

        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons  
       ---------------------------------------------------------
              100     |      S1     |   11,290    |    11,290
       ---------------------------------------------------------

        <fig.4> Updating the eoEnergyIntervalMaxConsumed when Mode is total. 

Actions/Decisions  
　　・eoEnergyIntervalMaxConsumed is updated below (fig.4) in case eoEnergyParametersIntervalMode is total, 
　　　Would that be OK?
  → Yes
　 ・Does eoEnergyIntervalMaxConsumed have an entry in the eoEnergyTable when eoEnergyIntervalMode is total? 　　
  → Yes
  ・Besides, the value of eoEnergyIntervalMaxConsumed equals to that of eoEnergyIntervalEnergyConsumed?  
  → Yes

    

    Still yes, but let's pay attention that we now have
    eoEnergyIntervalMaxConsumed eoEnergyIntervalMaxProduced.

    Again, a useful addition to the draft.

    

      

4,
Discussion
  MIBObject has a tabel missing.  
  ・"energyObjectMibObjects 3" can be non-existent?      
  
     eoPowerStateTable OBJECT-TYPE
      ::= { energyObjectMibObjects 2 }

     eoEnergyParametersTable OBJECT-TYPE
      ::= { energyObjectMibObjects 4 }.

  eoPowerStateEntry has a object missing.
  ・"eoPowerStateEntry 2" can be non-existent?

     eoPowerStateIndex OBJECT-TYPE
      ::= { eoPowerStateEntry 1 }

     eoPowerStateMaxPower OBJECT-TYPE
      ::= { eoPowerStateEntry 3 }

Actions/Decisions 
  Yes, both of them are mistakes.
  Mouli shall correct those texts. 

    

    

      

5,
Discussion
  eoEnergyTable about when Read-Create objects are modified.
  ・An Object whose syntax is Read-Create such as eoEnergyParametersIntervalLength is changed by snmp manager,
   eoEnergyTable is reset once?  

    

    Found an editorial mistake in 

    

      
eoPowerMeasurementCaliber   OBJECT-TYPE
            SYNTAX          INTEGER  {
                                unavailable(1) ,
                                unknown(2),
                                actual(3) ,
                                estimated(4),
                                presumed(5)                    }
            MAX-ACCESS      read-only
            STATUS          current
            DESCRIPTION
               "This object specifies how the usage value reported by
               eoPower was obtained:
     
               - unavailable(1): Indicates that the usage is not
               available. In such a case, the eoPower value must be 0
               For devices that can not measure or report power this
               option can be used.

      Replace "For" by "for"

    

    

      
   

Actions/Decisions
  maybe yes,
　　Confirm to mouli.

    

    I would still say yes, but the document is not clear, so it requires
    a clarification. Good catch.

    See

    
        eoEnergyParametersStatus OBJECT-TYPE
            SYNTAX          RowStatus
            MAX-ACCESS      read-create
            STATUS          current
            DESCRIPTION
              "The status of this row. The eoEnergyParametersStatus is
              used to start or stop energy usage logging. An entry
              status may not be active(1) unless all objects in the
              entry have an appropriate value.  If this object is not
              equal to active(1), all associated usage-data logged into
              the eoEnergyTable will be deleted. The data can be
              destroyed by setting up the eoEnergyParametersStatus to
              destroy(2)."



    I read again the RowStatus TC in
    http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/SNMPv2-TC, as
    read-create is always a difficult mattter.

    Anyway, the goal is that, one of the parameters need to be changed
    in eoEnergyParametersTable, then eoEnergyParametersStatus must be
    set to "destroy" first.

    The only exception might be eoEnergyParametersIntervalNumber, as we
    might want to extend the number while keeping the current values.

    Note: we want to specifically mention this in the MIB module.

    

    For reference in this discussion:

    
ForyoeoEnergyParametersTable
                eoEnergyParametersIntervalLength     TimeInterval,
                eoEnergyParametersIntervalNumber     Integer32,
                eoEnergyParametersIntervalMode       Integer32,
                eoEnergyParametersIntervalWindow     TimeInterval,
                eoEnergyParametersSampleRate         Integer32,
                eoEnergyParametersStatus             RowStatus




    

      

6,
Discussion
  Power State about whole chassis.
　　・Following case, How do I define Power State of whole chassis?  
  
   - whole chassis includes two line cards. 
   - each of line cards is different Power State, such as high(Power on) and sleep(Power off).
  
Actions/Decisions
  It's depends on implementation.

    

    

    Regards, Benoit (as a contributor)

    

      


Best regards, 
Hiroto

---------------------------------
 Hiroto Ogaki 
 ALAXALA Networks, Corp.
 E-mail:hiroto.ogaki@alaxala.com
 URL:http://www.alaxala.com
---------------------------------



      

        
Hiroto-san,

As we discussed, can you please post your feedback on the list.

Regards, Benoit.



      

    

    

  


--------------060707000107020105000203--

From Minoru.Teraoka@jp.yokogawa.com  Mon Dec  5 21:45:52 2011
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 0810C21F8AF5 for ; Mon,  5 Dec 2011 21:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.393
X-Spam-Level: **
X-Spam-Status: No, score=2.393 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 S+ENSa+AvwRV for ; Mon,  5 Dec 2011 21:45:51 -0800 (PST)
Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by ietfa.amsl.com (Postfix) with ESMTP id 09E8C21F8511 for ; Mon,  5 Dec 2011 21:45:49 -0800 (PST)
Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id pB65jkrK026719; Tue, 6 Dec 2011 14:45:46 +0900 (JST)
Received: from zex001-0m9025.jp.ykgw.net (zex001-0m9025.jp.ykgw.net [10.0.11.44]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id pB65jkJo026716; Tue, 6 Dec 2011 14:45:46 +0900 (JST)
Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9025.jp.ykgw.net ([10.0.11.44]) with mapi; Tue, 6 Dec 2011 14:45:46 +0900
From: 
To: , 
Date: Tue, 6 Dec 2011 14:45:44 +0900
Thread-Topic: Feedback regarding the EMAN monitoring
Thread-Index: AcyzbmMylYA+T8IBQsSzpEOdreYAvwAanTvA
Message-ID: <92A5C8A0221B31479EB7913C528ACC590171C0DB6AA2@EXMAIL01.jp.ykgw.net>
References: <4EC69011.1060203@cisco.com>  <4EDCF6EF.5010606@cisco.com>
In-Reply-To: <4EDCF6EF.5010606@cisco.com>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: eman@ietf.org
Subject: Re: [eman] Feedback regarding the EMAN monitoring
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: Tue, 06 Dec 2011 05:45:52 -0000

SGkgYWxsLA0KDQpUaGVyZSBpcyBhIHBvaW50IHdoaWNoIEkgd291bGQgbGlrZSB0byBjb25maXJt
Lg0KDQo+IDIsIA0KPiBEaXNjdXNzaW9uDQo+ICAgSG93IHRvIHVwZGF0ZSBlb0VuZXJneUludGVy
dmFsTWF4Q29uc3VtZWQocGVyaW9kaWNhbCkuDQo+IEkgZm91bmQgYW4gaXNzdWUgd2l0aCB0aGUg
ZHJhZnQ6IHRoZSAiIEZpZ3VyZSAyOiBVTUwgZGlhZ3JhbSBmb3IgdGhlIHBvd2VyUXVhbGl0eU1J
QiIgZG9lc24ndCBjb250YWluIHRoZSBlb0VuZXJneVBhcmFtZXRlcnNUYWJsZS4gRm9yIGV4YW1w
bGU6IGVvRW5lcmd5SW50ZXJ2YWxNYXhDb25zdW1lZCANCj4gDQo+IA0KPiAgIOODu2VvRW5lcmd5
SW50ZXJ2YWxNYXhDb25zdW1lZCBpcyB1cGRhdGVkIGJlbG93IChmaWcuMi1BLDItQikgaW4gY2Fz
ZSBlb0VuZXJneVBhcmFtZXRlcnNJbnRlcnZhbE1vZGUgaXMgcGVyaW9kLCANCj4g44CA44CAIFdv
dWxkIHRoYXQgYmUgT0s/DQo+IFllcy4NCj4gTm90ZSB0aGF0IHdlIGhhdmUgdHdvIG1heGltYSBu
b3c6IGVvRW5lcmd5SW50ZXJ2YWxNYXhDb25zdW1lZCBhbmQgZW9FbmVyZ3lJbnRlcnZhbE1heFBy
b2R1Y2VkDQoNCg0KRG9lcyBlb0VuZXJneUludGVydmFsRGlzY29udGludWl0eVRpbWUgbmVlZCB0
byBiZSBkaXN0aW5ndWlzaGVkDQpiZXR3ZWVuIGNvbnN1bWluZyBhbmQgcHJvZHVjaW5nPyAgZW5l
cmd5TmV0IGFsc28/DQoNCkJlc3QgcmVnYXJkcywNCk1pbm9ydQ0KDQoNCi0tDQpNaW5vcnUgVGVy
YW9rYQ0KWW9rb2dhd2EgRWxlY3RyaWMgQ29ycG9yYXRpb24NCg0K

From bclaise@cisco.com  Mon Dec  5 23:33:40 2011
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 83B1B21F850B for ; Mon,  5 Dec 2011 23:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.293
X-Spam-Level: 
X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.305,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 2gUPcGZOiHfC for ; Mon,  5 Dec 2011 23:33:39 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACFA21F854D for ; Mon,  5 Dec 2011 23:33:39 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB67XYIl009241; Tue, 6 Dec 2011 08:33:35 +0100 (CET)
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB67XTY6012615; Tue, 6 Dec 2011 08:33:30 +0100 (CET)
Message-ID: <4EDDC546.1020704@cisco.com>
Date: Tue, 06 Dec 2011 08:33:26 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Minoru.Teraoka@jp.yokogawa.com
References: <4EC69011.1060203@cisco.com>  <4EDCF6EF.5010606@cisco.com> <92A5C8A0221B31479EB7913C528ACC590171C0DB6AA2@EXMAIL01.jp.ykgw.net>
In-Reply-To: <92A5C8A0221B31479EB7913C528ACC590171C0DB6AA2@EXMAIL01.jp.ykgw.net>
Content-Type: multipart/alternative; boundary="------------040308070307050100030307"
Cc: eman@ietf.org
Subject: Re: [eman] Feedback regarding the EMAN monitoring
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: Tue, 06 Dec 2011 07:33:40 -0000

This is a multi-part message in MIME format.
--------------040308070307050100030307
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,
> Hi all,
>
> There is a point which I would like to confirm.
>
>> 2,
>> Discussion
>>    How to update eoEnergyIntervalMaxConsumed(periodical).
>> I found an issue with the draft: the " Figure 2: UML diagram for the powerQualityMIB" doesn't contain the eoEnergyParametersTable. For example: eoEnergyIntervalMaxConsumed
>>
>>
>>    ・eoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period,
>> 　　 Would that be OK?
>> Yes.
>> Note that we have two maxima now: eoEnergyIntervalMaxConsumed and eoEnergyIntervalMaxProduced
>
> Does eoEnergyIntervalDiscontinuityTime need to be distinguished
> between consuming and producing?  energyNet also?
Yes.

one improvement though
OLD:

          eoEnergyIntervalDiscontinuityTime OBJECT-TYPE
             SYNTAX      TimeTicks
             MAX-ACCESS  read-only


             STATUS      current
             DESCRIPTION
               "The value of sysUpTime [RFC3418  ] on the most recent
               occasion at which any one or more of this entity's energy
               consumption counters suffered a discontinuity. If no such
               discontinuities have occurred since the last re-
               initialization of the local management subsystem, then
               this object contains a zero value."
             ::= { eoEnergyIntervalEntry 9 }

NEW:
          eoEnergyIntervalDiscontinuityTime OBJECT-TYPE
             SYNTAX      TimeTicks
             MAX-ACCESS  read-only
             STATUS      current
             DESCRIPTION
               "The value of sysUpTime [RFC3418  ] on the most recent
               occasion at which any one or more of this entity's energy
               counters in this table suffered a discontinuity:
               eoEnergyIntervalEnergyConsumed, eoEnergyIntervalEnergyProduced,
               or eoEnergyIntervalEnergyNet. If no such
               discontinuities have occurred since the last re-
               initialization of the local management subsystem, then
               this object contains a zero value."
             ::= { eoEnergyIntervalEntry 9 }


Regards, Benoit (as a contributor)

>
> Best regards,
> Minoru
>
>
> --
> Minoru Teraoka
> Yokogawa Electric Corporation
>
>
>


--------------040308070307050100030307
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi, 

    

      
Hi all,

There is a point which I would like to confirm.



      

        
2, 
Discussion
  How to update eoEnergyIntervalMaxConsumed(periodical).
I found an issue with the draft: the " Figure 2: UML diagram for the powerQualityMIB" doesn't contain the eoEnergyParametersTable. For example: eoEnergyIntervalMaxConsumed 


  ・eoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period, 
　　 Would that be OK?
Yes.
Note that we have two maxima now: eoEnergyIntervalMaxConsumed and eoEnergyIntervalMaxProduced


      

      

Does eoEnergyIntervalDiscontinuityTime need to be distinguished
between consuming and producing?  energyNet also?

    

    Yes.

    

    one improvement though

    OLD:

    
         eoEnergyIntervalDiscontinuityTime OBJECT-TYPE
            SYNTAX      TimeTicks
            MAX-ACCESS  read-only
     
    
            STATUS      current
            DESCRIPTION
              "The value of sysUpTime [RFC3418] on the most recent
              occasion at which any one or more of this entity's energy
              consumption counters suffered a discontinuity. If no such
              discontinuities have occurred since the last re-
              initialization of the local management subsystem, then
              this object contains a zero value."
            ::= { eoEnergyIntervalEntry 9 }

NEW:
         eoEnergyIntervalDiscontinuityTime OBJECT-TYPE
            SYNTAX      TimeTicks
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
              "The value of sysUpTime [RFC3418] on the most recent
              occasion at which any one or more of this entity's energy
              counters in this table suffered a discontinuity: 
              eoEnergyIntervalEnergyConsumed, eoEnergyIntervalEnergyProduced, 
              or eoEnergyIntervalEnergyNet. If no such
              discontinuities have occurred since the last re-
              initialization of the local management subsystem, then
              this object contains a zero value."
            ::= { eoEnergyIntervalEntry 9 }


    

    Regards, Benoit (as a contributor)

    

    

      

Best regards,
Minoru


--
Minoru Teraoka
Yokogawa Electric Corporation





    

    

  


--------------040308070307050100030307--

From moulchan@cisco.com  Mon Dec  5 23:40:25 2011
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 83DB521F8AAA for ; Mon,  5 Dec 2011 23:40:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PK+x2zlYJmpu for ; Mon,  5 Dec 2011 23:40:24 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C8B1A21F8AA9 for ; Mon,  5 Dec 2011 23:40:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2386; q=dns/txt; s=iport; t=1323157225; x=1324366825; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Vlc/6AJsGGBxHDUhjr9Hr0UiRqTiHcMAmBM5A59mmRU=; b=Tj8SbIWgScVPf8+E7hkzLTBM9y35Rz+kQ547h9wxRIeKaCZx5QVhKHmx +bBGQ74mg/lvWeISW/iXlVljHgjYFdGt42HH90lyJaKZEmMRVUxdq7ICT DASW5Mh2Dczbw7Apz17cju2+icE+zk/BhWz2I3BqTSy/dt/qCw0ZmthIw E=;
X-IronPort-AV: E=Sophos;i="4.71,304,1320624000"; d="scan'208";a="41460588"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 06 Dec 2011 07:40:23 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pB67eNMl017225;  Tue, 6 Dec 2011 07:40:23 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 6 Dec 2011 01:40:19 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 6 Dec 2011 01:40:17 -0600
Message-ID: 
In-Reply-To: <92A5C8A0221B31479EB7913C528ACC590171C0DB6AA2@EXMAIL01.jp.ykgw.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Feedback regarding the EMAN monitoring
Thread-Index: AcyzbmMylYA+T8IBQsSzpEOdreYAvwAanTvAAAGRO1A=
References: <4EC69011.1060203@cisco.com>  <4EDCF6EF.5010606@cisco.com> <92A5C8A0221B31479EB7913C528ACC590171C0DB6AA2@EXMAIL01.jp.ykgw.net>
From: "Mouli Chandramouli (moulchan)" 
To: , "Benoit Claise (bclaise)" , 
X-OriginalArrivalTime: 06 Dec 2011 07:40:19.0778 (UTC) FILETIME=[4DE9AA20:01CCB3EA]
Cc: eman@ietf.org
Subject: Re: [eman] Feedback regarding the EMAN monitoring
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: Tue, 06 Dec 2011 07:40:25 -0000

SGkgTWlub3J1LXNhbiwNCg0KZW9FbmVyZ3lJbnRlcnZhbERpc2NvbnRpbnVpdHlUaW1lIGluZGlj
YXRlcyBpZiB0aGVyZSB3YXMgYSBkaXNydXB0aW9uIG9yIHJlLWluaXRpYWxpemF0aW9uIG9mIE5N
Uy4NCg0KVGhlIEVuZXJneSBtZWFzdXJlbWVudCB2YWx1ZXMgd291bGQgYmUgcmVzZXQgd2hlbiB0
aGVyZSBpcyBhIGRpc3J1cHRpb24gaW4gbWVhc3VyZW1lbnQuIA0KVGhpcyB3b3VsZCBiZSBwYXJ0
aWN1bGFybHkgaW1wb3J0YW50IGlmIHRoZSBlb0VuZXJneVBhcmFtZXRlcnNJbnRlcnZhbE1vZGUg
aXMgdG90YWwgKDMpLiBXaGVyZWFzIHdpdGgNCmVvRW5lcmd5UGFyYW1ldGVyc0ludGVydmFsTW9k
ZSBQZXJpb2QgKDEpLCBTbGlkaW5nICgyKSAgdGhlIG1lYXN1cmVtZW50IHZhbHVlcyB3b3VsZCBi
ZSBvaywgDQoNClRoaW5raW5nIGFib3V0IHRoaXMgbW9yZSwgSSBmZWVsIHRoYXQgU1lOVEFYIHBl
cmhhcHMgc2hvdWxkIGJlIFRpbWVTdGFtcCBpbnN0ZWFkIG9mIFRpbWVUaWNrcywgYW5hbG9nb3Vz
IHRvIA0KDQppZkNvdW50ZXJEaXNjb250aW51aXR5VGltZSBPQkpFQ1QtVFlQRQ0KICAgICAgICAg
ICBTWU5UQVggICAgICBUaW1lU3RhbXANCiAgICAgICAgIA0KVGhhbmtzDQpNb3VsaQ0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaW5vcnUuVGVyYW9rYUBqcC55b2tvZ2F3
YS5jb20gW21haWx0bzpNaW5vcnUuVGVyYW9rYUBqcC55b2tvZ2F3YS5jb21dIA0KU2VudDogVHVl
c2RheSwgRGVjZW1iZXIgMDYsIDIwMTEgMTE6MTYgQU0NClRvOiBCZW5vaXQgQ2xhaXNlIChiY2xh
aXNlKTsgaGlyb3RvLm9nYWtpQGFsYXhhbGEuY29tDQpDYzogaGlkZW8ua29kYWthQGFsYXhhbGEu
Y29tOyBNb3VsaSBDaGFuZHJhbW91bGkgKG1vdWxjaGFuKTsgZW1hbkBpZXRmLm9yZw0KU3ViamVj
dDogUkU6IEZlZWRiYWNrIHJlZ2FyZGluZyB0aGUgRU1BTiBtb25pdG9yaW5nDQoNCkhpIGFsbCwN
Cg0KVGhlcmUgaXMgYSBwb2ludCB3aGljaCBJIHdvdWxkIGxpa2UgdG8gY29uZmlybS4NCg0KPiAy
LCANCj4gRGlzY3Vzc2lvbg0KPiAgIEhvdyB0byB1cGRhdGUgZW9FbmVyZ3lJbnRlcnZhbE1heENv
bnN1bWVkKHBlcmlvZGljYWwpLg0KPiBJIGZvdW5kIGFuIGlzc3VlIHdpdGggdGhlIGRyYWZ0OiB0
aGUgIiBGaWd1cmUgMjogVU1MIGRpYWdyYW0gZm9yIHRoZSBwb3dlclF1YWxpdHlNSUIiIGRvZXNu
J3QgY29udGFpbiB0aGUgZW9FbmVyZ3lQYXJhbWV0ZXJzVGFibGUuIEZvciBleGFtcGxlOiBlb0Vu
ZXJneUludGVydmFsTWF4Q29uc3VtZWQgDQo+IA0KPiANCj4gICDjg7tlb0VuZXJneUludGVydmFs
TWF4Q29uc3VtZWQgaXMgdXBkYXRlZCBiZWxvdyAoZmlnLjItQSwyLUIpIGluIGNhc2UgZW9FbmVy
Z3lQYXJhbWV0ZXJzSW50ZXJ2YWxNb2RlIGlzIHBlcmlvZCwgDQo+IOOAgOOAgCBXb3VsZCB0aGF0
IGJlIE9LPw0KPiBZZXMuDQo+IE5vdGUgdGhhdCB3ZSBoYXZlIHR3byBtYXhpbWEgbm93OiBlb0Vu
ZXJneUludGVydmFsTWF4Q29uc3VtZWQgYW5kIGVvRW5lcmd5SW50ZXJ2YWxNYXhQcm9kdWNlZA0K
DQoNCkRvZXMgZW9FbmVyZ3lJbnRlcnZhbERpc2NvbnRpbnVpdHlUaW1lIG5lZWQgdG8gYmUgZGlz
dGluZ3Vpc2hlZA0KYmV0d2VlbiBjb25zdW1pbmcgYW5kIHByb2R1Y2luZz8gIGVuZXJneU5ldCBh
bHNvPw0KDQpCZXN0IHJlZ2FyZHMsDQpNaW5vcnUNCg0KDQotLQ0KTWlub3J1IFRlcmFva2ENCllv
a29nYXdhIEVsZWN0cmljIENvcnBvcmF0aW9uDQoNCg==

From Minoru.Teraoka@jp.yokogawa.com  Tue Dec  6 01:21:03 2011
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 EEF2A21F8B10 for ; Tue,  6 Dec 2011 01:21:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.648
X-Spam-Level: *
X-Spam-Status: No, score=1.648 tagged_above=-999 required=5 tests=[AWL=0.744,  BAYES_00=-2.599, 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 9TugBwPgIZiC for ; Tue,  6 Dec 2011 01:21:02 -0800 (PST)
Received: from zns001-0m9004.yokogawa.co.jp (zns001-0m9004.yokogawa.co.jp [203.174.79.162]) by ietfa.amsl.com (Postfix) with ESMTP id 5F28521F8A6F for ; Tue,  6 Dec 2011 01:21:02 -0800 (PST)
Received: from zns001-0m9004.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id pB69KtYp019092; Tue, 6 Dec 2011 18:20:55 +0900 (JST)
Received: from zex001-0m9026.jp.ykgw.net (zex001-0m9026.jp.ykgw.net [10.0.11.15]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id pB69KtBj019074; Tue, 6 Dec 2011 18:20:55 +0900 (JST)
Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9026.jp.ykgw.net ([10.0.11.15]) with mapi; Tue, 6 Dec 2011 18:20:55 +0900
From: 
To: , , 
Date: Tue, 6 Dec 2011 18:20:52 +0900
Thread-Topic: Feedback regarding the EMAN monitoring
Thread-Index: AcyzbmMylYA+T8IBQsSzpEOdreYAvwAanTvAAAGRO1AABHOBwg==
Message-ID: <92A5C8A0221B31479EB7913C528ACC590171BF7FC4D8@EXMAIL01.jp.ykgw.net>
References: <4EC69011.1060203@cisco.com>  <4EDCF6EF.5010606@cisco.com> <92A5C8A0221B31479EB7913C528ACC590171C0DB6AA2@EXMAIL01.jp.ykgw.net>, 
In-Reply-To: 
Accept-Language: en-US, ja-JP
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, ja-JP
Content-Type: text/plain; charset="iso-2022-jp"
MIME-Version: 1.0
Cc: eman@ietf.org
Subject: Re: [eman] Feedback regarding the EMAN monitoring
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: Tue, 06 Dec 2011 09:21:03 -0000

Hi Mouli, Benoit,

I checked rfc2863, and I think the same thought.  The SYNTAX of
eoEnergyIntervalDiscontinuityTime similar to ifCounterDiscontinuityTime
is appropriate.

I must confess the fact that I get the picture to use DiscontinuityTime
at last.

Thanks,
Minoru

> ________________________________________
> From: Mouli Chandramouli (moulchan) [moulchan@cisco.com]
> Sent: Tuesday, December 06, 2011 4:40 PM
> To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com); Benoit Claise (bclaise); hiroto.ogaki@alaxala.com
> Cc: hideo.kodaka@alaxala.com; eman@ietf.org
> Subject: RE: Feedback regarding the EMAN monitoring
> 
> Hi Minoru-san,
> 
> eoEnergyIntervalDiscontinuityTime indicates if there was a disruption or re-initialization of NMS.
> 
> The Energy measurement values would be reset when there is a disruption in measurement.
> This would be particularly important if the eoEnergyParametersIntervalMode is total (3). Whereas with
> eoEnergyParametersIntervalMode Period (1), Sliding (2)  the measurement values would be ok,
> 
> Thinking about this more, I feel that SYNTAX perhaps should be TimeStamp instead of TimeTicks, analogous to
> 
> ifCounterDiscontinuityTime OBJECT-TYPE
>            SYNTAX      TimeStamp
> 
> Thanks
> Mouli
> 
> 
> -----Original Message-----
> From: Minoru.Teraoka@jp.yokogawa.com [mailto:Minoru.Teraoka@jp.yokogawa.com]
> Sent: Tuesday, December 06, 2011 11:16 AM
> To: Benoit Claise (bclaise); hiroto.ogaki@alaxala.com
> Cc: hideo.kodaka@alaxala.com; Mouli Chandramouli (moulchan); eman@ietf.org
> Subject: RE: Feedback regarding the EMAN monitoring
> 
> Hi all,
> 
> There is a point which I would like to confirm.
> 
> > 2,
> > Discussion
> >   How to update eoEnergyIntervalMaxConsumed(periodical).
> > I found an issue with the draft: the " Figure 2: UML diagram for the powerQualityMIB" doesn't contain the eoEnergyParametersTable. For example: eoEnergyIntervalMaxConsumed
> >
> >
> >   $B!&(BeoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period,
> > $B!!!!(B Would that be OK?
> > Yes.
> > Note that we have two maxima now: eoEnergyIntervalMaxConsumed and eoEnergyIntervalMaxProduced
> 
> 
> Does eoEnergyIntervalDiscontinuityTime need to be distinguished
> between consuming and producing?  energyNet also?
> 
> Best regards,
> Minoru
> 
> 
> --
> Minoru Teraoka
> Yokogawa Electric Corporation
> 
> 

From hiroto.ogaki@alaxala.com  Wed Dec  7 17:35:28 2011
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 4D3B211E8083 for ; Wed,  7 Dec 2011 17:35:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.71
X-Spam-Level: ***
X-Spam-Status: No, score=3.71 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_45=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, SUBJ_RE_NUM=1]
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 UTzn6Gg9ifHd for ; Wed,  7 Dec 2011 17:35:27 -0800 (PST)
Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF2C11E80A4 for ; Wed,  7 Dec 2011 17:35:25 -0800 (PST)
Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 307DB33CCB; Thu,  8 Dec 2011 10:35:24 +0900 (JST)
Received: from mfilter03.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id pB81ZOFL022111; Thu, 8 Dec 2011 10:35:24 +0900
Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id pB81ZM6F021107; Thu, 8 Dec 2011 10:35:23 +0900
X-AuditID: b753bd60-9658fba000007b1b-eb-4ee0145a9554
Received: from gmml01.itg.hitachi.co.jp (unknown [158.213.165.31]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id 52FD22043AC; Thu,  8 Dec 2011 10:35:22 +0900 (JST)
Received: from [127.0.0.1] by gmml01.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id pB81ZMn7172282; Thu, 8 Dec 2011 10:35:22 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: 
Content-Type: text/plain; charset=ISO-2022-JP
To: 
From: 
Date: Thu, 8 Dec 2011 10:34:52 +0900
References: <4EC69011.1060203@cisco.com>  <4EDCF6EF.5010606@cisco.com>
Priority: normal
Importance: normal
X400-Content-Identifier: X4EE0143100000M
X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml03111208103441ZDF]
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: hideo.kodaka@itg.hitachi.co.jp, eman@ietf.org
Subject: Re: [eman] Feedback regarding the EMAN monitoring
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: Thu, 08 Dec 2011 01:35:28 -0000

Hi, Benoit
Cc, Mouli


Thanks for your comment.
See inline,

>Hiroto-san,
>
>(Mouli, there are some changes for the draft in line)
>
>Thanks for your review.
>See inline
>> Hi, Benoit
>> cc  Mouli
>>
>> Thank you for providing me with the opportunity to talk with you.
>> I enjoyed newcomer's meeting and had a good time with you.
>>
>> Following are the minutes which we discuss about.
>>
>> 1,
>> Discussion
>>    Why the following object is Counter64?
>>    $B!&(BeoPowerStateEnterCount
>It's true that, at first glance, 4294967295, i.e. Counter32, should be 
>enough
>Any other view?
>I reviewed http://www.ietf.org/rfc/rfc4181.txt, and I could not find a 
>guideline such as: "always use Counter64, just in case!"

I agree on your thought.
It's enough for Counter32.
We need to update the draft.

>> Actions/Decisions
>>    Ask Mouli.
>>
>> 2,
>> Discussion
>>    How to update eoEnergyIntervalMaxConsumed(periodical).
>I found an issue with the draft: the " Figure 2: UML diagram for the 
>powerQualityMIB" doesn't contain the eoEnergyParametersTable. For 
>example: eoEnergyIntervalMaxConsumed
>
>>    $B!&(BeoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period,
>> $B!!!!(B Would that be OK?
>Yes.
>Note that we have two maxima now: eoEnergyIntervalMaxConsumed and 
>eoEnergyIntervalMaxProduced
>
>We need to updated the draft
>OLD:
>
>eoEnergyParametersIntervalNumber OBJECT-TYPE
>             SYNTAX          Integer32
>             MAX-ACCESS      read-create
>             STATUS          current
>             DESCRIPTION
>                "The number of intervals maintained in the eoEnergyTable.
>                Each interval is characterized by a specific
>                eoEnergyIntervalStartTime, used as an index to the table
>                eoEnergyTable . Whenever the maximum number of entries is
>                reached, the measurement over the new interval replaces
>                the oldest measurement , except if the oldest measurement
>                were to be the maximum eoEnergyIntervalMax, in which case
>                the measurement the measurement over the next oldest
>                interval is replaced."
>              DEFVAL { 10 }
>
>NEW:
>eoEnergyParametersIntervalNumber OBJECT-TYPE
>             SYNTAX          Integer32
>             MAX-ACCESS      read-create
>             STATUS          current
>             DESCRIPTION
>                "The number of intervals maintained in the eoEnergyTable.
>                Each interval is characterized by a specific
>                eoEnergyIntervalStartTime, used as an index to the table
>                eoEnergyTable . Whenever the maximum number of entries is
>                reached, the measurement over the new interval replaces
>                the oldest measurement. There is one exception to this rule:
>                when the eoEnergyIntervalMaxConsumed and/or eoEnergyIntervalMaxProduced
>                are in (one of) the two oldest measurement(s), they are left untouched
>                and the next oldest measurement is replaced."
>              DEFVAL { 10 }
>
>
>I believe that the integration of your figures (updated with the two 
>maxima) would be a useful addition to the document.

Though you agreed on my figure indicated how to update the two maxima,
I've another idea.
I'll send details of my idea later on. 

>>    $B!&(BDoes eoEnergyParametersIntervalNumber indicate the number of intervals maintained in eoEnergyTable
>>     such as fig.2-A and fig.2-B?
>Yes.
>>
>>        
>>        $B!&(BeoEnergyParametersIntervalMode   : period
>>   $B!!(B  $B!!(B $B!&(BeoEnergyIntervalStartTime        : see fig.1
>>        $B!&(BeoPowerIndex                     : 100
>>        $B!&(BeoEnergyParametersIntervalNumber : 3
>>
>>
>>            |             |             | =========== |
>>            |============ |             |             |
>>            |             |             |             |
>>    $B!!(B   $B!!!!(B  |             |============ |             | $B!&!&!&!&!&(B
>>            |             |             |             |
>>            |<--- L --->  |<--- L --->  |<--- L --->  |
>>            |             |             |             |
>>           S1            S2            S3             S4
>>
>>             Period eoEnergyParametersIntervalMode
>>
>>
>>          eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>>         --------------------------------------------------------
>>                100     |      S1     |     390     |      390
>>                100     |      $B!](B     |             |        0
>>                100     |      $B!](B     |             |        0
>>         --------------------------------------------------------
>>                                    $B"-(B
>>          eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>>         --------------------------------------------------------
>>                100     |      S1     |     390     |      390
>>                100     |      S2     |     380     |      380
>>                100     |      $B!](B     |       0     |        0
>>         --------------------------------------------------------
>>                                    $B"-(B
>>          eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>>         --------------------------------------------------------
>>                100     |      S1     |     390     |      390
>>                100     |      S2     |     380     |      380
>>                100     |      S3     |     420     |      420
>>         --------------------------------------------------------
>>                                    $B"-(B
>>          eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>>         --------------------------------------------------------
>>                100     |      S2     |     380     |      380
>>                100     |      S3     |     420     |      420
>>                100     |      S4     |     490     |      490
>>         --------------------------------------------------------
>>
>>           The oldest measurement were not to be the maximum eoEnergyIntervalMaxConsumed.
>>
>>
>>
>>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>>         --------------------------------------------------------
>>                100     |      S1     |     490     |      490
>>                100     |      $B!](B     |       0     |        0
>>                100     |      $B!](B     |       0     |        0
>>         --------------------------------------------------------
>>                                    $B"-(B
>>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>>         --------------------------------------------------------
>>                100     |      S1     |     490     |      490
>>                100     |      S2     |     380     |      380
>>                100     |      $B!](B     |       0     |        0
>>         --------------------------------------------------------
>>                                    $B"-(B
>>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>>         --------------------------------------------------------
>>                100     |      S1     |     490     |      490
>>                100     |      S2     |     380     |      380
>>                100     |      S3     |     420     |      420
>>         --------------------------------------------------------
>>                                    $B"-(B
>>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>>         --------------------------------------------------------
>>                100     |      S1     |     490     |      490
>>                100     |      S3     |     420     |      420
>>                100     |      S4     |     390     |      390
>>         --------------------------------------------------------
>>
>>           The oldest measurement were to be the maximum eoEnergyIntervalMaxConsumed.
>>
>> Actions/Decisions
>>    $B!&(BeoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period,
>> $B!!!!(B Would that be OK?
>>    $B"*(B Yes
>>    $B!&(BDoes eoEnergyParametersIntervalNumber indicate the number of intervals maintained in eoEnergyTable
>>     such as fig.2-A and fig.2-B?
>>    $B"*(B Yes
>Good, I'm still consistent with what I said during the newcomer meeting ;-)

How kind of you to remember.

>> 3,
>> Discussion
>>    How to update eoEnergyIntervalMaxConsumed(total).
>> $B!!!!!&(BeoEnergyIntervalMaxConsumed is updated below (fig.4) in case eoEnergyParametersIntervalMode is total,
>> $B!!!!!!(BWould that be OK?
>> $B!!(B $B!&(BDoes eoEnergyIntervalMaxConsumed have an entry in the eoEnergyTable when eoEnergyIntervalMode is total? $B!!!!(B
>>    $B!&(BBesides, the value of eoEnergyIntervalMaxConsumed equals to that of eoEnergyIntervalEnergyConsumed?   $B!!(B
>>   $B!!(B
>>        
>>        $B!&(BeoEnergyParametersIntervalMode   : total
>>   $B!!!!(B   $B!&(BeoEnergyIntervalStartTime        : see fig.3
>>        $B!&(BeoPowerIndex                     : 100
>>        $B!&(BeoEnergyParametersIntervalNumber : 1
>>
>>          |                          |
>>          |========================= |
>>          |                          |
>>          |                          |
>>          |                          |
>>          |<--- Total length --->   |
>>          |                          |
>>          S1
>>
>>            Total eoEnergyParametersIntervalMode
>>
>>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>>         ---------------------------------------------------------
>>                100     |      S1     |   11,290    |    11,290
>>         ---------------------------------------------------------
>>
>>            Updating the eoEnergyIntervalMaxConsumed when Mode is total.
>>
>> Actions/Decisions
>> $B!!!!!&(BeoEnergyIntervalMaxConsumed is updated below (fig.4) in case eoEnergyParametersIntervalMode is total,
>> $B!!!!!!(BWould that be OK?
>>    $B"*(B Yes
>> $B!!(B $B!&(BDoes eoEnergyIntervalMaxConsumed have an entry in the eoEnergyTable when eoEnergyIntervalMode is total? $B!!!!(B
>>    $B"*(B Yes
>>    $B!&(BBesides, the value of eoEnergyIntervalMaxConsumed equals to that of eoEnergyIntervalEnergyConsumed?
>>    $B"*(B Yes
>Still yes, but let's pay attention that we now have 
>eoEnergyIntervalMaxConsumed eoEnergyIntervalMaxProduced.
>Again, a useful addition to the draft.
>>
>> 4,
>> Discussion
>>    MIBObject has a tabel missing.
>>    $B!&(B"energyObjectMibObjects 3" can be non-existent?
>>
>>       eoPowerStateTable OBJECT-TYPE
>>        ::= { energyObjectMibObjects 2 }
>>
>>       eoEnergyParametersTable OBJECT-TYPE
>>        ::= { energyObjectMibObjects 4 }.
>>
>>    eoPowerStateEntry has a object missing.
>>    $B!&(B"eoPowerStateEntry 2" can be non-existent?
>>
>>       eoPowerStateIndex OBJECT-TYPE
>>        ::= { eoPowerStateEntry 1 }
>>
>>       eoPowerStateMaxPower OBJECT-TYPE
>>        ::= { eoPowerStateEntry 3 }
>>
>> Actions/Decisions
>>    Yes, both of them are mistakes.
>>    Mouli shall correct those texts.
>>
>> 5,
>> Discussion
>>    eoEnergyTable about when Read-Create objects are modified.
>>    $B!&(BAn Object whose syntax is Read-Create such as eoEnergyParametersIntervalLength is changed by snmp manager,
>>     eoEnergyTable is reset once?
>Found an editorial mistake in
>
>    eoPowerMeasurementCaliber   OBJECT-TYPE
>                 SYNTAX          INTEGER  {
>                                     unavailable(1) ,
>                                     unknown(2),
>                                     actual(3) ,
>                                     estimated(4),
>                                     presumed(5)                    }
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                    "This object specifies how the usage value reported by
>                    eoPower was obtained:
>
>                    - unavailable(1): Indicates that the usage is not
>                    available. In such a case, the eoPower value must be 0
>                    For devices that can not measure or report power this
>                    option can be used.
>
>    Replace "For" by "for"
>
>>
>>
>> Actions/Decisions
>>    maybe yes,
>> $B!!!!(BConfirm to mouli.
>I would still say yes, but the document is not clear, so it requires a 
>clarification. Good catch.
>See
>
>         eoEnergyParametersStatus OBJECT-TYPE
>             SYNTAX          RowStatus
>             MAX-ACCESS      read-create
>             STATUS          current
>             DESCRIPTION
>               "The status of this row. The eoEnergyParametersStatus is
>               used to start or stop energy usage logging. An entry
>               status may not be active(1) unless all objects in the
>               entry have an appropriate value.  If this object is not
>               equal to active(1), all associated usage-data logged into
>               the eoEnergyTable will be deleted. The data can be
>               destroyed by setting up the eoEnergyParametersStatus to
>               destroy(2)."
>
>
>I read again the RowStatus TC in 
>http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/SNMPv2-TC, as 
>read-create is always a difficult mattter.
>Anyway, the goal is that, one of the parameters need to be changed in 
>eoEnergyParametersTable, then eoEnergyParametersStatus must be set to 
>"destroy" first.

Yes,
it's need to be following procedure.

   1. snmpset parametersStatus.xx destroy
   2. snmpset parametersStatus.xx createAndWait
   3. snmpset parametersIntervalLength.xx 1800
   4. snmpset parametersIntervalNumber.xx 30
   5. snmpset parametersStatus.xx active

>The only exception might be eoEnergyParametersIntervalNumber, as we 
>might want to extend the number while keeping the current values.
>Note: we want to specifically mention this in the MIB module.
>For reference in this discussion:

This exception needs to be mentioned, but it looks difficult to extend the number while keeping the current value.
Any idea ?

>
>ForyoeoEnergyParametersTable
>                 eoEnergyParametersIntervalLength     TimeInterval,
>                 eoEnergyParametersIntervalNumber     Integer32,
>                 eoEnergyParametersIntervalMode       Integer32,
>                 eoEnergyParametersIntervalWindow     TimeInterval,
>                 eoEnergyParametersSampleRate         Integer32,
>                 eoEnergyParametersStatus             RowStatus
>
>
>
>>
>> 6,
>> Discussion
>>    Power State about whole chassis.
>> $B!!!!!&(BFollowing case, How do I define Power State of whole chassis?
>>
>>     - whole chassis includes two line cards.
>>     - each of line cards is different Power State, such as high(Power on) and sleep(Power off).
>>
>> Actions/Decisions
>>    It's depends on implementation.
>
>Regards, Benoit (as a contributor)


Regards, Hiroto
>>
>> Best regards,
>> Hiroto
>>
>> ---------------------------------
>>   Hiroto Ogaki
>>   ALAXALA Networks, Corp.
>>   E-mail:hiroto.ogaki@alaxala.com
>>   URL:http://www.alaxala.com
>> ---------------------------------
>>
>>> Hiroto-san,
>>>
>>> As we discussed, can you please post your feedback on the list.
>>>
>>> Regards, Benoit.
>>>
>
>

From hiroto.ogaki@alaxala.com  Wed Dec  7 18:23:19 2011
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 80CA121F8467 for ; Wed,  7 Dec 2011 18:23:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.517
X-Spam-Level: **
X-Spam-Status: No, score=2.517 tagged_above=-999 required=5 tests=[AWL=1.193,  BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1]
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 3rAuf3tDLaRD for ; Wed,  7 Dec 2011 18:23:18 -0800 (PST)
Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60D1021F8450 for ; Wed,  7 Dec 2011 18:23:18 -0800 (PST)
Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 7826437C83; Thu,  8 Dec 2011 11:23:17 +0900 (JST)
Received: from mfilter03.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id pB82NH9J021060; Thu, 8 Dec 2011 11:23:17 +0900
Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id pB82NGWB014350; Thu, 8 Dec 2011 11:23:17 +0900
X-AuditID: b753bd60-a0885ba000000655-03-4ee01f94faf6
Received: from gmml01.itg.hitachi.co.jp (unknown [158.213.165.31]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 4C5E87741B3; Thu,  8 Dec 2011 11:23:16 +0900 (JST)
Received: from [127.0.0.1] by gmml01.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id pB82NGq14921942; Thu, 8 Dec 2011 11:23:16 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: 
Content-Type: text/plain; charset=ISO-2022-JP
To: , 
From: 
Date: Thu, 8 Dec 2011 11:22:39 +0900
Priority: normal
Importance: normal
X400-Content-Identifier: X4EE01F5200000M
X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml031112081122103XN]
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: hideo.kodaka@itg.hitachi.co.jp, eman@ietf.org
Subject: Re: [eman] Minutes(11/16) for Eman-Mib
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: Thu, 08 Dec 2011 02:23:19 -0000

Hi, all

There is a thing I confrim.

>2.
>  Discussed the additional index of eoEnergyParametersEntry.

We agreed to using period(1) and total(3) at the same time.
Therefore, eoEnergyTable has multiple entries that are the same eoPowerIndex
and different eoEnergyParametersIntervalMode.
But, now, eoEnergyParametersEntry can't be distinguished between periodical and total.

following is an example.

    eoEnergyParametersIntervalLength.xx = 800 <- periodical or total??
    eoEnergyParametersIntervalNumber.xx =  20 <- periodical or total??
    (xx indicates eoPowerIndex)

So, I need to have another index as such.

OLD$B!'(B
         eoEnergyParametersEntry OBJECT-TYPE
             SYNTAX          EoEnergyParametersEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "An entry controls an energy measurement in
                eoEnergyTable."
             INDEX  { eoPowerIndex }

NEW$B!'(B

         eoEnergyParametersEntry OBJECT-TYPE
             SYNTAX          EoEnergyParametersEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "An entry controls an energy measurement in
                eoEnergyTable."
             INDEX  { eoPowerIndex, eoEnergyParametersIntervalMode }
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is my understanding correct?

Regards,
Hiroto



From hiroto.ogaki@alaxala.com  Wed Dec  7 18:43:40 2011
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 B6CF811E8096 for ; Wed,  7 Dec 2011 18:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.143
X-Spam-Level: **
X-Spam-Status: No, score=2.143 tagged_above=-999 required=5 tests=[AWL=0.374,  BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1, SUBJ_RE_NUM=1]
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 1O3Hf9ZfCbqi for ; Wed,  7 Dec 2011 18:43:39 -0800 (PST)
Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id B628711E8095 for ; Wed,  7 Dec 2011 18:43:38 -0800 (PST)
Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 11C2A33CC7; Thu,  8 Dec 2011 11:43:29 +0900 (JST)
Received: from mfilter04.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id pB82hTYY009255; Thu, 8 Dec 2011 11:43:29 +0900
Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id pB82hSsE030179; Thu, 8 Dec 2011 11:43:28 +0900
X-AuditID: b753bd60-98392ba000007b1b-1a-4ee0244f4aa9
Received: from gmml01.itg.hitachi.co.jp (unknown [158.213.165.31]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id ACEC52043A2; Thu,  8 Dec 2011 11:43:27 +0900 (JST)
Received: from [127.0.0.1] by gmml01.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id pB82hRH14467304; Thu, 8 Dec 2011 11:43:27 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: 
Content-Type: text/plain; charset=ISO-2022-JP
To: , 
From: 
Date: Thu, 8 Dec 2011 11:43:07 +0900
Priority: normal
Importance: normal
X400-Content-Identifier: X4EE0242300000M
X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml031112081142435YG]
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: hideo.kodaka@itg.hitachi.co.jp, eman@ietf.org
Subject: Re: [eman] Feedback regarding the EMAN monitoring
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: Thu, 08 Dec 2011 02:43:40 -0000

Hi, all

>Though you agreed on my figure indicated how to update the two maxima,
>I've another idea.
>I'll send details of my idea later on. 

Another idea is the following.
Which figures are correct?
 or  ?
Difference between those figures is keeing maxim or not.
#refer my previous email about 


        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     390     |      390
       --------------------------------------------------------
                                  $B"-(B
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     390     |      390
              100     |      S2     |     390     |      380
       --------------------------------------------------------
                                  $B"-(B
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     390     |      390
              100     |      S2     |     390     |      380
              100     |      S3     |     420     |      420
       --------------------------------------------------------
                                  $B"-(B
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S2     |     390     |      380
              100     |      S3     |     420     |      420
              100     |      S4     |     490     |      490
       --------------------------------------------------------
         The oldest measurement were not to be the maximum eoEnergyIntervalMaxConsumed.



        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     490     |      490
       --------------------------------------------------------
                                  $B"-(B
        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      S2     |     490     |      380
       --------------------------------------------------------
                                  $B"-(B
        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      S2     |     490     |      380
              100     |      S3     |     490     |      420
       --------------------------------------------------------
                                  $B"-(B
        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      S3     |     490     |      420
              100     |      S4     |     490     |      390
       --------------------------------------------------------
        The oldest measurement were to be the maximum eoEnergyIntervalMaxConsumed.

 Best regards,
 Hiroto



From bclaise@cisco.com  Thu Dec  8 07:52:48 2011
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 C021621F8557 for ; Thu,  8 Dec 2011 07:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.352
X-Spam-Level: 
X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247,  BAYES_00=-2.599]
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 ucMzfK1WJ1CG for ; Thu,  8 Dec 2011 07:52:48 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFF021F8593 for ; Thu,  8 Dec 2011 07:52:47 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB8FiLZX023687 for ; Thu, 8 Dec 2011 16:44:21 +0100 (CET)
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB8FiK8x004546; Thu, 8 Dec 2011 16:44:20 +0100 (CET)
Message-ID: <4EE0DB54.8010903@cisco.com>
Date: Thu, 08 Dec 2011 16:44:20 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "John Parello (jparello)" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: eman@ietf.org
Subject: Re: [eman] New Draft  draft-parello-eman-definitions-04.txt
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: Thu, 08 Dec 2011 15:52:48 -0000

Hi John,

> HI,
>
> I've updated the draft. I sent a few previous emails on specific points.
> In general.
>
> 1) As per consensus at IETF-82, picked one definition per term. Any
> other definitions form other standards I placed in the notes as
> reference.
Does it make sense to have the second definitions as a note?
As a reader, I'm asking myself:
     - why do we have a second definition?
     - how is the second different?
     - etc...

I could make sense to give a second reference, part of an explanation in 
one of the draft.
However, I think it's confusing to have a second definition in the note?

Regards, Benoit (as a contributor)
>
> 2) Put in power state definition. Went with modified IEEE and put the
> wording from the list in the notes.
>
> 3) Made a more concise parent/child definition form feedback
>
> 4) other minor edits from review.
>
> Thanks everyone!
>
> Jp
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>
>


From jparello@cisco.com  Thu Dec  8 08:44:58 2011
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 0BA4621F893C for ; Thu,  8 Dec 2011 08:44:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Level: 
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, 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 po3I44a3KbkU for ; Thu,  8 Dec 2011 08:44:57 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86F21F8753 for ; Thu,  8 Dec 2011 08:44:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=2327; q=dns/txt; s=iport; t=1323362697; x=1324572297; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gyK8xJxi7hsJC/1nIBCPKHbJBKy/VStnoimljgMN5fI=; b=GtfEcNUyXo5qqv8iOJIJJK1ILwfBnFzkUV9oeaTGz89SbroWzdmTpWft GtWf7dE/JOy16qS54UjXjfAUNNxSezK6udpodcRmV3PakLHPFo3Fntbwj lu2rdrVy+/eHUfOKXFRym+eZWR5RwnfktXFsPOlpgFJtwpEsAdTqyc7EG U=;
X-IronPort-AV: E=Sophos;i="4.71,320,1320624000"; d="scan'208";a="18473313"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 08 Dec 2011 16:44:57 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB8Giv4k001243; Thu, 8 Dec 2011 16:44:57 GMT
Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Dec 2011 08:44:57 -0800
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: Thu, 8 Dec 2011 08:42:16 -0800
Message-ID: 
In-Reply-To: <4EE0DB54.8010903@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] New Draft  draft-parello-eman-definitions-04.txt
Thread-Index: Acy1wEQAmBsLN7w5TfqDsKtttNOeygABs/kQ
References:  <4EE0DB54.8010903@cisco.com>
From: "John Parello (jparello)" 
To: "Benoit Claise (bclaise)" 
X-OriginalArrivalTime: 08 Dec 2011 16:44:57.0190 (UTC) FILETIME=[B7FE8860:01CCB5C8]
Cc: eman@ietf.org
Subject: Re: [eman] New Draft  draft-parello-eman-definitions-04.txt
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: Thu, 08 Dec 2011 16:44:58 -0000

Hi Benoit,

I wasn't intending the note to be a second definition. I'm just siting
multiple references in the notes that lead to the single definition
selection.=20

IMO this helps to clarify when a term is overloaded in other standards
etc and indicate how we picked the single definition. For example Energy
Management System (EnMS) has an alternate meanings in ISO or other
standards.  So the reader of this draft could be familiar with a term
from another standard and want to know how this compares to the way the
term is used in EMAN. I don't want to lose information or a reference by
cherry picking a term.

I would envision an author of a spec to just use the definition from my
draft and need not include the Notes. The notes, examples etc are for
use to make sense of the terms.

As a formatting example see any  Wiki or printed-pedia entry. There is a
definition or explanation then a list of notes and references. If you
site the definition you don't include the notes from the entry.

Jp


-----Original Message-----
From: Benoit Claise (bclaise)=20
Sent: Thursday, December 08, 2011 7:44 AM
To: John Parello (jparello)
Cc: eman@ietf.org
Subject: Re: [eman] New Draft draft-parello-eman-definitions-04.txt

Hi John,

> HI,
>
> I've updated the draft. I sent a few previous emails on specific
points.
> In general.
>
> 1) As per consensus at IETF-82, picked one definition per term. Any=20
> other definitions form other standards I placed in the notes as=20
> reference.
Does it make sense to have the second definitions as a note?
As a reader, I'm asking myself:
     - why do we have a second definition?
     - how is the second different?
     - etc...

I could make sense to give a second reference, part of an explanation in
one of the draft.
However, I think it's confusing to have a second definition in the note?

Regards, Benoit (as a contributor)
>
> 2) Put in power state definition. Went with modified IEEE and put the=20
> wording from the list in the notes.
>
> 3) Made a more concise parent/child definition form feedback
>
> 4) other minor edits from review.
>
> Thanks everyone!
>
> Jp
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>
>


From moulchan@cisco.com  Mon Dec 12 02:24:09 2011
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 6E02021F8AFE for ; Mon, 12 Dec 2011 02:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 szETC+ycE4UW for ; Mon, 12 Dec 2011 02:24:08 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C7EDC21F8AF4 for ; Mon, 12 Dec 2011 02:24:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=3273; q=dns/txt; s=iport; t=1323685448; x=1324895048; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=JikAab6/nMM4Qzxcxoyvo8o0mPIdiVy55Kd76iqR8hY=; b=VnJg3eNYeAtrhp2AsOEVKa+W33uCgbUdbsbEaOG2IEb7f0Q1/XcXfF2j CDHSEX9wKlwJm4Ta2LJtJYh1mRMEJL1qa54hZ13OusFosKiU0Jq1lh3t7 Q5SsTqRpDoYc+uFBwA1Fc+qsEkjAYFN+P/qz81LNZ5UPO6nifxWIbCjuU 8=;
X-IronPort-AV: E=Sophos;i="4.71,337,1320624000"; d="scan'208";a="43119904"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 12 Dec 2011 10:24:08 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pBCAO8T8008487;  Mon, 12 Dec 2011 10:24:08 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, 12 Dec 2011 04:24:08 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Date: Mon, 12 Dec 2011 04:24:05 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Minutes(11/16) for Eman-Mib
Thread-Index: Acy1UFn0dsRr7644R4CRNkogKmgUKQDTnuhA
References: 
From: "Mouli Chandramouli (moulchan)" 
To: , "Benoit Claise (bclaise)" 
X-OriginalArrivalTime: 12 Dec 2011 10:24:08.0382 (UTC) FILETIME=[2EB21DE0:01CCB8B8]
Cc: hideo.kodaka@itg.hitachi.co.jp, eman@ietf.org
Subject: Re: [eman] Minutes(11/16) for Eman-Mib
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, 12 Dec 2011 10:24:09 -0000

Hello,

As I had mentioned in conversation, it would be useful to understand the use case for the simultaneous measurement of total and period together. 

   EoEnergyParametersEntry ::= SEQUENCE {
                eoEnergyParametersIntervalLength     TimeInterval,
                eoEnergyParametersIntervalNumber     Integer32,
                eoEnergyParametersIntervalMode       Integer32,
                eoEnergyParametersIntervalWindow     TimeInterval,
                eoEnergyParametersSampleRate         Integer32,
                eoEnergyParametersStatus             RowStatus
        }


The parameters table - specifies the parameters for Energy measurement  - length of the interval,  number of intervals, offset for window, sampling rate etc. 

But, for total energy measurement, some of the other parameters need not even be specified; interval length, number of intervals, offset, etc. 
So, it may not be useful to add another index to the parameters table I think. 

Whereas, based on the parameters,  Energy measurement is reported eoEnergyTable -  eoEnergyIntervalEnergyConsumed, eoEnergyIntervalEnergyProduced. 
Which reports the energy consumed in that specified interval. 

It may be possible to add a couple of more objects to report the total energy consumed, total energy produced - in addition  to the energy consumed or produced in a given interval. 

Thanks
Mouli

-----Original Message-----
From: hiroto.ogaki@alaxala.com [mailto:hiroto.ogaki@alaxala.com] 
Sent: Thursday, December 08, 2011 7:53 AM
To: Benoit Claise (bclaise); Mouli Chandramouli (moulchan)
Cc: hiroto.ogaki@alaxala.com; eman@ietf.org; Minoru.Teraoka@jp.yokogawa.com; hideo.kodaka@itg.hitachi.co.jp
Subject: Re:Minutes(11/16) for Eman-Mib

Hi, all

There is a thing I confrim.

>2.
>  Discussed the additional index of eoEnergyParametersEntry.

We agreed to using period(1) and total(3) at the same time.
Therefore, eoEnergyTable has multiple entries that are the same eoPowerIndex
and different eoEnergyParametersIntervalMode.
But, now, eoEnergyParametersEntry can't be distinguished between periodical and total.

following is an example.

    eoEnergyParametersIntervalLength.xx = 800 <- periodical or total??
    eoEnergyParametersIntervalNumber.xx =  20 <- periodical or total??
    (xx indicates eoPowerIndex)

So, I need to have another index as such.

OLD$B!'(J
         eoEnergyParametersEntry OBJECT-TYPE
             SYNTAX          EoEnergyParametersEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "An entry controls an energy measurement in
                eoEnergyTable."
             INDEX  { eoPowerIndex }

NEW$B!'(J

         eoEnergyParametersEntry OBJECT-TYPE
             SYNTAX          EoEnergyParametersEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "An entry controls an energy measurement in
                eoEnergyTable."
             INDEX  { eoPowerIndex, eoEnergyParametersIntervalMode }
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is my understanding correct?

Regards,
Hiroto



From moulchan@cisco.com  Mon Dec 12 05:48:20 2011
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 8479721F847C for ; Mon, 12 Dec 2011 05:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Z3eEy4URWAOJ for ; Mon, 12 Dec 2011 05:48:19 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 965E321F8450 for ; Mon, 12 Dec 2011 05:48:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=7125; q=dns/txt; s=iport; t=1323697699; x=1324907299; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=axzhMbqxFfb9FX99NEPzp7UeAk1sMMqez3HmqOGODpU=; b=cNuyUeTLjDBf9CgbOljoia7Rc+sMdzuRTYhoEsXBzosrrCSCFwJiy0Nb Z/qTHxNAxsLRPuVrWSFCNH41sPXfmHnSR+IlJusmh/vJ36LpssfCZoZ7Q ZoepL/kX2NV8sjjZzXNlS/XicGOIONGXh4Y0dHJEp49iUqtgeEmaZoNZa I=;
X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; d="scan'208";a="43179146"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 12 Dec 2011 13:48:18 +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 pBCDmIE1008760;  Mon, 12 Dec 2011 13:48:18 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, 12 Dec 2011 07:48:18 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Date: Mon, 12 Dec 2011 07:48:14 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re[3]: Feedback regarding the EMAN monitoring
Thread-Index: Acy1UyvvJUuFPEdZTDuamjoW2MfplADfzfdQ
References: 
From: "Mouli Chandramouli (moulchan)" 
To: , "Benoit Claise (bclaise)" 
X-OriginalArrivalTime: 12 Dec 2011 13:48:18.0040 (UTC) FILETIME=[B40F9780:01CCB8D4]
Cc: hideo.kodaka@itg.hitachi.co.jp, eman@ietf.org
Subject: Re: [eman] Feedback regarding the EMAN monitoring
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, 12 Dec 2011 13:48:20 -0000

Hello,

Regarding your question on Maximum -  
A maximum can occur at any window and that max value is stored (and compared with the current measurement - almost like quicksort. 
The maximum value shall be reset when the Energy Object or the NMS is rebooted. The first value is the maximum 

eoEnergyIntervalMaxConsumed OBJECT-TYPE
            SYNTAX          Integer32
            UNITS           "Watt-hours"
            MAX-ACCESS      read-only
            STATUS          current
            DESCRIPTION
               "This object is the maximum energy ever observed in
               eoEnergyIntervalEnergyConsumed since the monitoring
               started. This value is specified in the common billing
               units of watt-hours with the magnitude of watt-hours (kW-
               Hr,   MW-Hr, etc.) indicated separately in
               eoEnergyIntervalEnergyUnits."
            ::= { eoEnergyIntervalEntry 7  }


The important word is "maximum since monitoring started".

I think it would be easier if you would consider the following example.   

Thanks
Mouli


        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     300     |      300
       --------------------------------------------------------
                                  $B"-(J
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     300     |      300
              100     |      S2     |     340     |      340
       --------------------------------------------------------
                                  $B"-(J
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     300     |      300
              100     |      S2     |     340     |      340
              100     |      S3     |     340     |      320
       --------------------------------------------------------
                                  $B"-(J
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S2     |     340     |      340
              100     |      S3     |     340     |      320
              100     |      S4     |     360     |      360
                                       $B"-(J
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S3     |     340     |      320
              100     |      S4     |     360     |      360
              100     |      S5     |     360     |      300

                                       $B"-(J
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S4     |     360     |      360
              100     |      S5     |     360     |      300
              100     |      S6     |     380     |      380


-----Original Message-----
From: hiroto.ogaki@alaxala.com [mailto:hiroto.ogaki@alaxala.com] 
Sent: Thursday, December 08, 2011 8:13 AM
To: Benoit Claise (bclaise); Mouli Chandramouli (moulchan)
Cc: eman@ietf.org; Minoru.Teraoka@jp.yokogawa.com; hideo.kodaka@itg.hitachi.co.jp
Subject: Re[3]: Feedback regarding the EMAN monitoring

Hi, all

>Though you agreed on my figure indicated how to update the two maxima,
>I've another idea.
>I'll send details of my idea later on. 

Another idea is the following.
Which figures are correct?
 or  ?
Difference between those figures is keeing maxim or not.
#refer my previous email about 


        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     390     |      390
       --------------------------------------------------------
                                  $B"-(J
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     390     |      390
              100     |      S2     |     390     |      380
       --------------------------------------------------------
                                  $B"-(J
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     390     |      390
              100     |      S2     |     390     |      380
              100     |      S3     |     420     |      420
       --------------------------------------------------------
                                  $B"-(J
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S2     |     390     |      380
              100     |      S3     |     420     |      420
              100     |      S4     |     490     |      490
       --------------------------------------------------------
         The oldest measurement were not to be the maximum eoEnergyIntervalMaxConsumed.



        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     490     |      490
       --------------------------------------------------------
                                  $B"-(J
        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      S2     |     490     |      380
       --------------------------------------------------------
                                  $B"-(J
        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      S2     |     490     |      380
              100     |      S3     |     490     |      420
       --------------------------------------------------------
                                  $B"-(J
        pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S1     |     490     |      490
              100     |      S3     |     490     |      420
              100     |      S4     |     490     |      390
       --------------------------------------------------------
        The oldest measurement were to be the maximum eoEnergyIntervalMaxConsumed.

 Best regards,
 Hiroto



From j.schoenwaelder@jacobs-university.de  Mon Dec 12 06:04:14 2011
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 445F821F8B06 for ; Mon, 12 Dec 2011 06:04:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.131
X-Spam-Level: 
X-Spam-Status: No, score=-103.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 bgyhRw+3AZ4Q for ; Mon, 12 Dec 2011 06:04:13 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 87E0021F8B04 for ; Mon, 12 Dec 2011 06:04:13 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5653D20D26; Mon, 12 Dec 2011 15:04:12 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5RW9tMzbXcEc; Mon, 12 Dec 2011 15:04:11 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E00FC20D04; Mon, 12 Dec 2011 15:04:10 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id A93951C0FECA; Mon, 12 Dec 2011 15:03:52 +0100 (CET)
Date: Mon, 12 Dec 2011 15:03:52 +0100
From: Juergen Schoenwaelder 
To: "Mouli Chandramouli (moulchan)" 
Message-ID: <20111212140352.GB300@elstar.local>
Mail-Followup-To: "Mouli Chandramouli (moulchan)" , hiroto.ogaki@alaxala.com, "Benoit Claise (bclaise)" , hideo.kodaka@itg.hitachi.co.jp, eman@ietf.org
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: eman@ietf.org, hideo.kodaka@itg.hitachi.co.jp
Subject: Re: [eman] Feedback regarding the EMAN monitoring
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Discussions about the Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Dec 2011 14:04:14 -0000

On Mon, Dec 12, 2011 at 07:48:14AM -0600, Mouli Chandramouli (moulchan) wrote:

> The maximum value shall be reset when the Energy Object or the NMS
> is rebooted. The first value is the maximum

You assume a single NMS? This is usually not what we do in SNMP land.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From Minoru.Teraoka@jp.yokogawa.com  Mon Dec 12 21:56:27 2011
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 7EDF521F853B for ; Mon, 12 Dec 2011 21:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.276
X-Spam-Level: *
X-Spam-Status: No, score=1.276 tagged_above=-999 required=5 tests=[AWL=0.372,  BAYES_00=-2.599, 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 sGFsv8vHP4ax for ; Mon, 12 Dec 2011 21:56:26 -0800 (PST)
Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by ietfa.amsl.com (Postfix) with ESMTP id 730B121F8531 for ; Mon, 12 Dec 2011 21:56:25 -0800 (PST)
Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id pBD5uLCE000861; Tue, 13 Dec 2011 14:56:21 +0900 (JST)
Received: from zex001-0m9026.jp.ykgw.net (zex001-0m9026.jp.ykgw.net [10.0.11.15]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id pBD5uLeB000858; Tue, 13 Dec 2011 14:56:21 +0900 (JST)
Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9026.jp.ykgw.net ([10.0.11.15]) with mapi; Tue, 13 Dec 2011 14:56:21 +0900
From: 
To: 
Date: Tue, 13 Dec 2011 14:56:17 +0900
Thread-Topic: Re[3]: Feedback regarding the EMAN monitoring
Thread-Index: Acy1UyvvJUuFPEdZTDuamjoW2MfplADfzfdQACJWIBA=
Message-ID: <92A5C8A0221B31479EB7913C528ACC590171C0ECDB69@EXMAIL01.jp.ykgw.net>
References:  
In-Reply-To: 
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="iso-2022-jp"
MIME-Version: 1.0
Cc: eman@ietf.org
Subject: Re: [eman] Feedback regarding the EMAN monitoring
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: Tue, 13 Dec 2011 05:56:27 -0000

Hi Mouli,

I would like to know which is right understanding of how to handle S6.

case#1
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S6     |     380     |      380
              100     |      S7     |     380     |      300
              100     |      S8     |     380     |      300
                                       $B"-(B
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S7     |     380     |      300    <--- ***
              100     |      S8     |     380     |      300
              100     |      S9     |     380     |      300

case#2
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S6     |     380     |      380
              100     |      S7     |     380     |      300
              100     |      S8     |     380     |      300
                                       $B"-(B
        eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
       --------------------------------------------------------
              100     |      S6     |     380     |      380    <--- ***
              100     |      S8     |     380     |      300
              100     |      S9     |     380     |      300



        eoEnergyParametersIntervalNumber OBJECT-TYPE
            SYNTAX          Integer32
            MAX-ACCESS      read-create
            STATUS          current
            DESCRIPTION
               "The number of intervals maintained in the eoEnergyTable.
               Each interval is characterized by a specific
               eoEnergyIntervalStartTime, used as an index to the table
               eoEnergyTable . Whenever the maximum number of entries is
               reached, the measurement over the new interval replaces
               the oldest measurement , except if the oldest measurement
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
               were to be the maximum eoEnergyIntervalMax, in which case
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
               the measurement the measurement over the next oldest
               interval is replaced."
             DEFVAL { 10 }

Do we need to distinguish between consuming and producing?
If yes, EnergyTable may have two maximum entries.

Best regards,
Minoru


--
Minoru Teraoka
Yokogawa Electric Corporation


> -----Original Message-----
> From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com]
> Sent: Monday, December 12, 2011 10:48 PM
> To: hiroto.ogaki@alaxala.com; Benoit Claise (bclaise)
> Cc: eman@ietf.org; Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com);
> hideo.kodaka@itg.hitachi.co.jp
> Subject: RE: Re[3]: Feedback regarding the EMAN monitoring
> 
> Hello,
> 
> Regarding your question on Maximum -
> A maximum can occur at any window and that max value is stored (and compared
> with the current measurement - almost like quicksort.
> The maximum value shall be reset when the Energy Object or the NMS is rebooted.
> The first value is the maximum
> 
> eoEnergyIntervalMaxConsumed OBJECT-TYPE
>             SYNTAX          Integer32
>             UNITS           "Watt-hours"
>             MAX-ACCESS      read-only
>             STATUS          current
>             DESCRIPTION
>                "This object is the maximum energy ever observed in
>                eoEnergyIntervalEnergyConsumed since the monitoring
>                started. This value is specified in the common billing
>                units of watt-hours with the magnitude of watt-hours (kW-
>                Hr,   MW-Hr, etc.) indicated separately in
>                eoEnergyIntervalEnergyUnits."
>             ::= { eoEnergyIntervalEntry 7  }
> 
> 
> The important word is "maximum since monitoring started".
> 
> I think it would be easier if you would consider the following example.
> 
> Thanks
> Mouli
> 
> 
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     300     |      300
>        --------------------------------------------------------
>                                   $B"-(B
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     300     |      300
>               100     |      S2     |     340     |      340
>        --------------------------------------------------------
>                                   $B"-(B
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     300     |      300
>               100     |      S2     |     340     |      340
>               100     |      S3     |     340     |      320
>        --------------------------------------------------------
>                                   $B"-(B
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S2     |     340     |      340
>               100     |      S3     |     340     |      320
>               100     |      S4     |     360     |      360
>                                        $B"-(B
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S3     |     340     |      320
>               100     |      S4     |     360     |      360
>               100     |      S5     |     360     |      300
> 
>                                        $B"-(B
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S4     |     360     |      360
>               100     |      S5     |     360     |      300
>               100     |      S6     |     380     |      380
> 
> 
> -----Original Message-----
> From: hiroto.ogaki@alaxala.com [mailto:hiroto.ogaki@alaxala.com]
> Sent: Thursday, December 08, 2011 8:13 AM
> To: Benoit Claise (bclaise); Mouli Chandramouli (moulchan)
> Cc: eman@ietf.org; Minoru.Teraoka@jp.yokogawa.com;
> hideo.kodaka@itg.hitachi.co.jp
> Subject: Re[3]: Feedback regarding the EMAN monitoring
> 
> Hi, all
> 
> >Though you agreed on my figure indicated how to update the two maxima,
> >I've another idea.
> >I'll send details of my idea later on.
> 
> Another idea is the following.
> Which figures are correct?
>  or  ?
> Difference between those figures is keeing maxim or not.
> #refer my previous email about 
> 
> 
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     390     |      390
>        --------------------------------------------------------
>                                   $B"-(B
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     390     |      390
>               100     |      S2     |     390     |      380
>        --------------------------------------------------------
>                                   $B"-(B
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     390     |      390
>               100     |      S2     |     390     |      380
>               100     |      S3     |     420     |      420
>        --------------------------------------------------------
>                                   $B"-(B
>         eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S2     |     390     |      380
>               100     |      S3     |     420     |      420
>               100     |      S4     |     490     |      490
>        --------------------------------------------------------
>          The oldest measurement were not to be the maximum
> eoEnergyIntervalMaxConsumed.
> 
> 
> 
>         pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     490     |      490
>        --------------------------------------------------------
>                                   $B"-(B
>         pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     490     |      490
>               100     |      S2     |     490     |      380
>        --------------------------------------------------------
>                                   $B"-(B
>         pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     490     |      490
>               100     |      S2     |     490     |      380
>               100     |      S3     |     490     |      420
>        --------------------------------------------------------
>                                   $B"-(B
>         pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>        --------------------------------------------------------
>               100     |      S1     |     490     |      490
>               100     |      S3     |     490     |      420
>               100     |      S4     |     490     |      390
>        --------------------------------------------------------
>         The oldest measurement were to be the maximum
> eoEnergyIntervalMaxConsumed.
> 
>  Best regards,
>  Hiroto
> 


From bnordman@lbl.gov  Wed Dec 14 00:24:40 2011
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 0170D21F87C5 for ; Wed, 14 Dec 2011 00:24:40 -0800 (PST)
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 6ihy8lyA2wZx for ; Wed, 14 Dec 2011 00:24:39 -0800 (PST)
Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4775D21F8783 for ; Wed, 14 Dec 2011 00:24:39 -0800 (PST)
X-Ironport-SBRS: 3.8
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkgBAAhd6E7RVdI0imdsb2JhbABAA4JNmFIBh2YBiBgIIgEBAQoJDQcSBiGCCwKBBAddEgEFASITCBMHnmqCXAqdE4hqgx8EiDKMQo10PYQZ
X-IronPort-AV: E=Sophos;i="4.71,350,1320652800"; d="scan'208";a="60138233"
Received: from mail-pz0-f52.google.com ([209.85.210.52]) by ironport3.lbl.gov with ESMTP; 14 Dec 2011 00:24:23 -0800
Received: by dadp15 with SMTP id p15so611991dad.39 for ; Wed, 14 Dec 2011 00:24:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.191.103 with SMTP id gx7mr2121681pbc.126.1323851061395; Wed, 14 Dec 2011 00:24:21 -0800 (PST)
Received: by 10.142.245.19 with HTTP; Wed, 14 Dec 2011 00:24:21 -0800 (PST)
Date: Wed, 14 Dec 2011 00:24:21 -0800
Message-ID: 
From: Bruce Nordman 
To: eman mailing list 
Content-Type: multipart/alternative; boundary=e89a8ff1c38a4000f404b409180e
Subject: [eman] Converging the Reference Model into the Framework
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, 14 Dec 2011 08:24:40 -0000

--e89a8ff1c38a4000f404b409180e
Content-Type: text/plain; charset=ISO-8859-1

Over the last year, the distance between the Reference Model and the
corresponding
parts of the Framework has been reduced.  Further progress in this
direction seems
desirable and I think could arrive at a point of general consensus.

One suggestion was to merge Section 2 of the Reference Model into the
Framework
as explanatory material.  This section only describes the problems at hand,
not the
solutions, so that doing this would seem to be easy.

A second possibility is to merge the energy object and interface concepts.
In the Framework, everything is an energy object, but in the Reference
Model,
there are devices, components, and interfaces with distinct properties.
We could use the unified energy object frame while still recognizing some
distinct characteristics (only devices have interfaces, components do not
have interfaces, and interfaces consume no power themselves).  This could
accomplish the goal of both approaches.

The above would not resolve all differences, but it might well be most of
them.  I think that a draft which implemented the above, when read by us
all, would be compelling in being a step forward or not (I think it would be
a step forward).

Comments?

--Bruce (as contributor)

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--e89a8ff1c38a4000f404b409180e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Over the last year, the distance between the Reference Model and the corres=
ponding
parts of the Framework has been reduced.=A0 Further progress in =
this direction seems
desirable and I think could arrive at a point of ge=
neral consensus.


One suggestion was to merge Section 2 of the Reference Model into the F=
ramework
as explanatory material.=A0 This section only describes the pro=
blems at hand, not the
solutions, so that doing this would seem to be ea=
sy.


A second possibility is to merge the energy object and interface concep=
ts.
In the Framework, everything is an energy object, but in the Referen=
ce Model,
there are devices, components, and interfaces with distinct pr=
operties.

We could use the unified energy object frame while still recognizing some <=
br>distinct characteristics (only devices have interfaces, components do no=
t
have interfaces, and interfaces consume no power themselves).=A0 This =
could 

accomplish the goal of both approaches.

The above would not resolve =
all differences, but it might well be most of
them.=A0 I think that a dr=
aft which implemented the above, when read by us
all, would be compellin=
g in being a step forward or not (I think it would be

a step forward).

Comments?

--Bruce (as contributor)

-- 
Bruce Nordman
Lawrence Berkeley National Laboratoryeetd.lbl.gov/=
ea/nordman

BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--e89a8ff1c38a4000f404b409180e--

From moulchan@cisco.com  Wed Dec 14 00:54:30 2011
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 5104121F86A6 for ; Wed, 14 Dec 2011 00:54:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 kGsYb0wtbLXc for ; Wed, 14 Dec 2011 00:54:29 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 626A921F86A1 for ; Wed, 14 Dec 2011 00:54:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=6395; q=dns/txt; s=iport; t=1323852869; x=1325062469; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=r23kwEYlofRN0Lt4aAl5pcRiQIznkEcb/Z1NVaWTErI=; b=HM5wewKM/IVZMyp5D8H5SuM05ZRpuXi68loeJR+GPvTU6V4JdzLqO2/x 5thPN8A3NbKo2PuaC/mj/bhv/2LIZGPZccEVpsX7JA5cezt0kMUq3EEyF Oz9CEsiQfcwPQ/AV0SckKBGtAJ21GAAIjQjj71OjHxa+7LhM5NT+32WRt 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArMAAB9j6E6tJV2Y/2dsb2JhbABAA4JNmBGIKAGIIIEFgXIBAQEEEgEJEQM+GwIBCA4DBAEBCwYXAQYBRQkIAQEEARIIEweHYJg9AZ5ViGqCPGMEiDKfCg
X-IronPort-AV: E=Sophos;i="4.71,350,1320624000"; d="scan'208,217";a="43803151"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 14 Dec 2011 08:54:29 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBE8sSq8001111;  Wed, 14 Dec 2011 08:54:28 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 14 Dec 2011 02:54:28 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBA3D.FCD08D99"
Date: Wed, 14 Dec 2011 02:54:26 -0600
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] Converging the Reference Model into the Framework
Thread-Index: Acy6OdUnaTHktVmsQxCLYJc2cZkBiAAA1kyw
References: 
From: "Mouli Chandramouli (moulchan)" 
To: "Bruce Nordman" , "eman mailing list" 
X-OriginalArrivalTime: 14 Dec 2011 08:54:28.0712 (UTC) FILETIME=[FCFD1E80:01CCBA3D]
Subject: Re: [eman] Converging the Reference Model into the Framework
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, 14 Dec 2011 08:54:30 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCBA3D.FCD08D99
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bruce,

=20

I thought Section 1.2 of requirements draft
http://tools.ietf.org/html/draft-ietf-eman-requirements-05

=20

lists the important considerations for Energy Management   and based on
those considerations some requirements have been specified. =20

=20

Not sure if a similar set of considerations need to be replicated in
Framework draft.=20

=20

Thanks

Mouli

=20

=20

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Bruce Nordman
Sent: Wednesday, December 14, 2011 1:54 PM
To: eman mailing list
Subject: [eman] Converging the Reference Model into the Framework


One suggestion was to merge Section 2 of the Reference Model into the
Framework
as explanatory material.  This section only describes the problems at
hand, not the
solutions, so that doing this would seem to be easy.
Comments?

--Bruce (as contributor)

--=20
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943


------_=_NextPart_001_01CCBA3D.FCD08D99
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Bruce,



 



I thought Section 1.2 of requirements draft =
  http:=
//tools.ietf.org/html/draft-ietf-eman-requirements-05



 



lists the important considerations for Energy Management =
  and
based on those considerations some requirements have been specified. =
 



 



Not sure if a similar set of considerations need to be =
replicated
in Framework draft. 



 



Thanks



Mouli



 



 






From:=

eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of =
Bruce
Nordman

Sent: Wednesday, December 14, 2011 1:54 PM

To: eman mailing list

Subject: [eman] Converging the Reference Model into the =
Framework








One suggestion was to merge Section 2 of the Reference Model into the =
Framework

as explanatory material.  This section only describes the problems =
at
hand, not the

solutions, so that doing this would seem to be easy.

Comments?



--Bruce (as contributor)



-- 

Bruce Nordman

Lawrence Berkeley National =
Laboratory

eetd.lbl.gov/ea/nordman

BNordman@LBL.gov

510-486-7089

m: 510-501-7943









------_=_NextPart_001_01CCBA3D.FCD08D99--

From bclaise@cisco.com  Mon Dec 19 06:31:15 2011
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 4301921F8B89 for ; Mon, 19 Dec 2011 06:31:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.664
X-Spam-Level: 
X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=-1.314, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_URI_REFID1=0.648]
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 O7wuWGZox7TD for ; Mon, 19 Dec 2011 06:31:07 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E227B21F8B7D for ; Mon, 19 Dec 2011 06:31:05 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBJEV27X025657; Mon, 19 Dec 2011 15:31:02 +0100 (CET)
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBJEV03F013784; Mon, 19 Dec 2011 15:31:00 +0100 (CET)
Message-ID: <4EEF4AA4.3090104@cisco.com>
Date: Mon, 19 Dec 2011 15:31:00 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Brad Schoening 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070709070509000404070408"
Cc: "eman@ietf.org" 
Subject: Re: [eman] draft-tychon-eman-applicability-statement-05: review
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, 19 Dec 2011 14:31:15 -0000

This is a multi-part message in MIME format.
--------------070709070509000404070408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Brad,
> Benoit,
>
>
> A few comments on some of the larger points in your applicability
> statement review comments from last month...
>
> 1)      bclaise:  "Zigbee Smart Energy 2.0 is based on IP, right? This should
> be stressed."
>
> Zigbee 1.x is not based upon IP. But Zigbee 2.0, if adopted, is designed
> to interoperate with IP, but is still a draft at this point.  I think our
> applicability statement should probably focus on Zigbee 1.x which has seen
> wide deployment, with market forecasts for 36M Zigbee devices in 2011
> (source: On Research).
Don't you want to say a few words about Zigbee 2.0 anyway, as work in 
progress?

>
>
> 2)      bclaise:  "power caping is something that could be done in a management
> app using the EMAN Mib.  E.g., when polling for current usage, if this crosses a powercap use EMAN Mib to set the power state to a lower level."
>
> The more conventional use case seems to define the power cap on a device,
> and have that device enforce the power cap.  This seems to have derived
> from an HP product feature (Dynamic Power Capping - DPC) that has seen
> only limited adoption to date by other
> vendors.  The use of the term is almost always 'dynamic power capping',
> implying its autonomous.  EMAN could be used to set the power caps
> (although we lack an attribute for this at present), or monitor
> conformance with a power capping policy.  On the other hand, its biggest
> use case to-date is as an HP vendor proprietary feature.
>
> The use of power caping is also at variance with with ACPI and Intel's
> experience with CPU dynamic frequency and voltage scaling (DFVS).  Their
> experience show that "race to halt" was usually a more effective power
> management strategy than simply reducing the CPU frequency to reduce power
> usage.
>
> When the goal is to minimize energy consumption, capping power might not
> be the optional solution.[1]
>
>          1. http://www.ok-labs.com/_assets/ATC-161Paper_McCammon.pdf
Understood.
When I read section 2.15 "power capping", I'm wondering, as a reader, 
what is the link with EMAN.
This is what I was trying to clarify. I stand corrected with your 
explanation. However, the initial concern remains: please explain the 
link with EMAN, even if this case a statement such as "not covered by 
the current EMAN architecture" would be good enough.
>
>
> 3)      bclaise:  Question: what is the relationship with EMAN. If none,
> mentions it along with a list of pros/cons. I mean: why should an implementator chose EMAN versus DASH?
>
> DASH is a Web management (webem) protocol.  There should be no confusion
> that EMAN/SNMP and DASH/HTTP are entirely different protocols.  What we
> can stress is that while the protocols are incompatible, the EMAN data
> model can be aligned, where appropriate, with the DASH model.  Afterall,
> DASH has been itself been aligned with the prior power management standard
> ACPI.
>
> So, I propose adding something like:
>
>          "While the SNMP and WebEM communication protocols are incompatible, the
> EMAN data model should be aligned whenever possible, with the DASH model"
Well, this is an applicability statement, not a requirement draft, or an 
architecture.
So you have to explain the relationship, if any, between EMAN and DASH.
Some text around what you explained is more appropriate:

    DASH is a Web management (webem) protocol.  There should be no confusion
    that EMAN/SNMP and DASH/HTTP are entirely different protocols.  What we
    can stress is that while the protocols are incompatible, the EMAN data
    model can be aligned, where appropriate, with the DASH model.  Afterall,
    DASH has been itself been aligned with the prior power management standard
    ACPI.

Regards, Benoit (as a contributor)
>
>
> Regards,
>
>
>
> Brad Schoening
>
>>
>> -----Original Message-----
>> From: Benoit Claise (bclaise)
>> Sent: Saturday, November 12, 2011 8:25 PM
>> To: eman mailing list; Emmanuel Tychon (etychon); Mouli Chandramouli
>> (moulchan); Bruce Nordman; Brad Schoening
>> Subject: draft-tychon-eman-applicability-statement-05: review
>>
>> Dear authors,
>>
>> Thanks for producing this new version. Much appreciated.
>> I specifically like the structure you put in place with "target
>> devices", "how powered", "reporting"
>> See inline for some more comments.
>>
>> Regards, Benoit (as a contributor)
>>>        Energy Management Working Group                          E.
>> Tychon
>>>       Internet Draft                                  Cisco Systems
>> Inc.
>>>       Intended status: Informational                        B.
>> Schoening
>>>       Expires: April 31, 2012                     Independent
>> Consultant
>>>                                                       Mouli
>> Chandramouli
>>>                                                       Cisco Systems
>> Inc.
>>>                                                            Bruce
>> Nordman
>>>                                    Lawrence Berkeley National
>> Laboratory
>>>                                                         October 31,
>> 2011
>>>
>>>
>>>
>>>                  Energy Management (EMAN) Applicability Statement
>>>                    draft-tychon-eman-applicability-statement-05
>>>
>>>
>>>       Status of this Memo
>>>
>>>          This Internet-Draft is submitted to IETF in full conformance
>>>          with the provisions of BCP 78 and BCP 79.
>>>
>>>          Internet-Drafts are working documents of the Internet
>>>          Engineering Task Force (IETF), its areas, and its working
>>>          groups.  Note that other groups may also distribute working
>>>          documents as Internet-Drafts.
>>>
>>>          Internet-Drafts are draft documents valid for a maximum of six
>>>          months and may be updated, replaced, or obsoleted by other
>>>          documents at any time. It is inappropriate to use Internet-
>>>          Drafts as reference material or to cite them other than as
>> "work
>>>          in progress."
>>>
>>>          The list of current Internet-Drafts can be accessed at
>>>          http://www.ietf.org/ietf/1id-abstracts.txt
>>>
>>>          The list of Internet-Draft Shadow Directories can be accessed
>> at
>>>          http://www.ietf.org/shadow.html
>>>
>>>          This Internet-Draft will expire on April 31, 2012.
>>>
>>>
>>>       Copyright Notice
>>>
>>>          Copyright (c) 2011 IETF Trust and the persons identified as
>> the
>>>          document authors. All rights reserved.
>>>
>>>
>>>
>>>
>>>
>>>
>>                Expires April 31, 2012       [Page 1]
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          This document is subject to BCP 78 and the IETF Trust's Legal
>>>          Provisions Relating to IETF Documents
>>>          (http://trustee.ietf.org/license-info) in effect on the date
>> of
>>>          publication of this document. Please review these documents
>>>          carefully, as they describe your rights and restrictions with
>>>          respect to this document. Code Components extracted from this
>>>          document must include Simplified BSD License text as described
>>>          in Section 4.e of the Trust Legal Provisions and are provided
>>>          without warranty as described in the Simplified BSD License.
>>>
>>>
>>>       Abstract
>>>
>>>          The objective of Energy Management (EMAN)is to provide an
>> energy
>>>          management framework for networked devices. This document
>>>          presents the applicability of the EMAN framework for a variety
>>>          of scenarios. This document lists use cases and target devices
>>>          that can potentially implement the EMAN framework and
>> associated
>>>          SNMP MIB modules. These use cases are useful for identifying
>>>          monitoring requirements that need to be considered. Further,
>> we
>>>          describe the relationship of the EMAN framework to relevant
>>>          other energy monitoring standards and architectures.
>>>
>>>
>>>       Table of Contents
>>>
>>>        1. Introduction
>> ................................................3
>>>          1.1. Energy Management Overview
>>> ..............................4
>>>          1.2. Energy Measurement
>>> ......................................5
>>>          1.3. Energy Management
>>> .......................................5
>>>          1.4. EMAN Framework Application
>>> ..............................6
>>>          1.5. EMAN WG Document Overview
>>> ...............................6
>>>        2. Scenarios and Target Devices
>>> ................................7
>>>          2.1. Network Infrastructure Energy Objects
>>> ...................7
>>>          2.2. Devices Powered and Connected to a Network Device
>>> .......8
>>>          2.3. Devices Connected to a Network
>>> ..........................9
>>>          2.4. Power Meters
>>> ............................................9
>>>          2.5. Mid-level Managers
>>> .....................................10
>>>          2.6. Gateways to Building Systems
>>> ...........................11
>>>          2.7. Home Energy Gateways
>>> ...................................12
>>>          2.8. Data Center Devices
>>> ....................................13
>>>
>>         2.9. Energy Storage Devices ................................14
>>>          2.10. Ganged Outlets on a PDU Multiple Power Sources
>> ........14
>>>          2.11. Industrial Automation Networks
>>>    ......................15
>>>          2.12. Printers
>>>             ...................................15
>>>          2.13. Off-Grid Devices
>>> ......................................17
>>>          2.14. Demand/Response
>>>    .....................................17
>>>
>>>
>>>               Expires April 31, 2012        [Page 2]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          2.15. Power Capping
>>>    ........................................18
>>>        3. Use Case Patterns
>>>   ..........................................18
>>>          3.1. Metering
>>>   ...............................................18
>>>          3.2. Metering and Control
>>>   ...................................19
>>>          3.3. Power Supply, Metering and Control
>>>   .....................19
>>>          3.4. Multiple power sources
>>>   .................................19
>>>        4. Relationship of EMAN to other Standards
>>>   ....................19
>>>          4.1. Data Model and Reporting
>>>   ...............................20
>>>                4.1.1. IEC - CIM.
>> ......................................20
>>>                4.1.2. DMTF
>> ............................................20
>>>                4.1.3. ODVA
>> ............................................21
>>>                4.1.4. Ecma SDC
>> ........................................22
>>>                4.1.5. IEEE-ISTO Printer Working Group (PWG)
>> ...........22
>>>                4.1.6. ASHRAE
>> ..........................................23
>>>                4.1.7. ZigBee
>> ..........................................24
>>>          4.2. Measurement
>>>   ............................................24
>>>                4.2.1. ANSI C12
>> ........................................24
>>>                4.2.2. IEC62301
>> ........................................24
>>>          4.3. Other
>>>   ..................................................25
>>>                4.3.1. ISO
>> .............................................25
>>>                4.3.2. EnergyStar
>> ......................................26
>>>                4.3.3. SmartGrid
>> .......................................26
>>>        5. Limitations
>>>   ................................................27
>>>        6. Security Considerations
>>>   ....................................27
>>>        7. IANA Considerations
>>>   ........................................27
>>>        8. Acknowledgements
>>>   ...........................................27
>>>        9. Open Issues
>>>    ...............................................28
>>>        10. References
>>>   ................................................28
>>>          10.1. Normative References
>>>   ..................................28
>>>          10.2. Informative References
>>>   ................................29
>>>
>>>
>>>
>>>       1. Introduction
>>>
>>>          The focus of the Energy Management (EMAN) framework is energy
>>>          monitoring and management of energy objects [EMAN-DEF].  The
>>>          scope of devices considered are network equipment and its
>>>
>>         components, and devices connected directly or indirectly to
>>>          the network. The EMAN framework enables monitoring i.e.;
>>>          heterogeneous devices to report their energy consumption, and
>>>          secondly, if permissible, enables control policies for energy
>>>          savings.  There are multiple scenarios where this is
>>>          desirable, particularly considering the increased importance
>>>          of limiting consumption of finite energy resources and
>>>          reducing operational expenses.
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 3]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>          The EMAN framework describes how energy information can be
>> Introduce a reference.
>>>          retrieved from IP-enabled devices using Simple Network
>>>          Management Protocol (SNMP), specifically, Management
>> Information
>>>          Base (MIBs) for SNMP.
>>>
>>>          This document describes typical applications of the EMAN
>>>          framework, as well as its opportunities and limitations. Other
>>>          standards that are similar to EMAN but address different
>> domains
>>>          are described. This document contains references to those
>> other
>>>          standards and describes how they relate to the EMAN framework.
>>>
>>>       1.1. Energy Management Overview
>>>
>>>          First, a brief introduction to the definitions of Energy and
>>>          Power are presented. A draft on terminology has been submitted
>>>          so that to reach a consensus on the definitions of commonly
>> used
>>>          terms in the EMAN WG. While energy is available in many forms,
>>>          EMAN addresses only the electrical energy consumed by devices
>>>          connected to a network.
>>>
>>>          Energy is the capacity to perform work. Electrical energy is
>>>          typically expressed in kilowatt-hour units (kWh) or other
>>>          multiples of watt-hours (Wh). One kilowatt-hour is the
>>>          electrical energy used by a 1 kilowatt device for one hour.
>>>          Power is the rate of electrical energy flow. In other words,
>>>          power = energy / time. Power is often measured in watts.
>> Billing
>>>          is based on electrical energy (measured in kWh) supplied by
>> the
>>>          utility.
>>>
>>>          Towards the goal of increasing the energy efficiency in
>> networks
>>>          and buildings, a first step is to enable energy objects to
>>>          report their energy usage over time. The EMAN framework
>>>          addresses this problem with an information model for some
>>>          electrical equipment: energy object identification, energy
>>>          object context, power measurement and power measurement
>>>          attributes.
>> and power quality (even if we need a consensus on the name)
>>>          The EMAN WG framework defines SNMP MIB modules based on the
>>>          information model.  By implementing the SNMP MIB modules, any
>>>          energy object can report its energy consumption according to
>> the
>>>          information model. In that context, it is important to
>>>          distinguish energy objects that can report their own energy
>>>          usage from parent devices that can also collect and aggregate
>>>          energy usage of children energy objects.
>>>
>>>          The list of target devices and scenarios considered for Energy
>>>          Management are presented in Section 2 with detailed examples.
>>>
>>>
>>>               Expires April 31, 2012        [Page 4]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>
>>>       1.2. Energy Measurement
>>>
>>>          More and more devices are able to measure and report their own
>>>          energy consumption. Smart power strips and some Power over
>>>          Ethernet (PoE) switches can meter consumption of connected
>>>          devices.  However, when managed and reported through
>> proprietary
>>>          means, this information is minimally useful at the enterprise
>>>          level.
>>>
>>>          The primary goal of the EMAN MIBs is to enable reporting and
>>>          management within a standard framework that is applicable to a
>>>          wide variety of end devices, meters, and proxies. This enables
>> a
>>>          management system to know who's consuming what, when, and how
>> at
>>>          any time by leveraging existing networks, across various
>>>          equipment, in a unified and consistent manner.
>>>
>>>          Given that an energy object can consume energy and/or provide
>>>          energy to other devices, there are three types of meters for
>>>          energy measurement: energy input to a device, energy supplied
>> to
>>>          other devices, and net (resultant) energy consumed (the
>>>          difference between energy input and provided).
>>>
>>>       1.3. Energy Management
>>>
>>>          Beyond energy monitoring, the EMAN framework provides
>> mechanisms
>>>          for energy control.
>>>
>>>          There are many cases where reducing energy consumption of
>>>          devices is desirable, such as when the device utilization
>> islow
>> islow ->  is low
>>>          or when the electricity is expensive or in short supply.
>>>
>>>          In some cases, energy control requires considering the energy
>>>          object context. For instance, in a building: all phones would
>>>          not usually be turned off to keep some still available in case
>>>          of emergency; office cooling is usually not turned off totally
>>>          during non-work hours, but the comfort level is reduced; and
>> so
>>>          on.
>>>
>>>          Energy object control requires flexibility and support for
>>>          different polices and mechanisms: from centralized management
>>>          with a network management station, to autonomous management by
>>>          individual devices, and alignment with dynamic demand-response
>>>          mechanisms.
>>>
>>>          The EMAN framework can be used as a tool for the
>> demand/response
>>>          scenario where in response to time-of-day fluctuation of
>> energy
>>>
>>>               Expires April 31, 2012        [Page 5]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>          costs or possible energy shortages, it is possible to respond
>>>          and reduce the energy consumption for the network devices,
>>>          effectively changing its power state.
>>>
>>>
>>>       1.4. EMAN Framework Application
>>>
>>>
>>>          A Network Management System (NMS) is the entity that requests
>>>          information from compatible devices using SNMP protocol. It
>> may
>>>          be a system which also implements other network management
>>>          functions, e.g. security management, identity management and
>> so
>>>          on), or one that only deals exclusively with energy in which
>>>          case it is called EnMS, Energy Management System. It may be
>>>          limited to monitoring energy use, or it may also implement
>>>          control functions. In a typical application of the EMAN
>>>          framework, management software collects energy information for
>>>          devices in the network.
>>>
>>>          Energy management can be implemented by extending existing
>> SNMP
>>>          support to the EMAN specific MIBs. SNMP provides an industry
>>>          proven and well-known mechanism to discover, secure, measure,
>>>          and control SNMP-enabled end devices.  The EMAN framework
>>>          provides an information and data model to unify access to a
>>>          large range of devices. The scope of the target devices and
>> the
>>>          network scenarios considered for energy management are listed
>> in
>>>          Section 2.
>>>
>>>       1.5. EMAN WG Document Overview
>> I would move this section in 1.2, because you refer multiple times to
>> the documents
>>>          The EMAN working group charter calls for producing a series of
>>>          Internet standard drafts in the area of energy management. The
>>>          following drafts are currently under discussion in the working
>>>          group.
>> Write sentences as if the WG did the work already.
>>>            Applicability Statement [EMAN-AS] This draft presents the
>> use
>> Same comment. Change draft ->  document
>> Note that there are multiple instances of this open issue.
>>>            cases and scenarios for energy monitoring.  In addition,
>> other
>>>            relevant energy standards and architectures are listed.
>>>
>>>            Requirements [EMAN-REQ] This draft presents the requirements
>>>            of Energy Monitoring and the scope of the devices
>> considered.
>> Energy Monitoring ->  Energy Management
>>>            Framework [EMAN-FRAMEWORK] This draft defines the
>> terminology
>>>            and explains the different concepts associated with energy
>>>            monitoring; these are used in the MIB modules.
>> [EMAN-FRAMORK] says
>>
>>     This document defines a framework for providing Energy
>>          Management for devices within or connected to communication
>>          networks.
>>
>> Energy Monitoring ->  Energy Management
>> Note: multiple instance of this issue, please check "Energy Monitoring"
>> throughout the draft.
>>>
>>>
>>>               Expires April 31, 2012        [Page 6]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>            Energy-Aware MIB [EMAN-AWARE-MIB] This draft proposes a MIB
>>>            module that characterizes a device's identity and context.
>>>
>>>            Monitoring MIB [EMAN-MONITORING-MIB] This draft defines a
>> MIB
>>>            module for monitoring the power and energy consumption of a
>>>            device. In addition, the MIB module contains an optional
>>>            module for power quality metrics.
>>>
>>>            Battery MIB [EMAN-BATTERY-MIB] This draft contains a MIB
>>>            module for monitoring characteristics of an internal
>> battery.
>>>            Energy Management Terminology [EMAN-DEF] This draft lists
>> the
>>>            definitions and terms used in the Energy Management Working
>>>            Group.
>>>
>>>       2. Scenarios and Target Devices
>>>
>>>          In this section a selection of scenarios for energy management
>>>          are presented. The fundamental objective of the use cases is
>> to
>>>          list important network scenarios that the EMAN framework
>> should
>>>          solve. These use cases then drive the requirements for the
>> EMAN
>>>          framework.
>>>
>>>          Each scenario lists target devices for which the energy
>>>          management framework can be applied, as well as how the
>>>          reported-on devices are powered, and how the reporting is
>>>          accomplished.    While there may be some overlap between some
>> of
>>>          the use cases, the use cases serve as illustrative network
>>>          scenarios EMAN framework should solve.
>>>
>>>       2.1. Network Infrastructure Energy Objects
>>>
>>>          This scenario covers network devices and their components.
>> Power
>>>          management of energy objects is considered as a fundamental
>>>          requirement of energy management of networks.
>>>
>>>          It can be important to monitor the power state and energy
>>>          consumption of these energy objects at a granularity level
>> finer
>>>          than just the entire device. For these devices, the chassis
>>>          draws power from one or more sources and feeds all its
>> internal
>>>          components. It is highly desirable to have monitoring
>> available
>>>          for individual components, such as line cards, processors, and
>>>          hard drives as well as peripherals like USB devices.
>>>
>>>          As an illustrative example, consider a switch with the
>> following
>>>          grouping of sub-entities for which energy monitoring could be
>>>          useful.
>>>
>>>
>>>               Expires April 31, 2012        [Page 7]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>
>>>            .  physical view: chassis (or stack), line cards, service
>>>               modules of the switch
>> You should explain
>>      that the ENTITY-MIB provides the containment tree,
>>      that the MIB modules are based on the ENTITY-MIB indexing,
>>      that a component might be EO and that the ENTITY-containment tree
>> will express if it belongs to another EO (example: line card EO in a
>> chassis EO, assuming that both EOs can meter the power consumption)
>>>            .  component view: CPU, ASICs, fans, power supply, ports
>>>               (single port and port groups), storage and memory
>>>            .  logical view: system, data-plane, control-plane, etc.
>> Question: how can we get the logical view?
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Network devices such as routers, switches
>>>               and their components.
>>>            . How powered: Typically by a PDU on a rack or from a wall
>>>               outlet. The components of a device are powered by the
>>>               device chassis.
>>>            . Reporting: Direct power measurement can be performed at a
>>>               device level. Components can report their power
>> consumption
>>>               directly or the chassis/device that can report on behalf
>> of
>>>               some components.
>>>
>>>       2.2. Devices Powered and Connected to a Network Device
>>>
>>>
>>>          This scenario covers Power over Ethernet (PoE) devices. A PoE
>>>          Power Sourcing Equipment (PSE) device (e.g. a PoE switch)
>> Should refer to the POE RFC for the terms such PSE and PD
>>>          provides power to a Powered Device (PD) (e.g. a desktop
>> phone).
>>>          For each port, the PSE can control the power supply (switching
>>>          it on and off) and monitor actual power provided. PoE devices
>>>          obtain network connectivity as well as the power supply for
>> the
>>>          device over a single connection so the PSE can determine which
>>>          device to allocate each port's power to.
>>>
>>>          PoE ports on a switch are commonly connected to IP phones,
>>>          wireless access points, and IP cameras. The switch powers
>>>          itself, as well as supplies power to downstream PoE ports.
>>>          Monitoring the power consumption of the switch (Energy Object
>>>          Parent) and the power consumption of the PoE end-points(Energy
>>>          Object Children) is a simple use case of this scenario.
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Power over Ethernet devices such as IP
>>>               Phones, Wireless Access Points, and IP cameras.
>>>            . How powered: PoE devices are connected to the switch port
>>>               which supplies power to those devices.
>>>            . Reporting:  PoE device power consumption is often measured
>>>               and reported at the switch (PSE) port which supplies
>> power
>>>               for the PoE device.
>> As I said, I like this structure but what you're missing is:
>>                 . Parent/Child: explains who is the parent and who is
>> the child, if applicable
>>                 . Relationship: explains which relationship are
>> applicable, if any (*)
>>
>> (*) this is really missing for some of the examples below
>> Actually, it would even be better if the different use cases would
>> contain drawings such as
>> http://www.ietf.org/proceedings/81/slides/eman-4.pdf ->  slide 14 and 15
>>>
>>>               Expires April 31, 2012        [Page 8]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>
>>>          In this case, the PoE devices do not need to directly support
>>>          the EMAN framework, only the Power Sourcing Equipment (PSE)
>>>          does.
>> Not correct. The answer is "it depends". If the PD, along with its own
>> UUID,  might be represented in the PSE
>>>
>>>       2.3. Devices Connected to a Network
>>>
>>>          The use case covers the metering relationship between an
>> energy
>> "metering relationship". This should prove my point that you should add
>> Relationship in your bullet points.
>>>          object receiving power from a source such as a power brick,
>> and
>>>          have an independent network connection to a parent energy
>> object
>>>          such as a switch.
>>>
>>>          In continuation to the previous example is a switch port that
>> previous example ->  example in the section 2.2
>>>          has both a PoE connection powering an IP Phone, and a PC has a
>>>          daisy-chain connection to the IP Phone for network
>> connectivity.
>>>          The PC has a network connection from the switch, but draws
>> power
>>>          from the wall outlet, in contrast to the IP phone draws power
>>>          from the switch.
>>>
>>>          It is also possible to consider a simple example of PC which
>> has
>>>          a network connection but draws power from the wall outlet or
>>>          PDU.
>>>
>>>          The PC in this case, is an non-PoE device, can report power
>>>          usage by itself, for instance through the EMAN framework.
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices:  Abroad set of energy objects that have a
>>>               network connection, but receive power supply from the
>> wall
>>>               outlet.
>>>            . How powered:  These devices receive power supply from the
>>>               wall outlet or a PDU.
>> "these devices" ->  make sure that you distinguish which one you're
>> talking about. Switch, POE phone, PC
>>>            . Reporting:  There are two models: devices that can measure
>>>               and report the power consumption directly via the EMAN
>>>               framework, and those that communicate it to the network
>>>               device (switch) and the switch can report the device's
>>>               power consumption via the EMAN framework.
>>>
>>>       2.4. Power Meters
>>>
>>>          Some electrical devices are not equipped with instrumentation
>> to
>>>          measure their own power and accumulated energy consumption.
>>>          External meters can be used to measure the power consumption
>> of
>>>          such electrical devices.
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 9]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>          This use case covers the proxy relationship of energy objects
>>>          able to measure or report the power consumption of external
>>>          electrical devices, not natively connected to the network.
>>>          Examples of such metering devices are smart PDUs and smart
>>>          meters.
>>>
>>>          Three types of external metering are relevant to EMAN: PDUs,
>>>          standalone meters, and utility meters.  External meters can
>>>          measure these properties for a single device or for a set of
>>>          devices.
>> NEW:
>>          External meters can measure these properties for a single
>> device or for a set of
>>          devices. Three types of external metering are relevant to EMAN:
>>
>> PDUs,
>>          standalone meters, and utility meters.
>>
>>>          Power Distribution Unit (PDUs) in a rack have inbuilt meters
>> for
>>>          each socket and the PDUs can measure the power supplied to
>> each
>>>          device in an equipment rack. The PDUs have remote management
>>>          functionality which can be used to measure and possibly
>> control
>>>          the power supply of each outlet.
>>>
>>>          Standalone meters can be placed anywhere in a power
>> distribution
>>>          tree, and can measure the power consumption.
>>>          Utility meters monitor and report accumulated power
>> consumption
>>>          of the entire building. There can be sub-meters to measure the
>>>          power consumption of a portion of the building.
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices:  PDUs and Smart Meters.
>> confused by the two examples, while you speak about 3 types of external
>> metering
>>>            . How powered:  From traditional mains power but as passed
>>>               through a PDU or meter.
>>>            . Reporting:  The PDUs reports power consumption of
>>>               downstream devices. There is commonly only one device
>>>               downstream of each outlet, but there could be many.
>> There
>>>               can be external meters in between the power supply and
>>>               device and the meters can report the power consumption of
>>>               the device.
>>>
>>>       2.5. Mid-level Managers
>>>
>>>          This use case covers aggregation of energy management data at
>>>          "mid-level managers" that can provide energy management
>>>          functions for themselves as well as associated devices.
>>>
>>>          A switch can provide energy management functions for all
>> devices
>>>          connected to its ports, whether or not these devices are
>> powered
>>>          by the switch or whether the switch provides immediate network
>>>          connectivity to the devices; such a switch is a mid-level
>>>          manager, offering aggregation of power consumption data for
>>>          devices it does not supply power to them.  Devices report
>> their
>>>
>>>               Expires April 31, 2012        [Page 10]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          EMAN data to the switch and the switch aggregates the data for
>>>          these data.
>>>
>>>          The essential properties of this use case are summarized as
>>>          follows:
>>>
>>>            . Target devices: network devices which can perform
>>>               aggregation; commonly a switch or a proxy
>>>            . How powered:  Mid-level managers can be are commonly
>>>               powered by a PDU or from a wall outlet but there is no
>>>               limitation.
>> Some common language would be nice. "any method" is used in section 2.11
>>>            . Reporting:  The middle-manager aggregates the energy data
>>>               and reports that data to a NMS or higher mid-level
>> manager.
>>>       2.6. Gateways to Building Systems
>>>
>>>          This use case describes energy management of buildings.
>> Building
>>>          Management Systems (BMS) have been in place for many years
>> using
>>>          legacy protocols not based on IP. In these buildings, a
>> gateway
>>>          can provide a proxy relationship between IP and legacy
>> building
>>>          automation protocols. The gateway can provide an interface
>>>          between the EMAN framework and relevant building management
>>>          protocols.
>>>
>>>          Due to the potential energy savings, energy management of
>>>          buildings has received significant attention. There are
>> gateway
>>>          network elements to manage the multiple components ofa
>> building
>>>          energy management system such as Heating, Ventilation, and Air
>>>          Conditioning (HVAC), lighting, electrical, fire and emergency
>>>          systems, elevators, etc. The gateway device uses legacy
>> building
>>>          protocols to communicate with those devices, collects their
>>>          energy usage, and reports the results.
>>>
>>>          The gateway performs protocol conversion between many facility
>>>          management devices. The gateway communicates via RS-232/RS-485
>>>          interfaces, Ethernet interfaces, and protocols specific to
>>>          building management such as BACNET, MODBUS, or Zigbee.
>> References please
>>>          The essential properties of this use case are :
>>>
>>>            . Target devices: Building energy management devices - HVAC
>>>               systems, lighting, electrical, fire and emergency
>> systems.
>>>               There are meters for each of the sub-systems and the
>> energy
>>>               data is communicated to the proxy using legacy protocols.
>>>            . How powered: Any method, including directly from mains
>>>               power or via a UPS.
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 11]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>            . Reporting: The gateway collects energy consumption of non-
>>>               IP systems and communicates the data via the EMAN
>>>               framework.
>>>
>>>       2.7. Home Energy Gateways
>>>
>>>          This use case describes the scenario of energy management of a
>>>          home. The home energy gateway is another example of a proxy
>> that
>>>          interfaces to the electrical appliances and other devices in a
>>>          home and also has an interface to the utility. This gateway
>> can
>>>          monitor and manage electrical equipment (refrigerator,
>>>          heating/cooling, washing machine etc.) possibly using one of
>> the
>>>          many protocols (ZigBee, Smart Energy, ...) that are being
>>>          developed for the home area network products and considered in
>>>          standards organizations.
>>>
>>>          In its simplest form, metering can be performed at home.
>> Beyond
>>>          the metering, it is also possible implement energy saving
>>>          policies based on energy pricing from the utility grid. From
>> an
>>>          EMAN point of view, the information model that been
>> investigated
>>>          can be applied to the protocols under consideration for energy
>>>          monitoring of a home.
>>>
>>>
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Home energy gateway and Smart meters in a
>>>               home.
>> In terms of capitalization, there are sometimes some strange things. See
>>
>> "Smart" above.
>>>            . How powered:  Any method.
>>>            . Reporting: Home energy gateway can collect power
>>>               consumption of device in a home and possibly report the
>>>               metering reading to the utility.
>>>
>>>          Beyond the canonical setting of a home drawing power from the
>>>          utility, it is also possible to envision an energy neutral
>>>          situation wherein the buildings/homes that can produce and
>>>          consume energy without importing energy from the utility grid.
>>>          There are many energy production technologies such as solar
>>>          panels, wind turbines, or micro generators. This use case
>>>          illustrates the concept of self-contained energy generation
>> and
>>>          consumption and possibly the aggregation of the energy use of
>>>          homes.
>>>
>>>
>>>
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 12]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>         2.8. Data Center Devices
>>>
>>>          This use case describes energy management of a Data Center
>>>          network.
>>>
>>>          Energy efficiency of data centers has become a fundamental
>>>          challenge of data center operation, as datacenters are big
>>>          energy consumers and their infrastructure is expensive. The
>>>          equipment generates heat, and heat needs to be evacuated
>> though
>>>          a HVAC system.
>>>
>>>          A typical data center network consists of a hierarchy of
>>>          electrical energy objects.  At the bottom are servers mounted
>> on
>> Replace . by ;
>>>          a rack; these are connected to the top-of-the-rack switches;
>>>          these are connected to aggregation switches; those in turn
>>>          connected to core switches.  Power consumption of all network
>>>          elements and the servers in the Data center should be
>> measured.
>>>          In addition, there are also network storage devices. Energy
>>>          management can be implemented on different aggregation levels,
>>>          such as network level, Power Distribution Unit (PDU) level,
>> and
>>>          server level.
>>>
>>>          The Data center network contains UPS to provide back-up power
>>>          for the network devices in the event in the event of power
>>>          outages. Thus from a Data center energy management point of
>>>          view, in addition, to monitoring the energy usage of network
>>>          devices, it is also important to monitor the remaining
>> capacity
>>>          of the UPS.
>> "see some more information about the UPS in section 2.9"
>>>          In addition to monitoring the power consumption, at a data
>>>          center level, additional metrics such as power quality, power
>>>          characteristics can be important metrics. The dynamic
>> variations
>>>          in the input power supply from the grid referred to as power
>>>          quality is one metric. Secondly, how the devices use the power
>>>          can be referred to as power characteristics and it is also
>>>          useful to monitor these metrics. Lastly, the power plate set
>>>          will make it possible to know an aggregate of the potential
>>>          worst-case power usage and compare it to the budgeted power in
>>>          the data center.
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: All network devices in a data center, such
>>>               as network equipment, servers, and storage devices.
>>>            . How powered: Any method but commonly by a PDUs in racks.
>>>            . Reporting: Devices may report on their own behalf, or for
>>>               other connected devices as described in other use cases.
>>>
>>>
>>>               Expires April 31, 2012        [Page 13]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>
>>>       2.9. Energy Storage Devices
>>>
>>>          There are two types of devices with energy storage: those
>> whose
>>>          primary function is to provide power to another device (e.g. a
>>>          UPS), and those with a different primary function, but have an
>>>          energy storage as a component as an alternate internal power
>>>          source (e.g. a notebook).  EMAN covers both types of products
>> in
>>>          this use case.
>>>
>>>          The energy storage can be a battery, or any other means to
>> store
>>>          electricity such as a hydrogen cell.
>>>
>>>          Some devices have an internal battery as a back-up or
>>>          alternative source of power to mains power. When the
>> connection
>>>          to the power supply of the device is disconnected, the device
>>>          can run on the internal battery. As batteries have a finite
>>>          capacity and lifetime, means for reporting the actual charge,
>>>          age, and state of a battery are required.
>>>
>>>          UPS can provide backup power for many devices in a data
>> centers
>>>          for a finite period of time. Energy monitoring of such energy
>>>          storage devices is vital from a data center network operations
>>>          point of view. The UPS MIB provides a framework for monitoring
>>>          the remaining capacity of the UPS.
>>>
>>>          There are also battery systems for mobile towers particularly
>>>          for use in remote locations. It is important to monitor the
>>>          remaining battery life and raise an alarm when the battery
>> life
>>>          is below a threshold.
>> Explain that the battery is a component, which containment can be
>> tracked thanks to the ENTITY-MIB.
>>
>> We would need a special paragraph for the UPS. What is the link with the
>>
>> UPS-MIB.
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Devices that have an internal battery such
>>>               as notebook PC and other mobile devices.
>>>            . How powered: From internal batteries or mains power.
>>>            . Reporting:  The device reports on its internal battery.
>>>
>>>
>>>       2.10. Ganged Outlets on a PDU Multiple Power Sources
>>>
>>>          This use case describes the scenario of multiple power sources
>>>          of a devices and logical groupings of devices in a PDU.
>>>
>>>          Some PDUs allow physical entities like outlets to be "ganged"
>>>          together as a logical entity to simplify management.
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 14]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          This is particularly useful for servers with multiple power
>>>          supplies, where each power supply is connected to a different
>>>          physical outlet. Other implementations allow "gangs" to be
>>>          created based on common ownership of outlets, such as business
>>>          units, load shed priority, or other non-physical
>> relationships.
>>>          Current implementations allow for an "M-to-N" mapping between
>>>          outlet "gangs" and physical outlets, as with this example:
>>>
>>>            . Outlet 1 - physical entity
>>>            . Outlet 2 - physical entity
>>>            . Outlet 3 - physical entity
>>>            . Outlet 4 - physical entity
>>>            . Outlet Gang A - virtual entity
>>>            . Outlet Gang B - virtual entity
>>>
>>>                 o Gang A ->   Outlets 1, 2 and 3
>>>                 o Gang B ->   Outlets 3 and 4
>>>
>>>          Note the allowed overlap on Outlet 3, which belongs to both
>>>          "gangs."
>>>
>>>          Each "Outlet Gang" entity reports the aggregated data from the
>>>          individual outlet entities that comprise it and enables a
>> single
>>>          point of control for all the individual outlet entities.
>>>
>>>
>>>       2.11. Industrial Automation Networks
>>>
>>>          Energy consumption statistics in the industrial sector are
>>>          staggering. The industrial sector alone consumes about half of
>>>          the world's total delivered energy, making it the largest end-
>>>          use sector. Thus, the need for optimization of energy usage in
>>>          this sector is natural.
>>>          Industrial facilities consume energy in process loads, and in
>>>          non-process loads.
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Devices used in industrial automation
>>>            . How powered: Any method.
>>>            . Reporting: Currently, CIP protocol is currently used for
>>>               reporting energy for these devices
>>>
>>>       2.12. Printers
>>>
>>>          This use case describes the scenario of energy monitoring and
>>>          management of Printer devices.
>>>
>>>
>>>               Expires April 31, 2012        [Page 15]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>
>>>          Printers in this use case stand in for all imaging equipment,
>>>          also including multi-function devices (MFDs), copiers,
>> scanners,
>>>          fax machines, and mailing machines.  Energy use of printers
>> has
>>>          been an industry concern for several decades, and they usually
>>>          have sophisticated power management with a variety of
>> low-power
>>>          modes, particularly for managing energy-intensive thermo-
>>>          mechanical components. Printers also have long made extensive
>>>          use of SNMP for end-user system interaction and for management
>>>          generally, and cross-vendor management systems are available
>>>          today to manage fleets of printers in enterprises.  Power
>>>          consumption during active modes can vary widely, with high
>> peak
>>>          levels.
>>>
>>>          Printers today can expose detailed power state information,
>>>          distinct from operational state information, with some
>> printers
>>>          reporting transition states between stable long-term states.
>>>          Many also support active setting of power states, and setting
>> of
>>>          policies such as delay times when no activity will cause
>>>          automatic transition to a lower power mode.  Other features
>>>          include reporting on components of imaging equipment, counters
>>>          for state transitions, and typical power levels by state,
>>>          scheduling, and events/alarms.
>>>
>>>          Some large printers also have a "Digital Front End" which is a
>>>          computer that performs functions on behalf of the physical
>>>          imaging system.  These will typically have their own presence
>> on
>>>          the network and are sometimes separately powered.
>>>
>>>          There are some unique characteristics of Printers from the
>> point
>>>          of view energy monitoring. While the printer is not in use,
>>>          there are timer based low power states (sleep, stand-by),
>> which
>>>          consume very little power. On the other hand, while the
>> printer
>>>          is printing or copying the cylinder needs to be heated so that
>>>          power consumption is quite high but only for a short period of
>>>          time (duration of the print job). Given this work load,
>> periodic
>>>          polling of energy consumption would not suffice.
>>>
>>>          Target Devices: All imaging equipment.
>>>
>>>          How Powered: Typically via mains AC from a wall outlet
>>>
>>>          Reporting: Devices report for themselves
>> Thinking some more about this "Reporting", I believe that that we should
>>
>> tell what the implementers shoud do.
>> For example: "Devices report for themselves by implementing [EMAN-MON]"
>> Note that this is a generic comment for all use cases.
>>>
>>>
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 16]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       2.13. Off-Grid Devices
>>>
>>>          This use case concerns self-contained devices that use energy
>>>          but are not connected to an infrastructure power delivery
>> grid.
>>>          These devices typically scavenge energy from environmental
>>>          sources such as solar energy or wind power. The device
>> generally
>>>          contains a closely coupled combination of
>>>
>>>            . power scavenging or generation component(s)
>>>            . power storage component(s) (e.g., battery)
>>>            . power consuming component(s)
>>>
>>>          With scavenged power, the energy input is often dependent on
>> the
>>>          random variations of the weather. These devices therefore
>>>          require energy management both for internal control and remote
>>>          reporting of their state. In order to optimize the performance
>>>          of these devices and minimize the costs of the generation and
>>>          storage components, it is desirable to vary the activity
>> level,
>>>          and, hopefully, the energy requirements of the consuming
>>>          components in order to make best use of the available stored
>> and
>>>          instantaneously generated energy.  With appropriate energy
>>>          management, the overall device can be optimized to deliver an
>>>          appropriate level of service without over provisioning the
>>>          generation and storage components.
>>>
>>>          In many cases these devices are expected to operate
>>>          autonomously, as continuous communications for the purposes of
>>>          remote control is either impossible or would result in
>> excessive
>>>          power consumption.  Non continuous polling requires the
>> ability
>>>          to store and access later the information collected while the
>>>          communication was not possible.
>>>
>>>          Target Devices:  Remote network devices (mobile network) that
>>>          consume and produce energy
>>>
>>>          How Powered: Can be battery powered or using natural energy
>>>          sources
>>>
>>>          Reporting: Devices report their power usage but only
>>>          occasionally.
>>>
>>>
>>>       2.14. Demand/Response
>>>
>>>          Demand/Response from the utility or grid is a common theme
>> that
>>>          spans across some of the use cases. In some situations, in
>>>          response to time-of-day fluctuation of energy costs or sudden
>>>
>>>
>>>               Expires April 31, 2012        [Page 17]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          energy shortages due power outages, it may be important to
>>>          respond and reduce the energy consumption of the network.
>>>          From EMAN use case perspective, the demand/response scenario
>> can
>>>          apply to a Data Center or a Building or a residential home. As
>> a
>>>          first step, it may be important to monitor the energy
>>>          consumption in real-time of a Data center or a building or
>> home
>>>          which is already discussed in the previous use cases. Then
>> based
>>>          on the potential energy shortfall, the Energy Management
>> System
>>>          (EMS) could formulate a suitable response, i.e., the EMS could
>>>          shut down some selected devices that may be considered
>>>          discretionary or uniformly reduce the power supplied to all
>>>          devices. For multi-site data centers it may be possible to
>>>          formulate policies such as follow-the-moon type of approach,
>> by
>>>          scheduling the mobility of VMs across Data centers in
>> different
>>>          geographical locations.
>>          Target Devices:  ...
>>
>>          How Powered: ...
>>
>>          Reporting: ...
>>>       2.15. Power Capping
>>>
>>>          Power capping is a technique to limit the total power
>>>          consumption of a server. This technique can be useful for
>> power
>>>          limited data centers. Based on workload measurements, the
>> server
>>>          can choose the optimal power state of the server in terms of
>>>          performance and power consumption. When the server operates at
>>>          less than the power supply capacity, it runs at full speed.
>> When
>>>          the server power would be greater than the power supply
>>>          capacity, it runs at a slower speed so that its power
>>>          consumption matches the available power supply capacity. This
>>>          gives vendors the option to use smaller, cost-effective power
>>>          supplies that allow real world workloads to run at nominal
>>>          frequency.
>> power caping is something that could be done in a management app using
>> the EMAN Mib.  E.g., when polling for current usage, if this crosses a
>> powercap use EMAN Mib to set the power state to a lower level.
>>
>>          Target Devices:  ...
>>
>>          How Powered: ...
>>
>>          Reporting: ...
>>>
>>>
>>>
>>>
>>>       3. Use Case Patterns
>> You have in the introduction somewhere what the section contains.
>> Because, reading that far, I was not obvious that you wanted to
>> summarize the different patterns in section 3.
>> If the intro had mentioned it, I would have the text with that in mind.
>>>          The use cases presented above can be abstracted to the
>> following
>>>          broad patterns.
>>>
>>>       3.1. Metering
>>>
>>>          -energy objects which have capability for internal metering
>> add a space
>>>          - electrical devices which are metered by an external device
>>>
>>>
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 18]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       3.2. Metering and Control
>>>
>>>          - entities objects that do not supply power, butcan perform
>> only
>> butcan ->  but can
>>>          power metering for other devices
>> entity object ->  energy objects
>> (multiple instances of this issue)
>>>          - entities objects that do not supply power, can perform both
>>>       metering and control for other devices
>>>
>>>
>>>       3.3. Power Supply, Metering and Control
>>>
>>>          - entities devices that supply power for other devices but do
>>>          not perform power metering for those devices
>>>
>>>          - entities that supply power for other devices and also
>> perform
>>>          power metering
>>>
>>>          - entities supply power for other devices and also perform
>> power
>>>          metering and control for other devices
>>>
>>>
>>>
>>>       3.4. Multiple power sources
>>>
>>>          - entities that have multiple power sources and metering and
>>>          control is performed by one source
>>>
>>>          - entities that have multiple power sources and metering is
>>>          performed by one source and control another source
>> Thinking some more about this section 3, aren't we covering all the
>> possible combinations of relationships from [EMAN-FMWK]?
>> Any gaps?
>>>
>>>
>>>       4. Relationship of EMAN to other Standards
>>>
>>>          EMAN as a framework is tied to other standards and efforts
>> that
>>>          deal with energy. Existing standards are leveraged when
>>>          possible.  EMAN helps enable adjacent technologies such as
>> Smart
>>>          Grid.
>>>
>>>          The standards most relevant and applicable to EMAN are listed
>>>          below with a brief description of their objectives, the
>> current
>>>          state and how that standard can be applied to EMAN.
>> "how that standard can be applied to EMAN."  I don't think it's the
>> goal.
>> We want to explain the relationship/connection with EMAN
>>>
>>>
>>>
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 19]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       4.1. Data Model and Reporting
>>>
>>>       4.1.1. IEC - CIM
>>>
>>>          The International Electro-technical Commission (IEC) has
>>>          developed a broad set of standards for power management.
>> Among
>>>          these, the most applicable to EMAN is IEC 61850,a standard for
>>>          the design of electric utility automation.  The abstract data
>>>          model defined in 61850 is built upon and extends the Common
>>>          Information Model (CIM). The complete 61850 CIM model includes
>>>          over a hundred object classes and is widely used by utilities
>>>          worldwide.
>>>
>>>          This set of standards was originally conceived to automate
>>>          control of a substation (facilities which transfer electricity
>>>          from the transmission to the distribution system). While the
>>>          original domain of 61850 is substation automation, the
>> extensive
>>>          data model has been widely used in other domains, including
>>>          Energy Management Systems (EMS).
>>>
>>>          IEC TC57 WG19 is an ongoing working group to harmonize the CIM
>>>          data model and 61850 standards.
>>>
>>>          Concepts from IEC Standards have been reused in the EMAN WG
>>>          drafts. In particular, AC Power Quality measurements have been
>>>          reused from IEC 61850-7-4. The concept of Accuracy Classes for
>>>          measurement of power and energy has been reused IEC 62053-21
>> and
>>>          IEC 62053-22.
>> Is this inline with what you wrote before "The EMAN standard references
>> ANSI C12 accuracy classes."?
>>>       4.1.2. DMTF
>>>
>>>          The Distributed Management Task Force (DMTF)[DMTF] has
>>>          standardized management solutions for managing servers and
>> PCs,
>>>          including power-state configuration and management of elements
>>>          in a heterogeneous environment.  These specifications provide
>>>          physical, logical and virtual system management requirements
>> for
>>>          power-state control.
>>>
>>>          The EMAN standard references the DMTF Power Profile and Power
>>>          State Series.
>>>
>>>       4.1.2.1. Common Information Model Profiles
>>>
>>>          The DMTF uses CIM-based (Common Information Model) 'Profiles'
>> to
>>>          represent and manage power utilization and configuration of
>>>          managed elements (note that this is not the 61850 CIM).  Key
>>>          profiles for energy management are 'Power Supply' (DSP 1015),
>>>
>>>
>>>               Expires April 31, 2012        [Page 20]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          'Power State' (DSP 1027) and 'Power Utilization Management'
>> (DSP
>>>          1085).These profiles define monitoring and configuration of a
>>>          Power Managed Element's static and dynamic power saving modes,
>>>          power allocation limits and power states, among other
>> features.
>>>          Reduced power modes can be established as static or dynamic.
>>>          Static modes are fixed policies that limit power use or
>>>          utilization. Dynamic power saving modes rely upon internal
>>>          feedback to control power consumption.
>>>
>>>          Power states are eight named operational and non operational
>>>          levels.  These are On, Sleep-Light, Sleep-Deep, Hibernate,
>> Off-
>>>          Soft, and Off-Hard.  Power change capabilities provide
>>>          immediate, timed interval, and graceful transitions between
>> on,
>>>          off, and reset power states.  Table 3 of the Power State
>> Profile
>>>          defines the correspondence between the ACPI and DMTF power
>> state
>>>          models, although it is not necessary for a managed element to
>>>          support ACPI. Optionally, a TransitingToPowerState property
>> can
>>>          represent power state transitions in progress.
>>>
>>>       4.1.2.2. DASH
>> We need references for all entries in 4.*
>>>          DMTF DASH (DSP0232) (Desktop And Mobile Architecture for
>> System
>>>          Hardware) addresses managing heterogeneous desktop and mobile
>>>          systems (including power) via in-band and out-of-band
>>>          communications.  DASH provides management and control of
>> managed
>>>          elements like power, CPU, etc. using the DMTF's WS-Management
>>>          web services and CIM data model.
>>>
>>>          Both in service and out-of-service systems can be managed with
>>>          the DASH specification in a fully secured remote environment.
>>>          Full power lifecycle management is possible using out-of-band
>>>          management.
>> Question: what is the relationship with EMAN. If none, mentions it along
>>
>> with a list of pros/cons. I mean: why should an implementator chose EMAN
>>
>> versus DASH?
>>>       4.1.3. ODVA
>>>
>>>          The Open DeviceNet Vendors Association (ODVA) is an
>> association
>>>          for industrial automation companies and defines the Common
>>>          Industrial Protocol (CIP). Within ODVA, there is a special
>>>          interest group focused on energy.
>>>
>>>          There are many similar concepts between the ODVA and EMAN
>>>          frameworks towards monitoring and management of energy aware
>>>          devices. In particular, one of the concepts being considered
>>>          different energy meters based on if the device consumes
>>>          electricity or produces electricity or a passive device.
>> Express that the concept has been reused from ODVA since some ODVA
>> members were involved in the WG.
>>>
>>>
>>>               Expires April 31, 2012        [Page 21]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          The Open DeviceNet Vendors Association (ODVA) is developing an
>>>          energy management framework for the industrial sector.  There
>>>          are synergies between the ODVA and EMAN approaches to energy
>>>          management.
>> move that paragraph one place up
>>>          ODVA defines a three-part approach towards energy management:
>>>          awareness of energy usage, consuming energy more efficiently,
>>>          and exchanging energy with the utility or others. Energy
>>>          monitoring and management promote efficient consumption and
>>>          enable automating actions that reduce energy consumption.
>>>
>>>          The foundation of the approach is the information and
>>>          communication model for entities. An entity is a network-
>>>          connected, energy-aware device that has the ability to either
>>>          measure or derive its energy usage based on its native
>>>          consumption or generation of energy, or report a nominal or
>>>          static energy value.
>>>
>>>
>>>
>>>       4.1.4. Ecma SDC
>> Ecma stands for?
>>>          The Ecma International committee on Smart Data Centre
>> (TC38-TG2
>>>          SDC [Ecma-SDC]) is in the process of defining semantics for
>>>          management of entities in a data center such as servers,
>>>          storage, and network equipment.  It covers energy as one of
>> many
>>>          functional resources or attributes of systems for monitoring
>> and
>>>          control. It only defines messages and properties, and does not
>>>          reference any specific protocol. Its goal is to enable
>>>          interoperability of such protocols as SNMP, BACNET, and HTTP
>> by
>>>          ensuring a common semantic model across them. Four power
>> states
>>>          are defined, Off, Sleep, Idle and Active. The standard does
>> not
>>>          include actual power measurements in kWor kWh.
>> kWor ->  kW or
>>>          The 14th draft of SDC process was published in March 2011 and
>>>          the development of the standard is still underway. When used
>>>          with EMAN, the SDC standard will provide a thin abstraction on
>>>          top of the more detailed data model available in EMAN.
>>>
>>>       4.1.5. IEEE-ISTO Printer Working Group (PWG)
>>>
>>>
>>>          The IEEE-ISTO Printer Working Group (PWG) defines SNMP MIB
>>>          modules for printer management and has recently defined a "PWG
>>>          Power Management Model for Imaging Systems v1.0" [PWG5106.4]
>> and
>>>          a companion SNMP binding in the "PWG Imaging System Power MIB
>>>          v1.0" [PWG5106.5].  This PWG model and MIB are harmonized with
>>>
>>>
>>>               Expires April 31, 2012        [Page 22]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement        October 2011
>>>
>>>          the DMTF CIM Infrastructure [DSP0004] and DMTF CIM Power State
>>>          Management Profile [DSP1027] for power states and alerts.
>>>
>>>
>>>          The PWG would like its MIBs to be harmonized as closely as
>>>          possible with those from EMAN.  The PWG covers many topics in
>>>          greater detail than EMAN, as well as some that are specific to
>>>          imaging equipment.  The PWG also provides for vendor-specific
>>>          extension states (i.e., beyond the standard DMTF CIM states.)
>>>
>>>
>>>
>>>       4.1.6. ASHRAE
>>>
>>>          In the U.S., there is an extensive effort to coordinate and
>>>          develop standards related to the "Smart Grid".  The Smart Grid
>>>          Interoperability Panel, coordinated by the government's
>> National
>>>          Institute of Standards and Technology, identified the need for
>> a
>>>          building side information model (as a counterpart to utility
>>>          models) and specified this in Priority Action Plan (PAP) 17.
>>>          This was designated to be a joint effort by American Society
>> of
>>>          Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE)
>>>          and National Electrical Manufacturers Association (NEMA), both
>>>          ANSI approved SDO's.  The result is to be an information
>> model,
>>>          not a device level monitoring protocol.
>>>
>>>          The ASHRAE effort addresses data used only within a building
>> as
>>>          well as data that may be shared with the grid, particularly as
>>>          it relates to coordinating future demand levels with the needs
>>>          of the grid.  The model is intended to be applied to any
>>>          building type, both residential and commercial.  It is
>> expected
>>>          that existing protocols will be adapted to comply with the new
>>>          information model, as would any new protocols.
>>>
>>>          There are four basic types of entities in the model:
>> generators,
>>>          loads, meters, and energy managers.
>>>
>>>          The metering part of this model overlaps with the EMAN
>> framework
>>>          to a large degree, though there are features unique to each.
>>>          The load part speaks to control capabilities well beyond what
>>>          EMAN covers.  Details of generation and of the energy
>> management
>>>          function are outside of EMAN scope.
>>>
>>>          A public review draft of the ASHRAE standard is expected soon,
>>>          and at that point detailed comparison of the two models can be
>>>          made.  There are no apparent major conflicts between the two
>>>          approaches, but there are likely areas where some
>> harmonization
>>>
>>>               Expires April 31, 2012        [Page 23]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          is possible, and regardless, a description of the
>>>          correspondences would be helpful to create.
>>>
>>>
>>>       4.1.7. ZigBee
>>>
>>>          The Zigbee Smart Energy 2.0 effort[ZIGBEE] focuses on wireless
>>>          communication to appliances and lighting.  It is intended to
>>>          enable building energy management and enable direct load
>> control
>>>          by utilities.
>>>
>>>          ZigBee protocols are intended for use in embedded applications
>>>          requiring low data rates and low power consumption. ZigBee
>>>          defines a general-purpose, inexpensive, self-organizing mesh
>>>          network that can be used for industrial control, embedded
>>>          sensing, medical data collection, smoke and intruder warning,
>>>          building automation, home automation, etc.
>>>
>>>          Zigbee is currently not an ANSI recognized SDO.
>>>
>>>          The EMAN framework addresses the needs of IP-enabled networks
>>>          through the usage of SNMP, while Zigbee looks for completely
>>>          integrated and inexpensive mesh solution.
>> Zigbee Smart Energy 2.0 is based on IP, right? This should be stressed.
>>>       4.2. Measurement
>>>
>>>
>>>       4.2.1. ANSI C12
>>>
>>>          The American National Standards Institute (ANSI) has defined a
>>>          collection of power meter standards under ANSI C12.  The
>> primary
>>>          standards include communication protocols (C12.18, 21 and 22),
>>>          data and schema definitions (C12.19), and measurement accuracy
>>>          (C12.20). European equivalent standards are provided by IEC
>>>          62053-22.ANSI C12.20 defines accuracy classes for watt-hour
>>>          meters.
>>>
>>>          All of these standards are oriented toward the meter itself,
>> and
>>>          are therefore very specific and used by electricity
>> distributors
>>>          and producers.
>>>
>>>          The EMAN standard references ANSI C12 accuracy classes.
>>>
>>>       4.2.2. IEC62301
>>>
>>>          IEC 62301, "Household electrical appliances  Measurement of
>>>          standby power", specifies a power level measurement procedure.
>>>
>>>
>>>               Expires April 31, 2012        [Page 24]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          While nominally for appliances and low-power modes, many
>> aspects
>>>          of it apply to other device types and modes and it is commonly
>>>          referenced in test procedures for energy using products.
>>>
>>>          While the standard is intended for laboratory measurements of
>>>          devices in controlled conditions, many aspects of it are
>>>          informative to those implementing measurement in products that
>>>          ultimately report via EMAN.
>>>
>>>
>>>
>>>
>>>       4.3. Other
>>>
>>>       4.3.1. ISO
>>>
>>>          The ISO [ISO] is developing an energy management standard, ISO
>>>          50001, to complement ISO 9001 for quality management, and ISO
>>>          14001 for environment management. The intent of the framework
>> is
>>>          to facilitate the creation of energy management programs for
>>>          industrial, commercial and other entities.  The standard
>> defines
>>>          a process for energy management at an organization level.  It
>>>          does not define the way in which devices report energy and
>>>          consume energy.
>>>
>>>          EMAN is complementary to ISO 9001.
>> move that paragraph at the end of hte section
>>>          ISO 50001 is based on the common elements found in all of
>> ISO's
>>>          management system standards, assuring a high level of
>>>          compatibility with ISO 9001 (quality management) and ISO 14001
>>>          (environmental management). ISO 50001 benefits includes:
>>>
>>>         o Integrating energy efficiency into management practices and
>>>            throughout the supply chain
>>>         o Energy management best practices and good energy management
>>>            behaviors
>>>         o benchmarking, measuring, documenting, and reporting energy
>>>            intensity improvements and their projected impact on
>>>            reductions in greenhouse gas (GHG) emissions
>>>         o Evaluating and prioritizing the implementation of new energy-
>>>            efficient technologies
>>>
>>>          ISO 50001 has been developed by ISO project committee ISO/PC
>>>          242, Energy management.
>>>
>>>
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 25]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       4.3.2. EnergyStar
>>>
>>>          The US Environmental Protection Agency (EPA) and US Department
>>>          of Energy (DOE) jointly sponsor the Energy Star program
>> [ESTAR].
>>>          The program promotes the development of energy efficient
>>>          products and practices.
>>>
>>>          To qualify as Energy Star, products must meet specific energy
>>>          efficiency targets. The Energy Star program also provides
>>>          planning tools and technical documentation to encourage more
>>>          energy efficient building design. Energy Star is a program; it
>>>          is not a protocol or standard.
>>>
>>>          For businesses and data centers, Energy Star offers technical
>>>          support to help companies establish energy conservation
>>>          practices.  Energy Star provides best practices for measuring
>>>          current energy performance, goal setting, and tracking
>>>          improvement.  The Energy Star tools offered include a rating
>>>          system for building performance and comparative benchmarks.
>>>
>>>          There is no immediate link between EMAN and EnergyStar, one
>>>          being a protocol and the other a set of recommendations to
>>>          develop energy efficient products.  However, Energy Star could
>>>          include EMAN standards in specifications for future products,
>>>          either as required or rewarded with some benefit.
>>>
>>>       4.3.3. SmartGrid
>>>
>>>          The Smart Grid standards efforts underway in the United States
>>>          are overseen by the US National Institute of Standards and
>>>          Technology [NIST].NIST is responsible for coordinating a
>> public-
>> insert space
>>>          private partnership with key energy and consumer stakeholders
>> in
>>>          order to facilitate the development of smart grid standards.
>> The
>>>          NIST smart grid standards activities are monitored and
>>>          facilitated by the SGIP (Smart Grid Interoperability Panel).
>>>          This group has working groups for specific topics including
>>>          homes, commercial buildings, and industrial facilities as they
>>>          relate to the grid.
>>>
>>>          When a working group detects a standard or technology gap, the
>>>          team seeks approval from the SGIP for the creation of a
>> Priority
>>>          Action Plan (PAP), a private-public partnership to close the
>>>          gap.  There are currently 17 PAPs.  PAP 17 is discussed in
>>>          section 4.1.6.
>>>
>>>          PAP 10 addresses "Standard Energy Usage Information".
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 26]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          Smart Grid standards will provide distributed intelligence in
>>>          the network and allow enhanced load shedding.  For example,
>>>          pricing signals will enable selective shutdown of non critical
>>>          activities during peak-load pricing periods.  These actions
>> can
>>>          be effected through both centralized and distributed
>> management
>>>          controls.
>>>
>>>          There is an obvious functional link between SmartGrid and EMAN
>>>          in the form of demand response, even if the EMAN framework
>> does
>>>          not take any specific step toward SmartGrid communication.
>>>
>> "However, the EMAN framework, with its Energy Object Power State
>> control, offers a solution for the smart grid demand/response use case"
>>
>>>       5. Limitations
>>>
>>>          EMAN Framework shall address the needs of energy monitoring in
>> shall address ->  addresses
>>
>> Regards, Benoit.
>>>          terms of measurement and, considers limited control
>> capabilities
>>>          of energy monitoring of networks.
>>>
>>>          EMAN does not create a new protocol stack, but rather defines
>> a
>>>          data and information model useful for measuring and reporting
>>>          energy and other metrics over SNMP.
>>>
>>>          The EMAN framework does not address questions regarding
>>>          SmartGrid, electricity producers, and distributors even if
>> there
>>>          is obvious link between them.
>>>
>>>       6. Security Considerations
>>>
>>>          EMAN shall use SNMP protocol for energy monitoring and thus
>> has
>>>          the functionality of SNMP's security capabilities. SNMPv3
>>>          [RFC3411] provides important security features such as
>>>          confidentiality, integrity, and authentication.
>>>
>>>       7. IANA Considerations
>>>
>>>          This memo includes no request to IANA.
>>>
>>>       8. Acknowledgements
>>>
>>>          The authors would like to thank Jeff Wheeler, Benoit Claise,
>>>          Juergen Quittek, Chris Verges, John Parello, and Matt Laherty,
>>>          for their valuable contributions.
>>>
>>>          The authors would like to thank Georgios Karagiannis for use
>>>          case involving energy neutral homes, Elwyn Davies for off-grid
>>>          electricity systems, and Kerry Lynn for the comment on the
>>>          Demand/Response scenario.
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 27]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       9. Open Issues
>>>
>>>          "EDITOR NOTE: use the latest definition from
>> draft-parello-eman-
>>>          definitions"
>>>
>>>          OPEN ISSUE 1: Relevant IEC standards for application for EMAN
>>>            Applicability Statement document can provide guidance on the
>>>            issue of what is appropriate standard used by EMAN
>>>
>>>            IEC 61850-7-4 has been extensively used in EMAN WG
>> documents.
>>>            The other IEC documents referred for possible use are IEC
>>>            61000-4-30, IEC 62053-21 and IEC 62301.
>>>
>>>            There is feedback that IEC 61850-7-4 applies only to sub-
>>>            stations ?
>>>
>>>
>>>
>>>          OPEN ISSUE 2: Should review ASHRAE SPC 201P standard when it
>> is
>>>          released for public review
>>>
>>>            . Need to review ASHRAE information model and the use cases
>>>               and how it relates to EMAN
>>>
>>>
>>>
>>>          OPEN ISSUE 3: Review ALL requirements to ensure that they can
>> be
>>>          traced to a use case
>>>            . Missing is an use case for power quality
>>>
>>>          OPEN ISSUE 4: Question for the WG. Should we have unique use
>>>          cases that introduce specific requirements ? or can there be
>>>          some overlap between use cases ?
>>>
>>>          Any use cases out of scope scenarios ?
>>>
>>>
>>>
>>>       10. References
>>>
>>>       10.1. Normative References
>>>
>>>          [RFC3411] An Architecture for Describing Simple Network
>>>                  Management Protocol (SNMP) Management Frameworks, RFC
>>>                  3411, December 2002.
>>>
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 28]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       10.2. Informative References
>>>
>>>
>>>          [DASH] "Desktop and mobile Architecture for System Hardware",
>>>                  http://www.dmtf.org/standards/mgmt/dash/
>>>
>>>          [NIST]  http://www.nist.gov/smartgrid/
>>>
>>>          [Ecma-SDC] Ecma TC38 / SDC Task Group, "Smart Data Centre
>>>                  Resource Monitoring and Control (DRAFT)", March 2011.
>>>
>>>          [ENERGY] http://en.wikipedia.org/wiki/Kilowatt_hour
>>>
>>>          [EMAN-AS] Tychon, E., B. Schoening,MouliChandramouli, Bruce
>>>                  Nordman, "Energy Management (EMAN) Applicability
>>>                  Statement", draft-tychon-eman-applicability-statement-
>>>                  04.txt, work in progress, October 2011.
>>>
>>>          [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and
>>>                  M. Chandramouli, "Requirements for Energy Management
>> ",
>>>                  draft-ietf-eman-requirements-04 (work in
>> progress),July
>>>                  2011.
>>>
>>>          [EMAN-MONITORING-MIB] M. Chandramouli, Schoening, B., Dietz,
>> T.,
>>>                  Quittek, J. and B. Claise  "Energy and Power
>> Monitoring
>>>                  MIB ", draft-ietf-eman-monitoring-mib-00,August 2011.
>>>
>>>          [EMAN-AWARE-MIB] J. Parello, and B. Claise, "draft-ietf-eman-
>>>                  energy-aware-mib-02", work in progress, July 2011.
>>>
>>>          [EMAN-FRAMEWORK] Claise, B., Parello, J., Schoening, B., and
>> J.
>>>                  Quittek, "Energy Management Framework", draft-ietf-
>>>                  eman-framework-02 ,July 2011.
>>>
>>>          [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz,
>>>                  "Definition of Managed Objects for Battery Monitoring"
>>>                  draft-ietf-eman-battery-mib-02.txt, July 2011.
>>>
>>>          [EMAN-DEF] J. Parello"Energy Management Terminology", draft-
>>>                  parello-eman-definitions-03
>>>
>>>          [DMTF] "Power State Management ProfileDMTFDSP1027  Version
>> 2.0"
>>>                  December2009.
>>>
>> http://www.dmtf.org/sites/default/files/standards/docum
>>>                  ents/DSP1027_2.0.0.pdf
>>>
>>>          [ESTAR]  http://www.energystar.gov/
>>>
>>>
>>>               Expires April 31, 2012        [Page 29]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>
>>>          [ISO]    http://www.iso.org/iso/pressrelease.htm?refid=Ref1434
>>>
>>>          [SGRID]  http://collaborate.nist.gov/twiki-
>>>
>> sggrid/bin/view/SmartGrid/SGIPWorkingGroupsAndCommittee
>>>                  s
>>>
>>>
>>>          [ASHRAE] http://collaborate.nist.gov/twiki-
>>>                  sggrid/bin/view/SmartGrid/PAP17Information
>>>
>>>          [PAP17] http://collaborate.nist.gov/twiki-
>>>
>> sggrid/bin/view/SmartGrid/PAP17FacilitySmartGridInforma
>>>                  tionStandard
>>>
>>>          [ZIGBEE] http://www.zigbee.org/
>>>
>>>          [ISO]  http://www.iso.org/iso/pressrelease.htm?refid=Ref1337
>>>
>>>          [DSP0004] DMTF Common Information Model (CIM) Infrastructure,
>>>                  DSP0004, May 2009.
>>>
>> http://www.dmtf.org/standards/published_documents/DSP00
>>>                  04_2.5.0.pdf
>>>
>>>          [DSP1027] DMTF Power State Management Profile, DSP1027,
>> December
>>>                  2009.
>>>
>> http://www.dmtf.org/standards/published_documents/DSP10
>>>                  27_2.0.0.pdf
>>>
>>>          [PWG5106.4]IEEE-ISTO PWG Power Management Model for Imaging
>>>                  Systems v1.0, PWG Candidate Standard 5106.4-2011,
>>>                  February 2011.ftp://ftp.pwg.org/pub/pwg/candidates/cs-
>>>                  wimspower10-20110214-5106.4.mib
>>>
>>>          [PWG5106.5] IEEE-ISTO PWG Imaging System Power MIB v1.0, PWG
>>>                  Candidate Standard 5106.5-2011, February 2011.
>>>
>>>          [IEC62301] International Electrotechnical Commission, "IEC
>> 62301
>>>                  Household electrical appliances  Measurement of
>> standby
>>>                  power", Edition 2.0, 2011.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 30]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>
>>>
>>>       Authors' Addresses
>>>
>>>          Emmanuel Tychon
>>>          Cisco Systems, Inc.
>>>          De Keleetlaan, 6A
>>>          B1831 Diegem
>>>          Belgium
>>>          Email: etychon@cisco.com
>>>
>>>
>>>          Brad Schoening
>>>          44 Rivers Edge Drive
>>>          Little Silver, NJ 07739
>>>          USA
>>>          Email:brad@bradschoening.com
>>>
>>>
>>>          MouliChandramouli
>>>          Cisco Systems, Inc.
>>>          Sarjapur Outer Ring Road
>>>          Bangalore,
>>>          India
>>>          Phone: +91 80 4426 3947
>>>          Email: moulchan@cisco.com
>>>
>>>
>>>          Bruce Nordman
>>>          Lawrence Berkeley National Laboratory
>>>          1 Cyclotron Road, 90-4000
>>>          Berkeley  94720-8136
>>>          USA
>>>
>>>          Phone: +1 510 486 7089
>>>          Email: bnordman@lbl.gov
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>               Expires April 31, 2012        [Page 31]
>>>
>>>
>>>
>
>


--------------070709070509000404070408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Brad,
    

      
Benoit,


A few comments on some of the larger points in your applicability
statement review comments from last month...

1)      bclaise:  "Zigbee Smart Energy 2.0 is based on IP, right? This should
be stressed."

Zigbee 1.x is not based upon IP. But Zigbee 2.0, if adopted, is designed
to interoperate with IP, but is still a draft at this point.  I think our
applicability statement should probably focus on Zigbee 1.x which has seen
wide deployment, with market forecasts for 36M Zigbee devices in 2011
(source: On Research).

    

    Don't you want to say a few words about Zigbee 2.0 anyway, as work
    in progress?

    

    

      


2)      bclaise:  "power caping is something that could be done in a management
app using the EMAN Mib.  E.g., when polling for current usage, if this crosses a powercap use EMAN Mib to set the power state to a lower level."

The more conventional use case seems to define the power cap on a device,
and have that device enforce the power cap.  This seems to have derived
from an HP product feature (Dynamic Power Capping - DPC) that has seen
only limited adoption to date by other
vendors.  The use of the term is almost always 'dynamic power capping',
implying its autonomous.  EMAN could be used to set the power caps
(although we lack an attribute for this at present), or monitor
conformance with a power capping policy.  On the other hand, its biggest
use case to-date is as an HP vendor proprietary feature.

The use of power caping is also at variance with with ACPI and Intel's
experience with CPU dynamic frequency and voltage scaling (DFVS).  Their
experience show that "race to halt" was usually a more effective power
management strategy than simply reducing the CPU frequency to reduce power
usage.

When the goal is to minimize energy consumption, capping power might not
be the optional solution.[1]

        1. http://www.ok-labs.com/_assets/ATC-161Paper_McCammon.pdf

    

    Understood.

    When I read section 2.15 "power capping", I'm wondering, as a
    reader, what is the link with EMAN.

    This is what I was trying to clarify. I stand corrected with your
    explanation. However, the initial concern remains: please explain
    the link with EMAN, even if this case a statement such as "not
    covered by the current EMAN architecture" would be good enough.

    

      


3)      bclaise:  Question: what is the relationship with EMAN. If none,
mentions it along with a list of pros/cons. I mean: why should an implementator chose EMAN versus DASH?

DASH is a Web management (webem) protocol.  There should be no confusion
that EMAN/SNMP and DASH/HTTP are entirely different protocols.  What we
can stress is that while the protocols are incompatible, the EMAN data
model can be aligned, where appropriate, with the DASH model.  Afterall,
DASH has been itself been aligned with the prior power management standard
ACPI.

So, I propose adding something like:

        "While the SNMP and WebEM communication protocols are incompatible, the
EMAN data model should be aligned whenever possible, with the DASH model"

    

    Well, this is an applicability statement, not a requirement draft,
    or an architecture.

    So you have to explain the relationship, if any, between EMAN and
    DASH.

    Some text around what you explained is more appropriate:

    

      
DASH is a Web management (webem) protocol.  There should be no confusion
that EMAN/SNMP and DASH/HTTP are entirely different protocols.  What we
can stress is that while the protocols are incompatible, the EMAN data
model can be aligned, where appropriate, with the DASH model.  Afterall,
DASH has been itself been aligned with the prior power management standard
ACPI.

    

    Regards, Benoit (as a contributor)

    

      


Regards,



Brad Schoening



      

        

-----Original Message-----
From: Benoit Claise (bclaise)
Sent: Saturday, November 12, 2011 8:25 PM
To: eman mailing list; Emmanuel Tychon (etychon); Mouli Chandramouli
(moulchan); Bruce Nordman; Brad Schoening
Subject: draft-tychon-eman-applicability-statement-05: review

Dear authors,

Thanks for producing this new version. Much appreciated.
I specifically like the structure you put in place with "target
devices", "how powered", "reporting"
See inline for some more comments.

Regards, Benoit (as a contributor)


        

          
      Energy Management Working Group                          E.


        

        
Tychon


        

          
     Internet Draft                                  Cisco Systems


        

        
Inc.


        

          
     Intended status: Informational                        B.


        

        
Schoening


        

          
     Expires: April 31, 2012                     Independent


        

        
Consultant


        

          
                                                     Mouli


        

        
Chandramouli


        

          
                                                     Cisco Systems


        

        
Inc.


        

          
                                                          Bruce


        

        
Nordman


        

          
                                  Lawrence Berkeley National


        

        
Laboratory


        

          
                                                       October 31,


        

        
2011


        

          



                Energy Management (EMAN) Applicability Statement
                  draft-tychon-eman-applicability-statement-05


     Status of this Memo

        This Internet-Draft is submitted to IETF in full conformance
        with the provisions of BCP 78 and BCP 79.

        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups.  Note that other groups may also distribute working
        documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of six
        months and may be updated, replaced, or obsoleted by other
        documents at any time. It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as


        

        
"work


        

          
        in progress."

        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

        The list of Internet-Draft Shadow Directories can be accessed


        

        
at


        

          
        http://www.ietf.org/shadow.html

        This Internet-Draft will expire on April 31, 2012.


     Copyright Notice

        Copyright (c) 2011 IETF Trust and the persons identified as


        

        
the


        

          
        document authors. All rights reserved.








        

        
<Tychon, et Al.>              Expires April 31, 2012       [Page 1]


        

          



        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        This document is subject to BCP 78 and the IETF Trust's Legal
        Provisions Relating to IETF Documents
        (http://trustee.ietf.org/license-info) in effect on the date


        

        
of


        

          
        publication of this document. Please review these documents
        carefully, as they describe your rights and restrictions with
        respect to this document. Code Components extracted from this
        document must include Simplified BSD License text as described
        in Section 4.e of the Trust Legal Provisions and are provided
        without warranty as described in the Simplified BSD License.


     Abstract

        The objective of Energy Management (EMAN)is to provide an


        

        
energy


        

          
        management framework for networked devices. This document
        presents the applicability of the EMAN framework for a variety
        of scenarios. This document lists use cases and target devices
        that can potentially implement the EMAN framework and


        

        
associated


        

          
        SNMP MIB modules. These use cases are useful for identifying
        monitoring requirements that need to be considered. Further,


        

        
we


        

          
        describe the relationship of the EMAN framework to relevant
        other energy monitoring standards and architectures.


     Table of Contents

      1. Introduction


        

        
................................................3


        

          
        1.1. Energy Management Overview
..............................4
        1.2. Energy Measurement
......................................5
        1.3. Energy Management
.......................................5
        1.4. EMAN Framework Application
..............................6
        1.5. EMAN WG Document Overview
...............................6
      2. Scenarios and Target Devices
................................7
        2.1. Network Infrastructure Energy Objects
...................7
        2.2. Devices Powered and Connected to a Network Device
.......8
        2.3. Devices Connected to a Network
..........................9
        2.4. Power Meters
............................................9
        2.5. Mid-level Managers
.....................................10
        2.6. Gateways to Building Systems
...........................11
        2.7. Home Energy Gateways
...................................12
        2.8. Data Center Devices
....................................13



        

        
       2.9. Energy Storage Devices ................................14


        

          
        2.10. Ganged Outlets on a PDU Multiple Power Sources


        

        
........14


        

          
        2.11. Industrial Automation Networks
  ......................15
        2.12. Printers
           ...................................15
        2.13. Off-Grid Devices
......................................17
        2.14. Demand/Response
  .....................................17


<Tychon, et al.>             Expires April 31, 2012        [Page 2]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        2.15. Power Capping
  ........................................18
      3. Use Case Patterns
 ..........................................18
        3.1. Metering
 ...............................................18
        3.2. Metering and Control
 ...................................19
        3.3. Power Supply, Metering and Control
 .....................19
        3.4. Multiple power sources
 .................................19
      4. Relationship of EMAN to other Standards
 ....................19
        4.1. Data Model and Reporting
 ...............................20
              4.1.1. IEC - CIM.


        

        
......................................20


        

          
              4.1.2. DMTF


        

        
............................................20


        

          
              4.1.3. ODVA


        

        
............................................21


        

          
              4.1.4. Ecma SDC


        

        
........................................22


        

          
              4.1.5. IEEE-ISTO Printer Working Group (PWG)


        

        
...........22


        

          
              4.1.6. ASHRAE


        

        
..........................................23


        

          
              4.1.7. ZigBee


        

        
..........................................24


        

          
        4.2. Measurement
 ............................................24
              4.2.1. ANSI C12


        

        
........................................24


        

          
              4.2.2. IEC62301


        

        
........................................24


        

          
        4.3. Other
 ..................................................25
              4.3.1. ISO


        

        
.............................................25


        

          
              4.3.2. EnergyStar


        

        
......................................26


        

          
              4.3.3. SmartGrid


        

        
.......................................26


        

          
      5. Limitations
 ................................................27
      6. Security Considerations
 ....................................27
      7. IANA Considerations
 ........................................27
      8. Acknowledgements
 ...........................................27
      9. Open Issues
  ...............................................28
      10. References
 ................................................28
        10.1. Normative References
 ..................................28
        10.2. Informative References
 ................................29



     1. Introduction

        The focus of the Energy Management (EMAN) framework is energy
        monitoring and management of energy objects [EMAN-DEF].  The
        scope of devices considered are network equipment and its



        

        
       components, and devices connected directly or indirectly to


        

          
        the network. The EMAN framework enables monitoring i.e.;
        heterogeneous devices to report their energy consumption, and
        secondly, if permissible, enables control policies for energy
        savings.  There are multiple scenarios where this is
        desirable, particularly considering the increased importance
        of limiting consumption of finite energy resources and
        reducing operational expenses.



<Tychon, et al.>             Expires April 31, 2012        [Page 3]




        

        
    Internet-Draft     EMAN Applicability Statement      October 2011


        

          

        The EMAN framework describes how energy information can be


        

        
Introduce a reference.


        

          
        retrieved from IP-enabled devices using Simple Network
        Management Protocol (SNMP), specifically, Management


        

        
Information


        

          
        Base (MIBs) for SNMP.

        This document describes typical applications of the EMAN
        framework, as well as its opportunities and limitations. Other
        standards that are similar to EMAN but address different


        

        
domains


        

          
        are described. This document contains references to those


        

        
other


        

          
        standards and describes how they relate to the EMAN framework.

     1.1. Energy Management Overview

        First, a brief introduction to the definitions of Energy and
        Power are presented. A draft on terminology has been submitted
        so that to reach a consensus on the definitions of commonly


        

        
used


        

          
        terms in the EMAN WG. While energy is available in many forms,
        EMAN addresses only the electrical energy consumed by devices
        connected to a network.

        Energy is the capacity to perform work. Electrical energy is
        typically expressed in kilowatt-hour units (kWh) or other
        multiples of watt-hours (Wh). One kilowatt-hour is the
        electrical energy used by a 1 kilowatt device for one hour.
        Power is the rate of electrical energy flow. In other words,
        power = energy / time. Power is often measured in watts.


        

        
Billing


        

          
        is based on electrical energy (measured in kWh) supplied by


        

        
the


        

          
        utility.

        Towards the goal of increasing the energy efficiency in


        

        
networks


        

          
        and buildings, a first step is to enable energy objects to
        report their energy usage over time. The EMAN framework
        addresses this problem with an information model for some
        electrical equipment: energy object identification, energy
        object context, power measurement and power measurement
        attributes.


        

        
and power quality (even if we need a consensus on the name)


        

          
        The EMAN WG framework defines SNMP MIB modules based on the
        information model.  By implementing the SNMP MIB modules, any
        energy object can report its energy consumption according to


        

        
the


        

          
        information model. In that context, it is important to
        distinguish energy objects that can report their own energy
        usage from parent devices that can also collect and aggregate
        energy usage of children energy objects.

        The list of target devices and scenarios considered for Energy
        Management are presented in Section 2 with detailed examples.


<Tychon, et al.>             Expires April 31, 2012        [Page 4]




        

        
    Internet-Draft     EMAN Applicability Statement      October 2011


        

          


     1.2. Energy Measurement

        More and more devices are able to measure and report their own
        energy consumption. Smart power strips and some Power over
        Ethernet (PoE) switches can meter consumption of connected
        devices.  However, when managed and reported through


        

        
proprietary


        

          
        means, this information is minimally useful at the enterprise
        level.

        The primary goal of the EMAN MIBs is to enable reporting and
        management within a standard framework that is applicable to a
        wide variety of end devices, meters, and proxies. This enables


        

        
a


        

          
        management system to know who's consuming what, when, and how


        

        
at


        

          
        any time by leveraging existing networks, across various
        equipment, in a unified and consistent manner.

        Given that an energy object can consume energy and/or provide
        energy to other devices, there are three types of meters for
        energy measurement: energy input to a device, energy supplied


        

        
to


        

          
        other devices, and net (resultant) energy consumed (the
        difference between energy input and provided).

     1.3. Energy Management

        Beyond energy monitoring, the EMAN framework provides


        

        
mechanisms


        

          
        for energy control.

        There are many cases where reducing energy consumption of
        devices is desirable, such as when the device utilization


        

        
islow
islow -> is low


        

          
        or when the electricity is expensive or in short supply.

        In some cases, energy control requires considering the energy
        object context. For instance, in a building: all phones would
        not usually be turned off to keep some still available in case
        of emergency; office cooling is usually not turned off totally
        during non-work hours, but the comfort level is reduced; and


        

        
so


        

          
        on.

        Energy object control requires flexibility and support for
        different polices and mechanisms: from centralized management
        with a network management station, to autonomous management by
        individual devices, and alignment with dynamic demand-response
        mechanisms.

        The EMAN framework can be used as a tool for the


        

        
demand/response


        

          
        scenario where in response to time-of-day fluctuation of


        

        
energy


        

          

<Tychon, et al.>             Expires April 31, 2012        [Page 5]




        

        
    Internet-Draft     EMAN Applicability Statement      October 2011


        

          

        costs or possible energy shortages, it is possible to respond
        and reduce the energy consumption for the network devices,
        effectively changing its power state.


     1.4. EMAN Framework Application


        A Network Management System (NMS) is the entity that requests
        information from compatible devices using SNMP protocol. It


        

        
may


        

          
        be a system which also implements other network management
        functions, e.g. security management, identity management and


        

        
so


        

          
        on), or one that only deals exclusively with energy in which
        case it is called EnMS, Energy Management System. It may be
        limited to monitoring energy use, or it may also implement
        control functions. In a typical application of the EMAN
        framework, management software collects energy information for
        devices in the network.

        Energy management can be implemented by extending existing


        

        
SNMP


        

          
        support to the EMAN specific MIBs. SNMP provides an industry
        proven and well-known mechanism to discover, secure, measure,
        and control SNMP-enabled end devices.  The EMAN framework
        provides an information and data model to unify access to a
        large range of devices. The scope of the target devices and


        

        
the


        

          
        network scenarios considered for energy management are listed


        

        
in


        

          
        Section 2.

     1.5. EMAN WG Document Overview


        

        
I would move this section in 1.2, because you refer multiple times to
the documents


        

          
        The EMAN working group charter calls for producing a series of
        Internet standard drafts in the area of energy management. The
        following drafts are currently under discussion in the working
        group.


        

        
Write sentences as if the WG did the work already.


        

          
          Applicability Statement [EMAN-AS] This draft presents the


        

        
use
Same comment. Change draft -> document
Note that there are multiple instances of this open issue.


        

          
          cases and scenarios for energy monitoring.  In addition,


        

        
other


        

          
          relevant energy standards and architectures are listed.

          Requirements [EMAN-REQ] This draft presents the requirements
          of Energy Monitoring and the scope of the devices


        

        
considered.
Energy Monitoring -> Energy Management


        

          
          Framework [EMAN-FRAMEWORK] This draft defines the


        

        
terminology


        

          
          and explains the different concepts associated with energy
          monitoring; these are used in the MIB modules.


        

        
[EMAN-FRAMORK] says

   This document defines a framework for providing Energy
        Management for devices within or connected to communication
        networks.

Energy Monitoring -> Energy Management
Note: multiple instance of this issue, please check "Energy Monitoring"
throughout the draft.


        

          


<Tychon, et al.>             Expires April 31, 2012        [Page 6]




        

        
    Internet-Draft     EMAN Applicability Statement      October 2011


        

          

          Energy-Aware MIB [EMAN-AWARE-MIB] This draft proposes a MIB
          module that characterizes a device's identity and context.

          Monitoring MIB [EMAN-MONITORING-MIB] This draft defines a


        

        
MIB


        

          
          module for monitoring the power and energy consumption of a
          device. In addition, the MIB module contains an optional
          module for power quality metrics.

          Battery MIB [EMAN-BATTERY-MIB] This draft contains a MIB
          module for monitoring characteristics of an internal


        

        
battery.


        

          
          Energy Management Terminology [EMAN-DEF] This draft lists


        

        
the


        

          
          definitions and terms used in the Energy Management Working
          Group.

     2. Scenarios and Target Devices

        In this section a selection of scenarios for energy management
        are presented. The fundamental objective of the use cases is


        

        
to


        

          
        list important network scenarios that the EMAN framework


        

        
should


        

          
        solve. These use cases then drive the requirements for the


        

        
EMAN


        

          
        framework.

        Each scenario lists target devices for which the energy
        management framework can be applied, as well as how the
        reported-on devices are powered, and how the reporting is
        accomplished.    While there may be some overlap between some


        

        
of


        

          
        the use cases, the use cases serve as illustrative network
        scenarios EMAN framework should solve.

     2.1. Network Infrastructure Energy Objects

        This scenario covers network devices and their components.


        

        
Power


        

          
        management of energy objects is considered as a fundamental
        requirement of energy management of networks.

        It can be important to monitor the power state and energy
        consumption of these energy objects at a granularity level


        

        
finer


        

          
        than just the entire device. For these devices, the chassis
        draws power from one or more sources and feeds all its


        

        
internal


        

          
        components. It is highly desirable to have monitoring


        

        
available


        

          
        for individual components, such as line cards, processors, and
        hard drives as well as peripherals like USB devices.

        As an illustrative example, consider a switch with the


        

        
following


        

          
        grouping of sub-entities for which energy monitoring could be
        useful.


<Tychon, et al.>             Expires April 31, 2012        [Page 7]




        

        
    Internet-Draft     EMAN Applicability Statement      October 2011


        

          


          .  physical view: chassis (or stack), line cards, service
             modules of the switch


        

        
You should explain
    that the ENTITY-MIB provides the containment tree,
    that the MIB modules are based on the ENTITY-MIB indexing,
    that a component might be EO and that the ENTITY-containment tree
will express if it belongs to another EO (example: line card EO in a
chassis EO, assuming that both EOs can meter the power consumption)


        

          
          .  component view: CPU, ASICs, fans, power supply, ports
             (single port and port groups), storage and memory
          .  logical view: system, data-plane, control-plane, etc.


        

        
Question: how can we get the logical view?


        

          
        The essential properties of this use case are:

          . Target devices: Network devices such as routers, switches
             and their components.
          . How powered: Typically by a PDU on a rack or from a wall
             outlet. The components of a device are powered by the
             device chassis.
          . Reporting: Direct power measurement can be performed at a
             device level. Components can report their power


        

        
consumption


        

          
             directly or the chassis/device that can report on behalf


        

        
of


        

          
             some components.

     2.2. Devices Powered and Connected to a Network Device


        This scenario covers Power over Ethernet (PoE) devices. A PoE
        Power Sourcing Equipment (PSE) device (e.g. a PoE switch)


        

        
Should refer to the POE RFC for the terms such PSE and PD


        

          
        provides power to a Powered Device (PD) (e.g. a desktop


        

        
phone).


        

          
        For each port, the PSE can control the power supply (switching
        it on and off) and monitor actual power provided. PoE devices
        obtain network connectivity as well as the power supply for


        

        
the


        

          
        device over a single connection so the PSE can determine which
        device to allocate each port's power to.

        PoE ports on a switch are commonly connected to IP phones,
        wireless access points, and IP cameras. The switch powers
        itself, as well as supplies power to downstream PoE ports.
        Monitoring the power consumption of the switch (Energy Object
        Parent) and the power consumption of the PoE end-points(Energy
        Object Children) is a simple use case of this scenario.

        The essential properties of this use case are:

          . Target devices: Power over Ethernet devices such as IP
             Phones, Wireless Access Points, and IP cameras.
          . How powered: PoE devices are connected to the switch port
             which supplies power to those devices.
          . Reporting:  PoE device power consumption is often measured
             and reported at the switch (PSE) port which supplies


        

        
power


        

          
             for the PoE device.


        

        
As I said, I like this structure but what you're missing is:
               . Parent/Child: explains who is the parent and who is
the child, if applicable
               . Relationship: explains which relationship are
applicable, if any (*)

(*) this is really missing for some of the examples below
Actually, it would even be better if the different use cases would
contain drawings such as
http://www.ietf.org/proceedings/81/slides/eman-4.pdf -> slide 14 and 15


        

          

<Tychon, et al.>             Expires April 31, 2012        [Page 8]




        

        
    Internet-Draft     EMAN Applicability Statement      October 2011


        

          


        In this case, the PoE devices do not need to directly support
        the EMAN framework, only the Power Sourcing Equipment (PSE)
        does.


        

        
Not correct. The answer is "it depends". If the PD, along with its own
UUID,  might be represented in the PSE


        

          

     2.3. Devices Connected to a Network

        The use case covers the metering relationship between an


        

        
energy
"metering relationship". This should prove my point that you should add
Relationship in your bullet points.


        

          
        object receiving power from a source such as a power brick,


        

        
and


        

          
        have an independent network connection to a parent energy


        

        
object


        

          
        such as a switch.

        In continuation to the previous example is a switch port that


        

        
previous example -> example in the section 2.2


        

          
        has both a PoE connection powering an IP Phone, and a PC has a
        daisy-chain connection to the IP Phone for network


        

        
connectivity.


        

          
        The PC has a network connection from the switch, but draws


        

        
power


        

          
        from the wall outlet, in contrast to the IP phone draws power
        from the switch.

        It is also possible to consider a simple example of PC which


        

        
has


        

          
        a network connection but draws power from the wall outlet or
        PDU.

        The PC in this case, is an non-PoE device, can report power
        usage by itself, for instance through the EMAN framework.

        The essential properties of this use case are:

          . Target devices:  Abroad set of energy objects that have a
             network connection, but receive power supply from the


        

        
wall


        

          
             outlet.
          . How powered:  These devices receive power supply from the
             wall outlet or a PDU.


        

        
"these devices" -> make sure that you distinguish which one you're
talking about. Switch, POE phone, PC


        

          
          . Reporting:  There are two models: devices that can measure
             and report the power consumption directly via the EMAN
             framework, and those that communicate it to the network
             device (switch) and the switch can report the device's
             power consumption via the EMAN framework.

     2.4. Power Meters

        Some electrical devices are not equipped with instrumentation


        

        
to


        

          
        measure their own power and accumulated energy consumption.
        External meters can be used to measure the power consumption


        

        
of


        

          
        such electrical devices.



<Tychon, et al.>             Expires April 31, 2012        [Page 9]




        

        
    Internet-Draft     EMAN Applicability Statement      October 2011


        

          

        This use case covers the proxy relationship of energy objects
        able to measure or report the power consumption of external
        electrical devices, not natively connected to the network.
        Examples of such metering devices are smart PDUs and smart
        meters.

        Three types of external metering are relevant to EMAN: PDUs,
        standalone meters, and utility meters.  External meters can
        measure these properties for a single device or for a set of
        devices.


        

        
NEW:
        External meters can measure these properties for a single
device or for a set of
        devices. Three types of external metering are relevant to EMAN:

PDUs,
        standalone meters, and utility meters.



        

          
        Power Distribution Unit (PDUs) in a rack have inbuilt meters


        

        
for


        

          
        each socket and the PDUs can measure the power supplied to


        

        
each


        

          
        device in an equipment rack. The PDUs have remote management
        functionality which can be used to measure and possibly


        

        
control


        

          
        the power supply of each outlet.

        Standalone meters can be placed anywhere in a power


        

        
distribution


        

          
        tree, and can measure the power consumption.
        Utility meters monitor and report accumulated power


        

        
consumption


        

          
        of the entire building. There can be sub-meters to measure the
        power consumption of a portion of the building.

        The essential properties of this use case are:

          . Target devices:  PDUs and Smart Meters.


        

        
confused by the two examples, while you speak about 3 types of external
metering


        

          
          . How powered:  From traditional mains power but as passed
             through a PDU or meter.
          . Reporting:  The PDUs reports power consumption of
             downstream devices. There is commonly only one device
             downstream of each outlet, but there could be many.


        

        
There


        

          
             can be external meters in between the power supply and
             device and the meters can report the power consumption of
             the device.

     2.5. Mid-level Managers

        This use case covers aggregation of energy management data at
        "mid-level managers" that can provide energy management
        functions for themselves as well as associated devices.

        A switch can provide energy management functions for all


        

        
devices


        

          
        connected to its ports, whether or not these devices are


        

        
powered


        

          
        by the switch or whether the switch provides immediate network
        connectivity to the devices; such a switch is a mid-level
        manager, offering aggregation of power consumption data for
        devices it does not supply power to them.  Devices report


        

        
their


        

          

<Tychon, et al.>             Expires April 31, 2012        [Page 10]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        EMAN data to the switch and the switch aggregates the data for
        these data.

        The essential properties of this use case are summarized as
        follows:

          . Target devices: network devices which can perform
             aggregation; commonly a switch or a proxy
          . How powered:  Mid-level managers can be are commonly
             powered by a PDU or from a wall outlet but there is no
             limitation.


        

        
Some common language would be nice. "any method" is used in section 2.11


        

          
          . Reporting:  The middle-manager aggregates the energy data
             and reports that data to a NMS or higher mid-level


        

        
manager.


        

          
     2.6. Gateways to Building Systems

        This use case describes energy management of buildings.


        

        
Building


        

          
        Management Systems (BMS) have been in place for many years


        

        
using


        

          
        legacy protocols not based on IP. In these buildings, a


        

        
gateway


        

          
        can provide a proxy relationship between IP and legacy


        

        
building


        

          
        automation protocols. The gateway can provide an interface
        between the EMAN framework and relevant building management
        protocols.

        Due to the potential energy savings, energy management of
        buildings has received significant attention. There are


        

        
gateway


        

          
        network elements to manage the multiple components ofa


        

        
building


        

          
        energy management system such as Heating, Ventilation, and Air
        Conditioning (HVAC), lighting, electrical, fire and emergency
        systems, elevators, etc. The gateway device uses legacy


        

        
building


        

          
        protocols to communicate with those devices, collects their
        energy usage, and reports the results.

        The gateway performs protocol conversion between many facility
        management devices. The gateway communicates via RS-232/RS-485
        interfaces, Ethernet interfaces, and protocols specific to
        building management such as BACNET, MODBUS, or Zigbee.


        

        
References please


        

          
        The essential properties of this use case are :

          . Target devices: Building energy management devices - HVAC
             systems, lighting, electrical, fire and emergency


        

        
systems.


        

          
             There are meters for each of the sub-systems and the


        

        
energy


        

          
             data is communicated to the proxy using legacy protocols.
          . How powered: Any method, including directly from mains
             power or via a UPS.



<Tychon, et al.>             Expires April 31, 2012        [Page 11]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

          . Reporting: The gateway collects energy consumption of non-
             IP systems and communicates the data via the EMAN
             framework.

     2.7. Home Energy Gateways

        This use case describes the scenario of energy management of a
        home. The home energy gateway is another example of a proxy


        

        
that


        

          
        interfaces to the electrical appliances and other devices in a
        home and also has an interface to the utility. This gateway


        

        
can


        

          
        monitor and manage electrical equipment (refrigerator,
        heating/cooling, washing machine etc.) possibly using one of


        

        
the


        

          
        many protocols (ZigBee, Smart Energy, ...) that are being
        developed for the home area network products and considered in
        standards organizations.

        In its simplest form, metering can be performed at home.


        

        
Beyond


        

          
        the metering, it is also possible implement energy saving
        policies based on energy pricing from the utility grid. From


        

        
an


        

          
        EMAN point of view, the information model that been


        

        
investigated


        

          
        can be applied to the protocols under consideration for energy
        monitoring of a home.



        The essential properties of this use case are:

          . Target devices: Home energy gateway and Smart meters in a
             home.


        

        
In terms of capitalization, there are sometimes some strange things. See

"Smart" above.


        

          
          . How powered:  Any method.
          . Reporting: Home energy gateway can collect power
             consumption of device in a home and possibly report the
             metering reading to the utility.

        Beyond the canonical setting of a home drawing power from the
        utility, it is also possible to envision an energy neutral
        situation wherein the buildings/homes that can produce and
        consume energy without importing energy from the utility grid.
        There are many energy production technologies such as solar
        panels, wind turbines, or micro generators. This use case
        illustrates the concept of self-contained energy generation


        

        
and


        

          
        consumption and possibly the aggregation of the energy use of
        homes.






<Tychon, et al.>             Expires April 31, 2012        [Page 12]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

       2.8. Data Center Devices

        This use case describes energy management of a Data Center
        network.

        Energy efficiency of data centers has become a fundamental
        challenge of data center operation, as datacenters are big
        energy consumers and their infrastructure is expensive. The
        equipment generates heat, and heat needs to be evacuated


        

        
though


        

          
        a HVAC system.

        A typical data center network consists of a hierarchy of
        electrical energy objects.  At the bottom are servers mounted


        

        
on
Replace . by ;


        

          
        a rack; these are connected to the top-of-the-rack switches;
        these are connected to aggregation switches; those in turn
        connected to core switches.  Power consumption of all network
        elements and the servers in the Data center should be


        

        
measured.


        

          
        In addition, there are also network storage devices. Energy
        management can be implemented on different aggregation levels,
        such as network level, Power Distribution Unit (PDU) level,


        

        
and


        

          
        server level.

        The Data center network contains UPS to provide back-up power
        for the network devices in the event in the event of power
        outages. Thus from a Data center energy management point of
        view, in addition, to monitoring the energy usage of network
        devices, it is also important to monitor the remaining


        

        
capacity


        

          
        of the UPS.


        

        
"see some more information about the UPS in section 2.9"


        

          
        In addition to monitoring the power consumption, at a data
        center level, additional metrics such as power quality, power
        characteristics can be important metrics. The dynamic


        

        
variations


        

          
        in the input power supply from the grid referred to as power
        quality is one metric. Secondly, how the devices use the power
        can be referred to as power characteristics and it is also
        useful to monitor these metrics. Lastly, the power plate set
        will make it possible to know an aggregate of the potential
        worst-case power usage and compare it to the budgeted power in
        the data center.

        The essential properties of this use case are:

          . Target devices: All network devices in a data center, such
             as network equipment, servers, and storage devices.
          . How powered: Any method but commonly by a PDUs in racks.
          . Reporting: Devices may report on their own behalf, or for
             other connected devices as described in other use cases.


<Tychon, et al.>             Expires April 31, 2012        [Page 13]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          


     2.9. Energy Storage Devices

        There are two types of devices with energy storage: those


        

        
whose


        

          
        primary function is to provide power to another device (e.g. a
        UPS), and those with a different primary function, but have an
        energy storage as a component as an alternate internal power
        source (e.g. a notebook).  EMAN covers both types of products


        

        
in


        

          
        this use case.

        The energy storage can be a battery, or any other means to


        

        
store


        

          
        electricity such as a hydrogen cell.

        Some devices have an internal battery as a back-up or
        alternative source of power to mains power. When the


        

        
connection


        

          
        to the power supply of the device is disconnected, the device
        can run on the internal battery. As batteries have a finite
        capacity and lifetime, means for reporting the actual charge,
        age, and state of a battery are required.

        UPS can provide backup power for many devices in a data


        

        
centers


        

          
        for a finite period of time. Energy monitoring of such energy
        storage devices is vital from a data center network operations
        point of view. The UPS MIB provides a framework for monitoring
        the remaining capacity of the UPS.

        There are also battery systems for mobile towers particularly
        for use in remote locations. It is important to monitor the
        remaining battery life and raise an alarm when the battery


        

        
life


        

          
        is below a threshold.


        

        
Explain that the battery is a component, which containment can be
tracked thanks to the ENTITY-MIB.

We would need a special paragraph for the UPS. What is the link with the

UPS-MIB.


        

          
        The essential properties of this use case are:

          . Target devices: Devices that have an internal battery such
             as notebook PC and other mobile devices.
          . How powered: From internal batteries or mains power.
          . Reporting:  The device reports on its internal battery.


     2.10. Ganged Outlets on a PDU Multiple Power Sources

        This use case describes the scenario of multiple power sources
        of a devices and logical groupings of devices in a PDU.

        Some PDUs allow physical entities like outlets to be "ganged"
        together as a logical entity to simplify management.



<Tychon, et al.>             Expires April 31, 2012        [Page 14]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        This is particularly useful for servers with multiple power
        supplies, where each power supply is connected to a different
        physical outlet. Other implementations allow "gangs" to be
        created based on common ownership of outlets, such as business
        units, load shed priority, or other non-physical


        

        
relationships.


        

          
        Current implementations allow for an "M-to-N" mapping between
        outlet "gangs" and physical outlets, as with this example:

          . Outlet 1 - physical entity
          . Outlet 2 - physical entity
          . Outlet 3 - physical entity
          . Outlet 4 - physical entity
          . Outlet Gang A - virtual entity
          . Outlet Gang B - virtual entity

               o Gang A ->  Outlets 1, 2 and 3
               o Gang B ->  Outlets 3 and 4

        Note the allowed overlap on Outlet 3, which belongs to both
        "gangs."

        Each "Outlet Gang" entity reports the aggregated data from the
        individual outlet entities that comprise it and enables a


        

        
single


        

          
        point of control for all the individual outlet entities.


     2.11. Industrial Automation Networks

        Energy consumption statistics in the industrial sector are
        staggering. The industrial sector alone consumes about half of
        the world's total delivered energy, making it the largest end-
        use sector. Thus, the need for optimization of energy usage in
        this sector is natural.
        Industrial facilities consume energy in process loads, and in
        non-process loads.
        The essential properties of this use case are:

          . Target devices: Devices used in industrial automation
          . How powered: Any method.
          . Reporting: Currently, CIP protocol is currently used for
             reporting energy for these devices

     2.12. Printers

        This use case describes the scenario of energy monitoring and
        management of Printer devices.


<Tychon, et al.>             Expires April 31, 2012        [Page 15]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          


        Printers in this use case stand in for all imaging equipment,
        also including multi-function devices (MFDs), copiers,


        

        
scanners,


        

          
        fax machines, and mailing machines.  Energy use of printers


        

        
has


        

          
        been an industry concern for several decades, and they usually
        have sophisticated power management with a variety of


        

        
low-power


        

          
        modes, particularly for managing energy-intensive thermo-
        mechanical components. Printers also have long made extensive
        use of SNMP for end-user system interaction and for management
        generally, and cross-vendor management systems are available
        today to manage fleets of printers in enterprises.  Power
        consumption during active modes can vary widely, with high


        

        
peak


        

          
        levels.

        Printers today can expose detailed power state information,
        distinct from operational state information, with some


        

        
printers


        

          
        reporting transition states between stable long-term states.
        Many also support active setting of power states, and setting


        

        
of


        

          
        policies such as delay times when no activity will cause
        automatic transition to a lower power mode.  Other features
        include reporting on components of imaging equipment, counters
        for state transitions, and typical power levels by state,
        scheduling, and events/alarms.

        Some large printers also have a "Digital Front End" which is a
        computer that performs functions on behalf of the physical
        imaging system.  These will typically have their own presence


        

        
on


        

          
        the network and are sometimes separately powered.

        There are some unique characteristics of Printers from the


        

        
point


        

          
        of view energy monitoring. While the printer is not in use,
        there are timer based low power states (sleep, stand-by),


        

        
which


        

          
        consume very little power. On the other hand, while the


        

        
printer


        

          
        is printing or copying the cylinder needs to be heated so that
        power consumption is quite high but only for a short period of
        time (duration of the print job). Given this work load,


        

        
periodic


        

          
        polling of energy consumption would not suffice.

        Target Devices: All imaging equipment.

        How Powered: Typically via mains AC from a wall outlet

        Reporting: Devices report for themselves


        

        
Thinking some more about this "Reporting", I believe that that we should

tell what the implementers shoud do.
For example: "Devices report for themselves by implementing [EMAN-MON]"
Note that this is a generic comment for all use cases.


        

          





<Tychon, et al.>             Expires April 31, 2012        [Page 16]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

     2.13. Off-Grid Devices

        This use case concerns self-contained devices that use energy
        but are not connected to an infrastructure power delivery


        

        
grid.


        

          
        These devices typically scavenge energy from environmental
        sources such as solar energy or wind power. The device


        

        
generally


        

          
        contains a closely coupled combination of

          . power scavenging or generation component(s)
          . power storage component(s) (e.g., battery)
          . power consuming component(s)

        With scavenged power, the energy input is often dependent on


        

        
the


        

          
        random variations of the weather. These devices therefore
        require energy management both for internal control and remote
        reporting of their state. In order to optimize the performance
        of these devices and minimize the costs of the generation and
        storage components, it is desirable to vary the activity


        

        
level,


        

          
        and, hopefully, the energy requirements of the consuming
        components in order to make best use of the available stored


        

        
and


        

          
        instantaneously generated energy.  With appropriate energy
        management, the overall device can be optimized to deliver an
        appropriate level of service without over provisioning the
        generation and storage components.

        In many cases these devices are expected to operate
        autonomously, as continuous communications for the purposes of
        remote control is either impossible or would result in


        

        
excessive


        

          
        power consumption.  Non continuous polling requires the


        

        
ability


        

          
        to store and access later the information collected while the
        communication was not possible.

        Target Devices:  Remote network devices (mobile network) that
        consume and produce energy

        How Powered: Can be battery powered or using natural energy
        sources

        Reporting: Devices report their power usage but only
        occasionally.


     2.14. Demand/Response

        Demand/Response from the utility or grid is a common theme


        

        
that


        

          
        spans across some of the use cases. In some situations, in
        response to time-of-day fluctuation of energy costs or sudden


<Tychon, et al.>             Expires April 31, 2012        [Page 17]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        energy shortages due power outages, it may be important to
        respond and reduce the energy consumption of the network.
        From EMAN use case perspective, the demand/response scenario


        

        
can


        

          
        apply to a Data Center or a Building or a residential home. As


        

        
a


        

          
        first step, it may be important to monitor the energy
        consumption in real-time of a Data center or a building or


        

        
home


        

          
        which is already discussed in the previous use cases. Then


        

        
based


        

          
        on the potential energy shortfall, the Energy Management


        

        
System


        

          
        (EMS) could formulate a suitable response, i.e., the EMS could
        shut down some selected devices that may be considered
        discretionary or uniformly reduce the power supplied to all
        devices. For multi-site data centers it may be possible to
        formulate policies such as follow-the-moon type of approach,


        

        
by


        

          
        scheduling the mobility of VMs across Data centers in


        

        
different


        

          
        geographical locations.


        

        
        Target Devices:  ...

        How Powered: ...

        Reporting: ...


        

          
     2.15. Power Capping

        Power capping is a technique to limit the total power
        consumption of a server. This technique can be useful for


        

        
power


        

          
        limited data centers. Based on workload measurements, the


        

        
server


        

          
        can choose the optimal power state of the server in terms of
        performance and power consumption. When the server operates at
        less than the power supply capacity, it runs at full speed.


        

        
When


        

          
        the server power would be greater than the power supply
        capacity, it runs at a slower speed so that its power
        consumption matches the available power supply capacity. This
        gives vendors the option to use smaller, cost-effective power
        supplies that allow real world workloads to run at nominal
        frequency.


        

        
power caping is something that could be done in a management app using
the EMAN Mib.  E.g., when polling for current usage, if this crosses a
powercap use EMAN Mib to set the power state to a lower level.

        Target Devices:  ...

        How Powered: ...

        Reporting: ...


        

          




     3. Use Case Patterns


        

        
You have in the introduction somewhere what the section contains.
Because, reading that far, I was not obvious that you wanted to
summarize the different patterns in section 3.
If the intro had mentioned it, I would have the text with that in mind.


        

          
        The use cases presented above can be abstracted to the


        

        
following


        

          
        broad patterns.

     3.1. Metering

        -energy objects which have capability for internal metering


        

        
add a space


        

          
        - electrical devices which are metered by an external device





<Tychon, et al.>             Expires April 31, 2012        [Page 18]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

     3.2. Metering and Control

        - entities objects that do not supply power, butcan perform


        

        
only
butcan -> but can


        

          
        power metering for other devices


        

        
entity object -> energy objects
(multiple instances of this issue)


        

          
        - entities objects that do not supply power, can perform both
     metering and control for other devices


     3.3. Power Supply, Metering and Control

        - entities devices that supply power for other devices but do
        not perform power metering for those devices

        - entities that supply power for other devices and also


        

        
perform


        

          
        power metering

        - entities supply power for other devices and also perform


        

        
power


        

          
        metering and control for other devices



     3.4. Multiple power sources

        - entities that have multiple power sources and metering and
        control is performed by one source

        - entities that have multiple power sources and metering is
        performed by one source and control another source


        

        
Thinking some more about this section 3, aren't we covering all the
possible combinations of relationships from [EMAN-FMWK]?
Any gaps?


        

          


     4. Relationship of EMAN to other Standards

        EMAN as a framework is tied to other standards and efforts


        

        
that


        

          
        deal with energy. Existing standards are leveraged when
        possible.  EMAN helps enable adjacent technologies such as


        

        
Smart


        

          
        Grid.

        The standards most relevant and applicable to EMAN are listed
        below with a brief description of their objectives, the


        

        
current


        

          
        state and how that standard can be applied to EMAN.


        

        
"how that standard can be applied to EMAN."  I don't think it's the
goal.
We want to explain the relationship/connection with EMAN


        

          






<Tychon, et al.>             Expires April 31, 2012        [Page 19]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

     4.1. Data Model and Reporting

     4.1.1. IEC - CIM

        The International Electro-technical Commission (IEC) has
        developed a broad set of standards for power management.


        

        
Among


        

          
        these, the most applicable to EMAN is IEC 61850,a standard for
        the design of electric utility automation.  The abstract data
        model defined in 61850 is built upon and extends the Common
        Information Model (CIM). The complete 61850 CIM model includes
        over a hundred object classes and is widely used by utilities
        worldwide.

        This set of standards was originally conceived to automate
        control of a substation (facilities which transfer electricity
        from the transmission to the distribution system). While the
        original domain of 61850 is substation automation, the


        

        
extensive


        

          
        data model has been widely used in other domains, including
        Energy Management Systems (EMS).

        IEC TC57 WG19 is an ongoing working group to harmonize the CIM
        data model and 61850 standards.

        Concepts from IEC Standards have been reused in the EMAN WG
        drafts. In particular, AC Power Quality measurements have been
        reused from IEC 61850-7-4. The concept of Accuracy Classes for
        measurement of power and energy has been reused IEC 62053-21


        

        
and


        

          
        IEC 62053-22.


        

        
Is this inline with what you wrote before "The EMAN standard references
ANSI C12 accuracy classes."?


        

          
     4.1.2. DMTF

        The Distributed Management Task Force (DMTF)[DMTF] has
        standardized management solutions for managing servers and


        

        
PCs,


        

          
        including power-state configuration and management of elements
        in a heterogeneous environment.  These specifications provide
        physical, logical and virtual system management requirements


        

        
for


        

          
        power-state control.

        The EMAN standard references the DMTF Power Profile and Power
        State Series.

     4.1.2.1. Common Information Model Profiles

        The DMTF uses CIM-based (Common Information Model) 'Profiles'


        

        
to


        

          
        represent and manage power utilization and configuration of
        managed elements (note that this is not the 61850 CIM).  Key
        profiles for energy management are 'Power Supply' (DSP 1015),


<Tychon, et al.>             Expires April 31, 2012        [Page 20]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        'Power State' (DSP 1027) and 'Power Utilization Management'


        

        
(DSP


        

          
        1085).These profiles define monitoring and configuration of a
        Power Managed Element's static and dynamic power saving modes,
        power allocation limits and power states, among other


        

        
features.


        

          
        Reduced power modes can be established as static or dynamic.
        Static modes are fixed policies that limit power use or
        utilization. Dynamic power saving modes rely upon internal
        feedback to control power consumption.

        Power states are eight named operational and non operational
        levels.  These are On, Sleep-Light, Sleep-Deep, Hibernate,


        

        
Off-


        

          
        Soft, and Off-Hard.  Power change capabilities provide
        immediate, timed interval, and graceful transitions between


        

        
on,


        

          
        off, and reset power states.  Table 3 of the Power State


        

        
Profile


        

          
        defines the correspondence between the ACPI and DMTF power


        

        
state


        

          
        models, although it is not necessary for a managed element to
        support ACPI. Optionally, a TransitingToPowerState property


        

        
can


        

          
        represent power state transitions in progress.

     4.1.2.2. DASH


        

        
We need references for all entries in 4.*


        

          
        DMTF DASH (DSP0232) (Desktop And Mobile Architecture for


        

        
System


        

          
        Hardware) addresses managing heterogeneous desktop and mobile
        systems (including power) via in-band and out-of-band
        communications.  DASH provides management and control of


        

        
managed


        

          
        elements like power, CPU, etc. using the DMTF's WS-Management
        web services and CIM data model.

        Both in service and out-of-service systems can be managed with
        the DASH specification in a fully secured remote environment.
        Full power lifecycle management is possible using out-of-band
        management.


        

        
Question: what is the relationship with EMAN. If none, mentions it along

with a list of pros/cons. I mean: why should an implementator chose EMAN

versus DASH?


        

          
     4.1.3. ODVA

        The Open DeviceNet Vendors Association (ODVA) is an


        

        
association


        

          
        for industrial automation companies and defines the Common
        Industrial Protocol (CIP). Within ODVA, there is a special
        interest group focused on energy.

        There are many similar concepts between the ODVA and EMAN
        frameworks towards monitoring and management of energy aware
        devices. In particular, one of the concepts being considered
        different energy meters based on if the device consumes
        electricity or produces electricity or a passive device.


        

        
Express that the concept has been reused from ODVA since some ODVA
members were involved in the WG.


        

          


<Tychon, et al.>             Expires April 31, 2012        [Page 21]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        The Open DeviceNet Vendors Association (ODVA) is developing an
        energy management framework for the industrial sector.  There
        are synergies between the ODVA and EMAN approaches to energy
        management.


        

        
move that paragraph one place up


        

          
        ODVA defines a three-part approach towards energy management:
        awareness of energy usage, consuming energy more efficiently,
        and exchanging energy with the utility or others. Energy
        monitoring and management promote efficient consumption and
        enable automating actions that reduce energy consumption.

        The foundation of the approach is the information and
        communication model for entities. An entity is a network-
        connected, energy-aware device that has the ability to either
        measure or derive its energy usage based on its native
        consumption or generation of energy, or report a nominal or
        static energy value.



     4.1.4. Ecma SDC


        

        
Ecma stands for?


        

          
        The Ecma International committee on Smart Data Centre


        

        
(TC38-TG2


        

          
        SDC [Ecma-SDC]) is in the process of defining semantics for
        management of entities in a data center such as servers,
        storage, and network equipment.  It covers energy as one of


        

        
many


        

          
        functional resources or attributes of systems for monitoring


        

        
and


        

          
        control. It only defines messages and properties, and does not
        reference any specific protocol. Its goal is to enable
        interoperability of such protocols as SNMP, BACNET, and HTTP


        

        
by


        

          
        ensuring a common semantic model across them. Four power


        

        
states


        

          
        are defined, Off, Sleep, Idle and Active. The standard does


        

        
not


        

          
        include actual power measurements in kWor kWh.


        

        
kWor -> kW or


        

          
        The 14th draft of SDC process was published in March 2011 and
        the development of the standard is still underway. When used
        with EMAN, the SDC standard will provide a thin abstraction on
        top of the more detailed data model available in EMAN.

     4.1.5. IEEE-ISTO Printer Working Group (PWG)


        The IEEE-ISTO Printer Working Group (PWG) defines SNMP MIB
        modules for printer management and has recently defined a "PWG
        Power Management Model for Imaging Systems v1.0" [PWG5106.4]


        

        
and


        

          
        a companion SNMP binding in the "PWG Imaging System Power MIB
        v1.0" [PWG5106.5].  This PWG model and MIB are harmonized with


<Tychon, et al.>             Expires April 31, 2012        [Page 22]




        

        
    Internet-Draft     EMAN Applicability Statement        October 2011


        

          

        the DMTF CIM Infrastructure [DSP0004] and DMTF CIM Power State
        Management Profile [DSP1027] for power states and alerts.


        The PWG would like its MIBs to be harmonized as closely as
        possible with those from EMAN.  The PWG covers many topics in
        greater detail than EMAN, as well as some that are specific to
        imaging equipment.  The PWG also provides for vendor-specific
        extension states (i.e., beyond the standard DMTF CIM states.)



     4.1.6. ASHRAE

        In the U.S., there is an extensive effort to coordinate and
        develop standards related to the "Smart Grid".  The Smart Grid
        Interoperability Panel, coordinated by the government's


        

        
National


        

          
        Institute of Standards and Technology, identified the need for


        

        
a


        

          
        building side information model (as a counterpart to utility
        models) and specified this in Priority Action Plan (PAP) 17.
        This was designated to be a joint effort by American Society


        

        
of


        

          
        Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE)
        and National Electrical Manufacturers Association (NEMA), both
        ANSI approved SDO's.  The result is to be an information


        

        
model,


        

          
        not a device level monitoring protocol.

        The ASHRAE effort addresses data used only within a building


        

        
as


        

          
        well as data that may be shared with the grid, particularly as
        it relates to coordinating future demand levels with the needs
        of the grid.  The model is intended to be applied to any
        building type, both residential and commercial.  It is


        

        
expected


        

          
        that existing protocols will be adapted to comply with the new
        information model, as would any new protocols.

        There are four basic types of entities in the model:


        

        
generators,


        

          
        loads, meters, and energy managers.

        The metering part of this model overlaps with the EMAN


        

        
framework


        

          
        to a large degree, though there are features unique to each.
        The load part speaks to control capabilities well beyond what
        EMAN covers.  Details of generation and of the energy


        

        
management


        

          
        function are outside of EMAN scope.

        A public review draft of the ASHRAE standard is expected soon,
        and at that point detailed comparison of the two models can be
        made.  There are no apparent major conflicts between the two
        approaches, but there are likely areas where some


        

        
harmonization


        

          

<Tychon, et al.>             Expires April 31, 2012        [Page 23]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        is possible, and regardless, a description of the
        correspondences would be helpful to create.


     4.1.7. ZigBee

        The Zigbee Smart Energy 2.0 effort[ZIGBEE] focuses on wireless
        communication to appliances and lighting.  It is intended to
        enable building energy management and enable direct load


        

        
control


        

          
        by utilities.

        ZigBee protocols are intended for use in embedded applications
        requiring low data rates and low power consumption. ZigBee
        defines a general-purpose, inexpensive, self-organizing mesh
        network that can be used for industrial control, embedded
        sensing, medical data collection, smoke and intruder warning,
        building automation, home automation, etc.

        Zigbee is currently not an ANSI recognized SDO.

        The EMAN framework addresses the needs of IP-enabled networks
        through the usage of SNMP, while Zigbee looks for completely
        integrated and inexpensive mesh solution.


        

        
Zigbee Smart Energy 2.0 is based on IP, right? This should be stressed.


        

          
     4.2. Measurement


     4.2.1. ANSI C12

        The American National Standards Institute (ANSI) has defined a
        collection of power meter standards under ANSI C12.  The


        

        
primary


        

          
        standards include communication protocols (C12.18, 21 and 22),
        data and schema definitions (C12.19), and measurement accuracy
        (C12.20). European equivalent standards are provided by IEC
        62053-22.ANSI C12.20 defines accuracy classes for watt-hour
        meters.

        All of these standards are oriented toward the meter itself,


        

        
and


        

          
        are therefore very specific and used by electricity


        

        
distributors


        

          
        and producers.

        The EMAN standard references ANSI C12 accuracy classes.

     4.2.2. IEC62301

        IEC 62301, "Household electrical appliances  Measurement of
        standby power", specifies a power level measurement procedure.


<Tychon, et al.>             Expires April 31, 2012        [Page 24]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        While nominally for appliances and low-power modes, many


        

        
aspects


        

          
        of it apply to other device types and modes and it is commonly
        referenced in test procedures for energy using products.

        While the standard is intended for laboratory measurements of
        devices in controlled conditions, many aspects of it are
        informative to those implementing measurement in products that
        ultimately report via EMAN.




     4.3. Other

     4.3.1. ISO

        The ISO [ISO] is developing an energy management standard, ISO
        50001, to complement ISO 9001 for quality management, and ISO
        14001 for environment management. The intent of the framework


        

        
is


        

          
        to facilitate the creation of energy management programs for
        industrial, commercial and other entities.  The standard


        

        
defines


        

          
        a process for energy management at an organization level.  It
        does not define the way in which devices report energy and
        consume energy.

        EMAN is complementary to ISO 9001.


        

        
move that paragraph at the end of hte section


        

          
        ISO 50001 is based on the common elements found in all of


        

        
ISO's


        

          
        management system standards, assuring a high level of
        compatibility with ISO 9001 (quality management) and ISO 14001
        (environmental management). ISO 50001 benefits includes:

       o Integrating energy efficiency into management practices and
          throughout the supply chain
       o Energy management best practices and good energy management
          behaviors
       o benchmarking, measuring, documenting, and reporting energy
          intensity improvements and their projected impact on
          reductions in greenhouse gas (GHG) emissions
       o Evaluating and prioritizing the implementation of new energy-
          efficient technologies

        ISO 50001 has been developed by ISO project committee ISO/PC
        242, Energy management.





<Tychon, et al.>             Expires April 31, 2012        [Page 25]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

     4.3.2. EnergyStar

        The US Environmental Protection Agency (EPA) and US Department
        of Energy (DOE) jointly sponsor the Energy Star program


        

        
[ESTAR].


        

          
        The program promotes the development of energy efficient
        products and practices.

        To qualify as Energy Star, products must meet specific energy
        efficiency targets. The Energy Star program also provides
        planning tools and technical documentation to encourage more
        energy efficient building design. Energy Star is a program; it
        is not a protocol or standard.

        For businesses and data centers, Energy Star offers technical
        support to help companies establish energy conservation
        practices.  Energy Star provides best practices for measuring
        current energy performance, goal setting, and tracking
        improvement.  The Energy Star tools offered include a rating
        system for building performance and comparative benchmarks.

        There is no immediate link between EMAN and EnergyStar, one
        being a protocol and the other a set of recommendations to
        develop energy efficient products.  However, Energy Star could
        include EMAN standards in specifications for future products,
        either as required or rewarded with some benefit.

     4.3.3. SmartGrid

        The Smart Grid standards efforts underway in the United States
        are overseen by the US National Institute of Standards and
        Technology [NIST].NIST is responsible for coordinating a


        

        
public-
insert space


        

          
        private partnership with key energy and consumer stakeholders


        

        
in


        

          
        order to facilitate the development of smart grid standards.


        

        
The


        

          
        NIST smart grid standards activities are monitored and
        facilitated by the SGIP (Smart Grid Interoperability Panel).
        This group has working groups for specific topics including
        homes, commercial buildings, and industrial facilities as they
        relate to the grid.

        When a working group detects a standard or technology gap, the
        team seeks approval from the SGIP for the creation of a


        

        
Priority


        

          
        Action Plan (PAP), a private-public partnership to close the
        gap.  There are currently 17 PAPs.  PAP 17 is discussed in
        section 4.1.6.

        PAP 10 addresses "Standard Energy Usage Information".



<Tychon, et al.>             Expires April 31, 2012        [Page 26]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

        Smart Grid standards will provide distributed intelligence in
        the network and allow enhanced load shedding.  For example,
        pricing signals will enable selective shutdown of non critical
        activities during peak-load pricing periods.  These actions


        

        
can


        

          
        be effected through both centralized and distributed


        

        
management


        

          
        controls.

        There is an obvious functional link between SmartGrid and EMAN
        in the form of demand response, even if the EMAN framework


        

        
does


        

          
        not take any specific step toward SmartGrid communication.



        

        
"However, the EMAN framework, with its Energy Object Power State
control, offers a solution for the smart grid demand/response use case"



        

          
     5. Limitations

        EMAN Framework shall address the needs of energy monitoring in


        

        
shall address -> addresses

Regards, Benoit.


        

          
        terms of measurement and, considers limited control


        

        
capabilities


        

          
        of energy monitoring of networks.

        EMAN does not create a new protocol stack, but rather defines


        

        
a


        

          
        data and information model useful for measuring and reporting
        energy and other metrics over SNMP.

        The EMAN framework does not address questions regarding
        SmartGrid, electricity producers, and distributors even if


        

        
there


        

          
        is obvious link between them.

     6. Security Considerations

        EMAN shall use SNMP protocol for energy monitoring and thus


        

        
has


        

          
        the functionality of SNMP's security capabilities. SNMPv3
        [RFC3411] provides important security features such as
        confidentiality, integrity, and authentication.

     7. IANA Considerations

        This memo includes no request to IANA.

     8. Acknowledgements

        The authors would like to thank Jeff Wheeler, Benoit Claise,
        Juergen Quittek, Chris Verges, John Parello, and Matt Laherty,
        for their valuable contributions.

        The authors would like to thank Georgios Karagiannis for use
        case involving energy neutral homes, Elwyn Davies for off-grid
        electricity systems, and Kerry Lynn for the comment on the
        Demand/Response scenario.



<Tychon, et al.>             Expires April 31, 2012        [Page 27]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

     9. Open Issues

        "EDITOR NOTE: use the latest definition from


        

        
draft-parello-eman-


        

          
        definitions"

        OPEN ISSUE 1: Relevant IEC standards for application for EMAN
          Applicability Statement document can provide guidance on the
          issue of what is appropriate standard used by EMAN

          IEC 61850-7-4 has been extensively used in EMAN WG


        

        
documents.


        

          
          The other IEC documents referred for possible use are IEC
          61000-4-30, IEC 62053-21 and IEC 62301.

          There is feedback that IEC 61850-7-4 applies only to sub-
          stations ?



        OPEN ISSUE 2: Should review ASHRAE SPC 201P standard when it


        

        
is


        

          
        released for public review

          . Need to review ASHRAE information model and the use cases
             and how it relates to EMAN



        OPEN ISSUE 3: Review ALL requirements to ensure that they can


        

        
be


        

          
        traced to a use case
          . Missing is an use case for power quality

        OPEN ISSUE 4: Question for the WG. Should we have unique use
        cases that introduce specific requirements ? or can there be
        some overlap between use cases ?

        Any use cases out of scope scenarios ?



     10. References

     10.1. Normative References

        [RFC3411] An Architecture for Describing Simple Network
                Management Protocol (SNMP) Management Frameworks, RFC
                3411, December 2002.




<Tychon, et al.>             Expires April 31, 2012        [Page 28]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          

     10.2. Informative References


        [DASH] "Desktop and mobile Architecture for System Hardware",
                http://www.dmtf.org/standards/mgmt/dash/

        [NIST]  http://www.nist.gov/smartgrid/

        [Ecma-SDC] Ecma TC38 / SDC Task Group, "Smart Data Centre
                Resource Monitoring and Control (DRAFT)", March 2011.

        [ENERGY] http://en.wikipedia.org/wiki/Kilowatt_hour

        [EMAN-AS] Tychon, E., B. Schoening,MouliChandramouli, Bruce
                Nordman, "Energy Management (EMAN) Applicability
                Statement", draft-tychon-eman-applicability-statement-
                04.txt, work in progress, October 2011.

        [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and
                M. Chandramouli, "Requirements for Energy Management


        

        
",


        

          
                draft-ietf-eman-requirements-04 (work in


        

        
progress),July


        

          
                2011.

        [EMAN-MONITORING-MIB] M. Chandramouli, Schoening, B., Dietz,


        

        
T.,


        

          
                Quittek, J. and B. Claise  "Energy and Power


        

        
Monitoring


        

          
                MIB ", draft-ietf-eman-monitoring-mib-00,August 2011.

        [EMAN-AWARE-MIB] J. Parello, and B. Claise, "draft-ietf-eman-
                energy-aware-mib-02", work in progress, July 2011.

        [EMAN-FRAMEWORK] Claise, B., Parello, J., Schoening, B., and


        

        
J.


        

          
                Quittek, "Energy Management Framework", draft-ietf-
                eman-framework-02 ,July 2011.

        [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz,
                "Definition of Managed Objects for Battery Monitoring"
                draft-ietf-eman-battery-mib-02.txt, July 2011.

        [EMAN-DEF] J. Parello"Energy Management Terminology", draft-
                parello-eman-definitions-03

        [DMTF] "Power State Management ProfileDMTFDSP1027  Version


        

        
2.0"


        

          
                December2009.



        

        
http://www.dmtf.org/sites/default/files/standards/docum


        

          
                ents/DSP1027_2.0.0.pdf

        [ESTAR]  http://www.energystar.gov/


<Tychon, et al.>             Expires April 31, 2012        [Page 29]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          


        [ISO]    http://www.iso.org/iso/pressrelease.htm?refid=Ref1434

        [SGRID]  http://collaborate.nist.gov/twiki-



        

        
sggrid/bin/view/SmartGrid/SGIPWorkingGroupsAndCommittee


        

          
                s


        [ASHRAE] http://collaborate.nist.gov/twiki-
                sggrid/bin/view/SmartGrid/PAP17Information

        [PAP17] http://collaborate.nist.gov/twiki-



        

        
sggrid/bin/view/SmartGrid/PAP17FacilitySmartGridInforma


        

          
                tionStandard

        [ZIGBEE] http://www.zigbee.org/

        [ISO]  http://www.iso.org/iso/pressrelease.htm?refid=Ref1337

        [DSP0004] DMTF Common Information Model (CIM) Infrastructure,
                DSP0004, May 2009.



        

        
http://www.dmtf.org/standards/published_documents/DSP00


        

          
                04_2.5.0.pdf

        [DSP1027] DMTF Power State Management Profile, DSP1027,


        

        
December


        

          
                2009.



        

        
http://www.dmtf.org/standards/published_documents/DSP10


        

          
                27_2.0.0.pdf

        [PWG5106.4]IEEE-ISTO PWG Power Management Model for Imaging
                Systems v1.0, PWG Candidate Standard 5106.4-2011,
                February 2011.ftp://ftp.pwg.org/pub/pwg/candidates/cs-
                wimspower10-20110214-5106.4.mib

        [PWG5106.5] IEEE-ISTO PWG Imaging System Power MIB v1.0, PWG
                Candidate Standard 5106.5-2011, February 2011.

        [IEC62301] International Electrotechnical Commission, "IEC


        

        
62301


        

          
                Household electrical appliances  Measurement of


        

        
standby


        

          
                power", Edition 2.0, 2011.









<Tychon, et al.>             Expires April 31, 2012        [Page 30]




        

        
    Internet-Draft     EMAN Applicability Statement       October 2011


        

          



     Authors' Addresses

        Emmanuel Tychon
        Cisco Systems, Inc.
        De Keleetlaan, 6A
        B1831 Diegem
        Belgium
        Email: etychon@cisco.com


        Brad Schoening
        44 Rivers Edge Drive
        Little Silver, NJ 07739
        USA
        Email:brad@bradschoening.com


        MouliChandramouli
        Cisco Systems, Inc.
        Sarjapur Outer Ring Road
        Bangalore,
        India
        Phone: +91 80 4426 3947
        Email: moulchan@cisco.com


        Bruce Nordman
        Lawrence Berkeley National Laboratory
        1 Cyclotron Road, 90-4000
        Berkeley  94720-8136
        USA

        Phone: +1 510 486 7089
        Email: bnordman@lbl.gov













<Tychon, et al.>             Expires April 31, 2012        [Page 31]





        

        

      

      




    

    

  


--------------070709070509000404070408--

From bclaise@cisco.com  Tue Dec 20 00:09:01 2011
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 2B36511E80A2 for ; Tue, 20 Dec 2011 00:09:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.96
X-Spam-Level: 
X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.638,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 NNqNX66QYjJV for ; Tue, 20 Dec 2011 00:08:59 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2351B11E807F for ; Tue, 20 Dec 2011 00:08:44 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBK88h2N009374 for ; Tue, 20 Dec 2011 09:08:43 +0100 (CET)
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBK88hEs002270 for ; Tue, 20 Dec 2011 09:08:43 +0100 (CET)
Message-ID: <4EF0428A.20301@cisco.com>
Date: Tue, 20 Dec 2011 09:08:42 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: eman mailing list 
References: <20111219180753.F337E11E8098@ietfa.amsl.com>
In-Reply-To: <20111219180753.F337E11E8098@ietfa.amsl.com>
X-Forwarded-Message-Id: <20111219180753.F337E11E8098@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------050308060903070003090704"
Subject: [eman] Fwd: 83rd IETF - Working Group/BOF Scheduling
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: Tue, 20 Dec 2011 08:09:01 -0000

This is a multi-part message in MIME format.
--------------050308060903070003090704
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Dear all,

FYI, the complete list of "Important Dates"

Regards, Benoit.

-------- Original Message --------
Subject: 	83rd IETF - Working Group/BOF Scheduling
Date: 	Mon, 19 Dec 2011 10:07:53 -0800 (PST)
From: 	IETF Agenda 
To: 	Working Group Chairs 
CC: 	irsg@irtf.org



83rd IETF – Paris, France
Meeting Dates: March 25-30, 2012
Host: TBD
-----------------------------------------------------------------
IETF meetings start Monday morning and run through Friday afternoon (13:30).

We are accepting scheduling requests for all Working Groups and BOFs starting today.  The milestones and deadlines for scheduling-related activities are as follows:

NOTE: cutoff dates are subject to change.

- 2011-12-19 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool.
- 2012-01-30 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (UTC -8). To request a Working Group session, use the IETF Meeting Session Request Tool.
- 2012- 02-13 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (UTC -8). To request a BOF, please see instructions on Requesting a BOF.
- 2012-02-16 (Thursday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (UTC -8).
- 2012-02-23 (Thursday): Preliminary agenda published for comment.
- 2012-02-27 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (UTC -8).
- 2012-03-02 (Friday): Final agenda to be published.
- 2012-03-14 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool.
- 2012-03-19 (Monday): Revised Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool.
- 2012-04-27 (Friday): Proceedings submission cutoff date by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool.
- 2012-05-16 (Wednesday): Proceedings submission corrections cutoff date by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool.

Submitting Requests for Working Group and BOF Sessions

Please submit requests to schedule your Working Group sessions using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information that the Secretariat requires to schedule your sessions.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_tool_instruction.html

Please send requests to schedule your BOF sessions to agenda@ietf.org.  Please include the acronym of your BOF in the subject line of the message, and include all of the information specified in item (4) of "Requesting Meeting Sessions at IETF Meetings" in the body.  (This document is included below.)

Submitting Session Agendas

For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible.  Draft Working Group agendas are due Wednesday, March 14, 2012 by 17:00 PT.  Revised Working Group agendas are due no later than Monday, March 19, 2012 at 17:00 PT.  The proposed agenda for a BOF session should be submitted along with your request for a session.  Please be sure to copy your Area Director on that message.

Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting.  If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi

Additional information about this tool is available at:

http://www.ietf.org/instructions/meeting_materials_tool.html

Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" Web page as soon as they are submitted.

The URL for the "IETF 83 Meeting Materials" Web page is:

https://datatracker.ietf.org/meeting/83/materials.html

If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool."  The same User ID and password will work for both tools.  If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved.  If you require assistance in using either tool, or wish to report a bug, then please send a message to:
ietf-action@ietf.org.
===============================================================
For your convenience, comprehensive information on requesting meeting sessions at IETF 83 is presented below:

1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions.  The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_tool_instruction.html

If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org.  If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s).

Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s).

When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line.

2. BOFs will NOT be scheduled unless the Area Director(s) approved the BOF. The proponents behind a BOF need to contact a relevant Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC 5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs.

3. A Working Group may request either one or two sessions.  If your Working Group requires more than two sessions, then your request must be approved by an Area Director.  Additional sessions will be assigned, based on availability, after Monday, February 27, 2012 at 17:00 PT, the cut-off date for requests to reschedule a session.

4. You MUST provide the following information before a Working Group or BOF session will be scheduled:

     a. Working Group or BOF full name with acronym in brackets:

     b. AREA under which Working Group or BOF appears:

     c. CONFLICTS you wish to avoid, please be as specific as possible:

     d. Expected Attendance:

     e. Special requests:

     f. Number of sessions:

     g. Length of session:
        - 1 hour
        - 1 1/2 hours
        - 2 hours
        - 2 1/2 hours

For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt).
===============================================================
For your convenience please find here a list of the IETF Area Directors with their e-mail addresses:

IETF Chair
Russ Housley

Applications Area (app)
Pete Resnick
Peter Saint-Andre

Internet Area (int)
Jari Arkko
Ralph Droms

Operations&  Management Area (ops)
Ronald Bonica
Dan Romascanu

Real-time Applications and Infrastructure Area (rai)
Gonzalo Camarillo
Robert Sparks

Routing Area (rtg)
Stewart Bryant
Adrian Farrel

Security Area (sec)
Stephen Farrell
Sean Turner

Transport Area (tsv)
Wesley Eddy
David Harrington
  ===========================================================
82nd IETF Meeting Attendance Number - TBA




--------------050308060903070003090704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Dear all,

    

    FYI, the complete list of "Important Dates"

    

    Regards, Benoit.

    

    -------- Original Message --------
    

      
        

          Subject: 
          83rd IETF - Working Group/BOF Scheduling
        

        

          Date: 
          Mon, 19 Dec 2011 10:07:53 -0800 (PST)
        

        

          From: 
          IETF Agenda <agenda@ietf.org>
        

        

          To: 
          Working Group Chairs <wgchairs@ietf.org>
        

        

          CC: 
          irsg@irtf.org
        

      
    

    

    

    
83rd IETF – Paris, France
Meeting Dates: March 25-30, 2012
Host: TBD
-----------------------------------------------------------------
IETF meetings start Monday morning and run through Friday afternoon (13:30).

We are accepting scheduling requests for all Working Groups and BOFs starting today.  The milestones and deadlines for scheduling-related activities are as follows:

NOTE: cutoff dates are subject to change.

- 2011-12-19 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool.
- 2012-01-30 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (UTC -8). To request a Working Group session, use the IETF Meeting Session Request Tool.
- 2012- 02-13 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (UTC -8). To request a BOF, please see instructions on Requesting a BOF.
- 2012-02-16 (Thursday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (UTC -8).
- 2012-02-23 (Thursday): Preliminary agenda published for comment.
- 2012-02-27 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (UTC -8).
- 2012-03-02 (Friday): Final agenda to be published.
- 2012-03-14 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool.
- 2012-03-19 (Monday): Revised Working Group agendas due by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool.
- 2012-04-27 (Friday): Proceedings submission cutoff date by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool.
- 2012-05-16 (Wednesday): Proceedings submission corrections cutoff date by 17:00 PT (UTC -7), upload using IETF Meeting Materials Management Tool.

Submitting Requests for Working Group and BOF Sessions

Please submit requests to schedule your Working Group sessions using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information that the Secretariat requires to schedule your sessions.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_tool_instruction.html

Please send requests to schedule your BOF sessions to agenda@ietf.org.  Please include the acronym of your BOF in the subject line of the message, and include all of the information specified in item (4) of "Requesting Meeting Sessions at IETF Meetings" in the body.  (This document is included below.)

Submitting Session Agendas

For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible.  Draft Working Group agendas are due Wednesday, March 14, 2012 by 17:00 PT.  Revised Working Group agendas are due no later than Monday, March 19, 2012 at 17:00 PT.  The proposed agenda for a BOF session should be submitted along with your request for a session.  Please be sure to copy your Area Director on that message.

Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting.  If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi

Additional information about this tool is available at:

http://www.ietf.org/instructions/meeting_materials_tool.html

Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" Web page as soon as they are submitted.

The URL for the "IETF 83 Meeting Materials" Web page is:

https://datatracker.ietf.org/meeting/83/materials.html

If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool."  The same User ID and password will work for both tools.  If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved.  If you require assistance in using either tool, or wish to report a bug, then please send a message to:
ietf-action@ietf.org.
===============================================================
For your convenience, comprehensive information on requesting meeting sessions at IETF 83 is presented below:

1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions.  The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_tool_instruction.html

If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org.  If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s).

Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s).

When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line.

2. BOFs will NOT be scheduled unless the Area Director(s) approved the BOF. The proponents behind a BOF need to contact a relevant Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC 5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs.

3. A Working Group may request either one or two sessions.  If your Working Group requires more than two sessions, then your request must be approved by an Area Director.  Additional sessions will be assigned, based on availability, after Monday, February 27, 2012 at 17:00 PT, the cut-off date for requests to reschedule a session.

4. You MUST provide the following information before a Working Group or BOF session will be scheduled:

    a. Working Group or BOF full name with acronym in brackets: 

    b. AREA under which Working Group or BOF appears:

    c. CONFLICTS you wish to avoid, please be as specific as possible:

    d. Expected Attendance:

    e. Special requests:

    f. Number of sessions:

    g. Length of session: 
       - 1 hour 
       - 1 1/2 hours
       - 2 hours 
       - 2 1/2 hours

For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt).
===============================================================
For your convenience please find here a list of the IETF Area Directors with their e-mail addresses:

IETF Chair 
Russ Housley <housley@vigilsec.com> 

Applications Area (app)
Pete Resnick <presnick@qualcomm.com>
Peter Saint-Andre <stpeter@stpeter.im> 

Internet Area (int) 
Jari Arkko <jari.arkko@piuha.net>
Ralph Droms <rdroms.ietf@gmail.com> 

Operations & Management Area (ops) 
Ronald Bonica <rbonica@juniper.net>
Dan Romascanu <dromasca@avaya.com> 

Real-time Applications and Infrastructure Area (rai)
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Robert Sparks <rjsparks@nostrum.com>  

Routing Area (rtg) 
Stewart Bryant <stbryant@cisco.com>
Adrian Farrel <adrian@olddog.co.uk>  

Security Area (sec) 
Stephen Farrell <stephen.farrell@cs.tcd.ie>
Sean Turner <turners@ieca.com>  

Transport Area (tsv) 
Wesley Eddy <wes@mti-systems.com>
David Harrington <ietfdbh@comcast.net>  
 ===========================================================
82nd IETF Meeting Attendance Number - TBA




  


--------------050308060903070003090704--

From internet-drafts@ietf.org  Wed Dec 21 08:18:12 2011
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 1592D21F8AF7; Wed, 21 Dec 2011 08:18:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level: 
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, 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 RWdjEpUAOdbw; Wed, 21 Dec 2011 08:18:11 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B058121F8AAA; Wed, 21 Dec 2011 08:18:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p1
Message-ID: <20111221161811.6644.23242.idtracker@ietfa.amsl.com>
Date: Wed, 21 Dec 2011 08:18:11 -0800
Cc: eman@ietf.org
Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-00.txt
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, 21 Dec 2011 16:18:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Energy Management Working Group of th=
e IETF.

	Title           : Energy Management (EMAN) Applicability Statement
	Author(s)       : Brad Schoening
                          Mouli Chandramouli
                          Bruce Nordman
	Filename        : draft-ietf-eman-applicability-statement-00.txt
	Pages           : 31
	Date            : 2011-12-20

        The objective of Energy Management (EMAN) is to provide an
        energy management framework for networked devices.  This
        document presents the applicability of the EMAN framework for a
        variety of scenarios.  This document lists use cases and target
        devices that can potentially implement the EMAN framework and
        associated SNMP MIB modules.  These use cases are useful for
        identifying requirements for the framework.  Further, we
        describe the relationship of the EMAN framework to relevant
        other energy monitoring standards and architectures.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eman-applicability-statement=
-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-applicability-statement-=
00.txt


From moulchan@cisco.com  Wed Dec 21 09:54:10 2011
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 BBDAB11E8089 for ; Wed, 21 Dec 2011 09:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Ak+-eo-WRn38 for ; Wed, 21 Dec 2011 09:54:09 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B929E11E8073 for ; Wed, 21 Dec 2011 09:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2333; q=dns/txt; s=iport; t=1324490049; x=1325699649; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=bUCIOOKD9g7Q4Up71KwLGYVeaWS4qcXBqqoPnvVy4ao=; b=RrE7oCHBJPnMbWDd33YIPYdsk5BXvdX2lYZfyE+UsJ1hUs0MMBr2a2L0 OKO6jp55Ssr0ScLMKWyJmecMFtDVL5A1xTTUY9HbTdY2KayT4QfRB8ClN Z7fyrK7EtPy5W6kcwgW9AdaKmyYEH/yg/pDtsY+u4KjkH0ZYdRann6h5y g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AooAAAMc8k6tJV2a/2dsb2JhbABDm0aQV4EFgXIBAQEEAQEBDwEdCjQEEwQCAQgRBAEBCwYXAQYBJh8JCAEBBBMIARmHYJkrAZ5MiHWCN2MEiDefGQ
X-IronPort-AV: E=Sophos;i="4.71,389,1320624000"; d="scan'208";a="45926892"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 21 Dec 2011 17:54:09 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBLHs99n024850 for ; Wed, 21 Dec 2011 17:54:09 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);  Wed, 21 Dec 2011 11:54:09 -0600
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: Wed, 21 Dec 2011 11:54:06 -0600
Message-ID: 
In-Reply-To: <20111221161811.6644.23242.idtracker@ietfa.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] I-D Action: draft-ietf-eman-applicability-statement-00.txt
Thread-Index: Acy//Dii79yHbZfBRqij22edW0pPGQABrf/g
References: <20111221161811.6644.23242.idtracker@ietfa.amsl.com>
From: "Mouli Chandramouli (moulchan)" 
To: 
X-OriginalArrivalTime: 21 Dec 2011 17:54:09.0253 (UTC) FILETIME=[8A2FD150:01CCC009]
Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-00.txt
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, 21 Dec 2011 17:54:10 -0000

Hello all,

At the last WG meeting, EMAN Applicability Statement draft was adopted
as a WG item.=20
http://www.ietf.org/id/draft-ietf-eman-applicability-statement-00.txt


The draft has been revised based on comments from the EMAN mailing list.


We appreciate your comments on the draft;

 - comments on the use cases where EMAN can be applied
 - any scenario that has not been considered=20
 - feedback on the open issues

Thanks
Mouli

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Wednesday, December 21, 2011 9:48 PM
To: i-d-announce@ietf.org
Cc: eman@ietf.org
Subject: [eman] I-D Action:
draft-ietf-eman-applicability-statement-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Energy Management Working
Group of the IETF.

	Title           : Energy Management (EMAN) Applicability
Statement
	Author(s)       : Brad Schoening
                          Mouli Chandramouli
                          Bruce Nordman
	Filename        : draft-ietf-eman-applicability-statement-00.txt
	Pages           : 31
	Date            : 2011-12-20

        The objective of Energy Management (EMAN) is to provide an
        energy management framework for networked devices.  This
        document presents the applicability of the EMAN framework for a
        variety of scenarios.  This document lists use cases and target
        devices that can potentially implement the EMAN framework and
        associated SNMP MIB modules.  These use cases are useful for
        identifying requirements for the framework.  Further, we
        describe the relationship of the EMAN framework to relevant
        other energy monitoring standards and architectures.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eman-applicability-statem
ent-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eman-applicability-stateme
nt-00.txt

_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman