From karagian@cs.utwente.nl Sun Apr 3 13:31:09 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7518B3A679F for ; Sun, 3 Apr 2011 13:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uujUefb2liL0 for ; Sun, 3 Apr 2011 13:31:08 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 938153A67B5 for ; Sun, 3 Apr 2011 13:31:08 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p33KWBjg012582; Sun, 3 Apr 2011 22:32:11 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 03 Apr 2011 20:32:36 +0000 To: "Juergen Quittek" Date: Sun, 03 Apr 2011 20:32:36 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <73201B8B-63F7-4D7B-AE8E-76FB6353E229@quittek.at> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 03 Apr 2011 22:32:24 +0200 (MEST) Cc: "eman@ietf.org" Subject: [eman] comments on draft-ietf-eman-requirements-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 20:31:09 -0000 Hi Juergen I have read the draft-ietf-eman-requirements-01 draft. The draft includes important requirements. However, I have two comments: *) in my opinion the requirement on Power State Monitoring described in Section 3.4.1 is only focussing on individual devices, i.e, power monitor children. According to the discussions that we have had in the eman meeting, the types of powers states associated with the Power Monitor Parents can be different than the ones used for the Power Monitor Children. This is due to the fact that a Power Monitor Parent needs to aggregate the Power states associated with its Power Monitor Children. Is it possible to include an explanatory paragraph that emphasizes the fact that types of the power states in the Power Monitor Parents and Power Monitor Child can be different? *) there are situations where a device, e.g., a battery, sometimes supplies energy and other times the same device consumes energy. Is it possible to include a requirement that will ensure that the direction of energy to/from a device can also be monitored? Best regards, Georgios From bclaise@cisco.com Tue Apr 5 07:49:14 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B1628C14D for ; Tue, 5 Apr 2011 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMMJ8L7fBX33 for ; Tue, 5 Apr 2011 07:49:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 031ED28C148 for ; Tue, 5 Apr 2011 07:49:06 -0700 (PDT) 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 p35El4Od002125 for ; Tue, 5 Apr 2011 16:47:04 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p35El4t6012633 for ; Tue, 5 Apr 2011 16:47:04 +0200 (CEST) Message-ID: <4D9B2B68.7040801@cisco.com> Date: Tue, 05 Apr 2011 16:47:04 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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 EMAN minutes from IETF 80 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 14:49:14 -0000 Dear all Here are the draft minutes of our EMAN meeting. http://www.ietf.org/proceedings/80/minutes/eman.txt Please send me any corrections, changes, etc as soon as possible. Regards, Bruce and Benoit. From moulchan@cisco.com Wed Apr 6 05:10:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47193A69A6 for ; Wed, 6 Apr 2011 05:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PILL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZDlR3kBudT3 for ; Wed, 6 Apr 2011 05:10:09 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 822323A6935 for ; Wed, 6 Apr 2011 05:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=37347; q=dns/txt; s=iport; t=1302091912; x=1303301512; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=bc+8h/AYosf/r8L6eLGdrGjDxzkDq3v4A+CKIIRlqU4=; b=EOpxNIVkEzVgBK0HoEZxtyaongvHO6eLBPK0hVPDysZIGab6qftV5Twi Tr7hSr/bK+Ec4KVQEkhapWDxhc/dKR37lPMlEDA4P0kWe4VZZdKFhxbNV 8MpMWyzhh/8aJF/EBmdMIwOHu5bjWG/Ld5wtkFhFWkzb1tTPIfB9dCaP8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUAALpXnE2tJXG9/2dsb2JhbACYLI1Ld6UknCoCgw4HglUEhU6LVw X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208,217";a="331666164" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2011 12:11:44 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p36CBiBI032375; Wed, 6 Apr 2011 12:11:44 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 07:11:45 -0500 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_01CBF453.CB69AD5D" Date: Wed, 6 Apr 2011 07:11:40 -0500 Message-ID: In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362587@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Comments on draft-ietf-eman-requirements-01 Thread-Index: Acvt50b9erW+MI54RNyu7Dttk5Ox8AGZWLSw References: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362587@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: "Mouli Chandramouli (moulchan)" To: "Mielke, William F (Bill)" , "eman mailing list" X-OriginalArrivalTime: 06 Apr 2011 12:11:45.0043 (UTC) FILETIME=[CBE4E630:01CBF453] Subject: Re: [eman] Comments on draft-ietf-eman-requirements-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 12:10:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF453.CB69AD5D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bill, Thanks very much for your detailed comments. I would like to address your point on battery or energy storage devices - in particular, the point of possible double counting of energy consumption - when power is drawn from the grid or from back-up power. In my view, it depends on where is energy measured. Here is an example.=20 Power From Grid -------> (Meter 1) ------> | UPS | ------> (Meter 2)------> 10 Racks ----(Meter M) ---> Rack X -----(Meter N) -----> Servers 33.3 KW 0.9 eff 30 KW Consider 33.3 KW is drawn from the grid. Let us assume that the UPS has an efficiency of 0.9. The output of UPS is 30 KW used to feed 10 racks, where each rack consumes 3 KW. Let us assume there are 10 servers in each rack, each server consuming 300 Watts.=20 The 3.3 KW loss @ UPS can be attributed to AC --> DC --> AC conversion and that is also used to charge the UPS batteries. Consider, 1.3 KW is the (AC -> DC -> AC) loss and=20 2 KW to charge the UPS batteries. Once the UPS batteries are fully charged, there is only loss due to conversion and the efficiency of the UPS is much higher, perhaps 0.96.=20 The UPS MIB can be used to measure the power loss at UPS (difference between Meter 1 and Meter 2). =20 If we look at the server + its portion of back-up power as a whole, we can get 300 Watts per server + 20 watts attributed to UPS per server =3D 320 Watts.=20 In contrast, if we consider the server and the backup as independent quantities 300 Watts * 1000 =3D 30 KW for feeding the servers and 3.3 KW for the UPS.=20 When the grid power is ON, Energy monitoring MIB shall provide a measurement of 300 Watts per server and UPS MIB could provide 3.3 KW.=20 When the grid power is OFF, Energy monitoring MIB shall provide a measurement of 300 Watts per server, and UPS MIB could provide 0 KW.=20 Please let me know your thoughts.=20 Thanks Mouli =20 -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mielke, William F (Bill) Sent: Tuesday, March 29, 2011 1:30 PM To: eman mailing list Subject: [eman] Comments on draft-ietf-eman-requirements-01 Below please find my comments on draft-ietf-eman-requirements-01. I also have some minor textual formatting or rewording comments which I will provide to Benoit directly in a separate email. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein ------------------------------------------- Comments on draft-ietf-eman-requirements-01 ------------------------------------------- Section 1: We should clarify what we mean by "building networks" and "home networks". For example, do these networks explicitly include or exclude things like environmental management systems for heating, air conditioning, lighting control, etc? Sections 2.4, 2.5, and 2.6: It occurs to me that sections 2.4, 2.5, and 2.6 are all simply different examples of the same "energy proxying scenario". If we want to call these out as separate and distinct cases perhaps the sections should be updated to illustrate why they are unique from one another (i.e. for reasons other than simply the domain to which the proxying has been applied). Section 2.8: I am not certain on how best to address this point but I believe that the current thinking relative to batteries may be too narrow in scope. For example, telephone switching offices often employ huge banks of batteries which are used to power the entire office when the grid is unavailable. Another example is many alternative energy sources also employ batteries as a fundamental storage facility where accumulated energy can be saved until needs to be supplied to its connected devices. Both of these examples extend batteries beyond the simple concept of an on-board battery embedded within a simple device. Is this a separate scenario (e.g. for "energy storage devices") or an example of how the thinking on the battery scenario may need to be broadened? Section 3.4.4 The current text states "These devices can consume energy when turned off or to sleep mode, because in these modes they still can charge their batteries." >From an energy consumtion point of view this is not technically correct. Energy which is used to recharge a battery is not technically consumed (i.e. used up) but is rather merely transferred and stored for later use. The stored energy is only consumed when the device is actually discharging the battery. So, the proper way to account for the energy use of a device is: Energy(Consumed) =3D Energy(TransferedFromMains) - Energy(RemainingInBattery) Thus, when the device is technically "off" but charging the amount of energy actually consumed by the device remains unchanged, and when the main power is off and the device is draining the battery only then is the energy stored in the battery actually consumed (and is reflected in the decreasing value of Energy(RemainingInBattery). So I think that we need to be careful in how we define "energy consumption". Section 4: The text states: "However, the overhead of pull model monitoring is typically higher than for push model monitoring, particularly when large numbers of values are to be collected, such as time series of power values." I would like to better understand why you are asserting this to be true. The inherent efficiency of a transfer is not a function of which side initiates the transfer (i.e. push or pull). So you must be thinking of something else or I am misunderstanding the point. Perhaps you are equating "pull mode" with "polling" vs. "push mode" with "event driven". To me these are not equivalent statements so perhaps that is the source of my concern and/or perhaps I am merely splitting hairs too finely on this distinction. Consider an example where readings are pushed 1 per minunte vs. pulled 5 at a time every 5 minutes: Time --> +----+----+----+----+----+----+----+----+----+----+----+----+----+----+- ---+ | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | +----+----+----+----+----+----+----+----+----+----+----+----+----+----+- ---+ | | | | | | | | | | | | | | | V V V V V V V V V V V V V V V PU01 PU02 PU03 PU04 PU05 PU06 PU07 PU08 PU09 PU10 PU11 PU12 PU13 PU14 PU15 | | | V V V PL01 PL06 PL11 PL02 PL07 PL12 PL03 PL08 PL13 PL04 PL09 PL14 PL05 PL10 PL15 Where PUnn is a push mode transfer and PLnn is a pull mode transfer. Whether I push the values 1 at a time or pull them 5 at a time I still transfer the same number of values. So it is unclear to me why you are saying that the push mode approach is inherently more efficient than the pull mode approach. In fact, depending on the transfer protocol being used and the size of the packets involved I could actually argue that the pull mode approach is more efficient because it will (or at least it could) involve less network overhead per reading/unit transfered. The text states "The only exceptions are notifications on power state changes and high volume time series of energy consumption values." Until I better understand why you believe this is true I respectfully disagree that this is a fundamental implication/conclusion. So there is some confusion which may need to be cleared up here and I understand that the confusion may be on my part. Either way some additional clarification may be needed in the document to justify the main conclusions stated there. Section 7.1.2: The text states "For associating the provided information to specific components of a device, the ENTITY STATE MIB module makes use of the means provided by the ENTITY MIB module [RFC4133]. Particularly, it uses the entPhysicalIndex for identifying entities.". This is interesting information which seems to be trying to make a specific point however the point itself has not been articulated and so it lost. Add something to explain the implications of these points. This section seems to be articulating that the existing ENITITY STATE MIB facilities are insufficient for our larger purpose. This naturally implies that something additional needs to be defined but it is unclear from the existing text whether extending these existing facilities or defining new ones is the best approach. Perhaps that decision is left to later documents? _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman ------_=_NextPart_001_01CBF453.CB69AD5D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [eman] Comments on draft-ietf-eman-requirements-01

Hi = Bill,

Thanks very = much for your detailed comments. I would like to address your point on battery or energy storage = devices - in = particular, the point of possible double counting of energy consumption - when = power is drawn from the grid or from back-up power. In my view, it depends on where = is energy measured. Here is an example. =

Power From = Grid -------> (Meter 1) ------>  | UPS    |  ------> (Meter = 2)------> 10 Racks ----(Meter M) ---> Rack X -----(Meter N) -----> Servers

         &= nbsp;           &n= bsp;    33.3 KW            0.9 = eff           &nbs= p; 30 KW     

Consider = 33.3 KW is drawn from the grid. = Let us assume that the UPS has an efficiency of = 0.9. The = output of UPS = is 30 KW used to feed 10 racks, 

where each = rack consumes 3 KW. Let us assume there are 10 servers in each rack, = each server consuming 300 Watts.

The 3.3 KW = loss @ UPS can be attributed to AC --> DC --> AC conversion = and that = is also used to charge the UPS batteries. Consider,  = 1.3 KW is the = (AC -> DC -> AC) loss and

2 KW to charge = the UPS batteries. Once the UPS batteries are fully charged, there is only loss due to = conversion and the efficiency of the UPS is much higher, perhaps = 0.96.

The UPS MIB can be used to measure the power loss at = UPS = (difference between Meter 1 and Meter 2). 

If = we look at = the server + its portion of back-up power as a = whole, we can get 300 Watts per server + 20 watts attributed to = UPS per = server =3D = 320 Watts. =

In = contrast, if = we consider the server and the backup as independent quantities 300 Watts * 1000 =3D 30 = KW for = feeding the servers and 3.3 KW for the UPS.

When the grid = power is ON,  Energy monitoring MIB shall provide a measurement = of 300 Watts = per server and UPS MIB could provide 3.3 KW. =

When the grid = power is OFF, Energy monitoring MIB shall provide a measurement of = 300 Watts per server, and UPS MIB = could provide 0 KW. =

Please let me = know your thoughts.

Thanks

Mouli

 

-----Original = Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] = On Behalf Of Mielke, William F (Bill)
Sent: Tuesday, March 29, 2011 1:30 PM
To: eman mailing list
Subject: [eman] Comments on = draft-ietf-eman-requirements-01

Below please = find my comments on draft-ietf-eman-requirements-01.  I also have = some minor textual formatting or rewording comments which I will provide = to Benoit directly in a separate email.

William F. = Mielke

Alcatel-Lucent

Distinguished = Member of Technical Staff

6200 East = Broad Street

Room: = 4B01-1V

Columbus, = OH  43213-1530

Email: = Bill.Mielke@alcatel-lucent.com

Phone: 614 367 = 5628

Fax: 614 367 = 5965

"Live = like you're going to die tomorrow.

 Learn = like you're going to live forever."

    - Albert Einstein


-------------------------------------------

Comments on = draft-ietf-eman-requirements-01

-------------------------------------------

Section = 1:

We should = clarify what we mean by "building networks" and "home = networks".  For example, do these networks explicitly include = or exclude things like environmental management systems for heating, air = conditioning, lighting control, etc?

Sections 2.4, = 2.5, and 2.6:

It occurs to = me that sections 2.4, 2.5, and 2.6 are all simply different examples of = the same "energy proxying scenario".  If we want to call = these out as separate and distinct cases perhaps the sections should be = updated to illustrate why they are unique from one another (i.e. for = reasons other than simply the domain to which the proxying has been = applied).

Section = 2.8:

I am not = certain on how best to address this point but I believe that the current = thinking relative to batteries may be too narrow in scope.  For = example, telephone switching offices often employ huge banks of = batteries which are used to power the entire office when the grid is = unavailable.  Another example is many alternative energy sources = also employ batteries as a fundamental storage facility where = accumulated energy can be saved until needs to be supplied to its = connected devices.

Both of these = examples extend batteries beyond the simple concept of an on-board = battery embedded within a simple device.  Is this a separate = scenario (e.g. for "energy storage devices") or an example of = how the thinking on the battery scenario may need to be = broadened?

Section = 3.4.4

The current = text states "These devices can consume energy when turned off or to = sleep mode, because in these modes they still can charge their = batteries."

From an energy = consumtion point of view this is not technically correct.  Energy = which is used to recharge a battery is not technically consumed (i.e. = used up) but is rather merely transferred and stored for later = use.  The stored energy is only consumed when the device is = actually discharging the battery.  So, the proper way to account = for the energy use of a device is:

Energy(Consumed) =3D Energy(TransferedFromMains) - = Energy(RemainingInBattery)

Thus, when the = device is technically "off" but charging the amount of energy = actually consumed by the device remains unchanged, and when the main = power is off and the device is draining the battery only then is the = energy stored in the battery actually consumed (and is reflected in the = decreasing value of Energy(RemainingInBattery).

So I think = that we need to be careful in how we define "energy = consumption".

Section = 4:

The text = states: "However, the overhead of pull model monitoring is = typically higher than for push model monitoring, particularly when large = numbers of values are to be collected, such as time series of power = values."

I would like = to better understand why you are asserting this to be true.  The = inherent efficiency of a transfer is not a function of which side = initiates the transfer (i.e. push or pull).  So you must be = thinking of something else or I am misunderstanding the = point.

Perhaps you = are equating "pull mode" with "polling" vs. = "push mode" with "event driven".  To me these = are not equivalent statements so perhaps that is the source of my = concern and/or perhaps I am merely splitting hairs too finely on this = distinction.

Consider an = example where readings are pushed 1 per minunte vs. pulled 5 at a time = every 5 minutes:

Time = -->

+----+----+----+----+----+----+----+----+----+----+----= +----+----+----+----+

| 01 | 02 | 03 = | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 = |

+----+----+----+----+----+----+----+----+----+----+----= +----+----+----+----+

     |    = |    |    |    = |    |    |    = |    |    |    = |    |    |    = |    |

     V    = V    V    V    = V    V    V    = V    V    V    = V    V    V    = V    V

   = PU01 PU02 PU03 PU04 PU05 PU06 PU07 PU08 PU09 PU10 PU11 PU12 PU13 PU14 = PU15

         &= nbsp;           &n= bsp;   = |            =             = |            =             = |

         &= nbsp;           &n= bsp;   = V            =             = V            =             = V

         &= nbsp;           &n= bsp; = PL01           &nb= sp;         = PL06           &nb= sp;         = PL11

         &= nbsp;           &n= bsp; = PL02           &nb= sp;         = PL07           &nb= sp;         = PL12

         &= nbsp;           &n= bsp; = PL03           &nb= sp;         = PL08           &nb= sp;         = PL13

         &= nbsp;           &n= bsp; = PL04           &nb= sp;         = PL09           &nb= sp;         = PL14

         &= nbsp;           &n= bsp; = PL05           &nb= sp;         = PL10           &nb= sp;         = PL15

Where PUnn is = a push mode transfer and PLnn is a pull mode transfer.  Whether I = push the values 1 at a time or pull them 5 at a time I still transfer = the same number of values.  So it is unclear to me why you are = saying that the push mode approach is inherently more efficient than the = pull mode approach.

In fact, = depending on the transfer protocol being used and the size of the = packets involved I could actually argue that the pull mode approach is = more efficient because it will (or at least it could) involve less = network overhead per reading/unit transfered.

The text = states "The only exceptions are notifications on power state = changes and high volume time series of energy consumption = values."

Until I better = understand why you believe this is true I respectfully disagree that = this is a fundamental implication/conclusion.

So there is = some confusion which may need to be cleared up here and I understand = that the confusion may be on my part.  Either way some additional = clarification may be needed in the document to justify the main = conclusions stated there.

Section = 7.1.2:

The text = states "For associating the provided information to specific = components of a device, the ENTITY STATE MIB module makes use of the = means provided by the ENTITY MIB module [RFC4133]. Particularly, it uses = the entPhysicalIndex for identifying entities.".

This is = interesting information which seems to be trying to make a specific = point however the point itself has not been articulated and so it = lost.  Add something to explain the implications of these = points.

This section = seems to be articulating that the existing ENITITY STATE MIB facilities = are insufficient for our larger purpose.  This naturally implies = that something additional needs to be defined but it is unclear from the = existing text whether extending these existing facilities or defining = new ones is the best approach.  Perhaps that decision is left to = later documents?

_______________________________________________<= /SPAN>

eman mailing = list

eman@ietf.org

https://www.ietf.org/= mailman/listinfo/eman

------_=_NextPart_001_01CBF453.CB69AD5D-- From moulchan@cisco.com Wed Apr 6 05:41:25 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CFEF3A693E for ; Wed, 6 Apr 2011 05:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.394 X-Spam-Level: X-Spam-Status: No, score=-9.394 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599, MANGLED_PILL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yTotf+HFADo for ; Wed, 6 Apr 2011 05:41:24 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E00953A692C for ; Wed, 6 Apr 2011 05:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=7810; q=dns/txt; s=iport; t=1302093788; x=1303303388; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=6EATQKJS1dEOX0X0T8vEPjK6wZSCGO5I2KWpkshwAyY=; b=JsKzEPHe6rErZLrdUFEY1vRtjZ/82PBdydoHJwSCJlkVTJB/jwXcXJpD Z/MD/G6q73B9FwGTnijLQogfqRLB2K1HjZKOZAWAnPwKQ3pzRWAbRNBy0 +CsZtcpi4R7bbmAC+casIMv/wHJkNH81rCLtRxcAv5kbemXyuTh1AI5MP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUAAPRenE2tJV2d/2dsb2JhbACYLI1Ld6UnnCoCgw4HglUEhU6LVw X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208";a="229261868" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2011 12:43:07 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p36Ch7bl007649; Wed, 6 Apr 2011 12:43:07 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); Wed, 6 Apr 2011 07:43:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2011 07:43:02 -0500 Message-ID: In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362587@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Comments on draft-ietf-eman-requirements-01 Thread-Index: Acvt50b9erW+MI54RNyu7Dttk5Ox8AGb/tcw References: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362587@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: "Mouli Chandramouli (moulchan)" To: "Mielke, William F (Bill)" , "eman mailing list" X-OriginalArrivalTime: 06 Apr 2011 12:43:07.0626 (UTC) FILETIME=[2E0044A0:01CBF458] Subject: Re: [eman] Comments on draft-ietf-eman-requirements-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 12:41:25 -0000 Hi, Regarding the comment on pull vs push. Here are some comments.=20 As a requirements document, there is (and there should be) no requirement for energy monitoring advocating a pull or a push model.=20 In simple terms, in a pull model, there are two messages, a request (SNMP GET) and a response; whereas in PUSH, there is only one message (response) reporting.=20 Given the information model, it is up to the implementers to decide to use PULL or PUSH model.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mielke, William F (Bill) Sent: Tuesday, March 29, 2011 1:30 PM To: eman mailing list Subject: [eman] Comments on draft-ietf-eman-requirements-01 Below please find my comments on draft-ietf-eman-requirements-01. I also have some minor textual formatting or rewording comments which I will provide to Benoit directly in a separate email. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein ------------------------------------------- Comments on draft-ietf-eman-requirements-01 ------------------------------------------- Section 1: We should clarify what we mean by "building networks" and "home networks". For example, do these networks explicitly include or exclude things like environmental management systems for heating, air conditioning, lighting control, etc? Sections 2.4, 2.5, and 2.6: It occurs to me that sections 2.4, 2.5, and 2.6 are all simply different examples of the same "energy proxying scenario". If we want to call these out as separate and distinct cases perhaps the sections should be updated to illustrate why they are unique from one another (i.e. for reasons other than simply the domain to which the proxying has been applied). Section 2.8: I am not certain on how best to address this point but I believe that the current thinking relative to batteries may be too narrow in scope. For example, telephone switching offices often employ huge banks of batteries which are used to power the entire office when the grid is unavailable. Another example is many alternative energy sources also employ batteries as a fundamental storage facility where accumulated energy can be saved until needs to be supplied to its connected devices. Both of these examples extend batteries beyond the simple concept of an on-board battery embedded within a simple device. Is this a separate scenario (e.g. for "energy storage devices") or an example of how the thinking on the battery scenario may need to be broadened? Section 3.4.4 The current text states "These devices can consume energy when turned off or to sleep mode, because in these modes they still can charge their batteries." >From an energy consumtion point of view this is not technically correct. Energy which is used to recharge a battery is not technically consumed (i.e. used up) but is rather merely transferred and stored for later use. The stored energy is only consumed when the device is actually discharging the battery. So, the proper way to account for the energy use of a device is: Energy(Consumed) =3D Energy(TransferedFromMains) - Energy(RemainingInBattery) Thus, when the device is technically "off" but charging the amount of energy actually consumed by the device remains unchanged, and when the main power is off and the device is draining the battery only then is the energy stored in the battery actually consumed (and is reflected in the decreasing value of Energy(RemainingInBattery). So I think that we need to be careful in how we define "energy consumption". Section 4: The text states: "However, the overhead of pull model monitoring is typically higher than for push model monitoring, particularly when large numbers of values are to be collected, such as time series of power values." I would like to better understand why you are asserting this to be true. The inherent efficiency of a transfer is not a function of which side initiates the transfer (i.e. push or pull). So you must be thinking of something else or I am misunderstanding the point. Perhaps you are equating "pull mode" with "polling" vs. "push mode" with "event driven". To me these are not equivalent statements so perhaps that is the source of my concern and/or perhaps I am merely splitting hairs too finely on this distinction. Consider an example where readings are pushed 1 per minunte vs. pulled 5 at a time every 5 minutes: Time --> +----+----+----+----+----+----+----+----+----+----+----+----+----+----+- ---+ | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | +----+----+----+----+----+----+----+----+----+----+----+----+----+----+- ---+ | | | | | | | | | | | | | | | V V V V V V V V V V V V V V V PU01 PU02 PU03 PU04 PU05 PU06 PU07 PU08 PU09 PU10 PU11 PU12 PU13 PU14 PU15 | | | V V V PL01 PL06 PL11 PL02 PL07 PL12 PL03 PL08 PL13 PL04 PL09 PL14 PL05 PL10 PL15 Where PUnn is a push mode transfer and PLnn is a pull mode transfer. Whether I push the values 1 at a time or pull them 5 at a time I still transfer the same number of values. So it is unclear to me why you are saying that the push mode approach is inherently more efficient than the pull mode approach. In fact, depending on the transfer protocol being used and the size of the packets involved I could actually argue that the pull mode approach is more efficient because it will (or at least it could) involve less network overhead per reading/unit transfered. The text states "The only exceptions are notifications on power state changes and high volume time series of energy consumption values." Until I better understand why you believe this is true I respectfully disagree that this is a fundamental implication/conclusion. So there is some confusion which may need to be cleared up here and I understand that the confusion may be on my part. Either way some additional clarification may be needed in the document to justify the main conclusions stated there. Section 7.1.2: The text states "For associating the provided information to specific components of a device, the ENTITY STATE MIB module makes use of the means provided by the ENTITY MIB module [RFC4133]. Particularly, it uses the entPhysicalIndex for identifying entities.". This is interesting information which seems to be trying to make a specific point however the point itself has not been articulated and so it lost. Add something to explain the implications of these points. This section seems to be articulating that the existing ENITITY STATE MIB facilities are insufficient for our larger purpose. This naturally implies that something additional needs to be defined but it is unclear from the existing text whether extending these existing facilities or defining new ones is the best approach. Perhaps that decision is left to later documents? _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Wed Apr 6 07:53:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD2D28C0FD for ; Wed, 6 Apr 2011 07:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAcWFBFKcxj4 for ; Wed, 6 Apr 2011 07:53:20 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 890EB28C0D8 for ; Wed, 6 Apr 2011 07:53:19 -0700 (PDT) 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 p36Edpq0013659; Wed, 6 Apr 2011 16:39:51 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p36EdoHh004772; Wed, 6 Apr 2011 16:39:50 +0200 (CEST) Message-ID: <4D9C7B36.2000407@cisco.com> Date: Wed, 06 Apr 2011 16:39:50 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: eman mailing list References: <4D9B2B68.7040801@cisco.com> In-Reply-To: <4D9B2B68.7040801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] DRAFT EMAN minutes from IETF 80 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 14:53:22 -0000 Dear all, Editorial changes from Bill Mielke and Georgios Karagiannis inserted and uploaded Thanks and Regards, Bruce and Benoit > Dear all > > Here are the draft minutes of our EMAN meeting. > http://www.ietf.org/proceedings/80/minutes/eman.txt > > Please send me any corrections, changes, etc as soon as possible. > > Regards, Bruce and Benoit. > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Wed Apr 6 11:35:51 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0F128C0DE for ; Wed, 6 Apr 2011 11:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvpUmqF0DdIK for ; Wed, 6 Apr 2011 11:35:50 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0F4FB28C0D6 for ; Wed, 6 Apr 2011 11:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=1201; q=dns/txt; s=iport; t=1302115054; x=1303324654; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=O8pcQt501ZTXQ2zzpQVdBsjAz2xzFI1/10m2Q2HcP+0=; b=Daf93wcusDPKHL7NktKbrJvmPum413CjAsdXD4J1mHi4QGKQN8VgdCgq FAhCua/u1RwUzwqaY85vhc/sJiEfIXclNEdH97Hc0dd/AtbCvc7gYr6Jf YwZ2Xtcw53iI0b+hyZE2yXUacP08Zh1Wg4Sudis3b0Mf2HUONlyRLB+Ek 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGuynE2rRDoH/2dsb2JhbAClfHenBZxJhWwEhU6LVw X-IronPort-AV: E=Sophos;i="4.63,311,1299456000"; d="scan'208";a="290672863" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2011 18:37:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p36IbQoQ025495 for ; Wed, 6 Apr 2011 18:37:34 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); Wed, 6 Apr 2011 11:37:28 -0700 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, 6 Apr 2011 11:37:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review ODVA preso from IETF80 meeting Thread-Index: Acv0ib2a1KrCGm63Su+kI/mg8ePF/A== From: "John Parello (jparello)" To: "eman mailing list" X-OriginalArrivalTime: 06 Apr 2011 18:37:28.0353 (UTC) FILETIME=[AE61C110:01CBF489] Subject: [eman] Review ODVA preso from IETF80 meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 18:35:51 -0000 Hi, During our EMAN session at IETF80 I presented the work that the ODVA is doing on energy management. The time was very limited but I'd think it's very useful to see what a group of primarily electrical engineers are doing to address the same problem we are looking at. Given their request for a formal liaison we should look more closely at their information model and implementation. Unfortunately the draft spec is not available as yet but my presentation does have a summary. I think it would be well worth everyone's time to take a look at it. The presentation is here: http://www.ietf.org/proceedings/80/slides/eman-1.pdf More information on the ODVA is here: http://www.odva.org Summary of important items: - Division of information model into electrical and non-electrical objects - Electrical objects models with attributes: context, power, energy, demand and relationship information - Need for aggregation and parent child pattern with capabilities. - Standardization on units - Focus on devices that may not be able to implement the entire information model. Would love to have a discussion on the points and merge to our framework. Thanks Jp From karagian@cs.utwente.nl Thu Apr 7 02:35:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0BD3A68F5 for ; Thu, 7 Apr 2011 02:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf8tMP7hkmNp for ; Thu, 7 Apr 2011 02:35:09 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 722BE3A69F4 for ; Thu, 7 Apr 2011 02:35:08 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id p379a9rV000225; Thu, 7 Apr 2011 11:36:12 +0200 (MEST) From: "Georgios Karagiannis" To: "'John Parello \(jparello\)'" , "'eman mailing list'" References: Date: Thu, 7 Apr 2011 11:36:33 +0200 Message-ID: <165D9883F99A4700BD524FDEC893702A@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: Acv0ib2a1KrCGm63Su+kI/mg8ePF/AAfSvbQ X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 07 Apr 2011 11:36:21 +0200 (MEST) Subject: Re: [eman] Review ODVA preso from IETF80 meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 09:35:11 -0000 Hi John I think that the work done in ODVA is very interesting and it will be great if we could merge it to our framework! Best regards, Georgios > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On > Behalf Of John Parello (jparello) > Sent: woensdag 6 april 2011 20:38 > To: eman mailing list > Subject: [eman] Review ODVA preso from IETF80 meeting > > Hi, > > During our EMAN session at IETF80 I presented the work that > the ODVA is doing on energy management. The time was very > limited but I'd think it's very useful to see what a group of > primarily electrical engineers are doing to address the same > problem we are looking at. Given their request for a formal > liaison we should look more closely at their information > model and implementation. > > Unfortunately the draft spec is not available as yet but my > presentation does have a summary. I think it would be well > worth everyone's time to take a look at it. > > The presentation is here: > http://www.ietf.org/proceedings/80/slides/eman-1.pdf > > More information on the ODVA is here: > http://www.odva.org > > Summary of important items: > > - Division of information model into electrical and > non-electrical objects > - Electrical objects models with attributes: context, power, > energy, demand and relationship information > - Need for aggregation and parent child pattern with capabilities. > - Standardization on units > - Focus on devices that may not be able to implement the > entire information model. > > Would love to have a discussion on the points and merge to > our framework. > > Thanks > Jp > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > From jparello@cisco.com Thu Apr 7 09:06:49 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C086628C0EA for ; Thu, 7 Apr 2011 09:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIZnHE46aoU0 for ; Thu, 7 Apr 2011 09:06:48 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D49CB3A68CF for ; Thu, 7 Apr 2011 09:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=673; q=dns/txt; s=iport; t=1302192513; x=1303402113; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=YFmGgxw3Xai8Z+lxWIA+HXqVIS+2721x1MDrW8KJ1Ro=; b=B283N0BMiJejDL7sgO6ay0sSI6e2W2IJ0+gk32E0ais1lMHKiXSz6IVI pwwKlW8Ddhe3wnT/hlrDAEUiLnoyEGVBY3HQReHUhOc/mUZCkSrmcSqDH zEOZhi46PT+OSNZ71eoUbnQJyF2uenADYNzi4Xhqr/4DvK4omF6Y4ZfDj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE/gnU2rRDoI/2dsb2JhbACmB3ekT5xdhW0EhVCHdYNo X-IronPort-AV: E=Sophos;i="4.63,317,1299456000"; d="scan'208";a="332616280" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2011 16:08:33 +0000 Received: from [10.10.10.5] ([10.21.86.209]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37G8WBx002306 for ; Thu, 7 Apr 2011 16:08:32 GMT Message-ID: <4D9DE17D.5090606@cisco.com> Date: Thu, 07 Apr 2011 09:08:29 -0700 From: john parello User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "eman@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 16:06:49 -0000 Hi The requirements draft calls for an indication of the following for a state: - time in state - reason - count While working on adding multiple power state series we've found that this information was relevant only there was a single power state series. Now that we have multiple series do we need this information? I can see the usefulness of this information but the charter says we are to to do transitions optionally and the requirements is calling for this but I think it's based on a single series. What do people think: 1) Should we keep this information? 2) If so, do we need to model this information per power state series? Jp From bclaise@cisco.com Thu Apr 7 09:27:42 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D2C28C15D for ; Thu, 7 Apr 2011 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg+r6z-lyBIX for ; Thu, 7 Apr 2011 09:27:40 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 7340328C102 for ; Thu, 7 Apr 2011 09:27:40 -0700 (PDT) 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 p37GH2Sm003410 for ; Thu, 7 Apr 2011 18:17:02 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p37GGwJC004860 for ; Thu, 7 Apr 2011 18:16:58 +0200 (CEST) Message-ID: <4D9DE37A.5030105@cisco.com> Date: Thu, 07 Apr 2011 18:16:58 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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-claise-energy-monitoring-mib-07 -> pmPowerStateMappingTable? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 16:27:42 -0000 Dear all, During the meeting, we decided for multiple sets of power states in IANA. Do we still need this table, based on the Manufacturer Power State? pmPowerStateMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PmPowerStateMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates the maximum power usage, in watts, for every single Manufacturer Power State. This table also maps the Manufacturer Power States to the Power States specified in this document (more specifically, to the PowerMonitorState textual convention). Finally, this table returns the name of each Manufacturer Power State. For every different pmPowerManufacturerMappingId in the pmTable, there is a corresponding entry in this table." ::= { powerMonitorMIBObjects 3 } Regards, Benoit. From j.schoenwaelder@jacobs-university.de Thu Apr 7 11:17:58 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035F63A696A for ; Thu, 7 Apr 2011 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKC5YbfOrDjn for ; Thu, 7 Apr 2011 11:17:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8F30F3A6962 for ; Thu, 7 Apr 2011 11:17:54 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBFB3C003B; Thu, 7 Apr 2011 20:19:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WGbaNrmoI33g; Thu, 7 Apr 2011 20:19:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20503C000C; Thu, 7 Apr 2011 20:19:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 662FD175BCD0; Thu, 7 Apr 2011 20:19:34 +0200 (CEST) Date: Thu, 7 Apr 2011 20:19:33 +0200 From: Juergen Schoenwaelder To: john parello Message-ID: <20110407181933.GA78379@elstar.local> Mail-Followup-To: john parello , "eman@ietf.org" References: <4D9DE17D.5090606@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9DE17D.5090606@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 07 Apr 2011 18:17:58 -0000 On Thu, Apr 07, 2011 at 09:08:29AM -0700, john parello wrote: > Hi > > The requirements draft calls for an indication of the following for a state: > > - time in state > - reason > - count > > While working on adding multiple power state series we've found that > this information was relevant only there was a single power state > series. > > Now that we have multiple series do we need this information? > > I can see the usefulness of this information but the charter says we > are to to do transitions optionally and the requirements is calling > for this but I think it's based on a single series. > > What do people think: > > 1) Should we keep this information? > 2) If so, do we need to model this information per power state series? Can you explain why multiple power state series cause a change here? For any given point in time, is a device in just one state or in multiple? I personally would hope only one but I am not sure... If not, has there been WG concensus to support devices in multiple states of different sets concurrently? Independent of whether there is one or multiple concurrent states, should it not be possible to still measure the time spent in the state(s)? Or is the issue that a device can sometimes be in one state, at other times in two or even more? I would argue if the WG wants this complexity, then it needs to work it out instead of removing useful information. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From karagian@cs.utwente.nl Thu Apr 7 22:02:51 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4341D3A6800 for ; Thu, 7 Apr 2011 22:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAeWudRZOiJV for ; Thu, 7 Apr 2011 22:02:48 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 843693A67E6 for ; Thu, 7 Apr 2011 22:02:47 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p3853mIB008673; Fri, 8 Apr 2011 07:03:48 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 08 Apr 2011 05:04:20 +0000 To: "john parello" , "eman@ietf.org" Date: Fri, 08 Apr 2011 05:04:20 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4D9DE17D.5090606@cisco.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 08 Apr 2011 07:03:59 +0200 (MEST) Subject: Re: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 05:02:51 -0000 Hi John Can you please list what are the advantages and disadvantages of having this information in multiple power state series? Best regards, Georgios On 4/7/2011, "john parello" wrote: >Hi > >The requirements draft calls for an indication of the following for a state: > >- time in state >- reason >- count > >While working on adding multiple power state series we've found that >this information was relevant only there was a single power state series. > >Now that we have multiple series do we need this information? > >I can see the usefulness of this information but the charter says we are >to to do transitions optionally and the requirements is calling for this >but I think it's based on a single series. > >What do people think: > >1) Should we keep this information? >2) If so, do we need to model this information per power state series? > >Jp > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Fri Apr 8 04:16:33 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73003A69C4 for ; Fri, 8 Apr 2011 04:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGTQXTgYXYIG for ; Fri, 8 Apr 2011 04:16:33 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id AF7663A68EF for ; Fri, 8 Apr 2011 04:16:32 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MTvWL-1QYj612aaf-00RSk1; Fri, 08 Apr 2011 13:18:16 +0200 References: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250736277E@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250736277E@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 Message-Id: Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Fri, 8 Apr 2011 13:18:16 +0200 To: "Mielke, William F (Bill)" X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:fUSJLbovgVBTdX4d2BEaIe4fz5+SugteTYvKIiPJxce et0F3HiuDM7r48HhtdJ53sivwyvv7IMstJyBdXpxbYqtrWMb0a VGRyVoUPTUfAsKWzTQZmzM57C7aPpFwFKxzcvB39yp88TIjOiE R0xYFC0qgCM10kJMPyQ+102cqu0BFJcT8ncIrGURe43/a8rUxI BYfvCfTfEvN6oI43Q3VHg== Cc: eman mailing list Subject: Re: [eman] Comments on draft-quittek-eman-battery-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 11:16:33 -0000 Hi Bill, Thank you for organizing this review. It is very helpful. Please find replies inline. On 29.03.2011 19:06 Mielke, William F (Bill) wrote: > See below. >=20 > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 >=20 > "Live like you're going to die tomorrow. > Learn like you're going to live forever." >=20 > - Albert Einstein >=20 > --------------------------------------------- > Comments on draft-quittek-eman-battery-mib-00 > --------------------------------------------- >=20 > I queried one of my colleagues, Christophe Grangeat, to review this = document and provide some comments. Christophe has a lot of domain = expertise with various battery technologies and the monitoring = requirements for them. I can get back with him if we need further = clarification. >=20 > Here is his response to my query: >=20 > It is natural that the battery MIB topic is starting with Li-ion = batteries, since they require an embedded control board to operate = safely. However, it is now required that Hybrid systems with deep cycle = lead-acid batteries also need some careful monitoring in order to = operate in the most efficient and sustainable way. These lead-acid = batteries would not have their own embedded control board but the = battery monitoring MIBs would be embedded in the controller of the = energy management system. NiCd batteries would be managed in the same = way as lead-acid. We also observe new battery technologies, like Sodium = or Redox Flow batteries that also require some control electronics and = which we advocate should be using standardized MIBs.=20 >=20 > On the document itself, here are a few comments that we would propose = at this stage: >=20 > Chapter3 4th =A7 > In the static properties we recommend to add the manufacturer's = recommended charging data, such as boost voltage, float voltage, current = limitation, maximum duration at boost voltage, This sounds like a good idea. These numbers are typically known for all re-chageable batteries. I will add this as an open issue to the next version. Then we can discuss if we want to have these number in. I am in favor of doing so, but first, I would like to have some more = time to think about it. =20 > Chapter 7.1 > We consider temperature an important criterion for battery safety and = life time. We would recommend including battery temperature in the MIB, = as well as criteria that allow raising thermal run-away alarms. Fine. I added it. > On the same safety topic, we would recommend to add a "batteryHealth" = criterion, which can include for example SymetryAlarms for lead-acid = technology.=20 I am not very familiar with electronic control of lead-acid batteries. Can somebody elaborate more on this.=20 I will add this to the open issues and try to study the issue in the = next weeks. > Chapter 7.2 > The SoC estimate issues may be sensitive to address for some = technologies like lead-acid or NiCd. The group should seek advice from = manufacturers.=20 Sorry, what is SoC? Thanks and best regards, Juergen > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From russ@cisco.com Fri Apr 8 06:50:39 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD9D28C118 for ; Fri, 8 Apr 2011 06:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwXhfB6PmGMy for ; Fri, 8 Apr 2011 06:50:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 362113A690F for ; Fri, 8 Apr 2011 06:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1340; q=dns/txt; s=iport; t=1302270743; x=1303480343; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=nmFdG1G9Q/w5UCrW2/5JdM4IgCNJulegu1MYfye0QHA=; b=lBmGSUchxpQA24J3fyyblYYiUorCWtJlH0UcL2yxQx8Ws1NxZ8wlN0MD mJGx0VyUX6zNHVEXYXs0F5A8fvpEgjMu+5n8AYCqQ/QpaJNlRu/xTQpOM LUi0TlGsfdwOloZR7u5ZZJUh8J32OIgdFUV/XJY2KmuM5CsHK1hbuNxuf s=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.63,323,1299456000"; d="asc'?scan'208";a="426353682" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 08 Apr 2011 13:52:23 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p38DqMMS007941; Fri, 8 Apr 2011 13:52:23 GMT Message-ID: <4D9F12FE.3080409@cisco.com> Date: Fri, 08 Apr 2011 09:51:58 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: john parello References: <4D9DE17D.5090606@cisco.com> In-Reply-To: <4D9DE17D.5090606@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2849071BE6A28549A6C149D8" Cc: "eman@ietf.org" Subject: Re: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 13:50:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2849071BE6A28549A6C149D8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > 1) Should we keep this information? It seems like this could be inferred from traps, rather than trying to actually store the information locally... I wonder --once you start down the path of storing state changes, how far back do you go, etc? I would say no, unless we have a solid reason to collect this type of information. Russ --=20 riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone 'I suppose there are two views about everything,' said Mark. 'Eh? Two views? There are a dozen views about everything, until you know the answer. Then there=C2=92s never more than one.' -C.S. Lewis --------------enig2849071BE6A28549A6C149D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2fEv4ACgkQER27sUhU9OQy/ACglvfFlzYJP+w4t8ro7z9O7lYj /O0AnRPWocDvf8dLQxAKfxGN5SF4VXXi =JRdi -----END PGP SIGNATURE----- --------------enig2849071BE6A28549A6C149D8-- From j.schoenwaelder@jacobs-university.de Fri Apr 8 07:19:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6C893A6A0A for ; Fri, 8 Apr 2011 07:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a7ZF-b35TZ2 for ; Fri, 8 Apr 2011 07:19:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E8CEC3A6919 for ; Fri, 8 Apr 2011 07:19:10 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0C53C0044; Fri, 8 Apr 2011 16:20:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t7A7j1wCGldU; Fri, 8 Apr 2011 16:20:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0EB3C0014; Fri, 8 Apr 2011 16:20:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A29F6175E00B; Fri, 8 Apr 2011 16:20:50 +0200 (CEST) Date: Fri, 8 Apr 2011 16:20:49 +0200 From: Juergen Schoenwaelder To: Russ White Message-ID: <20110408142048.GA81222@elstar.local> Mail-Followup-To: Russ White , john parello , "eman@ietf.org" References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9F12FE.3080409@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 14:19:12 -0000 On Fri, Apr 08, 2011 at 09:51:58AM -0400, Russ White wrote: > > > 1) Should we keep this information? > > It seems like this could be inferred from traps, rather than trying to > actually store the information locally... I wonder --once you start down > the path of storing state changes, how far back do you go, etc? > > I would say no, unless we have a solid reason to collect this type of > information. Are we talking about 3.4.1. in draft-ietf-eman-requirements-01.txt? That text does not require to keep a history as far as I understand it. Being able to read the current state is nice. Being able to figure how how much time a device/component has been spent in each state without constant polling or relying on notifications (which might not get through) is even nicer. This is how I understand 3.4.1. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From russ@cisco.com Fri Apr 8 07:22:10 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECD73A6A0A for ; Fri, 8 Apr 2011 07:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJjJ55ErD4Yf for ; Fri, 8 Apr 2011 07:22:09 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3B8193A6919 for ; Fri, 8 Apr 2011 07:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1639; q=dns/txt; s=iport; t=1302272634; x=1303482234; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=lQAmavgfYhZW7MyU/jpvGbGVCUrJvs6fkBOWRcOGrI8=; b=cXK1oor5syr1YRjxfVTGh79MwV34zxIMyaRUjzSLmN8gs8aP03cqOI4j vO7/QSbFxeL54oXPUpHjoG/HQTIOew5f5trNTnH5rEI+VCK2O07D3h4qU W/tItboC6jDDyTg67PR3A5JVjBYGgm5MuMNL+k6r6v+fWzGADM4ys6iFy A=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.63,323,1299456000"; d="asc'?scan'208";a="292193647" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2011 14:23:54 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p38ENrX7025806; Fri, 8 Apr 2011 14:23:54 GMT Message-ID: <4D9F1A5F.1030107@cisco.com> Date: Fri, 08 Apr 2011 10:23:27 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: john parello , "eman@ietf.org" References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> In-Reply-To: <20110408142048.GA81222@elstar.local> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2CEF7DFEECFF9CF7427BF0E6" Subject: Re: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 14:22:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2CEF7DFEECFF9CF7427BF0E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Are we talking about 3.4.1. in draft-ietf-eman-requirements-01.txt? > That text does not require to keep a history as far as I understand > it. Being able to read the current state is nice. Being able to figure > how how much time a device/component has been spent in each state > without constant polling or relying on notifications (which might not > get through) is even nicer. This is how I understand 3.4.1. When you say, "in each state," do you mean "the current state," or do you mean, "for every previous state change," or "for n previous state changes," or... ?? Russ --=20 riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone Now, we never can annihilate a penalty. We can only divert it from the head of the man who has incurred it to the heads of others who have not incurred it. A vast amount of "social reform" consists in just this operation. -William Graham Sumner --------------enig2CEF7DFEECFF9CF7427BF0E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2fGmEACgkQER27sUhU9OReUwCeOz3P0jtxhEBVOAO0FB9XXLAa M30An3rNLHolu16xoFtc47mOk6XkA8vc =dhT+ -----END PGP SIGNATURE----- --------------enig2CEF7DFEECFF9CF7427BF0E6-- From j.schoenwaelder@jacobs-university.de Fri Apr 8 07:29:28 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1A53A6A0A for ; Fri, 8 Apr 2011 07:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaC4+ns4MjEq for ; Fri, 8 Apr 2011 07:29:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 45EA43A691F for ; Fri, 8 Apr 2011 07:29:27 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B86DC0044; Fri, 8 Apr 2011 16:31:12 +0200 (CEST) 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 gwYcUywODYSu; Fri, 8 Apr 2011 16:31:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9672FC0014; Fri, 8 Apr 2011 16:31:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C226D175E0E5; Fri, 8 Apr 2011 16:31:07 +0200 (CEST) Date: Fri, 8 Apr 2011 16:31:07 +0200 From: Juergen Schoenwaelder To: Russ White Message-ID: <20110408143107.GA81369@elstar.local> Mail-Followup-To: Russ White , john parello , "eman@ietf.org" References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9F1A5F.1030107@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 14:29:28 -0000 On Fri, Apr 08, 2011 at 10:23:27AM -0400, Russ White wrote: > > > Are we talking about 3.4.1. in draft-ietf-eman-requirements-01.txt? > > That text does not require to keep a history as far as I understand > > it. Being able to read the current state is nice. Being able to figure > > how how much time a device/component has been spent in each state > > without constant polling or relying on notifications (which might not > > get through) is even nicer. This is how I understand 3.4.1. > > When you say, "in each state," do you mean "the current state," or do > you mean, "for every previous state change," or "for n previous state > changes," or... ?? My reading of 3.4.1. is that "each state" means each power state (not state changes). If a box supports the five different power states, e.g., 'full power', 'low power', 'standby', 'hibernating', 'off', there would be five "counters" that keep track of how much time has been spent in each of those five different power states. By example, I would be able to read: 'full power': 24 mintues 'low power': 53 minutes 'standby': 0 minutes 'hibernating': 512 minutes 'off': 12345 minutes Perhaps Juergen Quittek can clarify this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From russ@cisco.com Fri Apr 8 08:14:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9470B3A693B for ; Fri, 8 Apr 2011 08:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Subqy3zchD+M for ; Fri, 8 Apr 2011 08:14:26 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A5BE23A681F for ; Fri, 8 Apr 2011 08:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1663; q=dns/txt; s=iport; t=1302275772; x=1303485372; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=NtV4FvxMarNP/+4ZoTkhuG6xYIYBDmeQ8ftSV84z1iQ=; b=Z9p6zlUSnbUdFMDhgDKmzoa4OvoTZGCq3Rv/qC4N1ChUzRgqeiSYIBiu Um4r2lscN54uVdtk4QK0TbSErjzknanMRY9env4GTGhJYkatdZlf8cYH2 Z85XYdD/xkWYlDmD7MkUv2YQQ5d7R4bswmeELweCtSu76tfe24CDV7jJ8 c=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.63,324,1299456000"; d="asc'?scan'208";a="229569559" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 08 Apr 2011 15:16:11 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p38FGBmO003924; Fri, 8 Apr 2011 15:16:11 GMT Message-ID: <4D9F26A0.20407@cisco.com> Date: Fri, 08 Apr 2011 11:15:44 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: john parello , "eman@ietf.org" References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> In-Reply-To: <20110408143107.GA81369@elstar.local> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5EC4049DBBD1AD7206D33E36" Subject: Re: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 15:14:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5EC4049DBBD1AD7206D33E36 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > My reading of 3.4.1. is that "each state" means each power state (not > state changes). If a box supports the five different power states, > e.g., 'full power', 'low power', 'standby', 'hibernating', 'off', > there would be five "counters" that keep track of how much time has > been spent in each of those five different power states. By example, I > would be able to read: >=20 > 'full power': 24 mintues > 'low power': 53 minutes > 'standby': 0 minutes > 'hibernating': 512 minutes > 'off': 12345 minutes I don't see the usefulness of this sort of information... Can someone explain? Russ --=20 riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone Extremism is a mental disorder in which a person actually believes jumping off a fifty story building will kill you. We all know from watching cartoons there is a high probability your shirt will be caught on a flag pole. --------------enig5EC4049DBBD1AD7206D33E36 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2fJqIACgkQER27sUhU9OSM/gCgqrcOeWPjCGFW27ywRgLmyG0N rwEAoMg5T6sAYIDb4ZwSz3vyjcp2TeZ0 =BWBF -----END PGP SIGNATURE----- --------------enig5EC4049DBBD1AD7206D33E36-- From blueroofmusic@gmail.com Fri Apr 8 08:19:15 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A0C3A681F for ; Fri, 8 Apr 2011 08:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXT-NvzdqqiY for ; Fri, 8 Apr 2011 08:19:14 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B07673A6819 for ; Fri, 8 Apr 2011 08:19:13 -0700 (PDT) Received: by fxm15 with SMTP id 15so2748485fxm.31 for ; Fri, 08 Apr 2011 08:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=mfBdDXI0fYOOQ50793S8v0mVsDrmdJ/9sRHefNC2Qv4=; b=oT39nKMcC3LY51/IOp2pod9zlpQEogbWq/IPEz2OVPGRefgZS7PXi0dReSZtCcYcEF JqfdSeUopY7NmCLRSdlgnAdnImxWTreUGmfWXhQu+ne6GbR/M7d/bdzOKwJl5RCd8vV4 6RBcyN93EuZLTBzvmW3tAI6HedXqRWDCdHo50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XS62Jk+kEQiytKz50bUz/Uzq7/nfrDncHBFhEqGP/mnPW9KbJy2qWAgNIoWBHAIC81 +TWZzo41Axpk786lJ+uqH0NtUfnmMS4AjytWbgsks6sBAsYQwdUZLxeBcprqiAvnI9T4 wRrRwTp4ePySk6mt3BGxCDJiEVkDi3HkVSLsQ= MIME-Version: 1.0 Received: by 10.223.159.14 with SMTP id h14mr2421052fax.20.1302276058412; Fri, 08 Apr 2011 08:20:58 -0700 (PDT) Received: by 10.223.158.143 with HTTP; Fri, 8 Apr 2011 08:20:58 -0700 (PDT) In-Reply-To: <20110408143107.GA81369@elstar.local> References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> Date: Fri, 8 Apr 2011 11:20:58 -0400 Message-ID: From: Ira McDonald To: Juergen Schoenwaelder , Russ White , john parello , "eman@ietf.org" Content-Type: multipart/alternative; boundary=0023541869fcdc7baf04a069c5df Subject: Re: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 15:19:15 -0000 --0023541869fcdc7baf04a069c5df Content-Type: text/plain; charset=ISO-8859-1 Hi, FWIW - in our recent IEEE-ISTO PWG Power Model [1] and MIB [2], we defined a REQUIRED short log of timestamped *stable* state entry times. So the calculation of time in state was offloaded to the remote SNMP Manager. Also the log can be slow-polled (although we also defined a state transition trap). There was a strong consensus among PWG members that this log table was important, especially to discover abnormal patterns of state transitions. We made it RECOMMENDED that at least 10 entries be supported. Here's the relevant MIB fragment: powLogTable OBJECT-TYPE SYNTAX SEQUENCE OF PowLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the log entries on this Imaging System. Usage: Conforming implementations SHOULD support at least 10 entries concurrently in the powLogTable and MUST always delete the oldest entry first (FIFO) for memory management, i.e., the powLogTable always consists of a sliding window of entries with contiguous values of powLogIndex." ::= { powLog 1 } powLogEntry OBJECT-TYPE SYNTAX PowLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a log entry on this Imaging System." INDEX { powLogIndex } ::= { powLogTable 1 } PowLogEntry ::= SEQUENCE { powLogIndex Integer32, powLogPowerState PowPowerStateTC, powLogPowerStateMessage SnmpAdminString, powLogPowerStateDateAndTime DateAndTime, powLogComponentType PowPowerComponentTypeTC, powLogComponentReferenceId Integer32 } Cheers, - Ira (editor of PWG Power Model/MIB) [1] ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf [2] ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Christmas through April: 579 Park Place Saline, MI 48176 734-944-0094 May to Christmas: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Apr 8, 2011 at 10:31 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Apr 08, 2011 at 10:23:27AM -0400, Russ White wrote: > > > > > Are we talking about 3.4.1. in draft-ietf-eman-requirements-01.txt? > > > That text does not require to keep a history as far as I understand > > > it. Being able to read the current state is nice. Being able to figure > > > how how much time a device/component has been spent in each state > > > without constant polling or relying on notifications (which might not > > > get through) is even nicer. This is how I understand 3.4.1. > > > > When you say, "in each state," do you mean "the current state," or do > > you mean, "for every previous state change," or "for n previous state > > changes," or... ?? > > My reading of 3.4.1. is that "each state" means each power state (not > state changes). If a box supports the five different power states, > e.g., 'full power', 'low power', 'standby', 'hibernating', 'off', > there would be five "counters" that keep track of how much time has > been spent in each of those five different power states. By example, I > would be able to read: > > 'full power': 24 mintues > 'low power': 53 minutes > 'standby': 0 minutes > 'hibernating': 512 minutes > 'off': 12345 minutes > > Perhaps Juergen Quittek can clarify this. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --0023541869fcdc7baf04a069c5df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

FWIW - in our recent IEEE-ISTO PWG Power Model [1] and MIB [2], =
we defined a REQUIRED short log of timestamped *stable* state entry
= times.=A0 So the calculation of time in state was offloaded to the remote SNMP Manager.=A0 Also the log can be slow-polled (although we also
defin= ed a state transition trap).

There was a strong consensus among PWG = members that this
log table was important, especially to discover abnormal patterns
of state transitions.

We made it RECOMMENDED that at least 10 entrie= s be supported.=A0
Here's=A0the relevant MIB fragment:

powLogTable= OBJECT-TYPE
=A0=A0=A0 SYNTAX=A0=A0= =A0=A0=A0 SEQUENCE OF PowLogEntry
=A0=A0= =A0 MAX-ACCESS=A0 not-accessible
=A0=A0=A0 STATUS=A0=A0= =A0=A0=A0 current
<= span style=3D"font-family: courier new,monospace;">=A0=A0=A0 DESCRIPTION
=A0=A0=A0=A0=A0=A0=A0 &= quot;A table of the log entries on this Imaging System.

=A0=A0=A0= =A0=A0=A0=A0 Usage:=A0 Conforming implementations SHOULD support at least 1= 0
=A0=A0=A0=A0=A0=A0=A0 e= ntries concurrently in the powLogTable and MUST always delete
=A0=A0=A0=A0=A0=A0=A0 the oldest entry first (FIFO) for= memory management, i.e., the
=A0=A0=A0=A0=A0=A0=A0 p= owLogTable always consists of a sliding window of entries with
=A0=A0=A0=A0=A0=A0=A0 contiguous values of powLogIndex= ."
=A0=A0=A0 ::=3D { powLo= g 1 }

powLogEntry OBJECT-TYPE
=A0=A0=A0 SYNTAX=A0=A0= =A0=A0=A0 PowLogEntry
=A0=A0=A0 MAX-ACCESS= =A0 not-accessible
=A0=A0=A0 STATUS=A0=A0= =A0=A0=A0 current
<= span style=3D"font-family: courier new,monospace;">=A0=A0=A0 DESCRIPTION
=A0=A0=A0=A0=A0=A0=A0 &= quot;An entry for a log entry on this Imaging System."
=A0=A0=A0 INDEX=A0=A0=A0=A0 { powLogIndex }
=A0=A0=A0 ::=3D { powLo= gTable 1 }

PowLogEntry ::=3D SEQUENCE {
=A0=A0=A0=A0=A0=A0=A0 p= owLogIndex=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Inte= ger32,
=A0=A0=A0=A0=A0=A0=A0 powLogPowerS= tate=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PowPowerStateTC, =A0=A0=A0=A0=A0=A0=A0 p= owLogPowerStateMessage=A0=A0=A0=A0=A0=A0=A0=A0 SnmpAdminString,
=A0=A0=A0=A0=A0=A0=A0 powLogPowerStateDateAndTime=A0= =A0=A0=A0 DateAndTime,
=A0=A0=A0=A0=A0=A0=A0 p= owLogComponentType=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PowPowerComponentTyp= eTC,
=A0=A0=A0=A0=A0=A0=A0 powLogComponent= ReferenceId=A0=A0=A0=A0=A0 Integer32
=A0=A0=A0 }

Cheers,
- Ira (e= ditor of PWG Power Model/MIB)

[1] ftp://ftp.pwg.org/pub/pwg= /candidates/cs-wimspower10-20110214-5106.4.pdf
[2] ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-2011= 0214-5106.5.pdf

Ira McDonald (Musician / Software = Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP W= G
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Print= er MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blue= roofmusic
http://sites.google.com/site/highnorthinc=
mailto:blu= eroofmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 Saline, MI=A0 48176
= =A0 734-944-0094
May to Christmas:
=A0 PO Box 221=A0 Grand Marais, MI= 49839
=A0 906-494-2434



On Fri, Apr 8, 2011 at 10:31 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote= :
On Fri, Apr 08, 2011 at 1= 0:23:27AM -0400, Russ White wrote:
>
> > Are we talking about 3.4.1. in draft-ietf-eman-requirements-01.tx= t?
> > That text does not require to keep a history as far as I understa= nd
> > it. Being able to read the current state is nice. Being able to f= igure
> > how how much time a device/component has been spent in each state=
> > without constant polling or relying on notifications (which might= not
> > get through) is even nicer. This is how I understand 3.4.1.
>
> When you say, "in each state," do you mean "the current= state," or do
> you mean, "for every previous state change," or "for n = previous state
> changes," or... ??

My reading of 3.4.1. is that "each state" means each power = state (not
state changes). If a box supports the five different power states,
e.g., 'full power', 'low power', 'standby', 'hi= bernating', 'off',
there would be five "counters" that keep track of how much time h= as
been spent in each of those five different power states. By example, I
would be able to read:

'full power': =A0 =A0 24 mintues
'low power': =A0 =A0 =A053 minutes
'standby': =A0 =A0 =A0 =A0 0 minutes
'hibernating': =A0 512 minutes
'off': =A0 =A0 =A0 =A0 12345 minutes

Perhaps Juergen Quittek can clarify this.

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman

--0023541869fcdc7baf04a069c5df-- From chrisv@cyberswitching.com Fri Apr 8 08:33:05 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407AF3A697B for ; Fri, 8 Apr 2011 08:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Snqrq5u2nfgz for ; Fri, 8 Apr 2011 08:33:04 -0700 (PDT) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) by core3.amsl.com (Postfix) with ESMTP id D13183A6974 for ; Fri, 8 Apr 2011 08:33:03 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o141.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 81b2f9d4.0.1340.00-367.3086.p01c12o141.mxlogic.net (envelope-from ); Fri, 08 Apr 2011 09:34:49 -0600 (MDT) X-MXL-Hash: 4d9f2b1938d92067-ce455ade729b755491349cc43f98256eafce6a12 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, 8 Apr 2011 08:34:22 -0700 Message-ID: <68FBE0F3CE97264395875AC1C468F22CF37345@mail03.cyberswitching.local> In-Reply-To: <4D9F26A0.20407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Do we need power state transition count and time instate? Thread-Index: Acv1/+Ton2cm9YWnTUKZXKAcnDK3XAAAjpRA References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com><20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com><20110408143107.GA81369@elstar.local> <4D9F26A0.20407@cisco.com> From: "Chris Verges" To: "Russ White" , "john parello" , X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=irOsLE28rlYA:10 a=RsFROoOW2E8A:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=7l7kQfU-n4_KXcp-36kA:9 a=E] X-AnalysisOut: [02jm-615jUEbJxRXtQA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 ] X-AnalysisOut: [a=JfD0Fch1gWkA:10] Subject: Re: [eman] Do we need power state transition count and time instate? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 15:33:05 -0000 Hi Russ, While I'm not advocating for the inclusion of this feature in the initial MIB design, such information could be useful to determine a weighted average of power usage over time. For example, if a device draws a lot of power while on, but is off most of the time, then a facilities manager can use that information to better plan for capacity needs. However, it does seem like EMAN is trying to do a LOT from the get-go without publishing and finishing a base set. I'd say this type of meta-information probably qualifies into a second-gen of EMAN's scope, perhaps? Chris -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Russ White Sent: Friday, April 08, 2011 8:16 AM To: john parello; eman@ietf.org Subject: Re: [eman] Do we need power state transition count and time instate? > My reading of 3.4.1. is that "each state" means each power state (not=20 > state changes). If a box supports the five different power states,=20 > e.g., 'full power', 'low power', 'standby', 'hibernating', 'off',=20 > there would be five "counters" that keep track of how much time has=20 > been spent in each of those five different power states. By example, I > would be able to read: >=20 > 'full power': 24 mintues > 'low power': 53 minutes > 'standby': 0 minutes > 'hibernating': 512 minutes > 'off': 12345 minutes I don't see the usefulness of this sort of information... Can someone explain? Russ -- riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone Extremism is a mental disorder in which a person actually believes jumping off a fifty story building will kill you. We all know from watching cartoons there is a high probability your shirt will be caught on a flag pole. From j.schoenwaelder@jacobs-university.de Fri Apr 8 08:46:59 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F043A6905 for ; Fri, 8 Apr 2011 08:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHCQFXA-tqLL for ; Fri, 8 Apr 2011 08:46:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 954FB3A6819 for ; Fri, 8 Apr 2011 08:46:58 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3DA9C0046; Fri, 8 Apr 2011 17:48:43 +0200 (CEST) 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 n13XIkSBXGAj; Fri, 8 Apr 2011 17:48:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF2B3C0002; Fri, 8 Apr 2011 17:48:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BD497175E490; Fri, 8 Apr 2011 17:48:39 +0200 (CEST) Date: Fri, 8 Apr 2011 17:48:39 +0200 From: Juergen Schoenwaelder To: Russ White Message-ID: <20110408154839.GA81729@elstar.local> Mail-Followup-To: Russ White , john parello , "eman@ietf.org" References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> <4D9F26A0.20407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9F26A0.20407@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] Do we need power state transition count and time in state? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 15:46:59 -0000 On Fri, Apr 08, 2011 at 11:15:44AM -0400, Russ White wrote: > > > My reading of 3.4.1. is that "each state" means each power state (not > > state changes). If a box supports the five different power states, > > e.g., 'full power', 'low power', 'standby', 'hibernating', 'off', > > there would be five "counters" that keep track of how much time has > > been spent in each of those five different power states. By example, I > > would be able to read: > > > > 'full power': 24 mintues > > 'low power': 53 minutes > > 'standby': 0 minutes > > 'hibernating': 512 minutes > > 'off': 12345 minutes > > I don't see the usefulness of this sort of information... Can someone > explain? I assume people find it important to know the percentage of time a device spends in a certain power state. Approximating this by active polling of the current state is pretty inefficient and inaccurate since you can miss state changes. If the device records the time spent in each state, you get a precise breakdown of the time spend in each power state between each poll, which means you can safely poll at a much lower frequency. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@quittek.at Fri Apr 8 09:29:17 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC353A68CF for ; Fri, 8 Apr 2011 09:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fI5WnHCv6xd for ; Fri, 8 Apr 2011 09:29:16 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id B0BC83A6889 for ; Fri, 8 Apr 2011 09:29:15 -0700 (PDT) Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MNN9N-1Q1Kp310o5-007eWD; Fri, 08 Apr 2011 18:30:53 +0200 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <4E865439-BB19-431C-83A8-2277AD7D23AC@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Fri, 8 Apr 2011 18:30:51 +0200 To: Georgios Karagiannis X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:02GLEcUVw0OqPYPJABdJTRWh7XWNW2JVXhESAHUyUfL MIUr3K+thLgjmqH4wtwNuMxD9RmpRl/Glp6OKeedri1MC2U3od HMGT/OSt7heeWai/P7MdGZivIbknA4K8YzTMtX38oAD6zxKV0x EaZSNPf+hGby4nAXZCFxi+0zi6BXZLH86s9bc+6pNS77f9gwwy 3LeEh/t0qBbSZWUJRT+3Q== Cc: "eman@ietf.org" Subject: Re: [eman] comments on draft-ietf-eman-requirements-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 16:29:17 -0000 Hi Georgios, Thank you for reviewing the draft. Please find replies inline. Am 03.04.2011 um 22:32 schrieb Georgios Karagiannis: > Hi Juergen >=20 > I have read the draft-ietf-eman-requirements-01 draft. The draft = includes > important requirements. However, I have two comments: Great. Thanks, > *) in my opinion the requirement on Power State Monitoring described = in > Section 3.4.1 is only focussing on individual devices, i.e, power > monitor children. According to the discussions that we have had in the > eman meeting, the types of powers states associated with the Power > Monitor Parents can be different than the ones used for the Power > Monitor Children. This is due to the fact that a Power Monitor Parent > needs to aggregate the Power states associated with its Power Monitor > Children. Is it possible to include an explanatory paragraph that > emphasizes the fact that types of the power states in the Power = Monitor > Parents and Power Monitor Child can be different? What would be the requirement here? Would we require that reports from parents are different to the ones = from children? Or would we require that parents need to have aggregation functions? Which functions would we require? > *) there are situations where a device, e.g., a battery, sometimes > supplies energy and other times the same device consumes energy. Is it > possible to include a requirement that will ensure that the direction = of > energy to/from a device can also be monitored? Yes, this is a very good point. We should add a requirement for the measurement of the direction of the = energy flow. Thanks and best regards, Juergen > Best regards, > Georgios From Internet-Drafts@ietf.org Fri Apr 8 09:45:04 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99BE23A6910; Fri, 8 Apr 2011 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EItaxkW5MFe5; Fri, 8 Apr 2011 09:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959283A68D4; Fri, 8 Apr 2011 09:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110408164501.12446.19644.idtracker@localhost> Date: Fri, 08 Apr 2011 09:45:01 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action:draft-ietf-eman-battery-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 16:45:05 -0000 --NextPart 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 : Definition of Managed Objects for Battery Monitoring Author(s) : J. Quittek, et al. Filename : draft-ietf-eman-battery-mib-00.txt Pages : 22 Date : 2011-04-08 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eman-battery-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-08093557.I-D@ietf.org> --NextPart-- From ietf@quittek.at Fri Apr 8 09:57:57 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799523A697E for ; Fri, 8 Apr 2011 09:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtMbxTRXa9PH for ; Fri, 8 Apr 2011 09:57:55 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 9BF323A6966 for ; Fri, 8 Apr 2011 09:57:54 -0700 (PDT) Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MVnY3-1QQ7Ne0WGV-00Z2Uj; Fri, 08 Apr 2011 18:59:38 +0200 References: <20110408164501.12446.19644.idtracker@localhost> From: Juergen Quittek Content-Type: multipart/alternative; boundary=Apple-Mail-4--295254415 In-Reply-To: <20110408164501.12446.19644.idtracker@localhost> Message-Id: <0B4397E7-292C-43ED-8904-D87B3CE49381@quittek.at> Date: Fri, 8 Apr 2011 18:59:36 +0200 To: "eman@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:jwZa8+FX/NNI/CV6aoBV448ALxshY1mUj7Ypev6SMAr Xzeavu61Sdr/H5mLhWQQj6KAwEz1RwX6Feo2HiYzVdA+7FUGfb CwG1vZMwrTmUPlp2X+bmoUAVZ2W7q+LOTaoAwt2noZylLmYgaO +3iACFhYydWpev8yloPhC9Q5ux3eYXoZ1b2QLmHl1CQIsoBFj6 hOUgoEDZH5CPrvqrBQ//A== Subject: Re: [eman] I-D Action:draft-ietf-eman-battery-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 16:57:57 -0000 --Apple-Mail-4--295254415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, As you can see from the previous posting, we now have a WG draft on the = battery MIB.=20 It is a revision of draft-quittek-eman-batter-mib-00. Changes are based = on comments received as four reviews on the mailing list and at our = session in Prague. Please find a summary of all changes at the end of = this message.=20 I look forward to your comments and questions on the new version. And I would be grateful for proposals on how to solve the remaining open = issues listed in Section 8. Changes between draft-quittek-eman-battery-mib-00 and draft-ietf-eman-battery-mib-00 are: - addressed relation to eman-framework - addressed monitoring of multiple batteries in a device - clarified that CMOS batteries are not explicitly in scope - change use of Entity MIB index from RECOMMENDED to REQUIRED - moved battery types from enumeration to IANA registration - this required some new text in new section 4 and in the IANA considerations - moved enumeration values 'unknown' and 'other' to the top of all enumerations - renamed batteryState to batteryChargingState - removed battery stated 'full' and 'empty' - mentioned that primary batteries are not re-chargeable - renamed batteryRemainingCapacity to batteryActualCapacity - fixed data types o some managed objects - added object batteryTemperature - removed object batteryCurrentChargePercentage - just using batteryCurrentCharge should be sufficient - changed object batteryLowAlarmPercentage to batteryLowAlarmCharge - changed MAX-ACCESS of all four objects with notifications thresholds from read-only to read-write - batteryLowAlarmCharge - batteryLowAlarmVoltage - batteryReplacementAlarmCapacity - atteryReplacementAlarmCycles - made implementation of batteryAlarmThresholdsGroup optional - fixed wrong group names in compliance statements - removed all old open issues except "Define Charging Cycle" - added new open issues - Writable Notification Thresholds - Re-arming batteryLowNotification - Add Charging Data of Batteries? - Add batteryHealth? - Battery Identifier Thanks, Juergen Am 08.04.2011 um 18:45 schrieb Internet-Drafts@ietf.org: > 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. >=20 >=20 > Title : Definition of Managed Objects for Battery = Monitoring > Author(s) : J. Quittek, et al. > Filename : draft-ietf-eman-battery-mib-00.txt > Pages : 22 > Date : 2011-04-08 >=20 > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it defines managed objects that provide information on > the status of batteries in managed devices. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-4--295254415 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

As you can see from the previous posting, we now = have a WG draft on the battery MIB. 

It = is a revision of draft-quittek-eman-batter-mib-00. Changes are = based on comments received as four reviews on the mailing list and = at our session in Prague. Please find a summary of all changes at the = end of this message. 

I look forward to your = comments and questions on the new version.

And = I would be grateful for proposals on how to solve the remaining open = issues listed in Section 8.

Changes between = draft-quittek-eman-battery-mib-00
and draft-ietf-eman-battery-mib-00 = are:

  - addressed relation to = eman-framework
  - addressed monitoring of multiple = batteries in a device
  - clarified that CMOS batteries are not = explicitly in scope
  - change use of Entity MIB index from = RECOMMENDED to REQUIRED
  - moved battery types from = enumeration to IANA registration
      - this = required some new text in new section 4 and in
    of all enumerations
  - renamed batteryRemainingCapacity to = batteryActualCapacity
  - fixed data types o some managed = objects
  - added object = batteryTemperature
  - removed object = batteryCurrentChargePercentage
      - just using = batteryCurrentCharge should be sufficient
  - changed object = batteryLowAlarmPercentage to
    = batteryLowAlarmCharge
  - changed MAX-ACCESS of all four objects = with notifications
    thresholds from read-only to = read-write
      - = batteryLowAlarmCharge
      - = batteryLowAlarmVoltage
      - = batteryReplacementAlarmCapacity
      - = atteryReplacementAlarmCycles
  - made implementation of = batteryAlarmThresholdsGroup optional
  - fixed wrong group names = in compliance statements
  - removed all old open = issues except "Define Charging Cycle"
  - added new open = issues
      - Writable Notification = Thresholds
      - Re-arming = batteryLowNotification
      - Add Charging Data of = Batteries?
      - Add = batteryHealth?
      - Battery = Identifier




Am 08.04.2011 um 18:45 schrieb = Internet-Drafts@ietf.org:
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 =           : Definition = of Managed Objects for Battery Monitoring
Author(s) =       : J. Quittek, et al.
Filename =        : = draft-ietf-eman-battery-mib-00.txt
Pages =           : = 22
= Date =            : = 2011-04-08

This memo defines a portion of the Management = Information Base (MIB)
for use with network management protocols in = the Internet community.
In particular, it defines managed objects = that provide information on
the status of batteries in managed = devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-00.t= xt

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

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
<Mail-Anhang>________________= _______________________________
eman mailing = list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

= --Apple-Mail-4--295254415-- From karagian@cs.utwente.nl Sat Apr 9 01:20:50 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E514D3A6A2B for ; Sat, 9 Apr 2011 01:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.706 X-Spam-Level: X-Spam-Status: No, score=0.706 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNw7AlfcFyOI for ; Sat, 9 Apr 2011 01:20:50 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 028A73A6A28 for ; Sat, 9 Apr 2011 01:20:49 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p398Lse4003944; Sat, 9 Apr 2011 10:21:54 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 09 Apr 2011 08:22:26 +0000 To: "Juergen Quittek" Date: Sat, 09 Apr 2011 08:22:26 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4E865439-BB19-431C-83A8-2277AD7D23AC@quittek.at> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 09 Apr 2011 10:22:04 +0200 (MEST) Cc: "eman@ietf.org" Subject: Re: [eman] comments on draft-ietf-eman-requirements-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2011 08:20:51 -0000 Hi Juergen Thanks for your observations! Please see in line! On 4/8/2011, "Juergen Quittek" wrote: >Hi Georgios, > >Thank you for reviewing the draft. >Please find replies inline. > >Am 03.04.2011 um 22:32 schrieb Georgios Karagiannis: > >> Hi Juergen >>=20 >> I have read the draft-ietf-eman-requirements-01 draft. The draft includes >> important requirements. However, I have two comments: > >Great. Thanks, > >> *) in my opinion the requirement on Power State Monitoring described in >> Section 3.4.1 is only focussing on individual devices, i.e, power >> monitor children. According to the discussions that we have had in the >> eman meeting, the types of powers states associated with the Power >> Monitor Parents can be different than the ones used for the Power >> Monitor Children. This is due to the fact that a Power Monitor Parent >> needs to aggregate the Power states associated with its Power Monitor >> Children. Is it possible to include an explanatory paragraph that >> emphasizes the fact that types of the power states in the Power Monitor >> Parents and Power Monitor Child can be different? > >What would be the requirement here? >Would we require that reports from parents are different to the ones from ch= ildren? >Or would we require that parents need to have aggregation functions? >Which functions would we require? Georgios: The parents will need to support aggregation functions in order to aggregate the power states maintained by their children. Moreover, the reports from parents could be different than the ones from children. This will however, depend on how the aggregation functions will be implemented. It is however needed to have requirements that accomodate both (1) the aggregation functions at the parents and (2) reports from parents needed to report the information associated with these aggregated power states. > >> *) there are situations where a device, e.g., a battery, sometimes >> supplies energy and other times the same device consumes energy. Is it >> possible to include a requirement that will ensure that the direction of >> energy to/from a device can also be monitored? > >Yes, this is a very good point. >We should add a requirement for the measurement of the direction of the ener= gy flow. Thanks, Best regards, Georgios > >Thanks and best regards, > > Juergen > > >> Best regards, >> Georgios From bnordman@lbl.gov Sat Apr 9 12:52:25 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEFD33A699C for ; Sat, 9 Apr 2011 12:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv5H1vg3fqv2 for ; Sat, 9 Apr 2011 12:52:24 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by core3.amsl.com (Postfix) with ESMTP id 528713A6972 for ; Sat, 9 Apr 2011 12:52:24 -0700 (PDT) X-Ironport-SBRS: 5.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQBAEO5oE3RVdy0mGdsb2JhbACCYIFrmkeHBQgUAQEBAQEICQ0HFCWIepw8iiyPXoMRB4FeeASFW4d9iTg6 X-IronPort-AV: E=Sophos;i="4.63,331,1299484800"; d="scan'208";a="38404975" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 09 Apr 2011 12:54:04 -0700 Received: by vxk12 with SMTP id 12so5418258vxk.39 for ; Sat, 09 Apr 2011 12:54:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.181.2 with SMTP id ds2mr1021832vdc.73.1302378843679; Sat, 09 Apr 2011 12:54:03 -0700 (PDT) Received: by 10.52.169.37 with HTTP; Sat, 9 Apr 2011 12:54:03 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Apr 2011 12:54:03 -0700 Message-ID: From: Bruce Nordman To: "John Parello (jparello)" Content-Type: multipart/alternative; boundary=bcaec548a88f572ab804a081b486 Cc: eman mailing list Subject: Re: [eman] Review ODVA preso from IETF80 meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2011 19:52:26 -0000 --bcaec548a88f572ab804a081b486 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John-- Thanks much for putting together the presentation. I am unfamiliar with Liaison processes within the IETF, but this seems well worth pursuing and you, Benoit, and I should pursue that. Below I have listed the WG items in your slides. I assume that in some cases we are already aligned with ODVA, but in other cases there are things to discuss and/or consider changes. I think we could use more clarity on what the open issues are so that we don't lose track of them. You might prefer that some of these should be deferred until some sort\ of liaison is set up. --Bruce "=EF=83=BCDefine power units in Watts with exponent." I am not sure if we need an exponent, but that seems possible. W definitely. I don't remember hearing anyone argue for a different power unit. "X Assumes all are electrical objects; =EF=83=BCContains same optional power quality values' X No modeling of non-electrical devices" Seems like Wh should be our base energy unit (not kWh). Any action items from this slide? "=EF=83=BCSame constructs for power reporting; =EF=83=BCSame recognition that states provide context and control." Any action items from this slide? It says that power is a floating point value. I would have thought our energy and power values would be integers. I agree that negative values should be allowed for some values to account for net generation or withdrawal from storage. "=EF=83=BCDemand object covers this as optional one value field. This appro= ach is clever for small devices" Are you proposing the 5-array odometer? or just noting it for reference. I had assumed a large integer counter for accumulated energy. "=EF=83=BCSame recognition for devices that are unable to report power or e= nergy" (simple devices) "=EF=83=BCRecognition of same problem with same solution for fixed devices" (nominal/fixed energy usage) Any action items here? or are we already covered? "=EF=83=BCCongruent solution to the caliber field which rates the reading. (This rates the devices capability of producing a reading versus the calibe= r of a reading) =EF=83=BCSame identification of Aggregator" "=EF=83=BCSame identification of accuracy for non fixed readings." Agree we need accuracy metric. Is what we have OK or is any adjustment called for? "=EF=83=BCSame identification of need for Aggregator and/or Proxy; =EF=83=BCExpressed as Parent/Child" Any action items here? "=EF=83=BCSame recognition of Parent/Child for Aggregation (Implemented as = a sort of URI)" Does this slide refer just to data aggregation, or is it assumed that there is also an electrical distribution topology that matches the data aggregation? On Wed, Apr 6, 2011 at 11:37 AM, John Parello (jparello) wrote: > Hi, > > During our EMAN session at IETF80 I presented the work that the ODVA is > doing on energy management. The time was very limited but I'd think it's > very useful to see what a group of primarily electrical engineers are > doing to address the same problem we are looking at. Given their > request for a formal liaison we should look more closely at their > information model and implementation. > > Unfortunately the draft spec is not available as yet but my presentation > does have a summary. I think it would be well worth everyone's time to > take a look at it. > > The presentation is here: > http://www.ietf.org/proceedings/80/slides/eman-1.pdf > > More information on the ODVA is here: > http://www.odva.org > > Summary of important items: > > - Division of information model into electrical and non-electrical > objects > - Electrical objects models with attributes: context, power, energy, > demand and relationship information > - Need for aggregation and parent child pattern with capabilities. > - Standardization on units > - Focus on devices that may not be able to implement the entire > information model. > > Would love to have a discussion on the points and merge to our > framework. > > Thanks > Jp > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec548a88f572ab804a081b486 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John--
=C2=A0 Thanks much for putting together the presentation.
=C2= =A0 I am unfamiliar with Liaison processes within the IETF, but this seems = well worth
pursuing and you, Benoit, and I should pursue that.
=C2=A0= Below I have listed the WG items in your slides.=C2=A0 I assume that in so= me cases we are
already aligned with ODVA, but in other cases there are things to discuss a= nd/or consider
changes.=C2=A0 I think we could use more clarity on what = the open issues are so that we don't
lose track of them.=C2=A0 You m= ight prefer that some of these should be deferred until some sort\
of liaison is set up.
--Bruce


"=EF=83=BCDefine power uni= ts in Watts with exponent."
=C2=A0 I am not sure if we need an expo= nent, but that seems possible.=C2=A0 W definitely.
I don't remember = hearing anyone argue for a different power unit.

"X Assumes all are electrical objects;
=EF=83=BCContains same o= ptional power quality values'
X No modeling of non-electrical device= s"
=C2=A0 Seems like Wh should be our base energy unit (not kWh).Any action items from this slide?

"=EF=83=BCSame constructs for power reporting;
=EF=83=BCSame re= cognition that states provide context and control."
=C2=A0 Any acti= on items from this slide?=C2=A0 It says that power is a floating point valu= e.
I would have thought our energy and power values would be integers. I agree that negative values should be allowed for some values to
accoun= t for net generation or withdrawal from storage.

"=EF=83=BCDema= nd object covers this as optional one value field. This approach is clever = for small devices"
=C2=A0 Are you proposing the 5-array odometer?=C2=A0 or just noting it for = reference.
I had assumed a large integer counter for accumulated energy.=

"=EF=83=BCSame recognition for devices that are unable to repo= rt power or energy" (simple devices)
"=EF=83=BCRecognition of same problem with same solution for fixed dev= ices" (nominal/fixed energy usage)
=C2=A0 Any action items here?=C2= =A0 or are we already covered?

"=EF=83=BCCongruent solution to = the caliber field which rates the reading.
(This rates the devices capability of producing a reading versus the calibe= r of a reading)
=EF=83=BCSame identification of Aggregator"
&quo= t;=EF=83=BCSame identification of accuracy for non fixed readings."=C2=A0 Agree we need accuracy metric.=C2=A0 Is what we have OK or is any a= djustment called for?

"=EF=83=BCSame identification of need for Aggregator and/or Proxy;=
=EF=83=BCExpressed as Parent/Child"
=C2=A0 Any action items her= e?

"=EF=83=BCSame recognition of Parent/Child for Aggregation (= Implemented as a sort of URI)"
=C2=A0 Does this slide refer just to data aggregation, or is it assumed tha= t there is also
an electrical distribution topology that matches the dat= a aggregation?








On Wed, Apr 6, 2011 at 11:37 AM, John Parello (jparello) <jparello@cisco.com> wrote:
Hi,

During our EMAN session at IETF80 I presented the work that the ODVA is
doing on energy management. The time was very limited but I'd think it&= #39;s
very useful to see what a group of primarily electrical engineers are
doing to address the same problem we are looking at. =C2=A0Given their
request for a formal liaison we should look more closely at their
information model and implementation.

Unfortunately the draft spec is not available as yet but my presentation does have a summary. I think it would be well worth everyone's time to<= br> take a look at it.

The presentation is here:
http://www.ietf.org/proceedings/80/slides/eman-1.pdf

More information on the ODVA is here:
http://www.odva.org
Summary of important items:

- Division of information model into electrical and non-electrical
objects
- Electrical objects models with attributes: context, power, energy,
demand and relationship information
- Need for aggregation and parent child pattern with capabilities.
- Standardization on units
- Focus on devices that may not be able to implement the entire
information model.

Would love to have a discussion on the points and merge to our
framework.

Thanks
Jp

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



--
Bru= ce Nordman
Lawrence Be= rkeley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--bcaec548a88f572ab804a081b486-- From Christian.Groves@nteczone.com Tue Apr 12 21:18:09 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C67EBE06AB for ; Tue, 12 Apr 2011 21:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WW9L00yTETk for ; Tue, 12 Apr 2011 21:18:09 -0700 (PDT) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfc.amsl.com (Postfix) with ESMTP id A502FE06A3 for ; Tue, 12 Apr 2011 21:18:08 -0700 (PDT) Received: from ppp118-209-170-73.lns20.mel6.internode.on.net ([118.209.170.73] helo=[192.168.0.2]) by cserver5.myshophosting.com with esmtp (Exim 4.69) (envelope-from ) id 1Q9rWh-0004Qa-Am; Wed, 13 Apr 2011 14:17:59 +1000 Message-ID: <4DA5245C.4090800@nteczone.com> Date: Wed, 13 Apr 2011 14:19:40 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brad Schoening References: <4D6E2CF8.6030103@cisco.com> <22B2909DCC2E62418BE369A1F1048899127B55D0@ex01.noveda.com> In-Reply-To: <22B2909DCC2E62418BE369A1F1048899127B55D0@ex01.noveda.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Source: X-Source-Args: X-Source-Dir: Cc: eman@ietf.org Subject: Re: [eman] Introduction; past comments 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, 13 Apr 2011 04:18:09 -0000 Hello Brad and Benoit, Sorry for the late reply other work took me away from following this WG and I've just caught up with the emails. I don't attend ITU-T SG5 (I attend ITU-T SG16) but it seems to me that given that this Study Group has questions (http://www.itu.int/net/ITU-T/lists/questions.aspx?Group=5&Period=14) looking at: Q 18/5 Methodology of environmental impact assessment of ICT Q 19/5 Power feeding systems Q 20/5 Data collection for energy efficiency for ICTs over the lifecycle that they may be interested in the output from the EMAN working group. Efficiency has to be measurable. I think the work in the this area is in its infancy in SG5. My email was just to let people know that there was work there. Regards, Christian On 3/03/2011 11:46 PM, Brad Schoening wrote: > > Hi Christian, > > The ITU-T Study Group 5 doesn’t seem to have any direct correspondence > to energy monitoring and control. According to itu.int: > > Study Group 5 have four main objectives. > > The first is to protect telecommunication equipment and installations > against damage and malfunction due to electromagnetic disturbances, > such as those from lightning. > > The second is to ensure safety of personnel and users of networks > against current and voltages used in telecommunication networks. > > The third is to avoid health risks from electromagnetic fields (EMF) > produced by telecommunication devices and installations. > > The fourth is to guarantee a good quality of service (QoS) for high > speed data services by providing requirements on characteristics of > copper cables and on the coexistence of services delivered by > different providers. > > > Perhaps you could provide a little more background on how you feel the > ITU-T work would fit in here with the IETF’s EMAN work. > > Thanks, > > Brad Schoening > > > -------- Original Message -------- > > *Subject: * > > > > Re: [eman] Introduction; past comments > > *Date: * > > > > Wed, 03 Nov 2010 13:33:15 +1100 > > *From: * > > > > Christian Groves > > > *To: * > > > > eman@ietf.org > > Hello Bruce, > > Thanks for the introduction. > > Your comment on other SDOs and the charter actually made me have a good > read of the EMAN charter. It mentions a list of SDOs whose work may be > applicable: IEC, ANSI, DTMF etc. However it doesn't mention ITU-T Study > Group 5"electromagnetic compatibility and electromagnetic effects" > . > This group was formed from two study groups, one looking at > electro-magnetic issues and one looking at indoor and outdoor plant. My > understanding is that operators are well represented in this group. It > may be beneficial for both SG5 and the EMAN WG to exchange information. > > Regards, Christian > > From russ@cisco.com Wed Apr 13 08:15:01 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C06C8E0705 for ; Wed, 13 Apr 2011 08:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jONtjNbLGtAj for ; Wed, 13 Apr 2011 08:15:00 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 1B59FE06A4 for ; Wed, 13 Apr 2011 08:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1535; q=dns/txt; s=iport; t=1302707700; x=1303917300; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=xs6pWH0NiieChgpJubmjnDPSaEvYRc4Wubsn7Z++BCg=; b=N32JsvPiYSFsoW+6uHR7BUEMF6Q8/GAt5Ih/TN+mNU7FgkyCeCpcbBxT KoZ3dpEPljNluv/8aYpgkxENQgjJuRhb6oMQ8xQRsKb/tAqSOdA2F01ey +m/5foQIc6G8qM/MOUMAQNCxwYQiClsJ6BuH8/1P/raeYn7A6Imj9wIwM g=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.64,204,1301875200"; d="asc'?scan'208";a="336300768" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2011 15:14:52 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3DFEpIL011139; Wed, 13 Apr 2011 15:14:51 GMT Message-ID: <4DA5BDDE.9060607@cisco.com> Date: Wed, 13 Apr 2011 11:14:38 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: john parello , "eman@ietf.org" References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> <4D9F26A0.20407@cisco.com> <20110408154839.GA81729@elstar.local> In-Reply-To: <20110408154839.GA81729@elstar.local> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA5A83541B96D2AD7D6B6B062" Subject: Re: [eman] Do we need power state transition count and time in 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: Wed, 13 Apr 2011 15:15:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA5A83541B96D2AD7D6B6B062 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I assume people find it important to know the percentage of time a > device spends in a certain power state. Approximating this by active > polling of the current state is pretty inefficient and inaccurate > since you can miss state changes. If the device records the time spent > in each state, you get a precise breakdown of the time spend in each > power state between each poll, which means you can safely poll at a > much lower frequency. It seems like this should be put into an extension, rather than in the base spec... Or as a device specific option (given we build the branches of information we had discussed on list before). :-) Russ --=20 riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone The bigger the government becomes, the smaller the individual becomes. --------------enigA5A83541B96D2AD7D6B6B062 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2lveEACgkQER27sUhU9ORMHACeOXLTv88CPLDb6dO/INi5uOxS QlIAniaA+CcnoySwAWkSQKFgLoaGMDUP =Zi+g -----END PGP SIGNATURE----- --------------enigA5A83541B96D2AD7D6B6B062-- From j.schoenwaelder@jacobs-university.de Wed Apr 13 08:17:34 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B0ADE078E for ; Wed, 13 Apr 2011 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2QobPvvD9xl for ; Wed, 13 Apr 2011 08:17:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfc.amsl.com (Postfix) with ESMTP id 603ECE0705 for ; Wed, 13 Apr 2011 08:17:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2B0BC0035; Wed, 13 Apr 2011 17:17:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id M0TANZrFirFT; Wed, 13 Apr 2011 17:17:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39D73C0015; Wed, 13 Apr 2011 17:17:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB0FC17660EB; Wed, 13 Apr 2011 17:17:28 +0200 (CEST) Date: Wed, 13 Apr 2011 17:17:28 +0200 From: Juergen Schoenwaelder To: Russ White Message-ID: <20110413151728.GA32536@elstar.local> Mail-Followup-To: Russ White , john parello , "eman@ietf.org" References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> <4D9F26A0.20407@cisco.com> <20110408154839.GA81729@elstar.local> <4DA5BDDE.9060607@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA5BDDE.9060607@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] Do we need power state transition count and time in state? 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: Wed, 13 Apr 2011 15:17:34 -0000 On Wed, Apr 13, 2011 at 11:14:38AM -0400, Russ White wrote: > > > I assume people find it important to know the percentage of time a > > device spends in a certain power state. Approximating this by active > > polling of the current state is pretty inefficient and inaccurate > > since you can miss state changes. If the device records the time spent > > in each state, you get a precise breakdown of the time spend in each > > power state between each poll, which means you can safely poll at a > > much lower frequency. > > It seems like this should be put into an extension, rather than in the > base spec... Or as a device specific option (given we build the branches > of information we had discussed on list before). And the reason is? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From russ@cisco.com Wed Apr 13 08:19:45 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 40EE2E07C4 for ; Wed, 13 Apr 2011 08:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x26gNn19Qtnl for ; Wed, 13 Apr 2011 08:19:44 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfc.amsl.com (Postfix) with ESMTP id 218D7E07C3 for ; Wed, 13 Apr 2011 08:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1992; q=dns/txt; s=iport; t=1302707984; x=1303917584; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=GqqmEcbsfZQPpi4citYBB+x6dn36OvWL14TYDy7dz8I=; b=DCH9PgI20GJOW8EpzbQGTpU0nZIqEG9q5LyOFmFewiTate/2I/fA5t1i O8JYLPbwQKquQKCRpBxRchrqkjUsIiT4fT+oSx4s+eP4cJHPbRvMe+bRB z76evIm9B7r6DatGurvm0wYnlcRPnmNfol5aOT1LcFgoXziDw9UspZoNm U=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.64,204,1301875200"; d="asc'?scan'208";a="230104336" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2011 15:19:43 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p3DFJgc7007615; Wed, 13 Apr 2011 15:19:43 GMT Message-ID: <4DA5BF04.8030204@cisco.com> Date: Wed, 13 Apr 2011 11:19:32 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: john parello , "eman@ietf.org" References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> <4D9F26A0.20407@cisco.com> <20110408154839.GA81729@elstar.local> <4DA5BDDE.9060607@cisco.com> <20110413151728.GA32536@elstar.local> In-Reply-To: <20110413151728.GA32536@elstar.local> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig197DE756B970D9603A5052EE" Subject: Re: [eman] Do we need power state transition count and time in 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: Wed, 13 Apr 2011 15:19:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig197DE756B970D9603A5052EE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> I assume people find it important to know the percentage of time a >>> device spends in a certain power state. Approximating this by active >>> polling of the current state is pretty inefficient and inaccurate >>> since you can miss state changes. If the device records the time spen= t >>> in each state, you get a precise breakdown of the time spend in each >>> power state between each poll, which means you can safely poll at a >>> much lower frequency. >> >> It seems like this should be put into an extension, rather than in the= >> base spec... Or as a device specific option (given we build the branch= es >> of information we had discussed on list before). >=20 > And the reason is? Because this doesn't seem to be useful for all devices... And because we should try and keep the MIB size down, with extensions, rather than trying to bundle everything possible into the base MIB. :-) Russ --=20 riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone Belief is a wise wager. Granted that faith cannot be proved, what harm will come to you if you gamble on its truth and it proves false? If you gain, you gain all; if you lose, you lose nothing. Wager, then, without hesitation, that He exists. Blaise Pascal --------------enig197DE756B970D9603A5052EE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2lvwUACgkQER27sUhU9OQjJQCeIUnWEUZpvOSi7gdQlWi9E1RF lyUAn0dhhM/ibPJfaZjl+q6CFEazjXbf =K9fO -----END PGP SIGNATURE----- --------------enig197DE756B970D9603A5052EE-- From ietf@quittek.at Wed Apr 13 08:52:30 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C0870E077C for ; Wed, 13 Apr 2011 08:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtiIZ1-XoBU8 for ; Wed, 13 Apr 2011 08:52:30 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfc.amsl.com (Postfix) with ESMTP id 0244DE079C for ; Wed, 13 Apr 2011 08:52:30 -0700 (PDT) Received: from [195.37.70.175] ([195.37.70.175]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LehKM-1PY0NH0V14-00qcbY; Wed, 13 Apr 2011 17:52:29 +0200 References: <4D9DE17D.5090606@cisco.com> <4D9F12FE.3080409@cisco.com> <20110408142048.GA81222@elstar.local> <4D9F1A5F.1030107@cisco.com> <20110408143107.GA81369@elstar.local> <4D9F26A0.20407@cisco.com> <20110408154839.GA81729@elstar.local> <4DA5BDDE.9060607@cisco.com> <20110413151728.GA32536@elstar.local> <4DA5BF04.8030204@cisco.com> In-Reply-To: <4DA5BF04.8030204@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Wed, 13 Apr 2011 17:52:28 +0200 To: Russ White X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:vBwv1K2B2xmT/k007FW94P5R5DbiK8qIjUC73owXtZ0 V1P6DlU1NEaqgY4B7vd6haaNBqS0caxLkDIbZ5K7B7PsXu3QhX zceSKor86Rk8F8PPVS8Eke1beeF9Zl/Cx/r4Z+Xv9MVKNPUWCT z9JUrh3HaEz6Sf8RnV7luQDBlWHZ9rwR/JVBPbkE7nxYmlLyZT uM5y3ULHXg3EwDa8hxxyQ== Cc: "eman@ietf.org" Subject: Re: [eman] Do we need power state transition count and time in 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: Wed, 13 Apr 2011 15:52:30 -0000 Am 13.04.2011 um 17:19 schrieb Russ White: > >>>> I assume people find it important to know the percentage of time a >>>> device spends in a certain power state. Approximating this by active >>>> polling of the current state is pretty inefficient and inaccurate >>>> since you can miss state changes. If the device records the time spent >>>> in each state, you get a precise breakdown of the time spend in each >>>> power state between each poll, which means you can safely poll at a >>>> much lower frequency. >>> >>> It seems like this should be put into an extension, rather than in the >>> base spec... Or as a device specific option (given we build the branches >>> of information we had discussed on list before). >> >> And the reason is? > > Because this doesn't seem to be useful for all devices... And because we > should try and keep the MIB size down, with extensions, rather than > trying to bundle everything possible into the base MIB. What about having it in the same MIB, but making it optional to implement? Juergen > :-) > > Russ > > > > -- > riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone > > Belief is a wise wager. Granted that faith cannot be proved, what harm > will come to you if you gamble on its truth and it proves false? If you > gain, you gain all; if you lose, you lose nothing. Wager, then, without > hesitation, that He exists. Blaise Pascal > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Fri Apr 15 10:05:54 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC7AC130080 for ; Fri, 15 Apr 2011 10:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOZCoFkLPka5 for ; Fri, 15 Apr 2011 10:05:54 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfc.amsl.com (Postfix) with ESMTP id 033E9130051 for ; Fri, 15 Apr 2011 10:05:53 -0700 (PDT) Received: from [192.168.1.132] (HSI-KBW-091-089-140-037.hsi2.kabel-badenwuerttemberg.de [91.89.140.37]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LzDgT-1Pp4fh3bhB-014Vwt; Fri, 15 Apr 2011 19:05:53 +0200 From: Juergen Quittek Content-Type: text/plain; charset=us-ascii Message-Id: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> Date: Fri, 15 Apr 2011 19:05:52 +0200 To: "eman@ietf.org list" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:/M6nI74hYZ/I/K4qUYblHi5VGdoR++uo6pLp24Dr34u eOuQHya42qKJvgkX7qLNt62i4mnTro+2i2ABPq5KrRlhrjdOE/ FURK2scWigVC+aMMJEHmf/O1bpipCJxmalkKkCh196eh0D4qtz NYKwNEzZfPMgmRJAtjOuka9VBEdXEJBi4gjQyvtQgbNg6ABPyk +WJPtO/Drf0MgLBnK7HKw== Subject: [eman] power inlets 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, 15 Apr 2011 17:05:54 -0000 Dear all, We are currently revising the eman requirements and discussing how to = cover devices with multiple power supplies.=20 A typical case is a server with dual main power supply. Often such = servers have their two power inlets connected to different power = distribution trees in order to be able to continue operation even when = power fails in one power distribution tree. Typically, servers do not = just have two inlets, but two full built-in power supply units. If one = breaks, the other can take over. I have thought about how to cover such servers in the requrements. My = current solution starts with the point that a powered device may have = more than one power inlet. Then the eman standard to be developed must = provide means (managed objects in MIB modules) for monitoring each power = inlet individually. This concerns monitoring of instantaneous power, = consumed energy, power quality, and maybe even just availability of = power at an inlet. Does anyone think this is a reasonable way to go? The inlet concept = somehow blurs the role of built-in power supply units. Do we have better alternatives? Thanks, Juergen= From jparello@cisco.com Fri Apr 15 11:10:22 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFEDAE090F for ; Fri, 15 Apr 2011 11:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmLarxzTG3cv for ; Fri, 15 Apr 2011 11:10:18 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 3D143E0768 for ; Fri, 15 Apr 2011 11:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=2037; q=dns/txt; s=iport; t=1302891018; x=1304100618; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=FtvxKbTAcMespHGcAdyBMgORgBpkguI3oPJ0dHhhWvI=; b=Kp5vMXzLgv4Rr7k0vzaLIkjR2j4K2jw3VWYiMRIozK2jPuRclvFLjK4e +MJ1arRTWKry1KSfbkAYDxZ0X/gJ9sacpPcR9tfze4llnsWiU/GK4Bo9s ceYmKFxFS8x20NOUk1LohI+ZLoFHcQY5/2USarR5K7/WXCVbyq+UXT236 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBANWJqE2rRDoG/2dsb2JhbACYCo1/d6gdnQKFbgSFYIwT X-IronPort-AV: E=Sophos;i="4.64,220,1301875200"; d="scan'208";a="338548696" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 18:10:05 +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 p3FIA5Xl015968; Fri, 15 Apr 2011 18:10:05 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, 15 Apr 2011 11:10:05 -0700 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, 15 Apr 2011 11:10:29 -0700 Message-ID: In-Reply-To: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] power inlets Thread-Index: Acv7j2f95VRYTeJsSPK81RAaonWC2gACEL6A References: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" , X-OriginalArrivalTime: 15 Apr 2011 18:10:05.0796 (UTC) FILETIME=[590F3240:01CBFB98] Subject: Re: [eman] power inlets 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, 15 Apr 2011 18:10:22 -0000 HI Jeurgen, This same pattern comes into play for PoE devices as well. You may have a PoE device that requires say 30 W of power and connects to two 15 W interfaces in order to power it. In our implementations of energy monitoring we simple maintain a relationship vector called "poweredby" that contains the ids of the devices. We also have a similar vector field called "meteredby"=20 Then if each managed object has power, energy and demand tracking the accounting can be taken care of in the management stations. Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Friday, April 15, 2011 10:06 AM To: eman@ietf.org list Subject: [eman] power inlets Dear all, We are currently revising the eman requirements and discussing how to cover devices with multiple power supplies.=20 A typical case is a server with dual main power supply. Often such servers have their two power inlets connected to different power distribution trees in order to be able to continue operation even when power fails in one power distribution tree. Typically, servers do not just have two inlets, but two full built-in power supply units. If one breaks, the other can take over. I have thought about how to cover such servers in the requrements. My current solution starts with the point that a powered device may have more than one power inlet. Then the eman standard to be developed must provide means (managed objects in MIB modules) for monitoring each power inlet individually. This concerns monitoring of instantaneous power, consumed energy, power quality, and maybe even just availability of power at an inlet. Does anyone think this is a reasonable way to go? The inlet concept somehow blurs the role of built-in power supply units. Do we have better alternatives? Thanks, Juergen _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Fri Apr 15 12:12:39 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92BA0E0910 for ; Fri, 15 Apr 2011 12:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6AJZGX7lf9t for ; Fri, 15 Apr 2011 12:12:39 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfc.amsl.com (Postfix) with ESMTP id BE86BE0749 for ; Fri, 15 Apr 2011 12:12:38 -0700 (PDT) Received: from [10.170.96.34] (tmo-096-165.customers.d1-online.com [80.187.96.165]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M6xID-1PyuKf0bwr-00x9OG; Fri, 15 Apr 2011 21:12:36 +0200 References: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Juergen Quittek Date: Fri, 15 Apr 2011 21:12:03 +0200 To: "John Parello (jparello)" X-Provags-ID: V02:K0:hy9TTFYvlOafIydfCycbqkX7Qcw4h2yPEM4lJdydmX4 DCox/AteE3Fu/fwi81ymThLQeDkhbEOev/kSTWXmAqPnQq8DJE SPJn4m+wliTyxfeJxJxmRBc6HN44fMMPV6xWuJxErD838SOZd3 09WDsDcImPh2DaVaVFR3vfUHTxdoq40hcv6ZKkpxYSl+ZwbxER zhV8CqzRsIfT3ZdujHgtg== Cc: "" Subject: Re: [eman] power inlets 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, 15 Apr 2011 19:12:39 -0000 Am 15.04.2011 um 20:10 schrieb "John Parello (jparello)" : > HI Jeurgen, >=20 > This same pattern comes into play for PoE devices as well. You may have > a PoE device that requires say 30 W of power and connects to two 15 W > interfaces in order to power it. >=20 > In our implementations of energy monitoring we simple maintain a > relationship vector called "poweredby" that contains the ids of the > devices. We also have a similar vector field called "meteredby"=20 >=20 > Then if each managed object has power, energy and demand tracking the > accounting can be taken care of in the management stations. >=20 > Jp >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Friday, April 15, 2011 10:06 AM > To: eman@ietf.org list > Subject: [eman] power inlets >=20 > Dear all, >=20 > We are currently revising the eman requirements and discussing how to > cover devices with multiple power supplies.=20 >=20 > A typical case is a server with dual main power supply. Often such > servers have their two power inlets connected to different power > distribution trees in order to be able to continue operation even when > power fails in one power distribution tree. Typically, servers do not > just have two inlets, but two full built-in power supply units. If one > breaks, the other can take over. >=20 > I have thought about how to cover such servers in the requrements. My > current solution starts with the point that a powered device may have > more than one power inlet. Then the eman standard to be developed must > provide means (managed objects in MIB modules) for monitoring each power > inlet individually. This concerns monitoring of instantaneous power, > consumed energy, power quality, and maybe even just availability of > power at an inlet. >=20 > Does anyone think this is a reasonable way to go? The inlet concept > somehow blurs the role of built-in power supply units. >=20 > Do we have better alternatives? >=20 > Thanks, >=20 > Juergen > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Fri Apr 15 12:21:40 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF5F0E083C for ; Fri, 15 Apr 2011 12:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfUrpdBBKdcH for ; Fri, 15 Apr 2011 12:21:36 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfc.amsl.com (Postfix) with ESMTP id 10800E07DA for ; Fri, 15 Apr 2011 12:21:36 -0700 (PDT) Received: from [10.170.96.34] (tmo-096-165.customers.d1-online.com [80.187.96.165]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lv8fS-1PkvhB3ZpK-00zd7x; Fri, 15 Apr 2011 21:21:33 +0200 References: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (8C148) From: Juergen Quittek Date: Fri, 15 Apr 2011 21:20:59 +0200 To: "John Parello (jparello)" X-Provags-ID: V02:K0:4TLeIRq2e7FVVBzo6VMYHK3R40HadLv4UElftXlJHCh JD962E+nUZUDFTW8sbbb6JN3a1wzZKDFn6fG024yMA2uOW/ilB G5WV1MWQU3osRbi/DiV0Jc5x/InECeqk2NW2NjcsdS43Zxi8X0 SqIFJecInarPT/TtagSQnJNok+GEY6S+zQqvr7PRb3pYPhrHwF dD64ZVNFD8byoWC513ppg== Cc: "" Subject: Re: [eman] power inlets 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, 15 Apr 2011 19:21:40 -0000 Hi Paul,=20 I am sorry for spamming with the empty email that I just sent. Touchscreens a= re dangerous ... Please see a question inline. On 15.04.2011, 20:10 "John Parello (jparello)" wrote: > HI Jeurgen, >=20 > This same pattern comes into play for PoE devices as well. You may have > a PoE device that requires say 30 W of power and connects to two 15 W > interfaces in order to power it. >=20 > In our implementations of energy monitoring we simple maintain a > relationship vector called "poweredby" that contains the ids of the > devices. We also have a similar vector field called "meteredby"=20 >=20 > Then if each managed object has power, energy and demand tracking the > accounting can be taken care of in the management stations. Just for my understanding: i have an idea what power and energy are. But wha= t so you refer to with "demand"? Tanks, Juergen > Jp >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Friday, April 15, 2011 10:06 AM > To: eman@ietf.org list > Subject: [eman] power inlets >=20 > Dear all, >=20 > We are currently revising the eman requirements and discussing how to > cover devices with multiple power supplies.=20 >=20 > A typical case is a server with dual main power supply. Often such > servers have their two power inlets connected to different power > distribution trees in order to be able to continue operation even when > power fails in one power distribution tree. Typically, servers do not > just have two inlets, but two full built-in power supply units. If one > breaks, the other can take over. >=20 > I have thought about how to cover such servers in the requrements. My > current solution starts with the point that a powered device may have > more than one power inlet. Then the eman standard to be developed must > provide means (managed objects in MIB modules) for monitoring each power > inlet individually. This concerns monitoring of instantaneous power, > consumed energy, power quality, and maybe even just availability of > power at an inlet. >=20 > Does anyone think this is a reasonable way to go? The inlet concept > somehow blurs the role of built-in power supply units. >=20 > Do we have better alternatives? >=20 > Thanks, >=20 > Juergen > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Fri Apr 15 13:26:21 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7791DE067F for ; Fri, 15 Apr 2011 13:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYFlU7sOQ8hS for ; Fri, 15 Apr 2011 13:26:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 61168E0674 for ; Fri, 15 Apr 2011 13:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=3979; q=dns/txt; s=iport; t=1302899177; x=1304108777; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=N2VUtbUjs3i/MmJLHJcgQa4L5p1LumpMXy/14JLKNnE=; b=dqGHfISiWwEZjQzBfizWofi+Jj3Lj1+dxOVikeq0+yf1ovvEWJaNxxmN ko78veyEAGuHE63ZNvs6LOBZdrgmYnsZQ0rq/LlQN1D3NfPnDz7L9cI8D WMQVK8g1J2J9xEgcbvstdFAjo/X/GqpRXK9m9kryjuAkG07za71Xjesgb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBADipqE2rRDoG/2dsb2JhbACYCo1/d4hvnmudCIVuBIVgjBM X-IronPort-AV: E=Sophos;i="4.64,221,1301875200"; d="scan'208";a="338657580" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 20:26:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3FKQFXr006829; Fri, 15 Apr 2011 20:26:16 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, 15 Apr 2011 13:25:05 -0700 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, 15 Apr 2011 13:25:27 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] power inlets Thread-Index: Acv7olkqx6eiBk4TRmaJqtrCTHksYQABklLg References: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" X-OriginalArrivalTime: 15 Apr 2011 20:25:05.0273 (UTC) FILETIME=[34B94E90:01CBFBAB] Cc: eman@ietf.org Subject: Re: [eman] power inlets 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, 15 Apr 2011 20:26:21 -0000 Hi Juergen, Demand is and average rate of energy consumed per interval of time.=20 This is the measurement utilities (most US,EU not China etc) use to charge. They typically charge for the highest demand interval over a period. This recognized that devices may spike in power at moments but the charges are for the peak demand This is also the term used in systems that negotiation systems (Demand Response systems) with providers. They are negotiating the demand they require for a period (Ex: OpenADR) There's a description and graph for clarity so that people understand the terms (which get over loaded in the vernacular) in the EMAN preso here: http://tools.ietf.org/agenda/80/slides/eman-1.pdf For others that may want a simple clarification of power, energy and demand simply put here: Power is like a reading off a speedometer Energy is like a reading off an odometer Demand would be like a "trip" odometer reading divided by time and collected at set intervals.=20 In our monitoring MIB draft we placed energy and demand in the same object and made it optional but in this problem space they are best separated since they are distinct and used for different mgt purposes. HTH Jp -----Original Message----- From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Friday, April 15, 2011 12:21 PM To: John Parello (jparello) Cc: Subject: Re: [eman] power inlets Hi Paul,=20 I am sorry for spamming with the empty email that I just sent. Touchscreens are dangerous ... Please see a question inline. On 15.04.2011, 20:10 "John Parello (jparello)" wrote: > HI Jeurgen, >=20 > This same pattern comes into play for PoE devices as well. You may have > a PoE device that requires say 30 W of power and connects to two 15 W > interfaces in order to power it. >=20 > In our implementations of energy monitoring we simple maintain a > relationship vector called "poweredby" that contains the ids of the > devices. We also have a similar vector field called "meteredby"=20 >=20 > Then if each managed object has power, energy and demand tracking the > accounting can be taken care of in the management stations. Just for my understanding: i have an idea what power and energy are. But what so you refer to with "demand"? Tanks, Juergen > Jp >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Friday, April 15, 2011 10:06 AM > To: eman@ietf.org list > Subject: [eman] power inlets >=20 > Dear all, >=20 > We are currently revising the eman requirements and discussing how to > cover devices with multiple power supplies.=20 >=20 > A typical case is a server with dual main power supply. Often such > servers have their two power inlets connected to different power > distribution trees in order to be able to continue operation even when > power fails in one power distribution tree. Typically, servers do not > just have two inlets, but two full built-in power supply units. If one > breaks, the other can take over. >=20 > I have thought about how to cover such servers in the requrements. My > current solution starts with the point that a powered device may have > more than one power inlet. Then the eman standard to be developed must > provide means (managed objects in MIB modules) for monitoring each power > inlet individually. This concerns monitoring of instantaneous power, > consumed energy, power quality, and maybe even just availability of > power at an inlet. >=20 > Does anyone think this is a reasonable way to go? The inlet concept > somehow blurs the role of built-in power supply units. >=20 > Do we have better alternatives? >=20 > Thanks, >=20 > Juergen > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bschoening@noveda.com Fri Apr 15 14:02:39 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0A15CE0691 for ; Fri, 15 Apr 2011 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA51PXkZcp3E for ; Fri, 15 Apr 2011 14:02:36 -0700 (PDT) Received: from cal3-mh484-a.smtproutes.com (cal3-mh484-a.smtproutes.com [208.70.89.247]) by ietfc.amsl.com (Postfix) with ESMTP id 843ABE0674 for ; Fri, 15 Apr 2011 14:02:36 -0700 (PDT) X-Katharion-ID: 1302901334.87399.cal3-mh484 Received: from ex01.noveda.com ([66.198.105.170]) by cal3-mh484.smtproutes.com [(208.70.89.158)] with ESMTP via TCP; 15 Apr 2011 14:02:14 -0700 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Fri, 15 Apr 2011 17:02:15 -0400 From: Brad Schoening To: Juergen Quittek , "eman@ietf.org list" Thread-Topic: [eman] power inlets Thread-Index: AQHL+49xuyYKkUM/O0WRYPuExIwTuJRfZ+Tg Date: Fri, 15 Apr 2011 21:02:16 +0000 Message-ID: <22B2909DCC2E62418BE369A1F10488992500C0DC@ex01.noveda.com> References: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> In-Reply-To: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] power inlets 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, 15 Apr 2011 21:02:39 -0000 Hi Juergen, I would definitely take a look at the UPS-MIB which models this with input = groups. UpsInputEntry ::=3D SEQUENCE { upsInputLineIndex PositiveInteger, upsInputFrequency NonNegativeInteger, upsInputVoltage NonNegativeInteger, upsInputCurrent NonNegativeInteger, upsInputTruePower NonNegativeInteger } upsOutputSource OBJECT-TYPE SYNTAX INTEGER { other(1), none(2), normal(3), bypass(4), battery(5), booster(6), reducer(7) } -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Jue= rgen Quittek Sent: Friday, April 15, 2011 1:06 PM To: eman@ietf.org list Subject: [eman] power inlets Dear all, We are currently revising the eman requirements and discussing how to cover= devices with multiple power supplies.=20 A typical case is a server with dual main power supply. Often such servers = have their two power inlets connected to different power distribution trees= in order to be able to continue operation even when power fails in one pow= er distribution tree. Typically, servers do not just have two inlets, but t= wo full built-in power supply units. If one breaks, the other can take over= . I have thought about how to cover such servers in the requrements. My curre= nt solution starts with the point that a powered device may have more than = one power inlet. Then the eman standard to be developed must provide means = (managed objects in MIB modules) for monitoring each power inlet individual= ly. This concerns monitoring of instantaneous power, consumed energy, power= quality, and maybe even just availability of power at an inlet. Does anyone think this is a reasonable way to go? The inlet concept somehow= blurs the role of built-in power supply units. Do we have better alternatives? Thanks, Juergen _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Fri Apr 15 14:39:08 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 921C8E06AD for ; Fri, 15 Apr 2011 14:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZAUTESls56V for ; Fri, 15 Apr 2011 14:39:07 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfc.amsl.com (Postfix) with ESMTP id AC618E06A9 for ; Fri, 15 Apr 2011 14:39:07 -0700 (PDT) Received: from [10.170.96.34] (tmo-096-165.customers.d1-online.com [80.187.96.165]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0M3ZGX-1PtSP11Usz-00rIPg; Fri, 15 Apr 2011 23:39:03 +0200 References: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> <22B2909DCC2E62418BE369A1F10488992500C0DC@ex01.noveda.com> In-Reply-To: <22B2909DCC2E62418BE369A1F10488992500C0DC@ex01.noveda.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <67FDA23C-9EDC-45F7-8051-9858F69397A6@quittek.at> X-Mailer: iPhone Mail (8C148) From: Juergen Quittek Date: Fri, 15 Apr 2011 23:38:30 +0200 To: Brad Schoening X-Provags-ID: V02:K0:3LPyOC/xogTx7mP/RcAtqYqA7s+xV1dmKxb2vqigeRA +XBBhzB5jJOUgyOWQsaGalnPJ1ot6WikXesVb6D1XSGjBhJq/g tWScKi/WVPKFxbZnrSErz/0hLJD1/v4xRFJSFg1cDyV7ML+HkU neiQuvcFj1hxEUxwsXSIM8lDkOeyEoP7ulI/o1aOxlHLq47M2f NdzHbiDuZsIgOiXI50dBA== Cc: "eman@ietf.org list" Subject: Re: [eman] power inlets 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, 15 Apr 2011 21:39:08 -0000 Hi Brad, Thanks for the hint. I had looked at the UPS MIB. The problen is that the sn= ippet you cited is almost all that is in there. For each listed object there= is just half a line of description :-( J=C3=BCrgen Am 15.04.2011 um 23:02 schrieb Brad Schoening : > Hi Juergen, >=20 > I would definitely take a look at the UPS-MIB which models this with input= groups. >=20 > UpsInputEntry ::=3D SEQUENCE { > upsInputLineIndex PositiveInteger, > upsInputFrequency NonNegativeInteger, > upsInputVoltage NonNegativeInteger, > upsInputCurrent NonNegativeInteger, > upsInputTruePower NonNegativeInteger > } >=20 > upsOutputSource OBJECT-TYPE > SYNTAX INTEGER { > other(1), > none(2), > normal(3), > bypass(4), > battery(5), > booster(6), > reducer(7) > } >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Ju= ergen Quittek > Sent: Friday, April 15, 2011 1:06 PM > To: eman@ietf.org list > Subject: [eman] power inlets >=20 > Dear all, >=20 > We are currently revising the eman requirements and discussing how to cove= r devices with multiple power supplies.=20 >=20 > A typical case is a server with dual main power supply. Often such servers= have their two power inlets connected to different power distribution trees= in order to be able to continue operation even when power fails in one powe= r distribution tree. Typically, servers do not just have two inlets, but two= full built-in power supply units. If one breaks, the other can take over. >=20 > I have thought about how to cover such servers in the requrements. My curr= ent solution starts with the point that a powered device may have more than o= ne power inlet. Then the eman standard to be developed must provide means (m= anaged objects in MIB modules) for monitoring each power inlet individually.= This concerns monitoring of instantaneous power, consumed energy, power qua= lity, and maybe even just availability of power at an inlet. >=20 > Does anyone think this is a reasonable way to go? The inlet concept someho= w blurs the role of built-in power supply units. >=20 > Do we have better alternatives? >=20 > Thanks, >=20 > Juergen > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 >=20 From bnordman@lbl.gov Fri Apr 15 16:03:50 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38A56E06AD for ; Fri, 15 Apr 2011 16:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xsSxgywvpkY for ; Fri, 15 Apr 2011 16:03:49 -0700 (PDT) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfc.amsl.com (Postfix) with ESMTP id A7E27E06BA for ; Fri, 15 Apr 2011 16:03:48 -0700 (PDT) X-Ironport-SBRS: 4.4 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4CACnOqE3RVdQ0kGdsb2JhbACCYpt0AYY+cAgUAQEBAQkJDQcUBCGIb599m3CDGIJWBIVhiBmJWjo X-IronPort-AV: E=Sophos;i="4.64,222,1301900400"; d="scan'208";a="39492686" Received: from mail-vw0-f52.google.com ([209.85.212.52]) by ironport3.lbl.gov with ESMTP; 15 Apr 2011 16:03:46 -0700 Received: by mail-vw0-f52.google.com with SMTP id 16so4121209vws.39 for ; Fri, 15 Apr 2011 16:03:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.173.37 with SMTP id bh5mr3658759vdc.56.1302908626559; Fri, 15 Apr 2011 16:03:46 -0700 (PDT) Received: by 10.52.165.201 with HTTP; Fri, 15 Apr 2011 16:03:46 -0700 (PDT) In-Reply-To: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> References: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> Date: Fri, 15 Apr 2011 16:03:46 -0700 Message-ID: From: Bruce Nordman To: Juergen Quittek Content-Type: multipart/alternative; boundary=bcaec5196d0bdc618f04a0fd0d47 Cc: "eman@ietf.org list" Subject: Re: [eman] power inlets 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, 15 Apr 2011 23:03:50 -0000 --bcaec5196d0bdc618f04a0fd0d47 Content-Type: text/plain; charset=ISO-8859-1 I can see two cases - when both power supplies are in the same electricity domain, and when they are not. If we only had the second case, then the two reports on the device would have the same UUID, but different domains, so a NMS would know they are different power supplies. However, since they could be in the same domain, then some labeling of the supplies is needed. I haven't looked at the MIB to see if there is an obvious existing variable to do this with, but otherwise just a numeric counter (usually just always "1") could do this. This would be used in both cases (same domain and different domain). This variable not being present would also imply just one supply. For reporting, if reported by a device other than the server (or whatever the end device is), then it would just report two separate entries with the same UUID - or more likely, each value would be reported by a different entity. If the server was reporting on itself, then it would need to specify that it was reporting on a collection of devices (like an aggregator) rather than an individual device, so we could reuse that same mechanism, not need to create a new one. The meter and power source data would be different for each supply. Each would report on power state, though the values reported should be identical. So, from the perspective of the MIB, there are two separate devices, though an NMS could observe they are the same device (having the same UUID) if it wanted to. So, I think the dual supply case can be accommodated without much difficulty in our current model. --Bruce On Fri, Apr 15, 2011 at 10:05 AM, Juergen Quittek wrote: > Dear all, > > We are currently revising the eman requirements and discussing how to cover > devices with multiple power supplies. > > A typical case is a server with dual main power supply. Often such servers > have their two power inlets connected to different power distribution trees > in order to be able to continue operation even when power fails in one power > distribution tree. Typically, servers do not just have two inlets, but two > full built-in power supply units. If one breaks, the other can take over. > > I have thought about how to cover such servers in the requrements. My > current solution starts with the point that a powered device may have more > than one power inlet. Then the eman standard to be developed must provide > means (managed objects in MIB modules) for monitoring each power inlet > individually. This concerns monitoring of instantaneous power, consumed > energy, power quality, and maybe even just availability of power at an > inlet. > > Does anyone think this is a reasonable way to go? The inlet concept somehow > blurs the role of built-in power supply units. > > Do we have better alternatives? > > Thanks, > > Juergen > _______________________________________________ > 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 --bcaec5196d0bdc618f04a0fd0d47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can see two cases - when both power supplies are in the same electricity<= br>domain, and when they are not.=A0 If we only had the second case, then t= he
two reports on the device would have the same UUID, but different dom= ains,
so a NMS would know they are different power supplies.=A0 However, sincethey could be in the same domain, then some labeling of the supplies isneeded.=A0 I haven't looked at the MIB to see if there is an obvious e= xisting
variable to do this with, but otherwise just a numeric counter (usually jus= t
always "1") could do this.=A0 This would be used in both cas= es (same domain
and different domain).=A0 This variable not being presen= t would also imply
just one supply.

For reporting, if reported by a device other than t= he server (or whatever the
end device is), then it would just report two= separate entries with the same
UUID - or more likely, each value would = be reported by a different entity.
If the server was reporting on itself, then it would need to specify that i= t
was reporting on a collection of devices (like an aggregator) rather t= han
an individual device, so we could reuse that same mechanism, not nee= d
to create a new one.

The meter and power source data would be differ= ent for each supply.
Each would report on power state, though the values= reported should
be identical.

So, from the perspective of the MI= B, there are two separate devices,
though an NMS could observe they are the same device (having the
same UU= ID) if it wanted to.

So, I think the dual supply case can be accommo= dated without much
difficulty in our current model.

--Bruce

On Fri, Apr 15, 2011 at 10:05 AM, Juergen Qu= ittek <ietf@quittek= .at> wrote:
Dear all,

We are currently revising the eman requirements and discussing how to cover= =A0devices with multiple power supplies.

A typical case is a server with dual main power supply. Often such servers = have their two power inlets connected to different power distribution trees= in order to be able to continue operation even when power fails in one pow= er distribution tree. Typically, servers do not just have two inlets, but t= wo full built-in power supply units. If one breaks, the other can take over= .

I have thought about how to cover such servers in the requrements. My curre= nt solution starts with the point that a powered device may have more than = one power inlet. Then the eman standard to be developed must provide means = (managed objects in MIB modules) for monitoring each power inlet individual= ly. This concerns monitoring of instantaneous power, consumed energy, power= quality, and maybe even just availability of power at an inlet.

Does anyone think this is a reasonable way to go? The inlet concept somehow= blurs the role of built-in power supply units.

Do we have better alternatives?

Thanks,

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



--
Bru= ce Nordman
Lawrence Berk= eley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--bcaec5196d0bdc618f04a0fd0d47-- From bschoening@noveda.com Sat Apr 16 09:32:40 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7DFBE070A for ; Sat, 16 Apr 2011 09:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPOChAbqleVZ for ; Sat, 16 Apr 2011 09:32:36 -0700 (PDT) Received: from cal3-mh481-a.smtproutes.com (cal3-mh481-a.smtproutes.com [208.70.89.235]) by ietfc.amsl.com (Postfix) with ESMTP id 3E985E072D for ; Sat, 16 Apr 2011 09:32:35 -0700 (PDT) X-Katharion-ID: 1302971537.95749.cal3-mh481 Received: from ex01.noveda.com ([66.198.105.170]) by cal3-mh481.smtproutes.com [(208.70.89.155)] with ESMTP via TCP; 16 Apr 2011 09:32:17 -0700 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Sat, 16 Apr 2011 12:32:17 -0400 From: Brad Schoening To: Bruce Nordman , Juergen Quittek Thread-Topic: [eman] power inlets Thread-Index: AQHL+49xuyYKkUM/O0WRYPuExIwTuJRfzq4AgADa0fA= Date: Sat, 16 Apr 2011 16:32:19 +0000 Message-ID: <22B2909DCC2E62418BE369A1F10488992500C6A4@ex01.noveda.com> References: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_22B2909DCC2E62418BE369A1F10488992500C6A4ex01novedacom_" MIME-Version: 1.0 Cc: "eman@ietf.org list" Subject: Re: [eman] power inlets 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, 16 Apr 2011 16:32:40 -0000 --_000_22B2909DCC2E62418BE369A1F10488992500C6A4ex01novedacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruce, In the UPS MIB, the variable that identifies the supply line are 'upsInputL= ineIndex' and 'upsOutputLineIndex'. It would probably be good to review ou= r goals with someone who has worked on the UPS mib and benefit from their i= mplementation experience with power supplies. Regards, Brad From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bru= ce Nordman Sent: Friday, April 15, 2011 7:04 PM To: Juergen Quittek Cc: eman@ietf.org list Subject: Re: [eman] power inlets I can see two cases - when both power supplies are in the same electricity domain, and when they are not. If we only had the second case, then the two reports on the device would have the same UUID, but different domains, so a NMS would know they are different power supplies. However, since they could be in the same domain, then some labeling of the supplies is needed. I haven't looked at the MIB to see if there is an obvious existing variable to do this with, but otherwise just a numeric counter (usually jus= t always "1") could do this. This would be used in both cases (same domain and different domain). This variable not being present would also imply just one supply. For reporting, if reported by a device other than the server (or whatever t= he end device is), then it would just report two separate entries with the sam= e UUID - or more likely, each value would be reported by a different entity. If the server was reporting on itself, then it would need to specify that i= t was reporting on a collection of devices (like an aggregator) rather than an individual device, so we could reuse that same mechanism, not need to create a new one. The meter and power source data would be different for each supply. Each would report on power state, though the values reported should be identical. So, from the perspective of the MIB, there are two separate devices, though an NMS could observe they are the same device (having the same UUID) if it wanted to. So, I think the dual supply case can be accommodated without much difficulty in our current model. --Bruce On Fri, Apr 15, 2011 at 10:05 AM, Juergen Quittek > wrote: Dear all, We are currently revising the eman requirements and discussing how to cover= devices with multiple power supplies. A typical case is a server with dual main power supply. Often such servers = have their two power inlets connected to different power distribution trees= in order to be able to continue operation even when power fails in one pow= er distribution tree. Typically, servers do not just have two inlets, but t= wo full built-in power supply units. If one breaks, the other can take over= . I have thought about how to cover such servers in the requrements. My curre= nt solution starts with the point that a powered device may have more than = one power inlet. Then the eman standard to be developed must provide means = (managed objects in MIB modules) for monitoring each power inlet individual= ly. This concerns monitoring of instantaneous power, consumed energy, power= quality, and maybe even just availability of power at an inlet. Does anyone think this is a reasonable way to go? The inlet concept somehow= blurs the role of built-in power supply units. Do we have better alternatives? Thanks, Juergen _______________________________________________ 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 --_000_22B2909DCC2E62418BE369A1F10488992500C6A4ex01novedacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruce,

 

In the UPS MIB= , the variable that identifies the supply line are ‘upsInputLi= neIndex’ and ‘upsOutputLineIndex’.  It would probabl= y be good to review our goals with someone who has worked on the UPS mib an= d benefit from their implementation experience with power supplies.

 

Regar= ds,

 

Brad

&nb= sp;

From: eman-bounces@ietf.org= [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman
Sen= t: Friday, April 15, 2011 7:04 PM
To: Juergen Quittek
C= c: eman@ietf.org list
Subject: Re: [eman] power inlets

 

I can see two cases - when both pow= er supplies are in the same electricity
domain, and when they are not.&n= bsp; If we only had the second case, then the
two reports on the device = would have the same UUID, but different domains,
so a NMS would know the= y are different power supplies.  However, since
they could be in th= e same domain, then some labeling of the supplies is
needed.  I hav= en't looked at the MIB to see if there is an obvious existing
variable t= o do this with, but otherwise just a numeric counter (usually just
alway= s "1") could do this.  This would be used in both cases (sam= e domain
and different domain).  This variable not being present wo= uld also imply
just one supply.

For reporting, if reported by a d= evice other than the server (or whatever the
end device is), then it wou= ld just report two separate entries with the same
UUID - or more likely,= each value would be reported by a different entity.
If the server was r= eporting on itself, then it would need to specify that it
was reporting = on a collection of devices (like an aggregator) rather than
an individua= l device, so we could reuse that same mechanism, not need
to create a ne= w one.

The meter and power source data would be different for each s= upply.
Each would report on power state, though the values reported shou= ld
be identical.

So, from the perspective of the MIB, there are t= wo separate devices,
though an NMS could observe they are the same devic= e (having the
same UUID) if it wanted to.

So, I think the dual su= pply case can be accommodated without much
difficulty in our current mod= el.

--Bruce

On Fri, Apr 15, = 2011 at 10:05 AM, Juergen Quittek <ie= tf@quittek.at> wrote:

Dear all,
We are currently revising the eman requirements and discussing how to= cover  devices with multiple power supplies.

A typical case is= a server with dual main power supply. Often such servers have their two po= wer inlets connected to different power distribution trees in order to be a= ble to continue operation even when power fails in one power distribution t= ree. Typically, servers do not just have two inlets, but two full built-in = power supply units. If one breaks, the other can take over.

I have t= hought about how to cover such servers in the requrements. My current solut= ion starts with the point that a powered device may have more than one powe= r inlet. Then the eman standard to be developed must provide means (managed= objects in MIB modules) for monitoring each power inlet individually. This= concerns monitoring of instantaneous power, consumed energy, power quality= , and maybe even just availability of power at an inlet.

Does anyone= think this is a reasonable way to go? The inlet concept somehow blurs the = role of built-in power supply units.

Do we have better alternatives?=

Thanks,

   Juergen
____________________________= ___________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman




--
Bruce Nordman
Lawrence Berkeley National Laborato= ry
e= etd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-50= 1-7943

= --_000_22B2909DCC2E62418BE369A1F10488992500C6A4ex01novedacom_-- From AnthonyB@wti.com Thu Apr 7 09:22:58 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D13B28C15C for ; Thu, 7 Apr 2011 09:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-RjNwjVY3+2 for ; Thu, 7 Apr 2011 09:22:57 -0700 (PDT) Received: from mail151.messagelabs.com (mail151.messagelabs.com [216.82.253.3]) by core3.amsl.com (Postfix) with SMTP id 197DD28C15B for ; Thu, 7 Apr 2011 09:22:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: AnthonyB@wti.com X-Msg-Ref: server-8.tower-151.messagelabs.com!1302193480!40606241!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [12.23.46.194] Received: (qmail 15108 invoked from network); 7 Apr 2011 16:24:40 -0000 Received: from unknown (HELO EMAIL.wti.com) (12.23.46.194) by server-8.tower-151.messagelabs.com with SMTP; 7 Apr 2011 16:24:40 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF540.D6CA1F61" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 7 Apr 2011 09:30:10 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Eman Requirements and Framework Feedback Thread-Index: Acv1QRCMWHv+KI3jT5SE938Wd/RlTw== From: "Anthony Barrera" To: X-Mailman-Approved-At: Mon, 18 Apr 2011 03:15:24 -0700 Subject: [eman] Eman Requirements and Framework Feedback 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, 07 Apr 2011 16:22:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF540.D6CA1F61 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Feedback on the following documents: =20 http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/ http://datatracker.ietf.org/doc/draft-ietf-eman-framework/ =20 I have reviewed the documents you provided. I thought the requirements=20 document provided a good high level description of the need for a new=20 energy management standard, the monitoring and control requirements,=20 as well as the shortcomings of the currently existing standards. While=20 monitoring and control were described, you may want to also touch on=20 energy related configuration requirements as well (i.e. keyword,=20 importance, and role). =20 The framework document also looked accurate in describing all of the=20 concepts involved with energy management. It is consistent with all of=20 the work I have been doing on energy management as well. I did see that there=20 was adequate mention of configuration of power monitors in this=20 document. =20 I hope this helps, thanks - Anthony =20 ------_=_NextPart_001_01CBF540.D6CA1F61 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Feedback on the following = documents:

 

ht= tp://datatracker.ietf.org/doc/draft-ietf-eman-requirements/

http:= //datatracker.ietf.org/doc/draft-ietf-eman-framework/

 

I have reviewed the documents you provided. I thought the requirements =

document provided a = good high level description of the need for a new =

energy management = standard, the monitoring and control requirements,

as well as the = shortcomings of the currently existing standards. While

monitoring and = control were described, you may want to also touch on

energy related = configuration requirements as well (i.e. keyword,

importance, and = role).

 

The framework = document also looked accurate in describing all of the

concepts involved = with energy management. It is consistent with all of =

the work I have = been doing on energy management as well. I did see that there =

was adequate = mention of configuration of power monitors in this

document.

 

I hope this helps, = thanks - Anthony

 

------_=_NextPart_001_01CBF540.D6CA1F61-- From bclaise@cisco.com Thu Apr 21 05:20:10 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8AAF6E0689 for ; Thu, 21 Apr 2011 05:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I94pTNSZHlX1 for ; Thu, 21 Apr 2011 05:20:09 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfc.amsl.com (Postfix) with ESMTP id 5C4C0E0682 for ; Thu, 21 Apr 2011 05:20:09 -0700 (PDT) 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 p3LCK79s014880; Thu, 21 Apr 2011 14:20:08 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3LCK6CO019642; Thu, 21 Apr 2011 14:20:06 +0200 (CEST) Message-ID: <4DB020F6.3020009@cisco.com> Date: Thu, 21 Apr 2011 14:20:06 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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: Katherine Voss , eman mailing list Subject: Re: [eman] Review ODVA preso from IETF80 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, 21 Apr 2011 12:20:10 -0000 Hi John, Thanks for the presentation. > Would love to have a discussion on the points and merge to our framework. What would be great is a review of the EMAN requirements draft by the OVDA experts and also the insertion of the ODVA use cases in the applicability statement. So basically, even if there is some obvious synergy, we should first focus on the common requirements and common use cases before merging the solution ;-) Regards, Benoit. > Hi, > > During our EMAN session at IETF80 I presented the work that the ODVA is > doing on energy management. The time was very limited but I'd think it's > very useful to see what a group of primarily electrical engineers are > doing to address the same problem we are looking at. Given their > request for a formal liaison we should look more closely at their > information model and implementation. > > Unfortunately the draft spec is not available as yet but my presentation > does have a summary. I think it would be well worth everyone's time to > take a look at it. > > The presentation is here: > http://www.ietf.org/proceedings/80/slides/eman-1.pdf > > More information on the ODVA is here: > http://www.odva.org > > Summary of important items: > > - Division of information model into electrical and non-electrical > objects > - Electrical objects models with attributes: context, power, energy, > demand and relationship information > - Need for aggregation and parent child pattern with capabilities. > - Standardization on units > - Focus on devices that may not be able to implement the entire > information model. > > Would love to have a discussion on the points and merge to our > framework. > > Thanks > Jp > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Thu Apr 21 05:25:03 2011 Return-Path: X-Original-To: eman@ietfc.amsl.com Delivered-To: eman@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5DDB0E0736 for ; Thu, 21 Apr 2011 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE6ib9WMBofS for ; Thu, 21 Apr 2011 05:25:02 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfc.amsl.com (Postfix) with ESMTP id 48EE6E0733 for ; Thu, 21 Apr 2011 05:25:02 -0700 (PDT) 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 p3LCLGTe015011; Thu, 21 Apr 2011 14:21:16 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3LCLFCO021101; Thu, 21 Apr 2011 14:21:16 +0200 (CEST) Message-ID: <4DB0213B.2070309@cisco.com> Date: Thu, 21 Apr 2011 14:21:15 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bruce Nordman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] Review ODVA preso from IETF80 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, 21 Apr 2011 12:25:03 -0000 Bruce, > John-- > Thanks much for putting together the presentation. > I am unfamiliar with Liaison processes within the IETF, but this > seems well worth > pursuing and you, Benoit, and I should pursue that. Let's follow up off line. Regards, Benoit. From bclaise@cisco.com Tue Apr 26 23:50:54 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 C5019E06AF for ; Tue, 26 Apr 2011 23:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcrofBlcETcz for ; Tue, 26 Apr 2011 23:50:50 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 55F13E06D4 for ; Tue, 26 Apr 2011 23:50:50 -0700 (PDT) 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 p3R6onqG003380; Wed, 27 Apr 2011 08:50:49 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3R6omE1002357; Wed, 27 Apr 2011 08:50:48 +0200 (CEST) Message-ID: <4DB7BCC8.50405@cisco.com> Date: Wed, 27 Apr 2011 08:50:48 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Juergen Quittek References: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> In-Reply-To: <28D47F38-D0AF-4B02-881E-1504440FA282@quittek.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "eman@ietf.org list" Subject: Re: [eman] power inlets 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, 27 Apr 2011 06:50:54 -0000 Juergen, Thinking some more about this term "inlet", I believe that we should use the term “power source” in the requirement draft as it’s more generic to the pattern versus the implementation (inlet) on specific devices. The inlet can be used some use cases Use Case X: Device with Multiple power Sources In this use case a device is powered by 1..N power sources….etc Examples: PoE Device connected to two interfaces from two sources A PC with two power inlets plugged into two wall outlets A washing machine bank requiring 240V wired to two 120V sources Regards, Benoit. > Dear all, > > We are currently revising the eman requirements and discussing how to cover devices with multiple power supplies. > > A typical case is a server with dual main power supply. Often such servers have their two power inlets connected to different power distribution trees in order to be able to continue operation even when power fails in one power distribution tree. Typically, servers do not just have two inlets, but two full built-in power supply units. If one breaks, the other can take over. > > I have thought about how to cover such servers in the requrements. My current solution starts with the point that a powered device may have more than one power inlet. Then the eman standard to be developed must provide means (managed objects in MIB modules) for monitoring each power inlet individually. This concerns monitoring of instantaneous power, consumed energy, power quality, and maybe even just availability of power at an inlet. > > Does anyone think this is a reasonable way to go? The inlet concept somehow blurs the role of built-in power supply units. > > Do we have better alternatives? > > Thanks, > > Juergen > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman