From moulchan@cisco.com Sun Oct 3 23:17:55 2010 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 13C5A3A6E47 for ; Sun, 3 Oct 2010 23:17:55 -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 m-60pynamLPg for ; Sun, 3 Oct 2010 23:17:54 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 12B1C3A6E37 for ; Sun, 3 Oct 2010 23:17:53 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGALIOqUytJV2a/2dsb2JhbACUNo4LcaRJm0uCGoMtBIRRiHc X-IronPort-AV: E=Sophos;i="4.57,277,1283731200"; d="scan'208";a="166461943" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2010 06:18:48 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o946ImiY024662; Mon, 4 Oct 2010 06:18:48 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Oct 2010 01:18:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Oct 2010 01:18:46 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: pmDemandEnergyParametersIntervalMode inclaise-energy-monitoring-mib-04 Thread-Index: ActIpcHQzOAkBLrrQrePJoLgedzqNAa5U+rAAAAz5rA= From: "Mouli Chandramouli (moulchan)" To: X-OriginalArrivalTime: 04 Oct 2010 06:18:47.0976 (UTC) FILETIME=[015EEA80:01CB638C] Subject: [eman] pmDemandEnergyParametersIntervalMode inclaise-energy-monitoring-mib-04 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 06:17:55 -0000 -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Mouli Chandramouli (moulchan) Sent: Monday, October 04, 2010 11:48 AM To: Minoru.Teraoka@jp.yokogawa.com; Benoit Claise (bclaise); opsawg@ietf.org Subject: Re: [OPSAWG] pmDemandEnergyParametersIntervalMode inclaise-energy-monitoring-mib-04 Minoru, Can you please give provide us an use case where multiple modes of energy measurement (sliding, period) would be required.=20 With either methods, there will be a computational overhead to poll the device to collect the energy measurement over time.=20 In that context, would it be useful to collect energy measurement using multiple modes.=20 Thanks Mouli -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Minoru.Teraoka@jp.yokogawa.com Sent: Tuesday, August 31, 2010 6:15 AM To: Benoit Claise (bclaise); opsawg@ietf.org Subject: [OPSAWG] pmDemandEnergyParametersIntervalMode in claise-energy-monitoring-mib-04 Dear Benoit, [My apologies for if this is a repost. Previous posting seems to have failed.] I had a question about how to use pmDemandEnergyParametersIntervalMode. We have already talked the question about it in Maastricht, but I am not sure I understand it. In pmDemandEnergyParametersTable, are pmIndex and pmDemandEnergyParametersIntervalMode the one-on-one relationships? I assume that there may be the case that both 'period' and 'total' are necessary at an object of 'PmIndex'. pmDemandEnergyParametersIntervalMode OBJECT-TYPE SYNTAX INTEGER { period(1), sliding(2), total(3) } Don't we need to define two or more modes of pmDemandEnergyParametersIntervalMode in one object? Best regards, Minoru _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From jinchoe@gmail.com Tue Oct 5 23:06:07 2010 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 6C6543A70FB for ; Tue, 5 Oct 2010 23:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 W6fuoYN6POB7 for ; Tue, 5 Oct 2010 23:05:55 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 8B1873A70EF for ; Tue, 5 Oct 2010 23:05:43 -0700 (PDT) Received: by wwb13 with SMTP id 13so489638wwb.1 for ; Tue, 05 Oct 2010 23:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=5WVWjbRX65zi3wlGtTNlEiO4aFU1RmOpHqVYygGQCtE=; b=POgFllsopHMvOPQZ6iDvS7xEavxKJO/O7pzrJynsxiVVdQhz9rKqCvZerLu3l1i1TW v4/U6UNblC+ZovYOapDhT2ug3eoQQq35kujBAZlFqBVF1d/enEPvciHBkxwiIU0b0fjA R0S5W1m0aFH/AGWsRSJMYTL6Q8LogtHNUUtj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=df3UyrKqu4Joc9u/z04NGgAT6uIdyQjmH2mfT2hJMEfQ9fqvJS06q4bFOifK9WWOlq N4gYf2DWGL1BDm4R6v5GKqXW73wlTnBrm0hyJsfkCbUuFosaMcYqg27/MDQaNtnEJzK7 RJYD4zIC7YRAT9FX1HSRyfBizqo2ERxBci9mg= MIME-Version: 1.0 Received: by 10.216.131.161 with SMTP id m33mr10228881wei.13.1286345144834; Tue, 05 Oct 2010 23:05:44 -0700 (PDT) Received: by 10.216.5.202 with HTTP; Tue, 5 Oct 2010 23:05:44 -0700 (PDT) Date: Wed, 6 Oct 2010 15:05:44 +0900 Message-ID: From: JinHyeock Choi To: Benoit Claise Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: eman@ietf.org Subject: [eman] Comments on Power Management Architecture X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 06:06:08 -0000 Hi Here are some comments. 1. Communication model I wish the communication model between Power Monitor & NMS (to which information would be ultimately reported, I assume). is more clearly presented. The power monitoring information is defined in detail but it=92s not clear which entity report that information to which entity through which mechanism. For example I guess that Large time series of energy consumption values of a Power Monitor Child are reported by Power Monitor Parent to NMS though IPFIX (or Syslog) but can=92t be sure that=92s right. Though there are some related contents in 7. Fault Management, I wish more clear statements & elaboration. For more clear communication model, it would help to add some paragraphs about 1) participating entities as defined in Nordman I-D . Participating entities are monitoring systems that receive information and networked devices that provide information on energy consumption and power state information concerning themselves or potentially also other devices. BTW which entity is IP enabled? Which entity understands IP to report to NMS (via SNMP)? All Power Monitor or Power Monitor Parent? 2) monitoring model SNMP/ MIB or IPFIX as presented in [POWER-MON-REQ]. BTW [POWER-MON-REQ] propose to (in Sec 6) develop a standard for pull-based power state monitoring and push based one (with IPFIX or Syslog). About which, this document won=92t make any statement? 2. Power Monitor Parent & Child There are some ambiguities regarding Power Monitor Parent & Child relationship. First it=92s not clear which makes two entities Power Monitor Parent & Power Monitor Child. >From the document, I assume either i) a Parent provides a Child power (as in PoE) or ii) a Child reports power information to its Parent. However, in 4.3, it=92s written A Power Monitor Child can be fully dependent on the Power Monitor Parent (as in the case of Power Over Ethernet) or independent from the parent (such as a PC connected to a switch). What makes a PC a child to a switch? Just because it=92s connected to the switch or is it assumed that the PC report its power usage to the switch? Also what if a Parent provides a Child a power but the Parent neither monitor the Child=92s power usage nor the Child makes no report to the Parent? In the above case, The Parent plays no role in the Child=92s Power Monitoring. Here are some more questions. 1) Can a Child have more than one Parents? For example a IP phone may get a power from PoE but report its power usage to a building gateway. 2) Does Parent always report the power information of its=92 Child for its stead? If so, to whom, NMS of it=92s own Parent? 3) It=92s written A Power Monitor cannot be at the same time a Power Monitor Parent and a Power Monitor Child. But the above seems to contradict with Figure 4 of Scenario 1 of [POWER-MON-MIB] in which SWITCH PORT is the CHILD of SWITCH and the PARENT of IP PHONE at that same time. Please clarify. 4) Which entity report to NMS with IP? A Child can make its own report to NMS or always a Parent should report for its stead? Best Regards JinHyeock Choi From chrisv@cyberswitching.com Sun Oct 10 01:19:23 2010 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 BB1F43A672F for ; Sun, 10 Oct 2010 01:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_50=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 RjTlKoRUqMYS for ; Sun, 10 Oct 2010 01:19:23 -0700 (PDT) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by core3.amsl.com (Postfix) with ESMTP id A9BB33A6452 for ; Sun, 10 Oct 2010 01:19:22 -0700 (PDT) Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c12o149.mxlogic.net(mxl_mta-6.7.0-1) with ESMTP id f4771bc4.0.138112.00-381.240329.p01c12o149.mxlogic.net (envelope-from ); Sun, 10 Oct 2010 02:20:32 -0600 (MDT) X-MXL-Hash: 4cb1775010eddfeb-dbea028be60c58c61afa0ad93c47af7350be7bff X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Oct 2010 01:20:16 -0700 Message-ID: <68FBE0F3CE97264395875AC1C468F22C3C797B@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: pmACPwrQualityDelPhaseToZeroVoltage in draft-claise-energy-monitoring-mib-05 Thread-Index: ActoU+OF5QHLCY4UQrmIYVuG6BaILg== From: "Chris Verges" To: X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010073001)] X-MAIL-FROM: X-SOURCE-IP: [64.81.28.110] X-AnalysisOut: [v=1.0 c=1 a=c3WTna4XPBkA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=4zsJQXJisSY22NXBO5KRuA==:17 a=W-pBGjjKdCCwMmKiCYwA] X-AnalysisOut: [:9 a=3lQAEVyn1cQRpHQkPOrNqU5grCUA:4 a=CjuIK1q_8ugA:10] Subject: [eman] pmACPwrQualityDelPhaseToZeroVoltage in draft-claise-energy-monitoring-mib-05 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 08:19:23 -0000 Hi EMAN WG, In running draft-claise-energywise-monitoring-mib-05 through smilint for a quick check, pmACPwrQualityDelPhaseToZeroVoltage is referenced in powerACPwrQualityDelPhaseMIBTableGroup, but is not defined anywhere. Was this dropped intentionally? Thanks, Chris From fletchj@us.ibm.com Sun Oct 10 15:01:13 2010 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 6C3993A6857 for ; Sun, 10 Oct 2010 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, 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 x79F7KRr3NjY for ; Sun, 10 Oct 2010 15:01:12 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 8DD013A684F for ; Sun, 10 Oct 2010 15:01:12 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9ALqdck020807 for ; Sun, 10 Oct 2010 15:52:40 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9AM2FC5143004 for ; Sun, 10 Oct 2010 16:02:15 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9AM2EW0021892 for ; Sun, 10 Oct 2010 16:02:15 -0600 Received: from d03nm120.boulder.ibm.com (d03nm120.boulder.ibm.com [9.17.195.146]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o9AM2EwS021889 for ; Sun, 10 Oct 2010 16:02:14 -0600 Auto-Submitted: auto-generated From: Jim Fletcher To: eman@ietf.org Message-ID: Date: Sun, 10 Oct 2010 16:02:13 -0600 X-MIMETrack: Serialize by Router on D03NM120/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 10/10/2010 16:02:14 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBFD2BDFEA8B528f9e8a93df938690918c08BBFD2BDFEA8B52" Content-Disposition: inline Subject: [eman] AUTO: Jim fletcher is out of the office -- returning Monday Oct 11 (returning 10/11/2010) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 22:01:13 -0000 --0__=08BBFD2BDFEA8B528f9e8a93df938690918c08BBFD2BDFEA8B52 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 10/11/2010. Note: This is an automated response to your message "eman Digest, Vol = 3, Issue 3" sent on 10/10/10 13:00:09. This is the only notification you will receive while this person is awa= y.= --0__=08BBFD2BDFEA8B528f9e8a93df938690918c08BBFD2BDFEA8B52 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 10/11/2010.




Note: This is an automated re= sponse to your message "eman Digest, V= ol 3, Issue 3" sent = on 10/10/10 13:00:09.

This is the only notification= you will receive while this person is away.= --0__=08BBFD2BDFEA8B528f9e8a93df938690918c08BBFD2BDFEA8B52-- From bclaise@cisco.com Tue Oct 12 05:47:12 2010 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 0C3173A6968 for ; Tue, 12 Oct 2010 05:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 qPs4FLL2AdK3 for ; Tue, 12 Oct 2010 05:47:11 -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 D15FA3A696B for ; Tue, 12 Oct 2010 05:47:10 -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 o9CCmOlX028173 for ; Tue, 12 Oct 2010 14:48:24 +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 o9CCmNxI008858 for ; Tue, 12 Oct 2010 14:48:24 +0200 (CEST) Message-ID: <4CB45917.7040900@cisco.com> Date: Tue, 12 Oct 2010 14:48:23 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; 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] Reminder: I-D cutoff dates for IETF-79 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:47:12 -0000 Dear all, Just a reminder that the cutoff date for -00 drafts is this Monday, October 18, at 24:00 UTC. The date for drafts with higher version numbers is the following Monday, October 25, also at 24:00 UTC. Yes, IETF 79 is fast approaching! Regards, Benoit. From bclaise@cisco.com Wed Oct 13 06:31:11 2010 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 2A2523A68ED for ; Wed, 13 Oct 2010 06:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 GIluttEw49xZ for ; Wed, 13 Oct 2010 06:31:09 -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 5986E3A6A85 for ; Wed, 13 Oct 2010 06:31:07 -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 o9DCfwtp025832; Wed, 13 Oct 2010 14:41:58 +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 o9DCfvle012664; Wed, 13 Oct 2010 14:41:58 +0200 (CEST) Message-ID: <4CB5A915.5090901@cisco.com> Date: Wed, 13 Oct 2010 14:41:57 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Chris Verges References: <68FBE0F3CE97264395875AC1C468F22C3C797B@mail03.cyberswitching.local> In-Reply-To: <68FBE0F3CE97264395875AC1C468F22C3C797B@mail03.cyberswitching.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman@ietf.org Subject: Re: [eman] pmACPwrQualityDelPhaseToZeroVoltage in draft-claise-energy-monitoring-mib-05 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 13:31:11 -0000 Hi Chris, Thanks for pointing that out Initially, pmACPwrQualityDelPhaseToZeroVoltage was added in the three-phase AC delta configuration, because it was part of the IEC data model A newer version of the IEC model actually removed this... which is more logical btw ;-) Anyway, corrected now. Regards, Benoit. > Hi EMAN WG, > > In running draft-claise-energywise-monitoring-mib-05 through smilint for > a quick check, pmACPwrQualityDelPhaseToZeroVoltage is referenced in > powerACPwrQualityDelPhaseMIBTableGroup, but is not defined anywhere. > Was this dropped intentionally? > > Thanks, > Chris > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Fri Oct 15 11:42:11 2010 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 9DD893A6CF4 for ; Fri, 15 Oct 2010 11:42:11 -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 Vt0cn0wOdz9R for ; Fri, 15 Oct 2010 11:42:10 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6A1963A684F for ; Fri, 15 Oct 2010 11:42:10 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.57,337,1283731200"; d="scan'208";a="270223849" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 15 Oct 2010 18:43:32 +0000 Received: from [171.71.229.114] (dhcp-p-229-114.cisco.com [171.71.229.114]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9FIhWIN022880; Fri, 15 Oct 2010 18:43:32 GMT Message-ID: <4CB8A0D3.2000403@cisco.com> Date: Fri, 15 Oct 2010 11:43:31 -0700 From: john parello User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: JinHyeock Choi References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Cc: eman@ietf.org Subject: Re: [eman] Comments on Power Management Architecture X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 18:42:11 -0000 Hi JinHyeock, Thanks for the feedback and review. We have made changes to help clarify = some of your point and it will be posted to the list. Please see inline for our thinking on the various points. On 10/5/10 11:05 PM, JinHyeock Choi wrote: > Hi > > Here are some comments. > > 1. Communication model > I wish the communication model between Power Monitor& NMS > (to which information would be ultimately reported, I assume). > is more clearly presented. > > The power monitoring information is defined in detail > but it=92s not clear > which entity report that information > to which entity through which mechanism. > [jparello] That's true however the assumption is that the communication=20 between the NMS and POwer Monitors would be via SNMP. So the=20 Architecture is a description of what we need that is then implemented=20 via SNMP data model. > For example I guess that > > Large time series of energy consumption values of a Power Monitor Ch= ild > are reported by Power Monitor Parent to NMS though IPFIX (or Syslog)= > > but can=92t be sure that=92s right. > [jparello] The group has not put a requirement for IPFIX but that could=20 be brought up the the WG meeting. > Though there are some related contents in 7. Fault Management, > I wish more clear statements& elaboration. > > For more clear communication model, > it would help to add some paragraphs about > > 1) participating entities > as defined in Nordman I-D . > > Participating entities are monitoring systems that receive > information and networked devices that provide information on ener= gy > consumption and power state information concerning themselves or > potentially also other devices. > [jparello] Yes I think we have this covered in the definition of Power=20 Monitor itself. > BTW which entity is IP enabled? > Which entity understands IP to report to NMS (via SNMP)? > All Power Monitor or Power Monitor Parent? > [jparello] The assumption is that we are starting with SNMP first so a=20 Parent power monitor would implement the mib and then and subtended=20 devices that did not or could not implement SNMP would be aggregated to=20 the Power Monitor parent. > 2) monitoring model > SNMP/ MIB or IPFIX > as presented in [POWER-MON-REQ]. > > BTW [POWER-MON-REQ] propose to (in Sec 6) develop > a standard for pull-based power state monitoring > and push based one (with IPFIX or Syslog). > About which, this document won=92t make any statement? > [jparello] See previous that IPFIX could be brought up as a WG item IMO. > 2. Power Monitor Parent& Child > There are some ambiguities regarding > Power Monitor Parent& Child relationship. > > First it=92s not clear which makes two entities > Power Monitor Parent& Power Monitor Child. > [jparello] We have added this in the next revision about to be posted. >> From the document, I assume either > i) a Parent provides a Child power (as in PoE) or > ii) a Child reports power information to its Parent. > [jparello] The parent may or may not provide power to the child. For=20 instance a PoE switch would have PoE endpoints as children and in this=20 case would clearly provide power to the child. In the case of a wireless = controller the controller may be the parent of the wireless APs but they = may draw power directly from a wall outlet. > However, in 4.3, it=92s written > > A Power Monitor Child can be fully dependent on the Power > Monitor Parent (as in the case of Power Over Ethernet) or > independent from the parent (such as a PC connected to a > switch). > > What makes a PC a child to a switch? > Just because it=92s connected to the switch or > is it assumed that the PC report its power usage to the switch? > [jparello] Yes. The idea is that some device that is capable of=20 communicating power usage could act as an aggregation point for other=20 subtended devices. So a switch could be a parent for connected PCs. One=20 could have one PC that is the parent and SNMP capable and other PCs that = are not capable as children. The proposed architecture allows for one=20 device that can communicate power information to an NMS can act as a=20 parent or aggregation point for others that cannot communicate to the NMS= =2E > Also what if a Parent provides a Child a power > but the Parent neither monitor the Child=92s power usage > nor the Child makes no report to the Parent? > [jparello] In that case we envision the parent to at least provide the=20 nameplate power characteristics of itself or even better of the=20 children. The power usage data model allows the Power Monitor parent to=20 describe how and to what accuracy the usage is reported. In this=20 scenario it would be a poor participant but could still presumably=20 report nameplate power. > In the above case, > The Parent plays no role in the Child=92s Power Monitoring. > [jparello] see above. > Here are some more questions. > > 1) Can a Child have more than one Parents? > For example a IP phone may get a power from PoE > but report its power usage to a building gateway. > [jparello] The parent is defines as the device that aggregates and=20 provides reporting it may not be the source of the power. So we=20 specifically don't want a device to report its power to two parents as=20 that would cause double counting. > 2) Does Parent always report > the power information of its=92 Child for its stead? > If so, to whom, NMS of it=92s own Parent? > [jparello] The parent may report the power usage on behalf of the child=20 or may delegate it to the child and aggregate it to the NMS. > 3) It=92s written > > A Power Monitor cannot be at the same time a Power Monitor > Parent and a Power Monitor Child. > > But the above seems to contradict with > Figure 4 of Scenario 1 of [POWER-MON-MIB] > in which > SWITCH PORT is the CHILD of SWITCH and > the PARENT of IP PHONE at that same time. > Please clarify. > [jparello] For SNMP the NMS would talk to each parent directly to get=20 power information. Having a parent that is also a child of another=20 parent would cause the devices to begin to "walk the network". As such=20 we specified each parent as a disjoint tree of power reporting. > 4) Which entity report to NMS with IP? > A Child can make its own report to NMS > or always a Parent should report for its stead? > [jparello] By definition the parent aggregates it. Thanks so much! John From tirth.ghose@gmail.com Sun Oct 17 00:46:07 2010 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 45C213A68F3 for ; Sun, 17 Oct 2010 00:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 PWk9L5zSkQX2 for ; Sun, 17 Oct 2010 00:46:05 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 771953A6A5B for ; Sun, 17 Oct 2010 00:46:05 -0700 (PDT) Received: by iwn10 with SMTP id 10so3165950iwn.31 for ; Sun, 17 Oct 2010 00:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=cDkMSZtxUB+M/CUTPZ7uZB2lEwL+uJueslonBSBS6TA=; b=IOlwzokgr88rjUnqMPbJb6gAsvPJryxKg9zbD33O62Qps8opceJsM+Cei7aTqXSjoT zQWCkxfkvfBuljnTUGrj6s2U7QkXkPrkEuX/HL4PGcpNmMsV9r++wr7mG2vpWtfUXAxp 0bujby/qpjmjJ3wI0S0fBgxWaJAWnYw1uXNSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=cohSKkGADFOJLDUh593cPREm3VgIM3PJLudfh4wTMfoIpfkkeiTPhBz3jHA5m5r1UR o688LKuP8neYH/gC77lt647QR60hCer5rEdbpeJfVsmQD66u8YNDLtIBGG9yJ7GZl7kJ DkJim8to731fuZLFvwHD65Rno9o9a4kb3b7xk= MIME-Version: 1.0 Received: by 10.231.30.193 with SMTP id v1mr2177285ibc.87.1287301650705; Sun, 17 Oct 2010 00:47:30 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.231.183.210 with HTTP; Sun, 17 Oct 2010 00:47:30 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Oct 2010 00:47:30 -0700 X-Google-Sender-Auth: BHmsvKy478Po43FukpEU5kCDEdI Message-ID: From: Ted Ghose To: JinHyeock Choi Content-Type: multipart/alternative; boundary=00032557a0d69bedb00492cb45a1 Cc: eman@ietf.org Subject: Re: [eman] Comments on Power Management Architecture X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 07:49:49 -0000 --00032557a0d69bedb00492cb45a1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable in line, look for [tg] On Tue, Oct 5, 2010 at 11:05 PM, JinHyeock Choi wrote: > Hi > > Here are some comments. > > 1. Communication model > I wish the communication model between Power Monitor & NMS > (to which information would be ultimately reported, I assume). > is more clearly presented. > > The power monitoring information is defined in detail > but it=92s not clear > which entity report that information > to which entity through which mechanism. > > For example I guess that > > Large time series of energy consumption values of a Power Monitor Child > are reported by Power Monitor Parent to NMS though IPFIX (or Syslog) > > but can=92t be sure that=92s right. > > Though there are some related contents in 7. Fault Management, > I wish more clear statements & elaboration. > > For more clear communication model, > it would help to add some paragraphs about > > 1) participating entities > as defined in Nordman I-D . > > Participating entities are monitoring systems that receive > information and networked devices that provide information on energy > consumption and power state information concerning themselves or > potentially also other devices. > > BTW which entity is IP enabled? > Which entity understands IP to report to NMS (via SNMP)? > All Power Monitor or Power Monitor Parent? > > [tg] if entity is ip enable, it can report its own information. if the entity is ip enable and do not have capability to monitor its own energy usage, it should at least be capable of telling (automatically or by configuration) who is monitoring its usage. 2) monitoring model > SNMP/ MIB or IPFIX > as presented in [POWER-MON-REQ]. > > BTW [POWER-MON-REQ] propose to (in Sec 6) develop > a standard for pull-based power state monitoring > and push based one (with IPFIX or Syslog). > About which, this document won=92t make any statement? > [tg] ipfix is a better choice, I'd keep it open for discussion. ipfix is more designed towards data collection for data mining. > > 2. Power Monitor Parent & Child > There are some ambiguities regarding > Power Monitor Parent & Child relationship. > > First it=92s not clear which makes two entities > Power Monitor Parent & Power Monitor Child. > > From the document, I assume either > i) a Parent provides a Child power (as in PoE) or > ii) a Child reports power information to its Parent. > > However, in 4.3, it=92s written > > A Power Monitor Child can be fully dependent on the Power > Monitor Parent (as in the case of Power Over Ethernet) or > independent from the parent (such as a PC connected to a > switch). > > What makes a PC a child to a switch? > Just because it=92s connected to the switch or > is it assumed that the PC report its power usage to the switch? > > Also what if a Parent provides a Child a power > but the Parent neither monitor the Child=92s power usage > nor the Child makes no report to the Parent? > > In the above case, > The Parent plays no role in the Child=92s Power Monitoring. > > [tg] model we should be looking for is: * entity that are not capable of monitoring/manage its own power to align u= p to a device who can do this for it, hence this device will be a child of th= e device who control it. > Here are some more questions. > > 1) Can a Child have more than one Parents? > For example a IP phone may get a power from PoE > but report its power usage to a building gateway. > [tg] if someone providing the PoE power, it will be double counting to measure it from building gateway. In this light we should have one and only one parent. > > 2) Does Parent always report > the power information of its=92 Child for its stead? > If so, to whom, NMS of it=92s own Parent? > [tg] if and only if a child wish the parent to report or control its power. We will always like to to make the end device to make the call. > > 3) It=92s written > > A Power Monitor cannot be at the same time a Power Monitor > Parent and a Power Monitor Child. > > But the above seems to contradict with > Figure 4 of Scenario 1 of [POWER-MON-MIB] > in which > SWITCH PORT is the CHILD of SWITCH and > the PARENT of IP PHONE at that same time. > Please clarify. > [tg] please read: monitoring of the device who is monitoring other devices is orthogonal about its own consumption. Take the case of an electric meter of a home. The meter may not be capable of measuring its own usage, but can measure the power drawn by the home. Now the power drawn by the meter can b= e monitored by someone else, hence the flexibility presented! > > 4) Which entity report to NMS with IP? > A Child can make its own report to NMS > or always a Parent should report for its stead? > [tg] in the light of all above cases, it depends. if a device is capable of doing so, it will, else it can ask somebody else to manage it for him. Best Regards -tg- > > Best Regards > > JinHyeock Choi > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --00032557a0d69bedb00492cb45a1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable in line, look for [tg]

On Tue, Oct 5, 2010 at= 11:05 PM, JinHyeock Choi <jinchoe@gmail.com> wrote:
Hi

Here are some comments.

1. Communication model
I wish the communication model between Power Monitor & NMS
(to which information would be ultimately reported, I assume).
is more clearly presented.

The power monitoring information is defined in detail
but it=92s not clear
which entity report that information
to which entity through which mechanism.

For example I guess that

=A0Large time series of energy consumption values of a Power Monitor Child=
=A0are reported by Power Monitor Parent to NMS though IPFIX (or Syslog)
but can=92t be sure that=92s right.

Though there are some related contents in 7. Fault Management,
I wish more clear statements & elaboration.

For more clear communication model,
it would help to add some paragraphs about

1) participating entities
=A0 =A0as defined in Nordman I-D .

=A0 =A0Participating entities are monitoring systems that receive
=A0 =A0information and networked devices that provide information on energ= y
=A0 =A0consumption and power state information concerning themselves or =A0 =A0potentially also other devices.

BTW which entity is IP enabled?
Which entity understands IP to report to NMS (via SNMP)?
All Power Monitor or Power Monitor Parent?


[tg] if entity is ip enable, it can report its ow= n information. if the entity is ip enable and do not have capability to mon= itor its own energy usage, it should at least be capable of telling (automa= tically or by configuration) who is monitoring its usage.


2) monitoring model
=A0 =A0SNMP/ MIB or IPFIX
=A0 =A0as presented in [POWER-MON-REQ].

BTW [POWER-MON-REQ] propose to (in Sec 6) develop
a standard for pull-based power state monitoring
and push based one (with IPFIX or Syslog).
About which, this document won=92t make any statement?

[tg] ipfix is a better choice, I'd keep it open for discussion. ip= fix is more designed towards data collection for data mining.=A0

2. Power Monitor Parent & Child
There are some ambiguities regarding
Power Monitor Parent & Child relationship.

First it=92s not clear which makes two entities
Power Monitor Parent & Power Monitor Child.

>From the document, I assume either
i) a Parent provides a Child power (as in PoE) or
ii) a Child reports power information to its Parent.

However, in 4.3, it=92s written

=A0 =A0 =A0 =A0A Power Monitor Child can be fully dependent on the Power =A0 =A0 =A0 =A0Monitor Parent (as in the case of Power Over Ethernet) or =A0 =A0 =A0 =A0independent from the parent (such as a PC connected to a =A0 =A0 =A0 =A0switch).

What makes a PC a child to a switch?
Just because it=92s connected to the switch or
is it assumed that the PC report its power usage to the switch?

Also what if a Parent provides a Child a power
but the Parent neither monitor the Child=92s power usage
nor the Child makes no report to the Parent?

In the above case,
The Parent plays no role in the Child=92s Power Monitoring.


[tg] model we should be looking for is:

* = entity that are not capable of monitoring/manage its own power to align up = to a device who can do this for it, hence this device will be a child of th= e device who control it.
=A0
Here are some more questions.

1) Can a Child have more than one Parents?
For example a IP phone may get a power from PoE
but report its power usage to a building gateway.

= [tg] if someone providing the PoE power, it will be double counting to meas= ure it from building gateway. In this light we should have one and only one= parent.

2) Does Parent always report
the power information of its=92 Child for its stead?
If so, to whom, NMS of it=92s own Parent?
[tg] if and = only if a child wish the parent to report or control its power. We will alw= ays like to to make the end device to make the call.=A0

3) It=92s written

=A0 =A0 A Power Monitor cannot be at the same time a Power Monitor
=A0 =A0 Parent and a Power Monitor Child.

But the above seems to contradict with
Figure 4 of Scenario 1 of [POWER-MON-MIB]
in which
SWITCH PORT is the CHILD of SWITCH and
the PARENT of IP PHONE at that same time.
Please clarify.
[tg] please read: monitoring of the de= vice who is monitoring other devices is orthogonal about its own consumptio= n. Take the case of an electric meter of a home. The meter may not be capab= le of measuring its own usage, but can measure the power drawn by the home.= Now the power drawn by the meter can be monitored by someone else, hence t= he flexibility presented! =A0

4) Which entity report to NMS with IP?
A Child can make its own report to NMS
or always a Parent should report for its stead?

[t= g] in the light of all above cases, it depends. if a device is capable of d= oing so, it will, else it can ask somebody else to manage it for him.

Best Regards

-tg-

Best Regards

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

--00032557a0d69bedb00492cb45a1-- From etychon@cisco.com Sun Oct 17 09:30:25 2010 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 7CF363A6BA7 for ; Sun, 17 Oct 2010 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uIG24msOxd+o for ; Sun, 17 Oct 2010 09:30:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 26F6D3A6BA2 for ; Sun, 17 Oct 2010 09:30:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUJALDBukyrR7Hu/2dsb2JhbACZOYdycadMm1CFSQSEVIV2 X-IronPort-AV: E=Sophos;i="4.57,342,1283731200"; d="scan'208,217";a="605358308" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2010 16:31:50 +0000 Received: from sjc-vpn7-957.cisco.com (sjc-vpn7-957.cisco.com [10.21.147.189]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9HGVoZs009145 for ; Sun, 17 Oct 2010 16:31:50 GMT From: Emmanuel Tychon Content-Type: multipart/alternative; boundary=Apple-Mail-1--211734671 Date: Sun, 17 Oct 2010 09:31:50 -0700 Message-Id: <7921EEA9-3FF9-41F4-99E7-0DC64016654F@cisco.com> To: eman@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [eman] Applicability Statement draft (draft-tychon-eman-applicability-statement-00) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 16:30:26 -0000 --Apple-Mail-1--211734671 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Dear all, A new draft for the working group Applicability Statement has been posted: http://www.ietf.org/id/draft-tychon-eman-applicability-statement-00.txt If possible, we would like to present it during the next IETF meeting. Thank you for your attention, Emmanuel, Brad, Jeff, and Matt --Apple-Mail-1--211734671 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Dear all,

A new draft for the working group Applicability Statement has been posted:

If possible, we would like to present it during the next IETF meeting.

Thank you for your attention,
Emmanuel, Brad, Jeff, and Matt

--Apple-Mail-1--211734671-- From jparello@cisco.com Wed Oct 20 17:36:28 2010 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 A98523A657C for ; Wed, 20 Oct 2010 17:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IJ9r5PJjbGF for ; Wed, 20 Oct 2010 17:36:23 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0FE223A68A2 for ; Wed, 20 Oct 2010 17:36:23 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,214,1286150400"; d="scan'208";a="204135835" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 21 Oct 2010 00:37:57 +0000 Received: from [10.10.10.5] ([10.21.87.54]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9L0bvW8021390; Thu, 21 Oct 2010 00:37:57 GMT Message-ID: <4CBF8B64.50400@cisco.com> Date: Wed, 20 Oct 2010 17:37:56 -0700 From: john parello User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: eman@ietf.org References: <4CA2DE3D.3030605@cisco.com> In-Reply-To: <4CA2DE3D.3030605@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] agenda items for EMAN in Beijing X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 00:36:28 -0000 HI, We posted two new drafts for mib monitoring and energy aware devices which I request a slot to present these: http://tools.ietf.org/id/draft-parello-eman-energy-aware-mib-00.txt http://tools.ietf.org/id/draft-claise-energy-monitoring-mib-05.txt These draft apply to both the arch and requirements in : http://tools.ietf.org/id/draft-claise-power-management-arch-02.txt http://tools.ietf.org/id/draft-quittek-power-monitoring-requirements-01.txt Thank you John On 9/28/10 11:35 PM, Benoit Claise wrote: > > Dear all, > > Please let the list know if you have a topic for the EMAN session in > Beijing. > > Regards, Benoit. > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > From jparello@cisco.com Wed Oct 20 17:46:38 2010 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 9FA903A6932 for ; Wed, 20 Oct 2010 17:46:38 -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 yao6seHzqsKV for ; Wed, 20 Oct 2010 17:46:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C848B3A6926 for ; Wed, 20 Oct 2010 17:46:37 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGANsqv0yrR7H+/2dsb2JhbACTZY1rcaMJnEeFSgSEVYV2gwQ X-IronPort-AV: E=Sophos;i="4.58,214,1286150400"; d="scan'208";a="273004293" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 21 Oct 2010 00:48:12 +0000 Received: from [10.10.10.5] ([10.21.87.54]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9L0mBRh017226 for ; Thu, 21 Oct 2010 00:48:12 GMT Message-ID: <4CBF8DCB.7060409@cisco.com> Date: Wed, 20 Oct 2010 17:48:11 -0700 From: john parello User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: eman@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] New draft posted: draft-claise-energy-monitoring-mib-05.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 00:46:38 -0000 Hi, We have posted the following draft update for review: http://tools.ietf.org/id/draft-claise-energy-monitoring-mib-05.txt The changes include: - Revision of terminology and concepts from feedback from the mailer - Consolidation and movement of items to Arch draft as discussed with group (draft-claise-power-management-arch-02) - Revision of scenarios to provide more detail as requested - Removal of energy aware objects that now apply to (draft-parello-eman-energy-aware-mib-00) You're feedback is welcome John From jparello@cisco.com Wed Oct 20 17:51:55 2010 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 AB8DD3A693A for ; Wed, 20 Oct 2010 17:51:55 -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 a4i5zuLRBkdb for ; Wed, 20 Oct 2010 17:51:55 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id EE0533A6934 for ; Wed, 20 Oct 2010 17:51:54 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGAAcsv0yrR7H+/2dsb2JhbACTZY1rcaMKnEeFSgSEVYV2gwQ X-IronPort-AV: E=Sophos;i="4.58,214,1286150400"; d="scan'208";a="204144366" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 21 Oct 2010 00:53:29 +0000 Received: from [10.10.10.5] ([10.21.87.54]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9L0rSsH020233 for ; Thu, 21 Oct 2010 00:53:28 GMT Message-ID: <4CBF8F08.7020209@cisco.com> Date: Wed, 20 Oct 2010 17:53:28 -0700 From: john parello User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: eman@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] New draft posted: draft-parello-eman-energy-aware-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 00:51:55 -0000 Hi, We have posted a new mib draft-parello-eman-energy-aware-mib-00 This mib represents a refactoring of draft-claise-energy-monitoring-mib. Items pertaining to making a device energy aware and providing context for the device are applied now in draft-parello-eman-energy-aware-mib-00. In contrast draft-claise-energy-monitoring-mib now contains objects pertaining to usage values. Both reference and/or fulfill the architect and requirements drafts: http://tools.ietf.org/id/draft-claise-power-management-arch-02.txt http://tools.ietf.org/id/draft-quittek-power-monitoring-requirements-01.txt You're feedback is welcome and greatly appreciated Thanks you John From bclaise@cisco.com Wed Oct 20 23:15:39 2010 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 918D83A6987 for ; Wed, 20 Oct 2010 23:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, 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 i3X3TucS6HXc for ; Wed, 20 Oct 2010 23:15:37 -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 458FA3A6954 for ; Wed, 20 Oct 2010 23:15:37 -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 o9L6DQBU026285 for ; Thu, 21 Oct 2010 08:13:26 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9L6DMbq017269; Thu, 21 Oct 2010 08:13:23 +0200 (CEST) Message-ID: <4CBFDA02.3040806@cisco.com> Date: Thu, 21 Oct 2010 08:13:22 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: john parello References: <4CBF8F08.7020209@cisco.com> In-Reply-To: <4CBF8F08.7020209@cisco.com> Content-Type: multipart/alternative; boundary="------------090105030808090002020708" Cc: eman@ietf.org Subject: Re: [eman] New draft posted: draft-parello-eman-energy-aware-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 06:15:39 -0000 This is a multi-part message in MIME format. --------------090105030808090002020708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, So draft-claise-energy-monitoring-mib has been split into two drafts, in order to match the charter items. _draft-parello-eman-energy-aware-mib-00 _ 3. Energy-aware Networks and Devices MIB document The EMAN WG will develop a MIB module for monitoring energy-aware networks and devices. The module will address devices identification, context information, and potential relationship between reporting devices, remote devices, and monitoring probes. _draft-claise-energy-monitoring-mib_ 4. Power and Energy Monitoring MIB document The EMAN WG will develop a document defining managed objects for monitoring of power states and energy consumption/production. The monitoring of power states includes: retrieving power states, properties of power states, current power state, power state transitions, and power state statistics. The managed objects will provide means for reporting detailed properties of the actual energy rate (power) and of accumulated energy. Further, it will provide information on electrical power quality. Regards, Benoit. (as a contributor) > Hi, > > We have posted a new mib draft-parello-eman-energy-aware-mib-00 > > This mib represents a refactoring of > draft-claise-energy-monitoring-mib. Items pertaining to making a > device energy aware and providing context for the device are applied > now in draft-parello-eman-energy-aware-mib-00. > > In contrast draft-claise-energy-monitoring-mib now contains objects > pertaining to usage values. > > Both reference and/or fulfill the architect and requirements drafts: > > http://tools.ietf.org/id/draft-claise-power-management-arch-02.txt > http://tools.ietf.org/id/draft-quittek-power-monitoring-requirements-01.txt > > > You're feedback is welcome and greatly appreciated > > Thanks you > John > > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------090105030808090002020708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

So draft-claise-energy-monitoring-mib has been split into two drafts, in order to match the charter items.

draft-parello-eman-energy-aware-mib-00

3. Energy-aware Networks and Devices MIB document The EMAN WG will
develop a MIB module for monitoring energy-aware networks and devices.
The module will address devices identification, context information, and
potential relationship between reporting devices, remote devices, and
monitoring probes.

draft-claise-energy-monitoring-mib

4. Power and Energy Monitoring MIB document The EMAN WG will develop a
document defining managed objects for monitoring of power states and
energy consumption/production. The monitoring of power states includes:
retrieving power states, properties of power states, current power
state, power state transitions, and power state statistics.
The managed objects will provide means for reporting detailed properties
of the actual energy rate (power) and of accumulated energy. Further, it
will provide information on electrical power quality.

Regards, Benoit. (as a contributor)
Hi,

We have posted a new mib draft-parello-eman-energy-aware-mib-00

This mib represents a refactoring of draft-claise-energy-monitoring-mib. Items pertaining to making a device energy aware and providing context for the device are applied now in draft-parello-eman-energy-aware-mib-00.

In contrast draft-claise-energy-monitoring-mib now contains objects pertaining to usage values.

Both reference and/or fulfill the architect and requirements drafts:

http://tools.ietf.org/id/draft-claise-power-management-arch-02.txt
http://tools.ietf.org/id/draft-quittek-power-monitoring-requirements-01.txt

You're feedback is welcome and greatly appreciated

Thanks you
John





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

--------------090105030808090002020708-- From bclaise@cisco.com Mon Oct 25 23:21:13 2010 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 052613A6845 for ; Mon, 25 Oct 2010 23:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, 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 CBY+6b6bUx9E for ; Mon, 25 Oct 2010 23:21:12 -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 A85623A67FC for ; Mon, 25 Oct 2010 23:21:11 -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 o9Q6MvaP029583 for ; Tue, 26 Oct 2010 08:22:57 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9Q6MvHg012687 for ; Tue, 26 Oct 2010 08:22:57 +0200 (CEST) Message-ID: <4CC673C0.8020008@cisco.com> Date: Tue, 26 Oct 2010 08:22:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: eman@ietf.org Content-Type: multipart/alternative; boundary="------------090509090008000907050004" Subject: [eman] EMAN chartered items versus drafts X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 06:21:13 -0000 This is a multi-part message in MIME format. --------------090509090008000907050004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I went through the exercise of mapping the existing six chartered items with the existing draft content. _Energy Management Requirements_ http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-02 https://datatracker.ietf.org/doc/draft-norwin-energy-consider/ _ Energy Management Framework_ http://tools.ietf.org/html/draft-claise-power-management-arch-02 _Energy-aware Networks and Devices MIB_ http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00 http://tools.ietf.org/html/draft-quittek-power-mib-02 _Power and Energy Monitoring MIB_ http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 http://tools.ietf.org/html/draft-quittek-power-mib-02 _Battery MIB_ http://tools.ietf.org/html/draft-quittek-power-mib-02 _Energy Management Applicability_ http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-statement/ Please let me know if I made any mistakes or if I missed any draft? Regards, Benoit. --------------090509090008000907050004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I went through the exercise of mapping the existing six chartered items with the existing draft content.

Energy Management Requirements
http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-02
https://datatracker.ietf.org/doc/draft-norwin-energy-consider/

Energy Management Framework
http://tools.ietf.org/html/draft-claise-power-management-arch-02

Energy-aware Networks and Devices MIB
http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
http://tools.ietf.org/html/draft-quittek-power-mib-02

Power and Energy Monitoring MIB
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
http://tools.ietf.org/html/draft-quittek-power-mib-02

Battery MIB
http://tools.ietf.org/html/draft-quittek-power-mib-02

Energy Management Applicability
http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-statement/

Please let me know if I made any mistakes or if I missed any draft?

Regards, Benoit.
--------------090509090008000907050004-- From bnordman@lbl.gov Mon Oct 25 23:35:21 2010 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 4AE173A68B7 for ; Mon, 25 Oct 2010 23:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[AWL=-1.824, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 2J+o2jgT8+kn for ; Mon, 25 Oct 2010 23:35:20 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by core3.amsl.com (Postfix) with ESMTP id 44B153A67FC for ; Mon, 25 Oct 2010 23:35:19 -0700 (PDT) X-Ironport-SBRS: 4.4 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoBADgTxkzRVdg0kGdsb2JhbACTXgEBjWwIFQEBAQEJCQwHEQMfo2ubNoMNgjsEhFSFeQ X-IronPort-AV: E=Sophos;i="4.58,239,1286175600"; d="scan'208";a="27897582" Received: from mail-qw0-f52.google.com ([209.85.216.52]) by ironport4.lbl.gov with ESMTP; 25 Oct 2010 23:36:59 -0700 Received: by qwh5 with SMTP id 5so2235326qwh.39 for ; Mon, 25 Oct 2010 23:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.227.8 with SMTP id iy8mr3894183qcb.36.1288075018929; Mon, 25 Oct 2010 23:36:58 -0700 (PDT) Received: by 10.229.239.142 with HTTP; Mon, 25 Oct 2010 23:36:58 -0700 (PDT) Date: Mon, 25 Oct 2010 23:36:58 -0700 Message-ID: From: Bruce Nordman To: eman@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [eman] Updated Internet Draft - Energy Considerations - 01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 06:35:21 -0000 https://datatracker.ietf.org/doc/draft-norwin-energy-consider/ This -01 document updates the -00 version from July. The purpose of the document is to reflect conclusions and issues on our topic area from the primary perspective of energy, to balance out the network perspective from the other documents. It is to help clarify issues and drive decisions that could change the other drafts. The structure has been adjusted some, and some topics added. We plan on presenting key points from it in Beijing. --Bruce -- Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 From bclaise@cisco.com Tue Oct 26 00:06:20 2010 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 C1F6A3A6830 for ; Tue, 26 Oct 2010 00:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 hrhrzTDEO-pS for ; Tue, 26 Oct 2010 00:06:19 -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 8C4313A67F1 for ; Tue, 26 Oct 2010 00:06: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 o9Q6lGmW003313 for ; Tue, 26 Oct 2010 08:47:16 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9Q6lCjC005464 for ; Tue, 26 Oct 2010 08:47:15 +0200 (CEST) Message-ID: <4CC67970.20201@cisco.com> Date: Tue, 26 Oct 2010 08:47:12 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: eman@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] New version of the Power Management Architecture X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 07:06:21 -0000 Dear all, A new version of the Power Management Architecture has been posted. http://tools.ietf.org/html/draft-claise-power-management-arch-02 We took into account the feedback from the mailing list (Jinhyeock Choi, Chris Verges). Other changes include: - polished the terminology section, which is reused in different drafts. - clarified the notion of parent/child. For example "The Power Monitor Child may or may not draw power from its Power Monitor Parent" - Included an Energy Management Reference Model, where IPFIX is briefly discussed. - Clarifications on the Manufacturer Power Levels - There is a to do list at the beginning of the draft. - New Security Considerations section - Note that the text has been improved by a technical writer You're feedback is welcome Regards, Benoit (as an individual contributor) From Quittek@neclab.eu Tue Oct 26 00:50:10 2010 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 8A5243A68E6 for ; Tue, 26 Oct 2010 00:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=0.494, 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 Y7IhYK7pcBbe for ; Tue, 26 Oct 2010 00:50:08 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 224B43A68CF for ; Tue, 26 Oct 2010 00:50:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 9CA8A2C0001B2; Tue, 26 Oct 2010 09:51:54 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f65cvMqYiWb; Tue, 26 Oct 2010 09:51:54 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 7EFEA2C0001AD; Tue, 26 Oct 2010 09:51:44 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.19]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0255.000; Tue, 26 Oct 2010 09:51:44 +0200 From: Juergen Quittek To: Benoit Claise , eman mailing list Thread-Topic: [eman] EMAN chartered items versus drafts Thread-Index: AQHLdNZK+QjBWFAESUqmXvnzsvRBIpNS25UA Date: Tue, 26 Oct 2010 07:51:44 +0000 Message-ID: In-Reply-To: <4CC673C0.8020008@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.6.0.100712 x-originating-ip: [10.1.2.39] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3370931503_12830152" MIME-Version: 1.0 Subject: Re: [eman] EMAN chartered items versus drafts X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 07:50:10 -0000 --B_3370931503_12830152 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Benoit, Thanks for checking all drafts. I don't think that draft-quittek-power-mib-02 makes significant contributions to the Energy-aware Networks and Devices MIB. It just covers the Power and Energy Monitoring MIB and the Battery MIB. Thanks, Juergen On 26.10.10 08:22 "Benoit Claise" wrote: > Dear all, > > I went through the exercise of mapping the existing six chartered items > with the existing draft content. > > _Energy Management Requirements_ > http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-02 > https://datatracker.ietf.org/doc/draft-norwin-energy-consider/ > _ > Energy Management Framework_ > http://tools.ietf.org/html/draft-claise-power-management-arch-02 > > _Energy-aware Networks and Devices MIB_ > http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00 > http://tools.ietf.org/html/draft-quittek-power-mib-02 > > _Power and Energy Monitoring MIB_ > http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 > http://tools.ietf.org/html/draft-quittek-power-mib-02 > > _Battery MIB_ > http://tools.ietf.org/html/draft-quittek-power-mib-02 > > _Energy Management Applicability_ > http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-statement/ > > Please let me know if I made any mistakes or if I missed any draft? > > Regards, Benoit. > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --B_3370931503_12830152 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIWIQYJKoZIhvcNAQcCoIIWEjCCFg4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC E8kwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMIIFMzCCBBugAwIBAgIED+0edzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQxMTJaFw0xMzA0MTkxMjQx MTJaMGMxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsT F05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRgwFgYDVQQDEw9KdWVyZ2VuIFF1aXR0ZWswggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDYGuB3+Ykow4r2vPwU5WrZ1xZTlj36mb2O wFOm7QlChYmhsMrRWq+1wsEYIB3AnqHWGjGaA0UhBmPm0VA72sozbxU5IS9fRZs8YODD5kAP drXCG//iMpWQ+WJFZMPPP+s2+pPk/qPO+S5SwEe/X/IL5aGjzG8YgfCsELXZRgfTojdZN/uz YhEqVpsk/Flq1sOBe6nNFi12lrqr+v970aPoyUscjsHnxJ860aIwnjydmQ+JoDzELzBz6qHQ 4U7yAQbqWKALVud9NuFpy/zxx9+KUNGZnJc/Lv2KHJ3zBGKMiw1biSp0KMAxe+S1W5ypqV3w rHCnm0p3RaUgDT9k4iNnAgMBAAGjggG/MIIBuzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DAp BgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0OBBYEFPVl D8YxQQLSTl8Se2oKl6Mxw8vYMB8GA1UdIwQYMBaAFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MBwG A1UdEQQVMBOBEVF1aXR0ZWtAbmVjbGFiLmV1MH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j ZHAxLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDigNqA0hjJodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY3JsL2NhY3JsLmNybDCBmAYIKwYB BQUHAQEEgYswgYgwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvbmVjbGFi LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDIucGNh LmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUA A4IBAQB/VUWmfe/CzaHPnjP9pPzkGnzSZeFIyi44hJx/BQrqp7jV2TADnXH5zK0SitW5fhYQ st7I4ILLj+DWptqEsu0Q2FmIy2PzCjDzvzA/z6TUnuoKMePePMH41hpo+FM94KoA6L0BAth9 N43D13rSagU4qapn57zBaqM6Dec44hMybri6SzGDTzPhPuKUJy7UQITfeAtXvQu6D+um+2rO joFVQgqZROZZZ6CjOZ4LQBS+Rt8oJv62babXZmjYETuow19cPQDq7JkjxqfkvmETaJyhhKk6 JSabpRCQe6zHQFIprFKf6nc71q4SGegN34Mx8BYayB6lQZQy5ru3EB7v0DFBMYICIDCCAhwC AQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNV BAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNMQUItQ0ExMTAvBgkq hkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIuZXUCBA0uKwcwCQYF Kw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQiu3/P8xPzxf8Y8C34rGrMRpn1JDAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEwMjYwNzUxNDJaMA0GCSqG SIb3DQEBAQUABIIBAJbLIizJSGsTSyE4BvzazS7NhHvziK6UNA3jPfOE8r9SZO9GTPV+ONIz urXR3YPLM+SmckGGJ8GCHylf9A5/vAhX1KprdjSHN25U+XBQS77ih4D+gbwDVswVdObRxp2W pdzXTNC9LtAsCSiNultnNRlqmD8R+qOz0fm0UIorMPt0GMlZgmWQ5TuM3m7qwgqDPlAcmRB0 LZfcPo1ghZWI70n6InE/I9ScoFY1ZhtERsJ0+uYVOxRG84xx19cufeFHGPMNBZezRKEg0gbK Ksj0SwI4bYFKdBKBMitzVgsehJXWHh+lRnoCwKDqpdlPEU6+qgIINZMW/VnUKG6sZW/wSSU= --B_3370931503_12830152-- From bclaise@cisco.com Tue Oct 26 03:06:32 2010 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 DB07E3A67AC for ; Tue, 26 Oct 2010 03:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 hj2Xpa6ggnFg for ; Tue, 26 Oct 2010 03:06:31 -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 7F13F3A689F for ; Tue, 26 Oct 2010 03:06:31 -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 o9Q9iZq7003139; Tue, 26 Oct 2010 11:44:35 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9Q9iYK7024874; Tue, 26 Oct 2010 11:44:34 +0200 (CEST) Message-ID: <4CC6A302.3060106@cisco.com> Date: Tue, 26 Oct 2010 11:44:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] EMAN chartered items versus drafts X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 10:06:33 -0000 Hi Juergen, Thanks for the clarification. Something key is to agree on the Power Monitor index for all MIB modules, which IMHO should be part of the Energy-aware Networks and Devices MIB module, but reuse in the other MIB modules. Regards, Benoit. > Hi Benoit, > > Thanks for checking all drafts. > > I don't think that draft-quittek-power-mib-02 makes significant > contributions to the Energy-aware Networks and Devices MIB. > It just covers the Power and Energy Monitoring MIB and the Battery MIB. > > Thanks, > Juergen > > > On 26.10.10 08:22 "Benoit Claise" wrote: > >> Dear all, >> >> I went through the exercise of mapping the existing six chartered items >> with the existing draft content. >> >> _Energy Management Requirements_ >> http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-02 >> https://datatracker.ietf.org/doc/draft-norwin-energy-consider/ >> _ >> Energy Management Framework_ >> http://tools.ietf.org/html/draft-claise-power-management-arch-02 >> >> _Energy-aware Networks and Devices MIB_ >> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00 >> http://tools.ietf.org/html/draft-quittek-power-mib-02 >> >> _Power and Energy Monitoring MIB_ >> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 >> http://tools.ietf.org/html/draft-quittek-power-mib-02 >> >> _Battery MIB_ >> http://tools.ietf.org/html/draft-quittek-power-mib-02 >> >> _Energy Management Applicability_ >> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-statement/ >> >> Please let me know if I made any mistakes or if I missed any draft? >> >> Regards, Benoit. >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman From Quittek@neclab.eu Tue Oct 26 05:58:56 2010 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 5E6433A695A for ; Tue, 26 Oct 2010 05:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=0.472, 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 cIqfA2Fkti82 for ; Tue, 26 Oct 2010 05:58:55 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 99C433A67FB for ; Tue, 26 Oct 2010 05:58:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 985392C0001B2; Tue, 26 Oct 2010 15:00:41 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFZTIKGedsmL; Tue, 26 Oct 2010 15:00:41 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 72FB42C0001AD; Tue, 26 Oct 2010 15:00:31 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.19]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Tue, 26 Oct 2010 15:00:31 +0200 From: Juergen Quittek To: Benoit Claise , eman mailing list Thread-Topic: Entity identification method (was: [eman] EMAN chartered items versus drafts) Thread-Index: AQHLdQ3EaMG7aU2FN0SaNbGSJdLxoQ== Date: Tue, 26 Oct 2010 13:00:30 +0000 Message-ID: In-Reply-To: <4CC6A302.3060106@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.6.0.100712 x-originating-ip: [10.1.2.39] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3370950028_13961643" MIME-Version: 1.0 Subject: [eman] Entity identification method (was: EMAN chartered items versus drafts) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 12:58:56 -0000 --B_3370950028_13961643 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Benoit and all, I agree that we should find a common identification method for entities used by all MIB modules. This does not apply to the POWER MIB only, but to all MIB modules in the eman WG. The modules will use an entity ID as index for their tables. Which entity is identified by the index can be resolved by other MIB modules, such as the POWER AWARE MIB module (draft-parello-eman-energy-aware-mib) or the ENTITY MIB module (RFC 4133). I see three basic scenarios for the entity identification: a) a device just reports on its own power state and energy consumption and it reports on its own as a single unit. Then we have a single index only stating "it's me". Such a device usually does not need further identification of itself, because typically there are sufficient other MIB modules for this purpose running in the same SNMP engine, that provide information about the device's IP address, manufacturer, operating system, etc. In such a case a 'trivial' index, such as '0' should be used in order to keep it simple in this most simple case. b) a device reports on its own but not just as a single unit but it reports power states and energy consumption for its individual components, for example it may report separately on contained hard drives, line cards, back planes, processor boards, etc. In such a case, identification of these components as individual entities would be required. The ENTITY MIB module was designed for this purpose and would be a good choice here. Also the POWER AWARE MIB module would be useful in this case. c) a device reports on energy consumption of other, remote devices. Then remote devices (and potentially also their contained components need to be identified. For identifying remote components there is the POWER AWARE MIB module that has been designed for this purpose. As far as I understand, the ENTITY MIB module is not applicable to remote devices. In summary, - if you need to report on remote entities (case c)), you need the POWER AWARE MIB module, - if you report only on entities locally contained in the reporting device (case b)), you can use the POWER AWARE MIB or the ENTITY MIB - if you report just on your own as a single device (case a)), identification is trivial Hence, my recommendation (stated for POWER-STATE MIB and ENERGY MIB in draft-quittek-power-mib-02) would be: If there is an implementation of the POWER AWARE MIB module instantiated in the local SNMP engine, then you SHOULD (or MUST?) use it for indexing (pmIndex). If this is not the case but there is an ENTITY MIB instance available, then you SHOULD use this one (entPhysicalIndex). If neither of this MIB modules is available you should use index 0 only and be limited to report on the local device as a single entity only. That's just my view. Certainly, there are more ways of entity identification. I look forward to discussing them. Thanks, Juergen On 26.10.10 11:44 "Benoit Claise" wrote: > Hi Juergen, > > Thanks for the clarification. > > Something key is to agree on the Power Monitor index for all MIB > modules, which IMHO should be part of the Energy-aware Networks and > Devices MIB module, but reuse in the other MIB modules. > > Regards, Benoit. >> Hi Benoit, >> >> Thanks for checking all drafts. >> >> I don't think that draft-quittek-power-mib-02 makes significant >> contributions to the Energy-aware Networks and Devices MIB. >> It just covers the Power and Energy Monitoring MIB and the Battery MIB. >> >> Thanks, >> Juergen >> >> >> On 26.10.10 08:22 "Benoit Claise" wrote: >> >>> Dear all, >>> >>> I went through the exercise of mapping the existing six chartered items >>> with the existing draft content. >>> >>> _Energy Management Requirements_ >>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-02 >>> https://datatracker.ietf.org/doc/draft-norwin-energy-consider/ >>> _ >>> Energy Management Framework_ >>> http://tools.ietf.org/html/draft-claise-power-management-arch-02 >>> >>> _Energy-aware Networks and Devices MIB_ >>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00 >>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>> >>> _Power and Energy Monitoring MIB_ >>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 >>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>> >>> _Battery MIB_ >>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>> >>> _Energy Management Applicability_ >>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-statement/ >>> >>> Please let me know if I made any mistakes or if I missed any draft? >>> >>> Regards, Benoit. >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman > --B_3370950028_13961643 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ5wYJKoZIhvcNAQcCoIIQ2DCCENQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Do8wggUzMIIEG6ADAgECAgQP7R53MA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTEwMDQyMDEyNDExMloXDTEzMDQxOTEyNDExMlow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANga4Hf5iSjDiva8/BTlatnXFlOWPfqZvY7AU6bt CUKFiaGwytFar7XCwRggHcCeodYaMZoDRSEGY+bRUDvayjNvFTkhL19Fmzxg4MPmQA92tcIb /+IylZD5YkVkw88/6zb6k+T+o875LlLAR79f8gvloaPMbxiB8KwQtdlGB9OiN1k3+7NiESpW myT8WWrWw4F7qc0WLXaWuqv6/3vRo+jJSxyOwefEnzrRojCePJ2ZD4mgPMQvMHPqodDhTvIB BupYoAtW53024WnL/PHH34pQ0Zmclz8u/YocnfMEYoyLDVuJKnQowDF75LVbnKmpXfCscKeb SndFpSANP2TiI2cCAwEAAaOCAb8wggG7MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQU9WUPxjFB AtJOXxJ7agqXozHDy9gwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHAYDVR0R BBUwE4ERUXVpdHRla0BuZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEu cGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEFBQcB AQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2EuZGZu LmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEB AH9VRaZ978LNoc+eM/2k/OQafNJl4UjKLjiEnH8FCuqnuNXZMAOdcfnMrRKK1bl+FhCy3sjg gsuP4Nam2oSy7RDYWYjLY/MKMPO/MD/PpNSe6gox4948wfjWGmj4Uz3gqgDovQEC2H03jcPX etJqBTipqmfnvMFqozoN5zjiEzJuuLpLMYNPM+E+4pQnLtRAhN94C1e9C7oP66b7as6OgVVC CplE5llnoKM5ngtAFL5G3ygm/rZtptdmaNgRO6jDX1w9AOrsmSPGp+S+YRNonKGEqTolJpul EJB7rMdAUimsUp/qdzvWrhIZ6A3fgzHwFhrIHqVBlDLmu7cQHu/QMUEwggUvMIIEF6ADAgEC AgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg LSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMCREUx GDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBF dXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK6kKX nTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDBaSa+ nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i/W+u OQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMzVw94 Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQwggHA MBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAvmfa+ FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREEJjAk gSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3Js LmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIv Y3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEekP3l3 GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWclSZQ4 60jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yyPjzI VPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS09mE WRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkzJNfb fEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUA MHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4t VmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txP eKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVY J9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYw cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vydmlj ZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09U X0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu6 9VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0G CSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0Z MfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSF PT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0 hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBn qyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA 9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3Bl IEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNM QUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUCBA/tHncwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQspzd1RJ3tc/QEqykekv/N wYD5HzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEwMjYx MzAwMjhaMA0GCSqGSIb3DQEBAQUABIIBAISlWLkPK4WkfaNQX4GNvRchDfU81LoRz/moDoOE I6sjCrZHX2qoXdOlm/9XHVaHm6h3y4B76/hO1ixRV86T0soxVCrplaRb40vhpR0iGOaZoGgC 2Z9qm7Tft16o/ah7dzc37uzaXQPISw8su5tFIyxD6tny++DaOGiUtIkUkYeIF6vJKCGpnFEc Mb2cjez2c+8PMV8wrLQh4BgWnvWFDcIbVatI+c2nljCFXyOkz3ZhXLH2PCbcveal5jib0eZu K6IiftKqvVqrAV5pG0/6Vg1toUkYeovh/FiFvYG0mYFi9C/0jOF/lxgd6YuHGw5ftCRi1vop ivVwPpm53VOrmKA= --B_3370950028_13961643-- From chrisv@cyberswitching.com Tue Oct 26 21:25:23 2010 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 0658B3A67D3 for ; Tue, 26 Oct 2010 21:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=1.101, 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 842Dv5r7m3Tj for ; Tue, 26 Oct 2010 21:25:21 -0700 (PDT) Received: from p01c12o143.mxlogic.net (p01c12o143.mxlogic.net [208.65.145.66]) by core3.amsl.com (Postfix) with ESMTP id 609503A68F7 for ; Tue, 26 Oct 2010 21:25:19 -0700 (PDT) Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c12o143.mxlogic.net(mxl_mta-6.7.0-2) with ESMTP id b1aa7cc4.0.40336.00-387.87514.p01c12o143.mxlogic.net (envelope-from ); Tue, 26 Oct 2010 22:27:08 -0600 (MDT) X-MXL-Hash: 4cc7aa1c68e2b08a-d650279578ba27ef6ef3b6b347fc0440b4b261c0 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: Tue, 26 Oct 2010 21:26:23 -0700 Message-ID: <68FBE0F3CE97264395875AC1C468F22C51458F@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Entity identification method (was: [eman] EMAN chartered itemsversus drafts) Thread-Index: AQHLdQ3EaMG7aU2FN0SaNbGSJdLxoZNUMZ3w From: "Chris Verges" To: "Juergen Quittek" , "Benoit Claise" , "eman mailing list" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010073001)] X-MAIL-FROM: X-SOURCE-IP: [64.81.28.110] X-AnalysisOut: [v=1.0 c=1 a=yoRczeUaaFEA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=4zsJQXJisSY22NXBO5KRuA==:17 a=48vgC7mUAAAA:8 a=AUd] X-AnalysisOut: [_NHdVAAAA:8 a=wWiK3K99XxOIunNjeKkA:9 a=vp7R7wG640On32Plz04] X-AnalysisOut: [A:7 a=asm2B2BdWhdmrlZJVy7XZGxXQoIA:4 a=CjuIK1q_8ugA:10 a=l] X-AnalysisOut: [ZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=vwnA2wmh8-ckJ0cb:21 a=0] X-AnalysisOut: [ph1pWR_nyJYG2wI:21] Subject: Re: [eman] Entity identification method (was: EMAN chartered items versus drafts) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 04:25:23 -0000 Hi Juergen and all, Agreed that a common ID method makes sense, and ENTITY-MIB seems to be a good choice. In case (c) from your list, wouldn't the remote agent condition be handled by ENTITY-MIB supporting a logical entity that is the remote agent iself? Since the logical entity is in the ENTITY-MIB table, it would be given a unique ID mixed amongst the other logical and physical entities. At that point, should all of the MIBs being discussed in the EMAN WG be sparse table augmentations of ENTITY-MIB? Thanks, Chris -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Tuesday, October 26, 2010 6:01 AM To: Benoit Claise; eman mailing list Subject: [eman] Entity identification method (was: EMAN chartered items versus drafts) Hi Benoit and all, I agree that we should find a common identification method for entities used by all MIB modules. This does not apply to the POWER MIB only, but to all MIB modules in the eman WG. The modules will use an entity ID as index for their tables. Which entity is identified by the index can be resolved by other MIB modules, such as the POWER AWARE MIB module (draft-parello-eman-energy-aware-mib) or the ENTITY MIB module (RFC 4133). I see three basic scenarios for the entity identification: a) a device just reports on its own power state and energy consumption and it reports on its own as a single unit. Then we have a single index only stating "it's me". Such a device usually does not need further identification of itself, because typically there are sufficient other MIB modules for this purpose running in the same SNMP engine, that provide information about the device's IP address, manufacturer, operating system, etc. In such a case a 'trivial' index, such as '0' should be used in order to keep it simple in this most simple case. b) a device reports on its own but not just as a single unit but it reports power states and energy consumption for its individual components, for example it may report separately on contained hard drives, line cards, back planes, processor boards, etc. In such a case, identification of these components as individual entities would be required. The ENTITY MIB module was designed for this purpose and would be a good choice here. Also the POWER AWARE MIB module would be useful in this case. c) a device reports on energy consumption of other, remote devices. Then remote devices (and potentially also their contained components need to be identified. For identifying remote components there is the POWER AWARE MIB module that has been designed for this purpose. As far as I understand, the ENTITY MIB module is not applicable to remote devices. In summary, - if you need to report on remote entities (case c)), you need the POWER AWARE MIB module, - if you report only on entities locally contained in the reporting device (case b)), you can use the POWER AWARE MIB or the ENTITY MIB - if you report just on your own as a single device (case a)), identification is trivial Hence, my recommendation (stated for POWER-STATE MIB and ENERGY MIB in draft-quittek-power-mib-02) would be: If there is an implementation of the POWER AWARE MIB module instantiated in the local SNMP engine, then you SHOULD (or MUST?) use it for indexing (pmIndex). If this is not the case but there is an ENTITY MIB instance available, then you SHOULD use this one (entPhysicalIndex). If neither of this MIB modules is available you should use index 0 only and be limited to report on the local device as a single entity only. That's just my view. Certainly, there are more ways of entity identification. I look forward to discussing them. Thanks, Juergen =20 On 26.10.10 11:44 "Benoit Claise" wrote: > Hi Juergen, >=20 > Thanks for the clarification. >=20 > Something key is to agree on the Power Monitor index for all MIB=20 > modules, which IMHO should be part of the Energy-aware Networks and=20 > Devices MIB module, but reuse in the other MIB modules. >=20 > Regards, Benoit. >> Hi Benoit, >>=20 >> Thanks for checking all drafts. >>=20 >> I don't think that draft-quittek-power-mib-02 makes significant=20 >> contributions to the Energy-aware Networks and Devices MIB. >> It just covers the Power and Energy Monitoring MIB and the Battery MIB. >>=20 >> Thanks, >> Juergen >>=20 >>=20 >> On 26.10.10 08:22 "Benoit Claise" wrote: >>=20 >>> Dear all, >>>=20 >>> I went through the exercise of mapping the existing six chartered=20 >>> items with the existing draft content. >>>=20 >>> _Energy Management Requirements_ >>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requiremen >>> ts-02 https://datatracker.ietf.org/doc/draft-norwin-energy-consider/ >>> _ >>> Energy Management Framework_ >>> http://tools.ietf.org/html/draft-claise-power-management-arch-02 >>>=20 >>> _Energy-aware Networks and Devices MIB_ >>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00 >>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>>=20 >>> _Power and Energy Monitoring MIB_ >>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 >>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>>=20 >>> _Battery MIB_ >>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>>=20 >>> _Energy Management Applicability_ >>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-stat >>> ement/ >>>=20 >>> Please let me know if I made any mistakes or if I missed any draft? >>>=20 >>> Regards, Benoit. >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >=20 From bclaise@cisco.com Thu Oct 28 00:14:33 2010 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 7F8503A6875 for ; Thu, 28 Oct 2010 00:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 rjV+KbBq+n6d for ; Thu, 28 Oct 2010 00:14:31 -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 7A2DF3A6869 for ; Thu, 28 Oct 2010 00:14:31 -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 o9S7GM5P007329 for ; Thu, 28 Oct 2010 09:16:22 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9S7GKxm009487 for ; Thu, 28 Oct 2010 09:16:20 +0200 (CEST) Message-ID: <4CC92344.60602@cisco.com> Date: Thu, 28 Oct 2010 09:16:20 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: eman mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] Preliminary agenda - EMAN meeting X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 07:14:33 -0000 Dear all, We have uploaded a preliminary agenda for the EMAN meeting in Beijing - accessible at http://www.ietf.org/proceedings/79/agenda/eman.txt We have allocated the full 2h30 time across the drafts, mainly the one with open issues. We should resolve as many as possible during the meeting. Thanks and Regards, Bruce and Benoit From chrisv@cyberswitching.com Thu Oct 28 04:33:46 2010 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 856F23A67F6 for ; Thu, 28 Oct 2010 04:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.681 X-Spam-Level: X-Spam-Status: No, score=-5.681 tagged_above=-999 required=5 tests=[AWL=0.918, 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 THv-swqsDkL5 for ; Thu, 28 Oct 2010 04:33:41 -0700 (PDT) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) by core3.amsl.com (Postfix) with ESMTP id 39FA23A67EF for ; Thu, 28 Oct 2010 04:33:39 -0700 (PDT) Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c12o145.mxlogic.net(mxl_mta-6.7.0-2) with ESMTP id 10069cc4.0.94354.00-388.217034.p01c12o145.mxlogic.net (envelope-from ); Thu, 28 Oct 2010 05:35:31 -0600 (MDT) X-MXL-Hash: 4cc9600323e7ca9b-c701b3cadaed169fec1d57e73e9c426ab2473f0e X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Oct 2010 04:34:39 -0700 Message-ID: <68FBE0F3CE97264395875AC1C468F22C514657@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Entity identification method (was: [eman] EMAN chartereditemsversus drafts) Thread-Index: AQHLdQ3EaMG7aU2FN0SaNbGSJdLxoZNUMZ3wgAIDsVA= From: "Chris Verges" To: "Juergen Quittek" , "Benoit Claise" , "eman mailing list" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010073001)] X-MAIL-FROM: X-SOURCE-IP: [64.81.28.110] X-AnalysisOut: [v=1.0 c=1 a=gPx1rXISJPUA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=4zsJQXJisSY22NXBO5KRuA==:17 a=48vgC7mUAAAA:8 a=AUd] X-AnalysisOut: [_NHdVAAAA:8 a=yhEAkUgIS2BXHeENvPgA:9 a=_W6Xe9ZAQRsU1m3Ir7U] X-AnalysisOut: [A:7 a=Yh-WNSJjDl3R0Oo4xeuMSCVaZlIA:4 a=CjuIK1q_8ugA:10 a=l] X-AnalysisOut: [ZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=X7bfEhj96K-v7h_N:21 a=h] X-AnalysisOut: [pFeuZnnd_Ml4Iok:21] Subject: Re: [eman] Entity identification method (was: EMAN chartered itemsversus drafts) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 11:33:46 -0000 Hi Jurgen and all, The more I've been thinking about these scenarios, the more something doesn't seem quite right. I'll try to explain my thought process behind this and see if my concerns/confusions get captured. ENTITY-MIB provides enumerated lists of physical and logical entities on the system. The indices in both lists are maintained separately, so there is not a single, unique identifier provided. Because of this, the MIBs being discussed by the EMAN WG must only reference to one type (physical or logical) and are limited to that without additional work. At some point in my mind, I'm asking myself the question, "What's the point of linking to ENTITY-MIB?" More on that question in later scenarios below ... One possibility would be to create a separate mapping table that gives a guaranteed unique index based on all entities, regardless of type. The physical vs. logical extensions would then become sparse tables that augment this. For example: ENTITY-MIB : entityGeneral.entGeneralTable.entGeneralEntry +-----------------+-----------------+-----+ | entGeneralIndex | entGeneralDescr | ... | +-----------------+-----------------+-----+ | 1 | PDU Chassis | | +-----------------+-----------------+-----+ | 2 | Meter #1 | | +-----------------+-----------------+-----+ | 3 | Meter #2 | | +-----------------+-----------------+-----+ | 4 | Remote Meter #1 | | +-----------------+-----------------+-----+ ENTITY-MIB : entityPhysical.entPhysicalTable.entPhysicalEntry +-----------------+-----------------+-----+ | entGeneralIndex | entVendorType | ... | +-----------------+-----------------+-----+ | 1 | enterprises.foo | | +-----------------+-----------------+-----+ | 2 | enterprises.foo | | +-----------------+-----------------+-----+ | 3 | enterprises.foo | | +-----------------+-----------------+-----+ ENTITY-MIB : entityLogical.entLogicalTable.entLogicalEntry +-----------------+----------------------+-----+ | entGeneralIndex | entLogicalCommunity | ... | +-----------------+----------------------+-----+ | 4 | remote-power-group-1 | | +-----------------+----------------------+-----+ It seems like this 'entGeneralIndex' concept is what's missing from the current ENTITY-MIB, and is causing problems when thinking about local and remote power data being reported by the same agent. Another possibility would be to choose one -- entLogicalIndex, most likely -- and require that anyone who wants to implement the EMAN WG MIBs to always create an entLogicalEntry for the power data. In this context, the entLogicalTable fills the role of entGeneralTable as described above. For all entPhysicalTable entries, there would need to be a corresponding entry in entLogicalTable with a 1:1 mapping between them. For all remote entries, there would be a unique entry in entLogicalTable. Of course, this would add some additional overhead on the part of the implementer, but isn't too overburdening. A third possibility is that ENTITY-MIB just doesn't do what we need in its present form and we need to think about enumerating power sensors separately from other components/sensors on the system. It seems like entPhysicalTable gives a good starting template for a new 'POWER-ENTITY-MIB', but can be extended to include support for remote agents. The difference would be a clean break from the legacy ENTITY-MIB structure. And with that, I look forward to others' feedback and ideas on solving this problem! Thanks, Chris=20 -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Chris Verges Sent: Tuesday, October 26, 2010 9:26 PM To: Juergen Quittek; Benoit Claise; eman mailing list Subject: Re: [eman] Entity identification method (was: EMAN chartered itemsversus drafts) Hi Juergen and all, Agreed that a common ID method makes sense, and ENTITY-MIB seems to be a good choice. In case (c) from your list, wouldn't the remote agent condition be handled by ENTITY-MIB supporting a logical entity that is the remote agent iself? Since the logical entity is in the ENTITY-MIB table, it would be given a unique ID mixed amongst the other logical and physical entities. At that point, should all of the MIBs being discussed in the EMAN WG be sparse table augmentations of ENTITY-MIB? Thanks, Chris -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Tuesday, October 26, 2010 6:01 AM To: Benoit Claise; eman mailing list Subject: [eman] Entity identification method (was: EMAN chartered items versus drafts) Hi Benoit and all, I agree that we should find a common identification method for entities used by all MIB modules. This does not apply to the POWER MIB only, but to all MIB modules in the eman WG. The modules will use an entity ID as index for their tables. Which entity is identified by the index can be resolved by other MIB modules, such as the POWER AWARE MIB module (draft-parello-eman-energy-aware-mib) or the ENTITY MIB module (RFC 4133). I see three basic scenarios for the entity identification: a) a device just reports on its own power state and energy consumption and it reports on its own as a single unit. Then we have a single index only stating "it's me". Such a device usually does not need further identification of itself, because typically there are sufficient other MIB modules for this purpose running in the same SNMP engine, that provide information about the device's IP address, manufacturer, operating system, etc. In such a case a 'trivial' index, such as '0' should be used in order to keep it simple in this most simple case. b) a device reports on its own but not just as a single unit but it reports power states and energy consumption for its individual components, for example it may report separately on contained hard drives, line cards, back planes, processor boards, etc. In such a case, identification of these components as individual entities would be required. The ENTITY MIB module was designed for this purpose and would be a good choice here. Also the POWER AWARE MIB module would be useful in this case. c) a device reports on energy consumption of other, remote devices. Then remote devices (and potentially also their contained components need to be identified. For identifying remote components there is the POWER AWARE MIB module that has been designed for this purpose. As far as I understand, the ENTITY MIB module is not applicable to remote devices. In summary, - if you need to report on remote entities (case c)), you need the POWER AWARE MIB module, - if you report only on entities locally contained in the reporting device (case b)), you can use the POWER AWARE MIB or the ENTITY MIB - if you report just on your own as a single device (case a)), identification is trivial Hence, my recommendation (stated for POWER-STATE MIB and ENERGY MIB in draft-quittek-power-mib-02) would be: If there is an implementation of the POWER AWARE MIB module instantiated in the local SNMP engine, then you SHOULD (or MUST?) use it for indexing (pmIndex). If this is not the case but there is an ENTITY MIB instance available, then you SHOULD use this one (entPhysicalIndex). If neither of this MIB modules is available you should use index 0 only and be limited to report on the local device as a single entity only. That's just my view. Certainly, there are more ways of entity identification. I look forward to discussing them. Thanks, Juergen =20 On 26.10.10 11:44 "Benoit Claise" wrote: > Hi Juergen, >=20 > Thanks for the clarification. >=20 > Something key is to agree on the Power Monitor index for all MIB=20 > modules, which IMHO should be part of the Energy-aware Networks and=20 > Devices MIB module, but reuse in the other MIB modules. >=20 > Regards, Benoit. >> Hi Benoit, >>=20 >> Thanks for checking all drafts. >>=20 >> I don't think that draft-quittek-power-mib-02 makes significant=20 >> contributions to the Energy-aware Networks and Devices MIB. >> It just covers the Power and Energy Monitoring MIB and the Battery MIB. >>=20 >> Thanks, >> Juergen >>=20 >>=20 >> On 26.10.10 08:22 "Benoit Claise" wrote: >>=20 >>> Dear all, >>>=20 >>> I went through the exercise of mapping the existing six chartered=20 >>> items with the existing draft content. >>>=20 >>> _Energy Management Requirements_ >>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requiremen >>> ts-02 https://datatracker.ietf.org/doc/draft-norwin-energy-consider/ >>> _ >>> Energy Management Framework_ >>> http://tools.ietf.org/html/draft-claise-power-management-arch-02 >>>=20 >>> _Energy-aware Networks and Devices MIB_ >>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00 >>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>>=20 >>> _Power and Energy Monitoring MIB_ >>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 >>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>>=20 >>> _Battery MIB_ >>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>>=20 >>> _Energy Management Applicability_ >>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-stat >>> ement/ >>>=20 >>> Please let me know if I made any mistakes or if I missed any draft? >>>=20 >>> Regards, Benoit. >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman >=20 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Thu Oct 28 07:02:39 2010 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 9AB1B3A6866 for ; Thu, 28 Oct 2010 07:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 bDXqnf5xjS5G for ; Thu, 28 Oct 2010 07:02:38 -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 916C63A68A0 for ; Thu, 28 Oct 2010 07:02:37 -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 o9SE4S04009143; Thu, 28 Oct 2010 16:04:29 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9SE4SmE024205; Thu, 28 Oct 2010 16:04:28 +0200 (CEST) Message-ID: <4CC982EC.80803@cisco.com> Date: Thu, 28 Oct 2010 16:04:28 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000609070100000907080204" Cc: eman mailing list Subject: Re: [eman] Entity identification method X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the creation of an Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 14:02:39 -0000 This is a multi-part message in MIME format. --------------000609070100000907080204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Juergen, draft-parello-eman-energy-aware-mib has its own pmIndex index, but also pmPhysicalEntity (as a non index MIB object) if the ENTITY-MIB is supported. Isn't it the best of both worlds? If the ENTITY-MIB is not supported, the pmIndex does its job. If you need to report on the remote entities, the pmIndex does its job. If the ENTITY-NIB is supported, then the pmPhysicalEntity contains the pointer to the ENTITY-MIB Btw, the same principle has been applied for the Power Ethernet MIB [RFC3621] with pmEthPortIndex and pmEthPortGrpIndex PethPsePortGroupIndexOrZero. And again with the [LLDP-MIB ] and [LLDP-MED-MIB ] with pmLldpPortNumber See inline. > Hi Benoit and all, > > I agree that we should find a common identification method > for entities used by all MIB modules. This does not apply to > the POWER MIB only, but to all MIB modules in the eman WG. > The modules will use an entity ID as index for their tables. > Which entity is identified by the index can be resolved by > other MIB modules, such as the POWER AWARE MIB module > (draft-parello-eman-energy-aware-mib) or the ENTITY MIB > module (RFC 4133). > I see three basic scenarios for the entity identification: > > a) a device just reports on its own power state and energy > consumption and it reports on its own as a single unit. > > Then we have a single index only stating "it's me". > Such a device usually does not need further identification > of itself, because typically there are sufficient other > MIB modules for this purpose running in the same SNMP engine, > that provide information about the device's IP address, > manufacturer, operating system, etc. In such a case a > 'trivial' index, such as '0' should be used in order to > keep it simple in this most simple case. > > b) a device reports on its own but not just as a single unit > but it reports power states and energy consumption for its > individual components, for example it may report separately > on contained hard drives, line cards, back planes, > processor boards, etc. > > In such a case, identification of these components as > individual entities would be required. The ENTITY MIB > module was designed for this purpose and would be a good > choice here. Also the POWER AWARE MIB module would be > useful in this case. > > c) a device reports on energy consumption of other, remote > devices. Then remote devices (and potentially also their > contained components need to be identified. For > identifying remote components there is the POWER AWARE MIB > module that has been designed for this purpose. As far as > I understand, the ENTITY MIB module is not applicable to > remote devices. > > In summary, > - if you need to report on remote entities (case c)), > you need the POWER AWARE MIB module, > - if you report only on entities locally contained > in the reporting device (case b)), you can use > the POWER AWARE MIB or the ENTITY MIB > - if you report just on your own as a single device > (case a)), identification is trivial > > Hence, my recommendation (stated for POWER-STATE MIB and > ENERGY MIB in draft-quittek-power-mib-02) would be: > > If there is an implementation of the POWER AWARE MIB module > instantiated in the local SNMP engine, then you SHOULD > (or MUST?) use it for indexing (pmIndex). > If this is not the case but there is an ENTITY MIB instance > available, then you SHOULD use this one (entPhysicalIndex). > If neither of this MIB modules is available you should use > index 0 only and be limited to report on the local device > as a single entity only. Another problem that is linked: index persistence. If the persistence is required (to be discussed), and if you use the entPhysicalIndex as an index in these MIB module, basically you're asking for the ENTITY-MIB persistence. IMHO, another reason to have this level of indirection via the pmIndex -> pmPhysicalEntity Regards, Benoit (as a contributor) > That's just my view. Certainly, there are more ways of > entity identification. I look forward to discussing them. > > Thanks, > > Juergen > > > On 26.10.10 11:44 "Benoit Claise" wrote: > >> Hi Juergen, >> >> Thanks for the clarification. >> >> Something key is to agree on the Power Monitor index for all MIB >> modules, which IMHO should be part of the Energy-aware Networks and >> Devices MIB module, but reuse in the other MIB modules. >> >> Regards, Benoit. >>> Hi Benoit, >>> >>> Thanks for checking all drafts. >>> >>> I don't think that draft-quittek-power-mib-02 makes significant >>> contributions to the Energy-aware Networks and Devices MIB. >>> It just covers the Power and Energy Monitoring MIB and the Battery MIB. >>> >>> Thanks, >>> Juergen >>> >>> >>> On 26.10.10 08:22 "Benoit Claise" wrote: >>> >>>> Dear all, >>>> >>>> I went through the exercise of mapping the existing six chartered items >>>> with the existing draft content. >>>> >>>> _Energy Management Requirements_ >>>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-02 >>>> https://datatracker.ietf.org/doc/draft-norwin-energy-consider/ >>>> _ >>>> Energy Management Framework_ >>>> http://tools.ietf.org/html/draft-claise-power-management-arch-02 >>>> >>>> _Energy-aware Networks and Devices MIB_ >>>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00 >>>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>>> >>>> _Power and Energy Monitoring MIB_ >>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06 >>>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>>> >>>> _Battery MIB_ >>>> http://tools.ietf.org/html/draft-quittek-power-mib-02 >>>> >>>> _Energy Management Applicability_ >>>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-statement/ >>>> >>>> Please let me know if I made any mistakes or if I missed any draft? >>>> >>>> Regards, Benoit. >>>> _______________________________________________ >>>> eman mailing list >>>> eman@ietf.org >>>> https://www.ietf.org/mailman/listinfo/eman --------------000609070100000907080204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Juergen,

draft-parello-eman-energy-aware-mib has its own pmIndex index, but also pmPhysicalEntity (as a non index MIB object) if the ENTITY-MIB is supported.
Isn't it the best of both worlds?
If the ENTITY-MIB is not supported, the pmIndex does its job.
If you need to report on the remote entities, the pmIndex does its job.
If the ENTITY-NIB is supported, then the pmPhysicalEntity contains the pointer to the ENTITY-MIB

Btw, the same principle has been applied for the Power Ethernet MIB [RFC3621] with pmEthPortIndex and pmEthPortGrpIndex PethPsePortGroupIndexOrZero.
And again with the [LLDP-MIB] and [LLDP-MED-MIB] with pmLldpPortNumber

See inline.
Hi Benoit and all,

I agree that we should find a common identification method
for entities used by all MIB modules. This does not apply to
the POWER MIB only, but to all MIB modules in the eman WG.
The modules will use an entity ID as index for their tables.
Which entity is identified by the index can be resolved by
other MIB modules, such as the POWER AWARE MIB module
(draft-parello-eman-energy-aware-mib) or the ENTITY MIB
module (RFC 4133).

I see three basic scenarios for the entity identification:

  a) a device just reports on its own power state and energy
     consumption and it reports on its own as a single unit.

     Then we have a single index only stating "it's me".
     Such a device usually does not need further identification
     of itself, because typically there are sufficient other
     MIB modules for this purpose running in the same SNMP engine,
     that provide information about the device's IP address,
     manufacturer, operating system, etc. In such a case a
     'trivial' index, such as '0' should be used in order to
     keep it simple in this most simple case.

  b) a device reports on its own but not just as a single unit
     but it reports power states and energy consumption for its
     individual components, for example it may report separately
     on contained hard drives, line cards, back planes,
     processor boards, etc.

     In such a case, identification of these components as
     individual entities would be required. The ENTITY MIB
     module was designed for this purpose and would be a good
     choice here. Also the POWER AWARE MIB module would be
     useful in this case.

  c) a device reports on energy consumption of other, remote
     devices. Then remote devices (and potentially also their
     contained components need to be identified. For
     identifying remote components there is the POWER AWARE MIB
     module that has been designed for this purpose. As far as
     I understand, the ENTITY MIB module is not applicable to
     remote devices.

In summary, 
  - if you need to report on remote entities (case c)),
    you need the POWER AWARE MIB module,
  - if you report only on entities locally contained
    in the reporting device (case b)), you can use
    the POWER AWARE MIB or the ENTITY MIB
  - if you report just on your own as a single device
    (case a)), identification is trivial

Hence, my recommendation (stated for POWER-STATE MIB and
ENERGY MIB in draft-quittek-power-mib-02) would be:

If there is an implementation of the POWER AWARE MIB module
instantiated in the local SNMP engine, then you SHOULD
(or MUST?) use it for indexing (pmIndex).
If this is not the case but there is an ENTITY MIB instance
available, then you SHOULD use this one (entPhysicalIndex).
If neither of this MIB modules is available you should use
index 0 only and be limited to report on the local device
as a single entity only.
Another problem that is linked: index persistence.
If the persistence is required (to be discussed), and if you use the entPhysicalIndex as an index in these MIB module, basically you're asking for the ENTITY-MIB persistence.
IMHO, another reason to have this level of indirection via the pmIndex -> pmPhysicalEntity

Regards, Benoit (as a contributor)
That's just my view. Certainly, there are more ways of
entity identification. I look forward to discussing them.

Thanks,

    Juergen
 

On 26.10.10 11:44  "Benoit Claise" <bclaise@cisco.com> wrote:


Hi Juergen,

Thanks for the clarification.

Something key is to agree on the Power Monitor index for all MIB
modules, which IMHO should be part of the Energy-aware Networks and
Devices MIB module, but reuse in the other MIB modules.

Regards, Benoit.

Hi Benoit,

Thanks for checking all drafts.

I don't think that draft-quittek-power-mib-02 makes significant
contributions to the Energy-aware Networks and Devices MIB.
It just covers the Power and Energy Monitoring MIB and the Battery MIB.

Thanks,
     Juergen


On 26.10.10 08:22  "Benoit Claise"<bclaise@cisco.com>  wrote:


Dear all,

I went through the exercise of mapping the existing six chartered items
with the existing draft content.

_Energy Management Requirements_
http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-02
https://datatracker.ietf.org/doc/draft-norwin-energy-consider/
_
Energy Management Framework_
http://tools.ietf.org/html/draft-claise-power-management-arch-02

_Energy-aware Networks and Devices MIB_
http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
http://tools.ietf.org/html/draft-quittek-power-mib-02

_Power and Energy Monitoring MIB_
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
http://tools.ietf.org/html/draft-quittek-power-mib-02

_Battery MIB_
http://tools.ietf.org/html/draft-quittek-power-mib-02

_Energy Management Applicability_
http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-statement/

Please let me know if I made any mistakes or if I missed any draft?

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


      

    

    

  


--------------000609070100000907080204--

From Quittek@neclab.eu  Thu Oct 28 07:20:42 2010
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 34D423A6802 for ; Thu, 28 Oct 2010 07:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.973
X-Spam-Level: 
X-Spam-Status: No, score=-101.973 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 SF9h8VtyR1h4 for ; Thu, 28 Oct 2010 07:20:40 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id CEE8B3A6839 for ; Thu, 28 Oct 2010 07:20:39 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id ADCE128000180; Thu, 28 Oct 2010 16:22:31 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLRYffVtyoZ0; Thu, 28 Oct 2010 16:22:31 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8C53528000178; Thu, 28 Oct 2010 16:22:16 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.19]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0255.000; Thu, 28 Oct 2010 16:22:16 +0200
From: Juergen Quittek 
To: Chris Verges , Benoit Claise , eman mailing list 
Thread-Topic: [eman] Entity identification method (was: EMAN chartered itemsversus drafts)
Thread-Index: AQHLdQ3EaMG7aU2FN0SaNbGSJdLxoZNUMZ3wgAIDsVCAADecIA==
Date: Thu, 28 Oct 2010 14:22:15 +0000
Message-ID: 
In-Reply-To: <68FBE0F3CE97264395875AC1C468F22C514657@mail03.cyberswitching.local>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.7.0.100913
x-originating-ip: [10.1.2.39]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3371127732_20239242"
MIME-Version: 1.0
Subject: Re: [eman] Entity identification method (was: EMAN chartered itemsversus drafts)
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Oct 2010 14:20:42 -0000

--B_3371127732_20239242
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Chris,

I think it may become very difficult if we want to assess energy consumption
of logical entities. It seems to be reasonable and practical to limit energy
consumption measurements to physical entities. The ENERGY AWARE MIB module
(draft-parello-eman-energy-aware-mib) and the POWER MIB
(draft-quittek-power-mib-02) went this way.

Just using entPhysicalIndex solves some of the problem you mentioned.
Particularly, you don't need a mapping table to entities if you restrict
Yourself to entPhysicalIndex.

Thanks,

    Juergen

On 28.10.10 13:34  "Chris Verges"  wrote:

> Hi Jurgen and all,
> 
> The more I've been thinking about these scenarios, the more something
> doesn't seem quite right.  I'll try to explain my thought process behind
> this and see if my concerns/confusions get captured.
> 
> ENTITY-MIB provides enumerated lists of physical and logical entities on
> the system.  The indices in both lists are maintained separately, so
> there is not a single, unique identifier provided.  Because of this, the
> MIBs being discussed by the EMAN WG must only reference to one type
> (physical or logical) and are limited to that without additional work.
> At some point in my mind, I'm asking myself the question, "What's the
> point of linking to ENTITY-MIB?"
> 
> More on that question in later scenarios below ...
> 
> One possibility would be to create a separate mapping table that gives a
> guaranteed unique index based on all entities, regardless of type.  The
> physical vs. logical extensions would then become sparse tables that
> augment this.  For example:
> 
>   ENTITY-MIB : entityGeneral.entGeneralTable.entGeneralEntry
>   +-----------------+-----------------+-----+
>   | entGeneralIndex | entGeneralDescr | ... |
>   +-----------------+-----------------+-----+
>   |        1        | PDU Chassis     |     |
>   +-----------------+-----------------+-----+
>   |        2        | Meter #1        |     |
>   +-----------------+-----------------+-----+
>   |        3        | Meter #2        |     |
>   +-----------------+-----------------+-----+
>   |        4        | Remote Meter #1 |     |
>   +-----------------+-----------------+-----+
> 
>   ENTITY-MIB : entityPhysical.entPhysicalTable.entPhysicalEntry
>   +-----------------+-----------------+-----+
>   | entGeneralIndex | entVendorType   | ... |
>   +-----------------+-----------------+-----+
>   |        1        | enterprises.foo |     |
>   +-----------------+-----------------+-----+
>   |        2        | enterprises.foo |     |
>   +-----------------+-----------------+-----+
>   |        3        | enterprises.foo |     |
>   +-----------------+-----------------+-----+
> 
>   ENTITY-MIB : entityLogical.entLogicalTable.entLogicalEntry
>   +-----------------+----------------------+-----+
>   | entGeneralIndex | entLogicalCommunity  | ... |
>   +-----------------+----------------------+-----+
>   |        4        | remote-power-group-1 |     |
>   +-----------------+----------------------+-----+
> 
> It seems like this 'entGeneralIndex' concept is what's missing from the
> current ENTITY-MIB, and is causing problems when thinking about local
> and remote power data being reported by the same agent.
> 
> Another possibility would be to choose one -- entLogicalIndex, most
> likely -- and require that anyone who wants to implement the EMAN WG
> MIBs to always create an entLogicalEntry for the power data.  In this
> context, the entLogicalTable fills the role of entGeneralTable as
> described above.  For all entPhysicalTable entries, there would need to
> be a corresponding entry in entLogicalTable with a 1:1 mapping between
> them.  For all remote entries, there would be a unique entry in
> entLogicalTable.  Of course, this would add some additional overhead on
> the part of the implementer, but isn't too overburdening.
> 
> A third possibility is that ENTITY-MIB just doesn't do what we need in
> its present form and we need to think about enumerating power sensors
> separately from other components/sensors on the system.  It seems like
> entPhysicalTable gives a good starting template for a new
> 'POWER-ENTITY-MIB', but can be extended to include support for remote
> agents.  The difference would be a clean break from the legacy
> ENTITY-MIB structure.
> 
> And with that, I look forward to others' feedback and ideas on solving
> this problem!
> 
> Thanks,
> Chris 
> 
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Chris Verges
> Sent: Tuesday, October 26, 2010 9:26 PM
> To: Juergen Quittek; Benoit Claise; eman mailing list
> Subject: Re: [eman] Entity identification method (was: EMAN chartered
> itemsversus drafts)
> 
> Hi Juergen and all,
> 
> Agreed that a common ID method makes sense, and ENTITY-MIB seems to be a
> good choice.  In case (c) from your list, wouldn't the remote agent
> condition be handled by ENTITY-MIB supporting a logical entity that is
> the remote agent iself?  Since the logical entity is in the ENTITY-MIB
> table, it would be given a unique ID mixed amongst the other logical and
> physical entities.
> 
> At that point, should all of the MIBs being discussed in the EMAN WG be
> sparse table augmentations of ENTITY-MIB?
> 
> Thanks,
> Chris
> 
> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Tuesday, October 26, 2010 6:01 AM
> To: Benoit Claise; eman mailing list
> Subject: [eman] Entity identification method (was: EMAN chartered items
> versus drafts)
> 
> Hi Benoit and all,
> 
> I agree that we should find a common identification method for entities
> used by all MIB modules. This does not apply to the POWER MIB only, but
> to all MIB modules in the eman WG.
> The modules will use an entity ID as index for their tables.
> Which entity is identified by the index can be resolved by other MIB
> modules, such as the POWER AWARE MIB module
> (draft-parello-eman-energy-aware-mib) or the ENTITY MIB module (RFC
> 4133).
> 
> I see three basic scenarios for the entity identification:
> 
>   a) a device just reports on its own power state and energy
>      consumption and it reports on its own as a single unit.
> 
>      Then we have a single index only stating "it's me".
>      Such a device usually does not need further identification
>      of itself, because typically there are sufficient other
>      MIB modules for this purpose running in the same SNMP engine,
>      that provide information about the device's IP address,
>      manufacturer, operating system, etc. In such a case a
>      'trivial' index, such as '0' should be used in order to
>      keep it simple in this most simple case.
> 
>   b) a device reports on its own but not just as a single unit
>      but it reports power states and energy consumption for its
>      individual components, for example it may report separately
>      on contained hard drives, line cards, back planes,
>      processor boards, etc.
> 
>      In such a case, identification of these components as
>      individual entities would be required. The ENTITY MIB
>      module was designed for this purpose and would be a good
>      choice here. Also the POWER AWARE MIB module would be
>      useful in this case.
> 
>   c) a device reports on energy consumption of other, remote
>      devices. Then remote devices (and potentially also their
>      contained components need to be identified. For
>      identifying remote components there is the POWER AWARE MIB
>      module that has been designed for this purpose. As far as
>      I understand, the ENTITY MIB module is not applicable to
>      remote devices.
> 
> In summary,
>   - if you need to report on remote entities (case c)),
>     you need the POWER AWARE MIB module,
>   - if you report only on entities locally contained
>     in the reporting device (case b)), you can use
>     the POWER AWARE MIB or the ENTITY MIB
>   - if you report just on your own as a single device
>     (case a)), identification is trivial
> 
> Hence, my recommendation (stated for POWER-STATE MIB and ENERGY MIB in
> draft-quittek-power-mib-02) would be:
> 
> If there is an implementation of the POWER AWARE MIB module instantiated
> in the local SNMP engine, then you SHOULD (or MUST?) use it for indexing
> (pmIndex).
> If this is not the case but there is an ENTITY MIB instance available,
> then you SHOULD use this one (entPhysicalIndex).
> If neither of this MIB modules is available you should use index 0 only
> and be limited to report on the local device as a single entity only.
> 
> That's just my view. Certainly, there are more ways of entity
> identification. I look forward to discussing them.
> 
> Thanks,
> 
>     Juergen
>  
> 
> On 26.10.10 11:44  "Benoit Claise"  wrote:
> 
>> Hi Juergen,
>> 
>> Thanks for the clarification.
>> 
>> Something key is to agree on the Power Monitor index for all MIB
>> modules, which IMHO should be part of the Energy-aware Networks and
>> Devices MIB module, but reuse in the other MIB modules.
>> 
>> Regards, Benoit.
>>> Hi Benoit,
>>> 
>>> Thanks for checking all drafts.
>>> 
>>> I don't think that draft-quittek-power-mib-02 makes significant
>>> contributions to the Energy-aware Networks and Devices MIB.
>>> It just covers the Power and Energy Monitoring MIB and the Battery
> MIB.
>>> 
>>> Thanks,
>>>      Juergen
>>> 
>>> 
>>> On 26.10.10 08:22  "Benoit Claise"  wrote:
>>> 
>>>> Dear all,
>>>> 
>>>> I went through the exercise of mapping the existing six chartered
>>>> items with the existing draft content.
>>>> 
>>>> _Energy Management Requirements_
>>>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requiremen
>>>> ts-02 https://datatracker.ietf.org/doc/draft-norwin-energy-consider/
>>>> _
>>>> Energy Management Framework_
>>>> http://tools.ietf.org/html/draft-claise-power-management-arch-02
>>>> 
>>>> _Energy-aware Networks and Devices MIB_
>>>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>> 
>>>> _Power and Energy Monitoring MIB_
>>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>> 
>>>> _Battery MIB_
>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>> 
>>>> _Energy Management Applicability_
>>>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-stat
>>>> ement/
>>>> 
>>>> Please let me know if I made any mistakes or if I missed any draft?
>>>> 
>>>> Regards, Benoit.
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>> 
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

-- 
Juergen Quittek            quittek@neclab.eu      Tel: +49 6221 4342-115
General Manager            http://www.neclab.eu   Fax: +49 6221 4342-155
NEC Europe Ltd., Network Laboratories Europe
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014

--B_3371127732_20239242
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIQ5wYJKoZIhvcNAQcCoIIQ2DCCENQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Do8wggUzMIIEG6ADAgECAgQP7R53MA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY
MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1
cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu
Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTEwMDQyMDEyNDExMloXDTEzMDQxOTEyNDExMlow
YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD
IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANga4Hf5iSjDiva8/BTlatnXFlOWPfqZvY7AU6bt
CUKFiaGwytFar7XCwRggHcCeodYaMZoDRSEGY+bRUDvayjNvFTkhL19Fmzxg4MPmQA92tcIb
/+IylZD5YkVkw88/6zb6k+T+o875LlLAR79f8gvloaPMbxiB8KwQtdlGB9OiN1k3+7NiESpW
myT8WWrWw4F7qc0WLXaWuqv6/3vRo+jJSxyOwefEnzrRojCePJ2ZD4mgPMQvMHPqodDhTvIB
BupYoAtW53024WnL/PHH34pQ0Zmclz8u/YocnfMEYoyLDVuJKnQowDF75LVbnKmpXfCscKeb
SndFpSANP2TiI2cCAwEAAaOCAb8wggG7MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud
JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQU9WUPxjFB
AtJOXxJ7agqXozHDy9gwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHAYDVR0R
BBUwE4ERUXVpdHRla0BuZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEu
cGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9j
ZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEFBQcB
AQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEB
AH9VRaZ978LNoc+eM/2k/OQafNJl4UjKLjiEnH8FCuqnuNXZMAOdcfnMrRKK1bl+FhCy3sjg
gsuP4Nam2oSy7RDYWYjLY/MKMPO/MD/PpNSe6gox4948wfjWGmj4Uz3gqgDovQEC2H03jcPX
etJqBTipqmfnvMFqozoN5zjiEzJuuLpLMYNPM+E+4pQnLtRAhN94C1e9C7oP66b7as6OgVVC
CplE5llnoKM5ngtAFL5G3ygm/rZtptdmaNgRO6jDX1w9AOrsmSPGp+S+YRNonKGEqTolJpul
EJB7rMdAUimsUp/qdzvWrhIZ6A3fgzHwFhrIHqVBlDLmu7cQHu/QMUEwggUvMIIEF6ADAgEC
AgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy
ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg
LSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMCREUx
GDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBF
dXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK6kKX
nTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDBaSa+
nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i/W+u
OQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMzVw94
Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQwggHA
MBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAvmfa+
FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREEJjAk
gSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9oDug
OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3Js
LmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIv
Y3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j
ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG
CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j
YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEekP3l3
GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWclSZQ4
60jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yyPjzI
VPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS09mE
WRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkzJNfb
fEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUA
MHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL
ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv
b3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4t
VmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0
iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txP
eKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVY
J9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV
Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYw
cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vydmlj
ZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09U
X0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu6
9VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0G
CSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0Z
MfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSF
PT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0
hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBn
qyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA
9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3Bl
IEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNM
QUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu
ZXUCBA/tHncwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTPBkZtKz+Cpovp4IQSGWCY
Z0rk3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEwMjgx
NDIyMTJaMA0GCSqGSIb3DQEBAQUABIIBAGD9dntSkR9yvCdA8hesiXqRMav7w83gufSaVXsG
uOjVoKk9vh5Pfvrw4GtYivuqhIzDfEobJEQlq1+5+9XEgGk2GmqMbHgBXWUSAxYEEErWziPv
m5Ej6BbYVn/abl5Ub9BscaMJHosc4crTSQdHaYLOPYkmFlmwvajJMuU5hVs38E8dF/7z28G4
adDvSZrDgcwPPVnu0a2qHnruvxl92ucQCGVQ9iDhYVoGgyszLIG4qUgluxjZ9HC1xywkELYm
MQLeTKdUbCSma2rC7DmY7xmWCfWUH6tDOad5pNHi4CG/LhGUu7g9ula+y2FA+y0BQxL1FQFL
Y6+6beFRtATPBH4=

--B_3371127732_20239242--

From Quittek@neclab.eu  Thu Oct 28 08:24:10 2010
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 2AECE3A6855 for ; Thu, 28 Oct 2010 08:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.009
X-Spam-Level: 
X-Spam-Status: No, score=-101.009 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, MANGLED_MEDS=2.3, 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 33RuvBP1slyE for ; Thu, 28 Oct 2010 08:24:07 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 74D8E3A677C for ; Thu, 28 Oct 2010 08:24:07 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 680742C0001B0; Thu, 28 Oct 2010 17:25:59 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8wszAofqKD8; Thu, 28 Oct 2010 17:25:59 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 3504D2C0001B2; Thu, 28 Oct 2010 17:25:49 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.19]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0255.000; Thu, 28 Oct 2010 17:25:49 +0200
From: Juergen Quittek 
To: Benoit Claise 
Thread-Topic: Entity identification method
Thread-Index: AQHLdqkPzhRnSz7auE2VMOFT88Los5NWe3WA
Date: Thu, 28 Oct 2010 15:25:48 +0000
Message-ID: 
In-Reply-To: <4CC982EC.80803@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.7.0.100913
x-originating-ip: [10.1.2.39]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3371131545_20451962"
MIME-Version: 1.0
Cc: eman mailing list 
Subject: Re: [eman] Entity identification method
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Oct 2010 15:24:10 -0000

--B_3371131545_20451962
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Benoit,

That's why I recommend that whenever you have an implementation of the
ENERGY AWARE MIB available in your local SNMP engine you should use the
ENERGY AWARE MIB for indexing. It serves all purposes and it can use the
ENTITY MIB if this is also available.

Thanks,

    Juergen

On 28.10.10 16:04  "Benoit Claise"  wrote:

> Hi Juergen,
> 
> draft-parello-eman-energy-aware-mib has its own pmIndex index, but also
> pmPhysicalEntity (as a non index MIB object) if the ENTITY-MIB is supported.
> Isn't it the best of both worlds?
> If the ENTITY-MIB is not supported, the pmIndex does its job.
> If you need to report on the remote entities, the pmIndex does its job.
> If the ENTITY-NIB is supported, then the pmPhysicalEntity contains the
> pointer to the ENTITY-MIB
> 
> Btw, the same principle has been applied for the Power Ethernet MIB
> [RFC3621] with pmEthPortIndex and pmEthPortGrpIndex
> PethPsePortGroupIndexOrZero.
> And again with the [LLDP-MIB
>  B>] 
> and [LLDP-MED-MIB
>  D-MIB>] 
> with pmLldpPortNumber
> 
> See inline.
>> Hi Benoit and all,
>> 
>> I agree that we should find a common identification method
>> for entities used by all MIB modules. This does not apply to
>> the POWER MIB only, but to all MIB modules in the eman WG.
>> The modules will use an entity ID as index for their tables.
>> Which entity is identified by the index can be resolved by
>> other MIB modules, such as the POWER AWARE MIB module
>> (draft-parello-eman-energy-aware-mib) or the ENTITY MIB
>> module (RFC 4133).
>> I see three basic scenarios for the entity identification:
>> 
>>    a) a device just reports on its own power state and energy
>>       consumption and it reports on its own as a single unit.
>> 
>>       Then we have a single index only stating "it's me".
>>       Such a device usually does not need further identification
>>       of itself, because typically there are sufficient other
>>       MIB modules for this purpose running in the same SNMP engine,
>>       that provide information about the device's IP address,
>>       manufacturer, operating system, etc. In such a case a
>>       'trivial' index, such as '0' should be used in order to
>>       keep it simple in this most simple case.
>> 
>>    b) a device reports on its own but not just as a single unit
>>       but it reports power states and energy consumption for its
>>       individual components, for example it may report separately
>>       on contained hard drives, line cards, back planes,
>>       processor boards, etc.
>> 
>>       In such a case, identification of these components as
>>       individual entities would be required. The ENTITY MIB
>>       module was designed for this purpose and would be a good
>>       choice here. Also the POWER AWARE MIB module would be
>>       useful in this case.
>> 
>>    c) a device reports on energy consumption of other, remote
>>       devices. Then remote devices (and potentially also their
>>       contained components need to be identified. For
>>       identifying remote components there is the POWER AWARE MIB
>>       module that has been designed for this purpose. As far as
>>       I understand, the ENTITY MIB module is not applicable to
>>       remote devices.
>> 
>> In summary,
>>    - if you need to report on remote entities (case c)),
>>      you need the POWER AWARE MIB module,
>>    - if you report only on entities locally contained
>>      in the reporting device (case b)), you can use
>>      the POWER AWARE MIB or the ENTITY MIB
>>    - if you report just on your own as a single device
>>      (case a)), identification is trivial
>> 
>> Hence, my recommendation (stated for POWER-STATE MIB and
>> ENERGY MIB in draft-quittek-power-mib-02) would be:
>> 
>> If there is an implementation of the POWER AWARE MIB module
>> instantiated in the local SNMP engine, then you SHOULD
>> (or MUST?) use it for indexing (pmIndex).
>> If this is not the case but there is an ENTITY MIB instance
>> available, then you SHOULD use this one (entPhysicalIndex).
>> If neither of this MIB modules is available you should use
>> index 0 only and be limited to report on the local device
>> as a single entity only.
> Another problem that is linked: index persistence.
> If the persistence is required (to be discussed), and if you use the
> entPhysicalIndex as an index in these MIB module, basically you're
> asking for the ENTITY-MIB persistence.
> IMHO, another reason to have this level of indirection via the pmIndex
> -> pmPhysicalEntity
> 
> Regards, Benoit (as a contributor)
>> That's just my view. Certainly, there are more ways of
>> entity identification. I look forward to discussing them.
>> 
>> Thanks,
>> 
>>      Juergen
>> 
>> 
>> On 26.10.10 11:44  "Benoit Claise"  wrote:
>> 
>>> Hi Juergen,
>>> 
>>> Thanks for the clarification.
>>> 
>>> Something key is to agree on the Power Monitor index for all MIB
>>> modules, which IMHO should be part of the Energy-aware Networks and
>>> Devices MIB module, but reuse in the other MIB modules.
>>> 
>>> Regards, Benoit.
>>>> Hi Benoit,
>>>> 
>>>> Thanks for checking all drafts.
>>>> 
>>>> I don't think that draft-quittek-power-mib-02 makes significant
>>>> contributions to the Energy-aware Networks and Devices MIB.
>>>> It just covers the Power and Energy Monitoring MIB and the Battery MIB.
>>>> 
>>>> Thanks,
>>>>       Juergen
>>>> 
>>>> 
>>>> On 26.10.10 08:22  "Benoit Claise"   wrote:
>>>> 
>>>>> Dear all,
>>>>> 
>>>>> I went through the exercise of mapping the existing six chartered items
>>>>> with the existing draft content.
>>>>> 
>>>>> _Energy Management Requirements_
>>>>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-02
>>>>> https://datatracker.ietf.org/doc/draft-norwin-energy-consider/
>>>>> _
>>>>> Energy Management Framework_
>>>>> http://tools.ietf.org/html/draft-claise-power-management-arch-02
>>>>> 
>>>>> _Energy-aware Networks and Devices MIB_
>>>>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>> 
>>>>> _Power and Energy Monitoring MIB_
>>>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>> 
>>>>> _Battery MIB_
>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>> 
>>>>> _Energy Management Applicability_
>>>>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-statement/
>>>>> 
>>>>> Please let me know if I made any mistakes or if I missed any draft?
>>>>> 
>>>>> Regards, Benoit.
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
> 

-- 
Juergen Quittek            quittek@neclab.eu      Tel: +49 6221 4342-115
General Manager            http://www.neclab.eu   Fax: +49 6221 4342-155
NEC Europe Ltd., Network Laboratories Europe
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014

--B_3371131545_20451962
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIQ5wYJKoZIhvcNAQcCoIIQ2DCCENQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Do8wggUzMIIEG6ADAgECAgQP7R53MA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY
MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1
cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu
Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTEwMDQyMDEyNDExMloXDTEzMDQxOTEyNDExMlow
YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD
IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANga4Hf5iSjDiva8/BTlatnXFlOWPfqZvY7AU6bt
CUKFiaGwytFar7XCwRggHcCeodYaMZoDRSEGY+bRUDvayjNvFTkhL19Fmzxg4MPmQA92tcIb
/+IylZD5YkVkw88/6zb6k+T+o875LlLAR79f8gvloaPMbxiB8KwQtdlGB9OiN1k3+7NiESpW
myT8WWrWw4F7qc0WLXaWuqv6/3vRo+jJSxyOwefEnzrRojCePJ2ZD4mgPMQvMHPqodDhTvIB
BupYoAtW53024WnL/PHH34pQ0Zmclz8u/YocnfMEYoyLDVuJKnQowDF75LVbnKmpXfCscKeb
SndFpSANP2TiI2cCAwEAAaOCAb8wggG7MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud
JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQU9WUPxjFB
AtJOXxJ7agqXozHDy9gwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHAYDVR0R
BBUwE4ERUXVpdHRla0BuZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEu
cGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9j
ZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEFBQcB
AQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEB
AH9VRaZ978LNoc+eM/2k/OQafNJl4UjKLjiEnH8FCuqnuNXZMAOdcfnMrRKK1bl+FhCy3sjg
gsuP4Nam2oSy7RDYWYjLY/MKMPO/MD/PpNSe6gox4948wfjWGmj4Uz3gqgDovQEC2H03jcPX
etJqBTipqmfnvMFqozoN5zjiEzJuuLpLMYNPM+E+4pQnLtRAhN94C1e9C7oP66b7as6OgVVC
CplE5llnoKM5ngtAFL5G3ygm/rZtptdmaNgRO6jDX1w9AOrsmSPGp+S+YRNonKGEqTolJpul
EJB7rMdAUimsUp/qdzvWrhIZ6A3fgzHwFhrIHqVBlDLmu7cQHu/QMUEwggUvMIIEF6ADAgEC
AgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy
ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg
LSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMCREUx
GDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBF
dXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK6kKX
nTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDBaSa+
nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i/W+u
OQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMzVw94
Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQwggHA
MBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAvmfa+
FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREEJjAk
gSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9oDug
OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3Js
LmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIv
Y3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j
ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG
CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j
YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEekP3l3
GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWclSZQ4
60jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yyPjzI
VPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS09mE
WRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkzJNfb
fEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUA
MHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL
ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv
b3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4t
VmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0
iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txP
eKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVY
J9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV
Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYw
cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vydmlj
ZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09U
X0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu6
9VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0G
CSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0Z
MfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSF
PT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0
hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBn
qyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA
9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3Bl
IEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNM
QUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu
ZXUCBA/tHncwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBS4WmQTw3hY0dd4YiZEDVVL
5pU8KzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEwMjgx
NTI1NDVaMA0GCSqGSIb3DQEBAQUABIIBACFfXa4cdr97BMIeLbjQOUuuhqYE8802PXV3APsc
NtrZDHcyp7SMtDJ/56O3Ec7J/EntqgEiDDIavvql16LkbjROmqWdEIUHgqjpPwlJ8qrHK+pz
7zYAXHWOidMT+d+rcS6PrCzcxqZvo9prmg6Nz8QuMd4ZUD7OlmV/XA9mzcv0/+a0BywwupZL
lBtWd1lqnfXTarBY82Rxx//Qc6jRMVqhYRmZw2e8+e2vfJHOFQpBMpVeS4xxocZVp16/lC/5
xjjSMaQ2V6XAGwu66PwolBZbR0oEc2h/NAJUTv4pCm6weDgimPOV4/K5+UIcF4q5GlynKQI6
wbJchgWNVXl0BIM=

--B_3371131545_20451962--

From chrisv@cyberswitching.com  Thu Oct 28 16:33:32 2010
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 ED1263A681E for ; Thu, 28 Oct 2010 16:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.812
X-Spam-Level: 
X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.786,  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 8U4X8cDTlr2E for ; Thu, 28 Oct 2010 16:33:23 -0700 (PDT)
Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by core3.amsl.com (Postfix) with ESMTP id AAC863A6801 for ; Thu, 28 Oct 2010 16:33:21 -0700 (PDT)
Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c12o142.mxlogic.net(mxl_mta-6.7.0-2) with ESMTP id 2b80acc4.0.31981.00-357.81440.p01c12o142.mxlogic.net (envelope-from );  Thu, 28 Oct 2010 17:35:15 -0600 (MDT)
X-MXL-Hash: 4cca08b337fc6229-6a0e6087bfc0d74c2745809fdf1f109edbc855dc
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_01CB76F8.A5856FD3"
Date: Thu, 28 Oct 2010 16:34:20 -0700
Message-ID: <68FBE0F3CE97264395875AC1C468F22C5146E3@mail03.cyberswitching.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: EMAN MIB reviews and development process understanding
Thread-Index: Act2+JTb8us1t2UNQsyiaJAWx0mIFQ==
From: "Chris Verges" 
To: 
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010073001)]
X-MAIL-FROM: 
X-SOURCE-IP: [64.81.28.110]
X-AnalysisOut: [v=1.0 c=1 a=TQHtl1TkdFwA:10 a=BLceEmwcHowA:10 a=4zsJQXJisS]
X-AnalysisOut: [Y22NXBO5KRuA==:17 a=QRcOdkru5iCViBY3tSwA:9 a=RMOmo7aHrwEMf]
X-AnalysisOut: [KUVvLsA:7 a=FJPqL-Xn7Z6LpykHRrizWhr4buAA:4 a=CjuIK1q_8ugA:]
X-AnalysisOut: [10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=iYMzcHXBF6X6WS82NvU]
X-AnalysisOut: [A:9 a=1qjbeMc3JJ_1F8bUU2gA:7 a=16D1qZNAU-dSmjHanT0Gj7dqHJg]
X-AnalysisOut: [A:4]
Subject: [eman] EMAN MIB reviews and development process understanding
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Oct 2010 23:33:32 -0000

This is a multi-part message in MIME format.

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

Hi EMAN WG,

=20

I've been looking further into the ENERGY-AWARE-MIB, POWER-MONITOR-MIB,
and POWER-QUALITY-MIB from an implementer's perspective.  Speaking
personally and not on behalf of my employer, I am extremely excited by
the potential that these MIBs and the EMAN group has on simplifying
power management.  A common schema for data reporting and control
management will be awesome to finally get in place.

=20

That being said, the three MIBs currently being proposed are definitely
expansive.  Understanding their nuances and providing adequate reviews
for all possible scenarios (intelligent PDUs, PoE network switches, PoE
edge devices, etc.) seems to be challenges that could impact release
dates.  I'm also a little confused with some of these MIBs, as they
appear to have some overlapping scope/implied meaning.  As an
implementer, I am eagerly poised to start coding these up, but want to
ensure that they are going to meet my long-term needs without
significant changes.

=20

As an agenda suggestion for the next WG meeting, would it be appropriate
to discuss a phased release process?  In such a process, the
functionality added at each stage is separately contained, modular for
maintenance purposes, and adds upon each other in a focused approach.
For example, by exposing Phase 1 sooner, then enterprise-specific
extensions can be worked on while the features in Phases 2 and 3 are
being developed further.

=20

To prompt discussion, here's one suggestion of how the work can be
broken down into phases:

=20

Phase 1 - Core Functionality

*         Setup a table that lists all power management entities (like
ENTITY-MIB, but for power entities, so perhaps POWER-ENTITY-MIB?)

o    Purpose of the table is focused on enumerating all entities that
support power management using a concise, flexible structure

o    Objects pass the test "Is this object necessary to describing all
power entities?"

o    Create a unique index value (pwrEntityIndex)

o    Link pwrEntityIndex with entPhysicalIndex, if ENTITY-MIB is
supported

o    Describe the entity with pwrEntityName, pwrEntityDescr,
pwrEntityType, and pwrEntityParent

=20

Phase 2 - State Functionality

*         Setup a sparse table that supports state monitoring/control of
power management entities (POWER-STATE-MIB?)

o    Purpose of the table is focused on providing state management of
power entities

o    Link to pwrEntityIndex

o    Describe the state with pwrStateLevel (off, on, tripped, shed,
reboot, ...?)

o    Describe the relative state with pwrStateRelLevel (0-100%?) and/or
pwrStateAcpiLevel (0..12?)

=20

Phase 3 - Meter Functionality

*         Setup a sparse table that supports power management entities
that report meter data (POWER-METER-MIB?)

o    Purpose of the table is focused on providing meter data for power
entities

o    Link to pwrEntityIndex

o    Structure TBD ... probably similar to POWER-MONITOR-MIB or
POWER-QUALITY-MIB

=20

Phase 4 - Configuration Control Functionality

*         Setup a sparse table that supports configuration parameters of
power management entities (POWER-CONFIG-MIB?)

o    Purpose of the table is focused on providing configuration
management of power entities

o    Link to pwrEntityIndex

o    Structure TBD ... probably based on the components of
ENERGY-AWARE-MIB not used in Phase 1

o    Describe the entity with pwrConfigKeywords, pwrConfigImportance,
pwrConfigRole, etc.

=20

If the development plan/approach isn't already on the agenda, is this
something we can add?  If there is a call-in to the meeting, I'd be
happy to participate remotely as a interested implementer.
(Unfortunately, Beijing is beyond my travel budget!  :-)

=20

Again, thank you for your work in establishing an industry standard in
this area!  Please let me know if there's anything I can do to help.

=20

Best regards,

=20

Chris


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


Hi EMAN =
WG,
 
I’ve =
been looking further into the ENERGY-AWARE-MIB, POWER-MONITOR-MIB, and =
POWER-QUALITY-MIB from an implementer’s perspective.  =
Speaking personally and not on behalf of my employer, I am extremely =
excited by the potential that these MIBs and the EMAN group has on =
simplifying power management.  A common schema for data reporting =
and control management will be awesome to finally get in =
place.
 
That being =
said, the three MIBs currently being proposed are definitely =
expansive.  Understanding their nuances and providing adequate =
reviews for all possible scenarios (intelligent PDUs, PoE network =
switches, PoE edge devices, etc.) seems to be challenges that could =
impact release dates.  I’m also a little confused with some =
of these MIBs, as they appear to have some overlapping scope/implied =
meaning.  As an implementer, I am eagerly poised to start coding =
these up, but want to ensure that they are going to meet my long-term =
needs without significant changes.
 
As an agenda =
suggestion for the next WG meeting, would it be appropriate to discuss a =
phased release process?  In such a process, the functionality added =
at each stage is separately contained, modular for maintenance purposes, =
and adds upon each other in a focused approach.  For example, by =
exposing Phase 1 sooner, then enterprise-specific extensions can be =
worked on while the features in Phases 2 and 3 are being developed =
further.
 
To prompt =
discussion, here’s one suggestion of how the work can be broken =
down into phases:
 
Phase 1 =
– Core Functionality
·         =
Setup a table =
that lists all power management entities (like ENTITY-MIB, but for power =
entities, so perhaps POWER-ENTITY-MIB?)
o    =
Purpose of =
the table is focused on enumerating all entities that support power =
management using a concise, flexible structure
o    =
Objects pass =
the test “Is this object necessary to describing all power =
entities?”
o    =
Create a =
unique index value (pwrEntityIndex)
o    =
Link =
pwrEntityIndex with entPhysicalIndex, if ENTITY-MIB is =
supported
o    =
Describe the =
entity with pwrEntityName, pwrEntityDescr, pwrEntityType, and =
pwrEntityParent
 
Phase 2 =
– State Functionality
·         =
Setup a =
sparse table that supports state monitoring/control of power management =
entities (POWER-STATE-MIB?)
o    =
Purpose of =
the table is focused on providing state management of power =
entities
o    =
Link to =
pwrEntityIndex
o    =
Describe the =
state with pwrStateLevel (off, on, tripped, shed, reboot, =
…?)
o    =
Describe the =
relative state with pwrStateRelLevel (0-100%?) and/or pwrStateAcpiLevel =
(0..12?)
 
Phase 3 =
– Meter Functionality
·         =
Setup a =
sparse table that supports power management entities that report meter =
data (POWER-METER-MIB?)
o    =
Purpose of =
the table is focused on providing meter data for power =
entities
o    =
Link to =
pwrEntityIndex
o    =
Structure TBD =
… probably similar to POWER-MONITOR-MIB or =
POWER-QUALITY-MIB
 
Phase 4 =
– Configuration Control Functionality
·         =
Setup a =
sparse table that supports configuration parameters of power management =
entities (POWER-CONFIG-MIB?)
o    =
Purpose of =
the table is focused on providing configuration management of power =
entities
o    =
Link to =
pwrEntityIndex
o    =
Structure TBD =
… probably based on the components of ENERGY-AWARE-MIB not used in =
Phase 1
o    =
Describe the =
entity with pwrConfigKeywords, pwrConfigImportance, pwrConfigRole, =
etc.
 
If the =
development plan/approach isn’t already on the agenda, is this =
something we can add?  If there is a call-in to the meeting, =
I’d be happy to participate remotely as a interested =
implementer.  (Unfortunately, Beijing is beyond my travel =
budget!  :-)
 
Again, thank =
you for your work in establishing an industry standard in this =
area!  Please let me know if there’s anything I can do to =
help.
 
Best =
regards,
 
Chris

------_=_NextPart_001_01CB76F8.A5856FD3--

From Christian.Groves@nteczone.com  Thu Oct 28 18:22:43 2010
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 6F2273A69DB for ; Thu, 28 Oct 2010 18:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604,  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 TOyKMrAkOr6B for ; Thu, 28 Oct 2010 18:22:41 -0700 (PDT)
Received: from quasar.websiteactive.com (quasar.websiteactive.com [202.191.61.215]) by core3.amsl.com (Postfix) with ESMTP id 48C3E3A67D0 for ; Thu, 28 Oct 2010 18:22:41 -0700 (PDT)
Received: from ppp118-209-48-77.lns20.mel4.internode.on.net ([118.209.48.77] helo=[127.0.0.1]) by quasar.websiteactive.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PBdhp-00062J-Co for eman@ietf.org; Fri, 29 Oct 2010 12:24:33 +1100
Message-ID: <4CCA2297.7050604@nteczone.com>
Date: Fri, 29 Oct 2010 12:25:43 +1100
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: eman@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - quasar.websiteactive.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: 
Subject: Re: [eman] Entity identification method
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 01:22:43 -0000

Hello

I've just started to digest the various drafts of the eman wg and I see 
the comment below on logical entities. It's not clear to me how/if 
network virtualization is intended on being handled in the eman work.

In networks there's now a trend towards network virtualization and cloud 
computing with the different "X" as a service models (i.e. Amazon EC2 
"platform as a service" running different server instances). Even in 
today's networks we have physical gateways that are virtualized into 
different logical gateways. For example: H.248/Megaco virtual MG (VMG) 
concept.

I think it would be advantageous to be able to assess the energy 
consumption of the VMGs or instances (which are logical entities) 
independent of the physical gateway so that a customers energy use may 
be recording. Will this sort of functionality be allowed?

Regards, Christian

On 29/10/2010 1:22 AM, Juergen Quittek wrote:
> Hi Chris,
>
> I think it may become very difficult if we want to assess energy consumption
> of logical entities. It seems to be reasonable and practical to limit energy
> consumption measurements to physical entities. The ENERGY AWARE MIB module
> (draft-parello-eman-energy-aware-mib) and the POWER MIB
> (draft-quittek-power-mib-02) went this way.
>
> Just using entPhysicalIndex solves some of the problem you mentioned.
> Particularly, you don't need a mapping table to entities if you restrict
> Yourself to entPhysicalIndex.
>
> Thanks,
>
>      Juergen
>
> On 28.10.10 13:34  "Chris Verges"  wrote:
>
>> Hi Jurgen and all,
>>
>> The more I've been thinking about these scenarios, the more something
>> doesn't seem quite right.  I'll try to explain my thought process behind
>> this and see if my concerns/confusions get captured.
>>
>> ENTITY-MIB provides enumerated lists of physical and logical entities on
>> the system.  The indices in both lists are maintained separately, so
>> there is not a single, unique identifier provided.  Because of this, the
>> MIBs being discussed by the EMAN WG must only reference to one type
>> (physical or logical) and are limited to that without additional work.
>> At some point in my mind, I'm asking myself the question, "What's the
>> point of linking to ENTITY-MIB?"
>>
>> More on that question in later scenarios below ...
>>
>> One possibility would be to create a separate mapping table that gives a
>> guaranteed unique index based on all entities, regardless of type.  The
>> physical vs. logical extensions would then become sparse tables that
>> augment this.  For example:
>>
>>    ENTITY-MIB : entityGeneral.entGeneralTable.entGeneralEntry
>>    +-----------------+-----------------+-----+
>>    | entGeneralIndex | entGeneralDescr | ... |
>>    +-----------------+-----------------+-----+
>>    |        1        | PDU Chassis     |     |
>>    +-----------------+-----------------+-----+
>>    |        2        | Meter #1        |     |
>>    +-----------------+-----------------+-----+
>>    |        3        | Meter #2        |     |
>>    +-----------------+-----------------+-----+
>>    |        4        | Remote Meter #1 |     |
>>    +-----------------+-----------------+-----+
>>
>>    ENTITY-MIB : entityPhysical.entPhysicalTable.entPhysicalEntry
>>    +-----------------+-----------------+-----+
>>    | entGeneralIndex | entVendorType   | ... |
>>    +-----------------+-----------------+-----+
>>    |        1        | enterprises.foo |     |
>>    +-----------------+-----------------+-----+
>>    |        2        | enterprises.foo |     |
>>    +-----------------+-----------------+-----+
>>    |        3        | enterprises.foo |     |
>>    +-----------------+-----------------+-----+
>>
>>    ENTITY-MIB : entityLogical.entLogicalTable.entLogicalEntry
>>    +-----------------+----------------------+-----+
>>    | entGeneralIndex | entLogicalCommunity  | ... |
>>    +-----------------+----------------------+-----+
>>    |        4        | remote-power-group-1 |     |
>>    +-----------------+----------------------+-----+
>>
>> It seems like this 'entGeneralIndex' concept is what's missing from the
>> current ENTITY-MIB, and is causing problems when thinking about local
>> and remote power data being reported by the same agent.
>>
>> Another possibility would be to choose one -- entLogicalIndex, most
>> likely -- and require that anyone who wants to implement the EMAN WG
>> MIBs to always create an entLogicalEntry for the power data.  In this
>> context, the entLogicalTable fills the role of entGeneralTable as
>> described above.  For all entPhysicalTable entries, there would need to
>> be a corresponding entry in entLogicalTable with a 1:1 mapping between
>> them.  For all remote entries, there would be a unique entry in
>> entLogicalTable.  Of course, this would add some additional overhead on
>> the part of the implementer, but isn't too overburdening.
>>
>> A third possibility is that ENTITY-MIB just doesn't do what we need in
>> its present form and we need to think about enumerating power sensors
>> separately from other components/sensors on the system.  It seems like
>> entPhysicalTable gives a good starting template for a new
>> 'POWER-ENTITY-MIB', but can be extended to include support for remote
>> agents.  The difference would be a clean break from the legacy
>> ENTITY-MIB structure.
>>
>> And with that, I look forward to others' feedback and ideas on solving
>> this problem!
>>
>> Thanks,
>> Chris
>>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>> Chris Verges
>> Sent: Tuesday, October 26, 2010 9:26 PM
>> To: Juergen Quittek; Benoit Claise; eman mailing list
>> Subject: Re: [eman] Entity identification method (was: EMAN chartered
>> itemsversus drafts)
>>
>> Hi Juergen and all,
>>
>> Agreed that a common ID method makes sense, and ENTITY-MIB seems to be a
>> good choice.  In case (c) from your list, wouldn't the remote agent
>> condition be handled by ENTITY-MIB supporting a logical entity that is
>> the remote agent iself?  Since the logical entity is in the ENTITY-MIB
>> table, it would be given a unique ID mixed amongst the other logical and
>> physical entities.
>>
>> At that point, should all of the MIBs being discussed in the EMAN WG be
>> sparse table augmentations of ENTITY-MIB?
>>
>> Thanks,
>> Chris
>>
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>> Juergen Quittek
>> Sent: Tuesday, October 26, 2010 6:01 AM
>> To: Benoit Claise; eman mailing list
>> Subject: [eman] Entity identification method (was: EMAN chartered items
>> versus drafts)
>>
>> Hi Benoit and all,
>>
>> I agree that we should find a common identification method for entities
>> used by all MIB modules. This does not apply to the POWER MIB only, but
>> to all MIB modules in the eman WG.
>> The modules will use an entity ID as index for their tables.
>> Which entity is identified by the index can be resolved by other MIB
>> modules, such as the POWER AWARE MIB module
>> (draft-parello-eman-energy-aware-mib) or the ENTITY MIB module (RFC
>> 4133).
>>
>> I see three basic scenarios for the entity identification:
>>
>>    a) a device just reports on its own power state and energy
>>       consumption and it reports on its own as a single unit.
>>
>>       Then we have a single index only stating "it's me".
>>       Such a device usually does not need further identification
>>       of itself, because typically there are sufficient other
>>       MIB modules for this purpose running in the same SNMP engine,
>>       that provide information about the device's IP address,
>>       manufacturer, operating system, etc. In such a case a
>>       'trivial' index, such as '0' should be used in order to
>>       keep it simple in this most simple case.
>>
>>    b) a device reports on its own but not just as a single unit
>>       but it reports power states and energy consumption for its
>>       individual components, for example it may report separately
>>       on contained hard drives, line cards, back planes,
>>       processor boards, etc.
>>
>>       In such a case, identification of these components as
>>       individual entities would be required. The ENTITY MIB
>>       module was designed for this purpose and would be a good
>>       choice here. Also the POWER AWARE MIB module would be
>>       useful in this case.
>>
>>    c) a device reports on energy consumption of other, remote
>>       devices. Then remote devices (and potentially also their
>>       contained components need to be identified. For
>>       identifying remote components there is the POWER AWARE MIB
>>       module that has been designed for this purpose. As far as
>>       I understand, the ENTITY MIB module is not applicable to
>>       remote devices.
>>
>> In summary,
>>    - if you need to report on remote entities (case c)),
>>      you need the POWER AWARE MIB module,
>>    - if you report only on entities locally contained
>>      in the reporting device (case b)), you can use
>>      the POWER AWARE MIB or the ENTITY MIB
>>    - if you report just on your own as a single device
>>      (case a)), identification is trivial
>>
>> Hence, my recommendation (stated for POWER-STATE MIB and ENERGY MIB in
>> draft-quittek-power-mib-02) would be:
>>
>> If there is an implementation of the POWER AWARE MIB module instantiated
>> in the local SNMP engine, then you SHOULD (or MUST?) use it for indexing
>> (pmIndex).
>> If this is not the case but there is an ENTITY MIB instance available,
>> then you SHOULD use this one (entPhysicalIndex).
>> If neither of this MIB modules is available you should use index 0 only
>> and be limited to report on the local device as a single entity only.
>>
>> That's just my view. Certainly, there are more ways of entity
>> identification. I look forward to discussing them.
>>
>> Thanks,
>>
>>      Juergen
>>
>>
>> On 26.10.10 11:44  "Benoit Claise"  wrote:
>>
>>> Hi Juergen,
>>>
>>> Thanks for the clarification.
>>>
>>> Something key is to agree on the Power Monitor index for all MIB
>>> modules, which IMHO should be part of the Energy-aware Networks and
>>> Devices MIB module, but reuse in the other MIB modules.
>>>
>>> Regards, Benoit.
>>>> Hi Benoit,
>>>>
>>>> Thanks for checking all drafts.
>>>>
>>>> I don't think that draft-quittek-power-mib-02 makes significant
>>>> contributions to the Energy-aware Networks and Devices MIB.
>>>> It just covers the Power and Energy Monitoring MIB and the Battery
>> MIB.
>>>> Thanks,
>>>>       Juergen
>>>>
>>>>
>>>> On 26.10.10 08:22  "Benoit Claise"   wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I went through the exercise of mapping the existing six chartered
>>>>> items with the existing draft content.
>>>>>
>>>>> _Energy Management Requirements_
>>>>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requiremen
>>>>> ts-02 https://datatracker.ietf.org/doc/draft-norwin-energy-consider/
>>>>> _
>>>>> Energy Management Framework_
>>>>> http://tools.ietf.org/html/draft-claise-power-management-arch-02
>>>>>
>>>>> _Energy-aware Networks and Devices MIB_
>>>>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>
>>>>> _Power and Energy Monitoring MIB_
>>>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>
>>>>> _Battery MIB_
>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>
>>>>> _Energy Management Applicability_
>>>>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-stat
>>>>> ement/
>>>>>
>>>>> Please let me know if I made any mistakes or if I missed any draft?
>>>>>
>>>>> Regards, Benoit.
>>>>> _______________________________________________
>>>>> eman mailing list
>>>>> eman@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/eman
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

From Quittek@neclab.eu  Thu Oct 28 18:47:28 2010
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 0A9D83A69DB for ; Thu, 28 Oct 2010 18:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.131
X-Spam-Level: 
X-Spam-Status: No, score=-102.131 tagged_above=-999 required=5 tests=[AWL=0.468, 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 eH-XQ9TmpJMV for ; Thu, 28 Oct 2010 18:47:19 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E98CE3A672F for ; Thu, 28 Oct 2010 18:47:16 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B1B222C0001B2; Fri, 29 Oct 2010 03:49:09 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPh3htOkPXUp; Fri, 29 Oct 2010 03:49:09 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 8C90F2C0001B0; Fri, 29 Oct 2010 03:48:59 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.19]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0255.000; Fri, 29 Oct 2010 03:48:59 +0200
From: Juergen Quittek 
To: Christian Groves , eman mailing list 
Thread-Topic: [eman] Entity identification method
Thread-Index: AQHLdwgcZes8a//UyUuRXgJBOE9+2ZNXKNIA
Date: Fri, 29 Oct 2010 01:48:58 +0000
Message-ID: 
In-Reply-To: <4CCA2297.7050604@nteczone.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.7.0.100913
x-originating-ip: [10.7.0.92]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3371168935_21878908"
MIME-Version: 1.0
Subject: Re: [eman] Entity identification method
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 01:47:28 -0000

--B_3371168935_21878908
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Christian,

Thank you for this interesting comment.

It looks like we have to distinguish two cases: power state monitoring and
energy consumption monitoring.

For a logical entity and a virtual machine it may be well possible to report
on their power state. However, reporting their energy consumption seems to
be a tough challenge at least if be base it on real measurements.

It is well feasible to measure energy consumption of physical entities, but
if you have a logical entity that consumes only partial resources of a
physical entity, then precise measurement of the energy consumption will be
hardly possible. Estimations may be possible based on a model of the logical
entity, but I don't know how good such models can be.

Thanks,

    Juergen 


On 29.10.10 03:25  "Christian Groves"  wrote:

> Hello
> 
> I've just started to digest the various drafts of the eman wg and I see
> the comment below on logical entities. It's not clear to me how/if
> network virtualization is intended on being handled in the eman work.
> 
> In networks there's now a trend towards network virtualization and cloud
> computing with the different "X" as a service models (i.e. Amazon EC2
> "platform as a service" running different server instances). Even in
> today's networks we have physical gateways that are virtualized into
> different logical gateways. For example: H.248/Megaco virtual MG (VMG)
> concept.
> 
> I think it would be advantageous to be able to assess the energy
> consumption of the VMGs or instances (which are logical entities)
> independent of the physical gateway so that a customers energy use may
> be recording. Will this sort of functionality be allowed?
> 
> Regards, Christian
> 
> On 29/10/2010 1:22 AM, Juergen Quittek wrote:
>> Hi Chris,
>> 
>> I think it may become very difficult if we want to assess energy consumption
>> of logical entities. It seems to be reasonable and practical to limit energy
>> consumption measurements to physical entities. The ENERGY AWARE MIB module
>> (draft-parello-eman-energy-aware-mib) and the POWER MIB
>> (draft-quittek-power-mib-02) went this way.
>> 
>> Just using entPhysicalIndex solves some of the problem you mentioned.
>> Particularly, you don't need a mapping table to entities if you restrict
>> Yourself to entPhysicalIndex.
>> 
>> Thanks,
>> 
>>      Juergen
>> 
>> On 28.10.10 13:34  "Chris Verges"  wrote:
>> 
>>> Hi Jurgen and all,
>>> 
>>> The more I've been thinking about these scenarios, the more something
>>> doesn't seem quite right.  I'll try to explain my thought process behind
>>> this and see if my concerns/confusions get captured.
>>> 
>>> ENTITY-MIB provides enumerated lists of physical and logical entities on
>>> the system.  The indices in both lists are maintained separately, so
>>> there is not a single, unique identifier provided.  Because of this, the
>>> MIBs being discussed by the EMAN WG must only reference to one type
>>> (physical or logical) and are limited to that without additional work.
>>> At some point in my mind, I'm asking myself the question, "What's the
>>> point of linking to ENTITY-MIB?"
>>> 
>>> More on that question in later scenarios below ...
>>> 
>>> One possibility would be to create a separate mapping table that gives a
>>> guaranteed unique index based on all entities, regardless of type.  The
>>> physical vs. logical extensions would then become sparse tables that
>>> augment this.  For example:
>>> 
>>>    ENTITY-MIB : entityGeneral.entGeneralTable.entGeneralEntry
>>>    +-----------------+-----------------+-----+
>>>    | entGeneralIndex | entGeneralDescr | ... |
>>>    +-----------------+-----------------+-----+
>>>    |        1        | PDU Chassis     |     |
>>>    +-----------------+-----------------+-----+
>>>    |        2        | Meter #1        |     |
>>>    +-----------------+-----------------+-----+
>>>    |        3        | Meter #2        |     |
>>>    +-----------------+-----------------+-----+
>>>    |        4        | Remote Meter #1 |     |
>>>    +-----------------+-----------------+-----+
>>> 
>>>    ENTITY-MIB : entityPhysical.entPhysicalTable.entPhysicalEntry
>>>    +-----------------+-----------------+-----+
>>>    | entGeneralIndex | entVendorType   | ... |
>>>    +-----------------+-----------------+-----+
>>>    |        1        | enterprises.foo |     |
>>>    +-----------------+-----------------+-----+
>>>    |        2        | enterprises.foo |     |
>>>    +-----------------+-----------------+-----+
>>>    |        3        | enterprises.foo |     |
>>>    +-----------------+-----------------+-----+
>>> 
>>>    ENTITY-MIB : entityLogical.entLogicalTable.entLogicalEntry
>>>    +-----------------+----------------------+-----+
>>>    | entGeneralIndex | entLogicalCommunity  | ... |
>>>    +-----------------+----------------------+-----+
>>>    |        4        | remote-power-group-1 |     |
>>>    +-----------------+----------------------+-----+
>>> 
>>> It seems like this 'entGeneralIndex' concept is what's missing from the
>>> current ENTITY-MIB, and is causing problems when thinking about local
>>> and remote power data being reported by the same agent.
>>> 
>>> Another possibility would be to choose one -- entLogicalIndex, most
>>> likely -- and require that anyone who wants to implement the EMAN WG
>>> MIBs to always create an entLogicalEntry for the power data.  In this
>>> context, the entLogicalTable fills the role of entGeneralTable as
>>> described above.  For all entPhysicalTable entries, there would need to
>>> be a corresponding entry in entLogicalTable with a 1:1 mapping between
>>> them.  For all remote entries, there would be a unique entry in
>>> entLogicalTable.  Of course, this would add some additional overhead on
>>> the part of the implementer, but isn't too overburdening.
>>> 
>>> A third possibility is that ENTITY-MIB just doesn't do what we need in
>>> its present form and we need to think about enumerating power sensors
>>> separately from other components/sensors on the system.  It seems like
>>> entPhysicalTable gives a good starting template for a new
>>> 'POWER-ENTITY-MIB', but can be extended to include support for remote
>>> agents.  The difference would be a clean break from the legacy
>>> ENTITY-MIB structure.
>>> 
>>> And with that, I look forward to others' feedback and ideas on solving
>>> this problem!
>>> 
>>> Thanks,
>>> Chris
>>> 
>>> -----Original Message-----
>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>>> Chris Verges
>>> Sent: Tuesday, October 26, 2010 9:26 PM
>>> To: Juergen Quittek; Benoit Claise; eman mailing list
>>> Subject: Re: [eman] Entity identification method (was: EMAN chartered
>>> itemsversus drafts)
>>> 
>>> Hi Juergen and all,
>>> 
>>> Agreed that a common ID method makes sense, and ENTITY-MIB seems to be a
>>> good choice.  In case (c) from your list, wouldn't the remote agent
>>> condition be handled by ENTITY-MIB supporting a logical entity that is
>>> the remote agent iself?  Since the logical entity is in the ENTITY-MIB
>>> table, it would be given a unique ID mixed amongst the other logical and
>>> physical entities.
>>> 
>>> At that point, should all of the MIBs being discussed in the EMAN WG be
>>> sparse table augmentations of ENTITY-MIB?
>>> 
>>> Thanks,
>>> Chris
>>> 
>>> -----Original Message-----
>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>>> Juergen Quittek
>>> Sent: Tuesday, October 26, 2010 6:01 AM
>>> To: Benoit Claise; eman mailing list
>>> Subject: [eman] Entity identification method (was: EMAN chartered items
>>> versus drafts)
>>> 
>>> Hi Benoit and all,
>>> 
>>> I agree that we should find a common identification method for entities
>>> used by all MIB modules. This does not apply to the POWER MIB only, but
>>> to all MIB modules in the eman WG.
>>> The modules will use an entity ID as index for their tables.
>>> Which entity is identified by the index can be resolved by other MIB
>>> modules, such as the POWER AWARE MIB module
>>> (draft-parello-eman-energy-aware-mib) or the ENTITY MIB module (RFC
>>> 4133).
>>> 
>>> I see three basic scenarios for the entity identification:
>>> 
>>>    a) a device just reports on its own power state and energy
>>>       consumption and it reports on its own as a single unit.
>>> 
>>>       Then we have a single index only stating "it's me".
>>>       Such a device usually does not need further identification
>>>       of itself, because typically there are sufficient other
>>>       MIB modules for this purpose running in the same SNMP engine,
>>>       that provide information about the device's IP address,
>>>       manufacturer, operating system, etc. In such a case a
>>>       'trivial' index, such as '0' should be used in order to
>>>       keep it simple in this most simple case.
>>> 
>>>    b) a device reports on its own but not just as a single unit
>>>       but it reports power states and energy consumption for its
>>>       individual components, for example it may report separately
>>>       on contained hard drives, line cards, back planes,
>>>       processor boards, etc.
>>> 
>>>       In such a case, identification of these components as
>>>       individual entities would be required. The ENTITY MIB
>>>       module was designed for this purpose and would be a good
>>>       choice here. Also the POWER AWARE MIB module would be
>>>       useful in this case.
>>> 
>>>    c) a device reports on energy consumption of other, remote
>>>       devices. Then remote devices (and potentially also their
>>>       contained components need to be identified. For
>>>       identifying remote components there is the POWER AWARE MIB
>>>       module that has been designed for this purpose. As far as
>>>       I understand, the ENTITY MIB module is not applicable to
>>>       remote devices.
>>> 
>>> In summary,
>>>    - if you need to report on remote entities (case c)),
>>>      you need the POWER AWARE MIB module,
>>>    - if you report only on entities locally contained
>>>      in the reporting device (case b)), you can use
>>>      the POWER AWARE MIB or the ENTITY MIB
>>>    - if you report just on your own as a single device
>>>      (case a)), identification is trivial
>>> 
>>> Hence, my recommendation (stated for POWER-STATE MIB and ENERGY MIB in
>>> draft-quittek-power-mib-02) would be:
>>> 
>>> If there is an implementation of the POWER AWARE MIB module instantiated
>>> in the local SNMP engine, then you SHOULD (or MUST?) use it for indexing
>>> (pmIndex).
>>> If this is not the case but there is an ENTITY MIB instance available,
>>> then you SHOULD use this one (entPhysicalIndex).
>>> If neither of this MIB modules is available you should use index 0 only
>>> and be limited to report on the local device as a single entity only.
>>> 
>>> That's just my view. Certainly, there are more ways of entity
>>> identification. I look forward to discussing them.
>>> 
>>> Thanks,
>>> 
>>>      Juergen
>>> 
>>> 
>>> On 26.10.10 11:44  "Benoit Claise"  wrote:
>>> 
>>>> Hi Juergen,
>>>> 
>>>> Thanks for the clarification.
>>>> 
>>>> Something key is to agree on the Power Monitor index for all MIB
>>>> modules, which IMHO should be part of the Energy-aware Networks and
>>>> Devices MIB module, but reuse in the other MIB modules.
>>>> 
>>>> Regards, Benoit.
>>>>> Hi Benoit,
>>>>> 
>>>>> Thanks for checking all drafts.
>>>>> 
>>>>> I don't think that draft-quittek-power-mib-02 makes significant
>>>>> contributions to the Energy-aware Networks and Devices MIB.
>>>>> It just covers the Power and Energy Monitoring MIB and the Battery
>>> MIB.
>>>>> Thanks,
>>>>>       Juergen
>>>>> 
>>>>> 
>>>>> On 26.10.10 08:22  "Benoit Claise"   wrote:
>>>>> 
>>>>>> Dear all,
>>>>>> 
>>>>>> I went through the exercise of mapping the existing six chartered
>>>>>> items with the existing draft content.
>>>>>> 
>>>>>> _Energy Management Requirements_
>>>>>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requiremen
>>>>>> ts-02 https://datatracker.ietf.org/doc/draft-norwin-energy-consider/
>>>>>> _
>>>>>> Energy Management Framework_
>>>>>> http://tools.ietf.org/html/draft-claise-power-management-arch-02
>>>>>> 
>>>>>> _Energy-aware Networks and Devices MIB_
>>>>>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>> 
>>>>>> _Power and Energy Monitoring MIB_
>>>>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>> 
>>>>>> _Battery MIB_
>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>> 
>>>>>> _Energy Management Applicability_
>>>>>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-stat
>>>>>> ement/
>>>>>> 
>>>>>> Please let me know if I made any mistakes or if I missed any draft?
>>>>>> 
>>>>>> Regards, Benoit.
>>>>>> _______________________________________________
>>>>>> eman mailing list
>>>>>> eman@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>> 
>> 
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman

-- 
Juergen Quittek            quittek@neclab.eu      Tel: +49 6221 4342-115
General Manager            http://www.neclab.eu   Fax: +49 6221 4342-155
NEC Europe Ltd., Network Laboratories Europe
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014

--B_3371168935_21878908
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIQ5wYJKoZIhvcNAQcCoIIQ2DCCENQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Do8wggUzMIIEG6ADAgECAgQP7R53MA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY
MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1
cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu
Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTEwMDQyMDEyNDExMloXDTEzMDQxOTEyNDExMlow
YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD
IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANga4Hf5iSjDiva8/BTlatnXFlOWPfqZvY7AU6bt
CUKFiaGwytFar7XCwRggHcCeodYaMZoDRSEGY+bRUDvayjNvFTkhL19Fmzxg4MPmQA92tcIb
/+IylZD5YkVkw88/6zb6k+T+o875LlLAR79f8gvloaPMbxiB8KwQtdlGB9OiN1k3+7NiESpW
myT8WWrWw4F7qc0WLXaWuqv6/3vRo+jJSxyOwefEnzrRojCePJ2ZD4mgPMQvMHPqodDhTvIB
BupYoAtW53024WnL/PHH34pQ0Zmclz8u/YocnfMEYoyLDVuJKnQowDF75LVbnKmpXfCscKeb
SndFpSANP2TiI2cCAwEAAaOCAb8wggG7MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud
JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQU9WUPxjFB
AtJOXxJ7agqXozHDy9gwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHAYDVR0R
BBUwE4ERUXVpdHRla0BuZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEu
cGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9j
ZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEFBQcB
AQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEB
AH9VRaZ978LNoc+eM/2k/OQafNJl4UjKLjiEnH8FCuqnuNXZMAOdcfnMrRKK1bl+FhCy3sjg
gsuP4Nam2oSy7RDYWYjLY/MKMPO/MD/PpNSe6gox4948wfjWGmj4Uz3gqgDovQEC2H03jcPX
etJqBTipqmfnvMFqozoN5zjiEzJuuLpLMYNPM+E+4pQnLtRAhN94C1e9C7oP66b7as6OgVVC
CplE5llnoKM5ngtAFL5G3ygm/rZtptdmaNgRO6jDX1w9AOrsmSPGp+S+YRNonKGEqTolJpul
EJB7rMdAUimsUp/qdzvWrhIZ6A3fgzHwFhrIHqVBlDLmu7cQHu/QMUEwggUvMIIEF6ADAgEC
AgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy
ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg
LSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMCREUx
GDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBF
dXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK6kKX
nTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDBaSa+
nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i/W+u
OQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMzVw94
Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQwggHA
MBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAvmfa+
FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREEJjAk
gSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9oDug
OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3Js
LmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIv
Y3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j
ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG
CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j
YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEekP3l3
GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWclSZQ4
60jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yyPjzI
VPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS09mE
WRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkzJNfb
fEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUA
MHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL
ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv
b3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4t
VmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0
iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txP
eKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVY
J9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV
Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYw
cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vydmlj
ZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09U
X0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu6
9VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0G
CSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0Z
MfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSF
PT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0
hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBn
qyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA
9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3Bl
IEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNM
QUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu
ZXUCBA/tHncwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTQThzv/dGQly+lfbTAW93w
vTW4hTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEwMjkw
MTQ4NTRaMA0GCSqGSIb3DQEBAQUABIIBAGdIhk6g4el5OF3aXjb/M0tBvnZ3O+STyjjukzzq
QjMheo7pRIwutfiIa4IxRia0rNufzXVNxhHKYCVEKCWLWkMQx9xE3Y5oiB8GO4QOY3749Z9z
4GJBkTsn6p6bcFJilq4nJ9Dc2exQ1pdc9EpviaP2AR2+Ano4wYIfUscSKRjkC+DM8CpeoR0J
0/eJqY/H5PXIBFGvffOCyZ9YVk/fGsz4FvOIc1Ugq4W/8+vDWHHHMoxXSbyVfnFxGu2zO524
SVlFX6l/IZHfR+gFjJK0hB3Yg+pg9CNsxlLss9+MxdHHzaf8juHyOP+L1tMj4Ru6x+20KhUg
D12oHWRqhZW/1uY=

--B_3371168935_21878908--

From moulchan@cisco.com  Thu Oct 28 22:43:51 2010
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 21A7C3A69F3 for ; Thu, 28 Oct 2010 22:43: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, HTML_MESSAGE=0.001, 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 4VOy3rT7kpPH for ; Thu, 28 Oct 2010 22:43:42 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 449753A67DF for ; Thu, 28 Oct 2010 22:43:41 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFALP8yUytJV2b/2dsb2JhbACBQ6ARcaA0nC2FSASEV4kK
X-IronPort-AV: E=Sophos;i="4.58,257,1286150400";  d="scan'208,217";a="176240652"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 29 Oct 2010 05:45:33 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9T5jXMN003433;  Fri, 29 Oct 2010 05:45:33 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 29 Oct 2010 00:45:33 -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_01CB772C.80A623F7"
Date: Fri, 29 Oct 2010 00:45:30 -0500
Message-ID: 
In-Reply-To: <68FBE0F3CE97264395875AC1C468F22C5146E3@mail03.cyberswitching.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] EMAN MIB reviews and development process understanding
Thread-Index: Act2+JTb8us1t2UNQsyiaJAWx0mIFQAMEdjQ
References: <68FBE0F3CE97264395875AC1C468F22C5146E3@mail03.cyberswitching.local>
From: "Mouli Chandramouli (moulchan)" 
To: "Chris Verges" , 
X-OriginalArrivalTime: 29 Oct 2010 05:45:33.0567 (UTC) FILETIME=[80F000F0:01CB772C]
Subject: Re: [eman] EMAN MIB reviews and development process understanding
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 05:43:51 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB772C.80A623F7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Chris,

=20

Thanks for your detailed comments. =20

=20

I think from a IETF WG perspective, I think the first step would be to
arrive at a consensus on whether the proposed MIB variables would be
sufficient and would meet the requirements for power management.=20

=20

>From an implementation perspective,  I understand your phased approach.
A probable solution to your question is perhaps consider having separate
MIB modules - =20

1.       Core functionality is covered by energy-aware-mib-00.=20

2.       Power Metering and Power  states are grouped together -
draft-claise-energy-monitoring-mib-06.  In addition, this module also
contains energy/demand measurement.=20

3.       Power Quality MIB - is already an optional MIB module in -
draft-claise-energy-monitoring-mib-06.=20

=20

The convergence or adoption of these drafts (or MIB modules)  depends on
the progress or consensus at the WG.=20

=20

Thanks

Mouli

=20

=20

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Chris Verges
Sent: Friday, October 29, 2010 5:04 AM
To: eman@ietf.org
Subject: [eman] EMAN MIB reviews and development process understanding

=20

Hi EMAN WG,

=20

I've been looking further into the ENERGY-AWARE-MIB, POWER-MONITOR-MIB,
and POWER-QUALITY-MIB from an implementer's perspective.  Speaking
personally and not on behalf of my employer, I am extremely excited by
the potential that these MIBs and the EMAN group has on simplifying
power management.  A common schema for data reporting and control
management will be awesome to finally get in place.

=20

That being said, the three MIBs currently being proposed are definitely
expansive.  Understanding their nuances and providing adequate reviews
for all possible scenarios (intelligent PDUs, PoE network switches, PoE
edge devices, etc.) seems to be challenges that could impact release
dates.  I'm also a little confused with some of these MIBs, as they
appear to have some overlapping scope/implied meaning.  As an
implementer, I am eagerly poised to start coding these up, but want to
ensure that they are going to meet my long-term needs without
significant changes.

=20

As an agenda suggestion for the next WG meeting, would it be appropriate
to discuss a phased release process?  In such a process, the
functionality added at each stage is separately contained, modular for
maintenance purposes, and adds upon each other in a focused approach.
For example, by exposing Phase 1 sooner, then enterprise-specific
extensions can be worked on while the features in Phases 2 and 3 are
being developed further.

=20

To prompt discussion, here's one suggestion of how the work can be
broken down into phases:

=20

Phase 1 - Core Functionality

*         Setup a table that lists all power management entities (like
ENTITY-MIB, but for power entities, so perhaps POWER-ENTITY-MIB?)

o    Purpose of the table is focused on enumerating all entities that
support power management using a concise, flexible structure

o    Objects pass the test "Is this object necessary to describing all
power entities?"

o    Create a unique index value (pwrEntityIndex)

o    Link pwrEntityIndex with entPhysicalIndex, if ENTITY-MIB is
supported

o    Describe the entity with pwrEntityName, pwrEntityDescr,
pwrEntityType, and pwrEntityParent

=20

Phase 2 - State Functionality

*         Setup a sparse table that supports state monitoring/control of
power management entities (POWER-STATE-MIB?)

o    Purpose of the table is focused on providing state management of
power entities

o    Link to pwrEntityIndex

o    Describe the state with pwrStateLevel (off, on, tripped, shed,
reboot, ...?)

o    Describe the relative state with pwrStateRelLevel (0-100%?) and/or
pwrStateAcpiLevel (0..12?)

=20

Phase 3 - Meter Functionality

*         Setup a sparse table that supports power management entities
that report meter data (POWER-METER-MIB?)

o    Purpose of the table is focused on providing meter data for power
entities

o    Link to pwrEntityIndex

o    Structure TBD ... probably similar to POWER-MONITOR-MIB or
POWER-QUALITY-MIB

=20

Phase 4 - Configuration Control Functionality

*         Setup a sparse table that supports configuration parameters of
power management entities (POWER-CONFIG-MIB?)

o    Purpose of the table is focused on providing configuration
management of power entities

o    Link to pwrEntityIndex

o    Structure TBD ... probably based on the components of
ENERGY-AWARE-MIB not used in Phase 1

o    Describe the entity with pwrConfigKeywords, pwrConfigImportance,
pwrConfigRole, etc.

=20

If the development plan/approach isn't already on the agenda, is this
something we can add?  If there is a call-in to the meeting, I'd be
happy to participate remotely as a interested implementer.
(Unfortunately, Beijing is beyond my travel budget!  :-)

=20

Again, thank you for your work in establishing an industry standard in
this area!  Please let me know if there's anything I can do to help.

=20

Best regards,

=20

Chris


------_=_NextPart_001_01CB772C.80A623F7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi =
Chris,



 



Thanks for your =
detailed
comments.  



 



I think from a IETF =
WG
perspective, I think the first step would be to arrive at a consensus on
whether the proposed MIB variables would be sufficient and would meet =
the
requirements for power management. 



 



From an =
implementation perspective, 
I understand your phased approach. A probable solution to your question =
is
perhaps consider having separate MIB modules - =
 



1.      
Core =
functionality
is covered by energy-aware-mib-00. 



2.      
Power =
Metering and
Power  states are grouped together - =
draft-claise-energy-monitoring-mib-06.
 In addition, this module also contains energy/demand =
measurement. 



3.      
Power =
Quality MIB –
is already an optional MIB module in - =
draft-claise-energy-monitoring-mib-06. 



 



The convergence or =
adoption of
these drafts (or MIB modules)  depends on the progress or consensus =
at the
WG. 



 



Thanks



Mouli



 



 









From:=

eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of =
Chris
Verges

Sent: Friday, October 29, 2010 5:04 AM

To: eman@ietf.org

Subject: [eman] EMAN MIB reviews and development process =
understanding









 



Hi EMAN WG,



 



I’ve been looking further into the =
ENERGY-AWARE-MIB,
POWER-MONITOR-MIB, and POWER-QUALITY-MIB from an implementer’s
perspective.  Speaking personally and not on behalf of my employer, =
I am
extremely excited by the potential that these MIBs and the EMAN group =
has on
simplifying power management.  A common schema for data reporting =
and
control management will be awesome to finally get in =
place.



 



That being said, the three MIBs currently being proposed =
are
definitely expansive.  Understanding their nuances and providing =
adequate
reviews for all possible scenarios (intelligent PDUs, PoE network =
switches, PoE
edge devices, etc.) seems to be challenges that could impact release
dates.  I’m also a little confused with some of these MIBs, =
as they
appear to have some overlapping scope/implied meaning.  As an =
implementer,
I am eagerly poised to start coding these up, but want to ensure that =
they are
going to meet my long-term needs without significant =
changes.



 



As an agenda suggestion for the next WG meeting, would it =
be
appropriate to discuss a phased release process?  In such a =
process, the
functionality added at each stage is separately contained, modular for
maintenance purposes, and adds upon each other in a focused =
approach.  For
example, by exposing Phase 1 sooner, then enterprise-specific extensions =
can be
worked on while the features in Phases 2 and 3 are being developed =
further.



 



To prompt discussion, here’s one suggestion of how =
the
work can be broken down into phases:



 



Phase 1 – Core =
Functionality



·       &=
nbsp;
Setup a
table that lists all power management entities (like ENTITY-MIB, but for =
power
entities, so perhaps POWER-ENTITY-MIB?)



o    Purpose of =
the table
is focused on enumerating all entities that support power management =
using a
concise, flexible structure



o    Objects pass =
the test
“Is this object necessary to describing all power =
entities?”



o    Create a =
unique index
value (pwrEntityIndex)



o    Link =
pwrEntityIndex
with entPhysicalIndex, if ENTITY-MIB is supported



o    Describe the =
entity
with pwrEntityName, pwrEntityDescr, pwrEntityType, and =
pwrEntityParent



 



Phase 2 – State =
Functionality



·       &=
nbsp;
Setup a
sparse table that supports state monitoring/control of power management
entities (POWER-STATE-MIB?)



o    Purpose of =
the table
is focused on providing state management of power =
entities



o    Link to =
pwrEntityIndex



o    Describe the =
state
with pwrStateLevel (off, on, tripped, shed, reboot, =
…?)



o    Describe the =
relative
state with pwrStateRelLevel (0-100%?) and/or pwrStateAcpiLevel =
(0..12?)



 



Phase 3 – Meter =
Functionality



·       &=
nbsp;
Setup a
sparse table that supports power management entities that report meter =
data
(POWER-METER-MIB?)



o    Purpose of =
the table
is focused on providing meter data for power =
entities



o    Link to =
pwrEntityIndex



o    Structure TBD =
…
probably similar to POWER-MONITOR-MIB or =
POWER-QUALITY-MIB



 



Phase 4 – Configuration =
Control
Functionality



·       &=
nbsp;
Setup a
sparse table that supports configuration parameters of power management
entities (POWER-CONFIG-MIB?)



o    Purpose of =
the table
is focused on providing configuration management of power =
entities



o    Link to =
pwrEntityIndex



o    Structure TBD =
… probably
based on the components of ENERGY-AWARE-MIB not used in Phase =
1



o    Describe the =
entity
with pwrConfigKeywords, pwrConfigImportance, pwrConfigRole, =
etc.



 



If the development plan/approach isn’t already on =
the
agenda, is this something we can add?  If there is a call-in to the
meeting, I’d be happy to participate remotely as a interested
implementer.  (Unfortunately, Beijing is beyond my travel =
budget! 
:-)



 



Again, thank you for your work in establishing an =
industry
standard in this area!  Please let me know if there’s =
anything I can
do to help.



 



Best regards,



 



Chris









------_=_NextPart_001_01CB772C.80A623F7--

From bclaise@cisco.com  Fri Oct 29 01:31:18 2010
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 BF3A63A6A27 for ; Fri, 29 Oct 2010 01:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  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 5UXGuu8mzODY for ; Fri, 29 Oct 2010 01:31:17 -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 8528F3A6807 for ; Fri, 29 Oct 2010 01:31:17 -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 o9T8TQaO012516 for ; Fri, 29 Oct 2010 10:29:26 +0200 (CEST)
Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9T8TPmu020569 for ; Fri, 29 Oct 2010 10:29:25 +0200 (CEST)
Message-ID: <4CCA85E5.3010107@cisco.com>
Date: Fri, 29 Oct 2010 10:29:25 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: eman mailing list 
References: <4CC92344.60602@cisco.com>
In-Reply-To: <4CC92344.60602@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [eman] Preliminary agenda - EMAN meeting
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 08:31:18 -0000

Dear all,

Some small time allocation corrections, as the meeting is 2 hours  and 
not 2h30. ;-)
New agenda posted at http://www.ietf.org/proceedings/79/agenda/eman.txt

Regards, Bruce and Benoit.

> Dear all,
>
> We have uploaded a preliminary agenda for the EMAN meeting in Beijing 
> - accessible at
> http://www.ietf.org/proceedings/79/agenda/eman.txt
>
> We have allocated the full 2h30 time across the drafts, mainly the one 
> with open issues.
> We should resolve as many as possible during the meeting.
>
> Thanks and Regards, Bruce and Benoit
>
>


From chrisv@cyberswitching.com  Fri Oct 29 06:50:19 2010
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 C3E093A681F for ; Fri, 29 Oct 2010 06:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.91
X-Spam-Level: 
X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[AWL=0.688,  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 VYxySQxY+dR0 for ; Fri, 29 Oct 2010 06:50:10 -0700 (PDT)
Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id 268F03A6944 for ; Fri, 29 Oct 2010 06:50:07 -0700 (PDT)
Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c12o144.mxlogic.net(mxl_mta-6.7.0-2) with ESMTP id 181dacc4.0.4622.00-338.12509.p01c12o144.mxlogic.net (envelope-from );  Fri, 29 Oct 2010 07:52:03 -0600 (MDT)
X-MXL-Hash: 4ccad18364adf19d-e09cd559aa030010c73ce6294b6048761deafcd8
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_01CB7770.54B3185F"
Date: Fri, 29 Oct 2010 06:51:03 -0700
Message-ID: <68FBE0F3CE97264395875AC1C468F22C51470A@mail03.cyberswitching.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] EMAN MIB reviews and development process understanding
Thread-Index: Act2+JTb8us1t2UNQsyiaJAWx0mIFQAMEdjQABHOdqA=
References: <68FBE0F3CE97264395875AC1C468F22C5146E3@mail03.cyberswitching.local> 
From: "Chris Verges" 
To: "Mouli Chandramouli \(moulchan\)" , 
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010073001)]
X-MAIL-FROM: 
X-SOURCE-IP: [64.81.28.110]
X-AnalysisOut: [v=1.0 c=1 a=gRFbAe8-ICMA:10 a=BLceEmwcHowA:10 a=4zsJQXJisS]
X-AnalysisOut: [Y22NXBO5KRuA==:17 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=_xiy]
X-AnalysisOut: [TTP9deZ0z7SKlkIA:9 a=JCsZp3dyqI7tgomY7fYA:7 a=2DfDUQNbfi-P]
X-AnalysisOut: [2NaN3hK4XHLsgU4A:4 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=l]
X-AnalysisOut: [ZB815dzVvQA:10 a=S-vj5UM2Z0mXVev3:21 a=C5aKEBLn-gIcWU40:21]
X-AnalysisOut: [ a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=qaZDL76UXL3D1QBcJ74A:]
X-AnalysisOut: [9 a=UbM46JNov_Bf4kZErSwA:7 a=1RI98Ba3DZCriQb3YJ1sCcWI5E8A:]
X-AnalysisOut: [4]
Subject: Re: [eman] EMAN MIB reviews and development process understanding
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 13:50:19 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB7770.54B3185F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Mouli,

=20

I guess my concern with the way it is currently broken down is that it
appears to be "cluttered."  For example, in ENERGY-AWARE-MIB, a good
deal of the objects contained in the sequence are not obviously related
to a generic power entity.  In fact, things like Importance and Role are
almost directly descended from Cisco EnergyWise.  At what point do we
break that away are truly focus on the "core"?

=20

Chris

=20

From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com]=20
Sent: Thursday, October 28, 2010 10:46 PM
To: Chris Verges; eman@ietf.org
Subject: RE: [eman] EMAN MIB reviews and development process
understanding

=20

Hi Chris,

=20

Thanks for your detailed comments. =20

=20

I think from a IETF WG perspective, I think the first step would be to
arrive at a consensus on whether the proposed MIB variables would be
sufficient and would meet the requirements for power management.=20

=20

>From an implementation perspective,  I understand your phased approach.
A probable solution to your question is perhaps consider having separate
MIB modules - =20

1.       Core functionality is covered by energy-aware-mib-00.=20

2.       Power Metering and Power  states are grouped together -
draft-claise-energy-monitoring-mib-06.  In addition, this module also
contains energy/demand measurement.=20

3.       Power Quality MIB - is already an optional MIB module in -
draft-claise-energy-monitoring-mib-06.=20

=20

The convergence or adoption of these drafts (or MIB modules)  depends on
the progress or consensus at the WG.=20

=20

Thanks

Mouli

=20

=20

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
Chris Verges
Sent: Friday, October 29, 2010 5:04 AM
To: eman@ietf.org
Subject: [eman] EMAN MIB reviews and development process understanding

=20

Hi EMAN WG,

=20

I've been looking further into the ENERGY-AWARE-MIB, POWER-MONITOR-MIB,
and POWER-QUALITY-MIB from an implementer's perspective.  Speaking
personally and not on behalf of my employer, I am extremely excited by
the potential that these MIBs and the EMAN group has on simplifying
power management.  A common schema for data reporting and control
management will be awesome to finally get in place.

=20

That being said, the three MIBs currently being proposed are definitely
expansive.  Understanding their nuances and providing adequate reviews
for all possible scenarios (intelligent PDUs, PoE network switches, PoE
edge devices, etc.) seems to be challenges that could impact release
dates.  I'm also a little confused with some of these MIBs, as they
appear to have some overlapping scope/implied meaning.  As an
implementer, I am eagerly poised to start coding these up, but want to
ensure that they are going to meet my long-term needs without
significant changes.

=20

As an agenda suggestion for the next WG meeting, would it be appropriate
to discuss a phased release process?  In such a process, the
functionality added at each stage is separately contained, modular for
maintenance purposes, and adds upon each other in a focused approach.
For example, by exposing Phase 1 sooner, then enterprise-specific
extensions can be worked on while the features in Phases 2 and 3 are
being developed further.

=20

To prompt discussion, here's one suggestion of how the work can be
broken down into phases:

=20

Phase 1 - Core Functionality

*         Setup a table that lists all power management entities (like
ENTITY-MIB, but for power entities, so perhaps POWER-ENTITY-MIB?)

o    Purpose of the table is focused on enumerating all entities that
support power management using a concise, flexible structure

o    Objects pass the test "Is this object necessary to describing all
power entities?"

o    Create a unique index value (pwrEntityIndex)

o    Link pwrEntityIndex with entPhysicalIndex, if ENTITY-MIB is
supported

o    Describe the entity with pwrEntityName, pwrEntityDescr,
pwrEntityType, and pwrEntityParent

=20

Phase 2 - State Functionality

*         Setup a sparse table that supports state monitoring/control of
power management entities (POWER-STATE-MIB?)

o    Purpose of the table is focused on providing state management of
power entities

o    Link to pwrEntityIndex

o    Describe the state with pwrStateLevel (off, on, tripped, shed,
reboot, ...?)

o    Describe the relative state with pwrStateRelLevel (0-100%?) and/or
pwrStateAcpiLevel (0..12?)

=20

Phase 3 - Meter Functionality

*         Setup a sparse table that supports power management entities
that report meter data (POWER-METER-MIB?)

o    Purpose of the table is focused on providing meter data for power
entities

o    Link to pwrEntityIndex

o    Structure TBD ... probably similar to POWER-MONITOR-MIB or
POWER-QUALITY-MIB

=20

Phase 4 - Configuration Control Functionality

*         Setup a sparse table that supports configuration parameters of
power management entities (POWER-CONFIG-MIB?)

o    Purpose of the table is focused on providing configuration
management of power entities

o    Link to pwrEntityIndex

o    Structure TBD ... probably based on the components of
ENERGY-AWARE-MIB not used in Phase 1

o    Describe the entity with pwrConfigKeywords, pwrConfigImportance,
pwrConfigRole, etc.

=20

If the development plan/approach isn't already on the agenda, is this
something we can add?  If there is a call-in to the meeting, I'd be
happy to participate remotely as a interested implementer.
(Unfortunately, Beijing is beyond my travel budget!  :-)

=20

Again, thank you for your work in establishing an industry standard in
this area!  Please let me know if there's anything I can do to help.

=20

Best regards,

=20

Chris


------_=_NextPart_001_01CB7770.54B3185F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi =
Mouli,
 
I guess =
my concern with the way it is currently broken down is that it appears =
to be “cluttered.”  For example, in ENERGY-AWARE-MIB, a =
good deal of the objects contained in the sequence are not obviously =
related to a generic power entity.  In fact, things like Importance =
and Role are almost directly descended from Cisco EnergyWise.  At =
what point do we break that away are truly focus on the =
“core”?
 
Chris
 
From:=
 =
Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] =

Sent: Thursday, October 28, 2010 10:46 PM
To: Chris =
Verges; eman@ietf.org
Subject: RE: [eman] EMAN MIB reviews and =
development process understanding
 
Hi Chris,
 
Thanks for your detailed =
comments.  
 
I think from a IETF WG =
perspective, I think the first step would be to arrive at a consensus on =
whether the proposed MIB variables would be sufficient and would meet =
the requirements for power management. 
 
From an implementation =
perspective,  I understand your phased approach. A probable =
solution to your question is perhaps consider having separate MIB =
modules -  
1.       =
Core =
functionality is covered by energy-aware-mib-00. =

2.       =
Power =
Metering and Power  states are grouped together - =
draft-claise-energy-monitoring-mib-06.  In addition, this module =
also contains energy/demand measurement. 
3.       =
Power =
Quality MIB – is already an optional MIB module in - =
draft-claise-energy-monitoring-mib-06. 
 
The convergence or =
adoption of these drafts (or MIB modules)  depends on the progress =
or consensus at the WG. 
 
Thanks
Mouli
 
 
From: eman-bounces@ietf.org =
[mailto:eman-bounces@ietf.org] On Behalf Of Chris =
Verges
Sent: Friday, October 29, 2010 5:04 AM
To: =
eman@ietf.org
Subject: [eman] EMAN MIB reviews and development =
process understanding
 
Hi EMAN =
WG,
 
I’ve been looking further into the =
ENERGY-AWARE-MIB, POWER-MONITOR-MIB, and POWER-QUALITY-MIB from an =
implementer’s perspective.  Speaking personally and not on =
behalf of my employer, I am extremely excited by the potential that =
these MIBs and the EMAN group has on simplifying power management.  =
A common schema for data reporting and control management will be =
awesome to finally get in place.
 
That =
being said, the three MIBs currently being proposed are definitely =
expansive.  Understanding their nuances and providing adequate =
reviews for all possible scenarios (intelligent PDUs, PoE network =
switches, PoE edge devices, etc.) seems to be challenges that could =
impact release dates.  I’m also a little confused with some =
of these MIBs, as they appear to have some overlapping scope/implied =
meaning.  As an implementer, I am eagerly poised to start coding =
these up, but want to ensure that they are going to meet my long-term =
needs without significant changes.
 
As an =
agenda suggestion for the next WG meeting, would it be appropriate to =
discuss a phased release process?  In such a process, the =
functionality added at each stage is separately contained, modular for =
maintenance purposes, and adds upon each other in a focused =
approach.  For example, by exposing Phase 1 sooner, then =
enterprise-specific extensions can be worked on while the features in =
Phases 2 and 3 are being developed further.
 
To =
prompt discussion, here’s one suggestion of how the work can be =
broken down into phases:
 
Phase 1 – Core =
Functionality
·  &nb=
sp;      Setup a table that lists all power =
management entities (like ENTITY-MIB, but for power entities, so perhaps =
POWER-ENTITY-MIB?)
o    =
Purpose of the table is focused on enumerating all entities that support =
power management using a concise, flexible structure
o    =
Objects pass the test “Is this object necessary to describing all =
power entities?”
o    =
Create a unique index value (pwrEntityIndex)
o    Link =
pwrEntityIndex with entPhysicalIndex, if ENTITY-MIB is =
supported
o    =
Describe the entity with pwrEntityName, pwrEntityDescr, pwrEntityType, =
and pwrEntityParent
 
Phase 2 – State =
Functionality
·  &nb=
sp;      Setup a sparse table that supports =
state monitoring/control of power management entities =
(POWER-STATE-MIB?)
o    =
Purpose of the table is focused on providing state management of power =
entities
o    Link =
to pwrEntityIndex
o    =
Describe the state with pwrStateLevel (off, on, tripped, shed, reboot, =
…?)
o    =
Describe the relative state with pwrStateRelLevel (0-100%?) and/or =
pwrStateAcpiLevel (0..12?)
 
Phase 3 – Meter =
Functionality
·  &nb=
sp;      Setup a sparse table that supports =
power management entities that report meter data =
(POWER-METER-MIB?)
o    =
Purpose of the table is focused on providing meter data for power =
entities
o    Link =
to pwrEntityIndex
o    =
Structure TBD … probably similar to POWER-MONITOR-MIB or =
POWER-QUALITY-MIB
 
Phase 4 – Configuration Control =
Functionality
·  &nb=
sp;      Setup a sparse table that supports =
configuration parameters of power management entities =
(POWER-CONFIG-MIB?)
o    =
Purpose of the table is focused on providing configuration management of =
power entities
o    Link =
to pwrEntityIndex
o    =
Structure TBD … probably based on the components of =
ENERGY-AWARE-MIB not used in Phase 1
o    =
Describe the entity with pwrConfigKeywords, pwrConfigImportance, =
pwrConfigRole, etc.
 
If the =
development plan/approach isn’t already on the agenda, is this =
something we can add?  If there is a call-in to the meeting, =
I’d be happy to participate remotely as a interested =
implementer.  (Unfortunately, Beijing is beyond my travel =
budget!  :-)
 
Again, =
thank you for your work in establishing an industry standard in this =
area!  Please let me know if there’s anything I can do to =
help.
 
Best regards,
 
Chris

------_=_NextPart_001_01CB7770.54B3185F--

From dromasca@avaya.com  Sun Oct 31 02:13:00 2010
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 665DF3A683C for ; Sun, 31 Oct 2010 02:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.533
X-Spam-Level: 
X-Spam-Status: No, score=-103.533 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 spvIEA3I0Z3G for ; Sun, 31 Oct 2010 02:12:52 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5615F3A67E5 for ; Sun, 31 Oct 2010 02:12:50 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADfQzEzGmAcF/2dsb2JhbACBRKAFcaESApkfhUQEjXU
X-IronPort-AV: E=Sophos;i="4.58,267,1286164800";  d="scan'208,217";a="216222859"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Oct 2010 05:14:47 -0400
X-IronPort-AV: E=Sophos;i="4.58,267,1286164800";  d="scan'208,217";a="534850585"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Oct 2010 05:14:46 -0400
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_01CB78DC.03BF3069"
Date: Sun, 31 Oct 2010 10:14:24 +0100
Message-ID: 
In-Reply-To: <68FBE0F3CE97264395875AC1C468F22C5146E3@mail03.cyberswitching.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [eman] EMAN MIB reviews and development process understanding
Thread-Index: Act2+JTb8us1t2UNQsyiaJAWx0mIFQB4pcQQ
References: <68FBE0F3CE97264395875AC1C468F22C5146E3@mail03.cyberswitching.local>
From: "Romascanu, Dan (Dan)" 
To: "Chris Verges" , 
Subject: Re: [eman] EMAN MIB reviews and development process understanding
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Oct 2010 09:13:00 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB78DC.03BF3069
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Chris,
=20
Speaking as a contributor, I like your phased approach proposal, with
the observation that the MIB modules that will be implemented need not
be (all) serialized from a development point of view. Modularity and
scalability of the model are however important features included in your
proposal.=20
=20
Concerning remote participation - we shall have an audio stream
available for people located remotely, and there will be a jabber room
that will allow remotely located participants to make comments and ask
questions. We shall probably also use WebEx but only to make the audio
available to remote participants and maybe also share presentations as
they are projected on the screen in the room, but not for voice comments
from remote participants.=20
=20
Please try to connect and participate remotely. The invitation is of
course directed to all WG participants who cannot make it to Beijing.=20
=20
Dan
=20


________________________________

	From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
Behalf Of Chris Verges
	Sent: Friday, October 29, 2010 1:34 AM
	To: eman@ietf.org
	Subject: [eman] EMAN MIB reviews and development process
understanding
=09
=09

	Hi EMAN WG,

	=20

	I've been looking further into the ENERGY-AWARE-MIB,
POWER-MONITOR-MIB, and POWER-QUALITY-MIB from an implementer's
perspective.  Speaking personally and not on behalf of my employer, I am
extremely excited by the potential that these MIBs and the EMAN group
has on simplifying power management.  A common schema for data reporting
and control management will be awesome to finally get in place.

	=20

	That being said, the three MIBs currently being proposed are
definitely expansive.  Understanding their nuances and providing
adequate reviews for all possible scenarios (intelligent PDUs, PoE
network switches, PoE edge devices, etc.) seems to be challenges that
could impact release dates.  I'm also a little confused with some of
these MIBs, as they appear to have some overlapping scope/implied
meaning.  As an implementer, I am eagerly poised to start coding these
up, but want to ensure that they are going to meet my long-term needs
without significant changes.

	=20

	As an agenda suggestion for the next WG meeting, would it be
appropriate to discuss a phased release process?  In such a process, the
functionality added at each stage is separately contained, modular for
maintenance purposes, and adds upon each other in a focused approach.
For example, by exposing Phase 1 sooner, then enterprise-specific
extensions can be worked on while the features in Phases 2 and 3 are
being developed further.

	=20

	To prompt discussion, here's one suggestion of how the work can
be broken down into phases:

	=20

	Phase 1 - Core Functionality

	*         Setup a table that lists all power management entities
(like ENTITY-MIB, but for power entities, so perhaps POWER-ENTITY-MIB?)

	o    Purpose of the table is focused on enumerating all entities
that support power management using a concise, flexible structure

	o    Objects pass the test "Is this object necessary to
describing all power entities?"

	o    Create a unique index value (pwrEntityIndex)

	o    Link pwrEntityIndex with entPhysicalIndex, if ENTITY-MIB is
supported

	o    Describe the entity with pwrEntityName, pwrEntityDescr,
pwrEntityType, and pwrEntityParent

	=20

	Phase 2 - State Functionality

	*         Setup a sparse table that supports state
monitoring/control of power management entities (POWER-STATE-MIB?)

	o    Purpose of the table is focused on providing state
management of power entities

	o    Link to pwrEntityIndex

	o    Describe the state with pwrStateLevel (off, on, tripped,
shed, reboot, ...?)

	o    Describe the relative state with pwrStateRelLevel (0-100%?)
and/or pwrStateAcpiLevel (0..12?)

	=20

	Phase 3 - Meter Functionality

	*         Setup a sparse table that supports power management
entities that report meter data (POWER-METER-MIB?)

	o    Purpose of the table is focused on providing meter data for
power entities

	o    Link to pwrEntityIndex

	o    Structure TBD ... probably similar to POWER-MONITOR-MIB or
POWER-QUALITY-MIB

	=20

	Phase 4 - Configuration Control Functionality

	*         Setup a sparse table that supports configuration
parameters of power management entities (POWER-CONFIG-MIB?)

	o    Purpose of the table is focused on providing configuration
management of power entities

	o    Link to pwrEntityIndex

	o    Structure TBD ... probably based on the components of
ENERGY-AWARE-MIB not used in Phase 1

	o    Describe the entity with pwrConfigKeywords,
pwrConfigImportance, pwrConfigRole, etc.

	=20

	If the development plan/approach isn't already on the agenda, is
this something we can add?  If there is a call-in to the meeting, I'd be
happy to participate remotely as a interested implementer.
(Unfortunately, Beijing is beyond my travel budget!  :-)

	=20

	Again, thank you for your work in establishing an industry
standard in this area!  Please let me know if there's anything I can do
to help.

	=20

	Best regards,

	=20

	Chris


------_=_NextPart_001_01CB78DC.03BF3069
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Hi=20
Chris,


 


Speaking as a contributor, I like your phased approach =
proposal, with=20
the observation that the MIB modules that will be implemented need not =
be (all)=20
serialized from a development point of view. Modularity and scalability =
of the=20
model are however important features included in your proposal.=20



 


Concerning remote participation - we shall have an audio =
stream=20
available for people located remotely, and there will be a jabber room =
that will=20
allow remotely located participants to make comments and ask questions. =
We shall=20
probably also use WebEx but only to make the audio available to remote=20
participants and maybe also share presentations as they are projected on =
the=20
screen in the room, but not for voice comments from remote participants. =




 


Please=20
try to connect and participate remotely. The invitation is of course =
directed to=20
all WG participants who cannot make it to Beijing. 


 


Dan


 



  

  

  From: eman-bounces@ietf.org=20
  [mailto:eman-bounces@ietf.org] On Behalf Of Chris=20
  Verges
Sent: Friday, October 29, 2010 1:34 AM
To:=20
  eman@ietf.org
Subject: [eman] EMAN MIB reviews and =
development=20
  process understanding


  

  

  
Hi EMAN=20
  WG,

  
 

  
I’ve been looking=20
  further into the ENERGY-AWARE-MIB, POWER-MONITOR-MIB, and =
POWER-QUALITY-MIB=20
  from an implementer’s perspective.  Speaking personally and =
not on behalf=20
  of my employer, I am extremely excited by the potential that these =
MIBs and=20
  the EMAN group has on simplifying power management.  A common =
schema for=20
  data reporting and control management will be awesome to finally get =
in=20
  place.

  
 

  
That =
being said,=20
  the three MIBs currently being proposed are definitely =
expansive. =20
  Understanding their nuances and providing adequate reviews for all =
possible=20
  scenarios (intelligent PDUs, PoE network switches, PoE edge devices, =
etc.)=20
  seems to be challenges that could impact release dates.  =
I’m also a=20
  little confused with some of these MIBs, as they appear to have some=20
  overlapping scope/implied meaning.  As an implementer, I am =
eagerly=20
  poised to start coding these up, but want to ensure that they are =
going to=20
  meet my long-term needs without significant =
changes.

  
 

  
As an =
agenda=20
  suggestion for the next WG meeting, would it be appropriate to discuss =
a=20
  phased release process?  In such a process, the functionality =
added at=20
  each stage is separately contained, modular for maintenance purposes, =
and adds=20
  upon each other in a focused approach.  For example, by exposing =
Phase 1=20
  sooner, then enterprise-specific extensions can be worked on while the =

  features in Phases 2 and 3 are being developed =
further.

  
 

  
To =
prompt=20
  discussion, here’s one suggestion of how the work can be broken =
down into=20
  phases:

  
 

  
Phase 1 =
– Core=20
  Functionality

  
·        =20
  Setup a =
table that=20
  lists all power management entities (like ENTITY-MIB, but for power =
entities,=20
  so perhaps POWER-ENTITY-MIB?)

  
o    =
Purpose =
of the=20
  table is focused on enumerating all entities that support power =
management=20
  using a concise, flexible structure

  
o    =
Objects =
pass the=20
  test “Is this object necessary to describing all power=20
  entities?”

  
o    =
Create a =
unique=20
  index value (pwrEntityIndex)

  
o    =
Link=20
  pwrEntityIndex with entPhysicalIndex, if ENTITY-MIB is=20
  supported

  
o    =
Describe =
the=20
  entity with pwrEntityName, pwrEntityDescr, pwrEntityType, and=20
  pwrEntityParent

  
 

  
Phase 2 =
– State=20
  Functionality

  
·        =20
  Setup a =
sparse=20
  table that supports state monitoring/control of power management =
entities=20
  (POWER-STATE-MIB?)

  
o    =
Purpose =
of the=20
  table is focused on providing state management of power=20
  entities

  
o    =
Link to=20
  pwrEntityIndex

  
o    =
Describe =
the state=20
  with pwrStateLevel (off, on, tripped, shed, reboot, =
…?)

  
o    =
Describe =
the=20
  relative state with pwrStateRelLevel (0-100%?) and/or =
pwrStateAcpiLevel=20
  (0..12?)

  
 

  
Phase 3 =
– Meter=20
  Functionality

  
·        =20
  Setup a =
sparse=20
  table that supports power management entities that report meter data=20
  (POWER-METER-MIB?)

  
o    =
Purpose =
of the=20
  table is focused on providing meter data for power=20
  entities

  
o    =
Link to=20
  pwrEntityIndex

  
o    =
Structure TBD …=20
  probably similar to POWER-MONITOR-MIB or=20
  POWER-QUALITY-MIB

  
 

  
Phase 4 =
–=20
  Configuration Control Functionality

  
·        =20
  Setup a =
sparse=20
  table that supports configuration parameters of power management =
entities=20
  (POWER-CONFIG-MIB?)

  
o    =
Purpose =
of the=20
  table is focused on providing configuration management of power=20
  entities

  
o    =
Link to=20
  pwrEntityIndex

  
o    =
Structure TBD …=20
  probably based on the components of ENERGY-AWARE-MIB not used in Phase =

  1

  
o    =
Describe =
the=20
  entity with pwrConfigKeywords, pwrConfigImportance, pwrConfigRole,=20
  etc.

  
 

  
If the =
development=20
  plan/approach isn’t already on the agenda, is this something we =
can add? =20
  If there is a call-in to the meeting, I’d be happy to =
participate remotely as=20
  a interested implementer.  (Unfortunately, Beijing is beyond my =
travel=20
  budget!  :-)

  
 

  
Again, =
thank you=20
  for your work in establishing an industry standard in this area!  =
Please=20
  let me know if there’s anything I can do to =
help.

  
 

  
Best=20
  regards,

  
 

  
Chris


------_=_NextPart_001_01CB78DC.03BF3069--

From Christian.Groves@nteczone.com  Sun Oct 31 20:12:38 2010
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 DA2A33A6889 for ; Sun, 31 Oct 2010 20:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
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 Wk9kTg8hWEHy for ; Sun, 31 Oct 2010 20:12:37 -0700 (PDT)
Received: from quasar.websiteactive.com (quasar.websiteactive.com [202.191.61.215]) by core3.amsl.com (Postfix) with ESMTP id 01DBD3A6882 for ; Sun, 31 Oct 2010 20:12:33 -0700 (PDT)
Received: from ppp118-209-116-69.lns20.mel4.internode.on.net ([118.209.116.69] helo=[127.0.0.1]) by quasar.websiteactive.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PCkov-0005AR-Vh for eman@ietf.org; Mon, 01 Nov 2010 14:12:30 +1100
Message-ID: <4CCE3065.6050705@nteczone.com>
Date: Mon, 01 Nov 2010 14:13:41 +1100
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: eman@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - quasar.websiteactive.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: 
Subject: Re: [eman] Entity identification method
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Nov 2010 03:12:38 -0000

Hello Juergen,

I think distinguishing the two cases is the correct way to go.

I agree that reporting energy consumption for logical entities is a 
challenge and not straight forward. I guess there are a number of ways 
to look at this problem and how address the problem depends on the 
ambition level.

As you rightly mention where there is partial use of a physical resource 
by a logical entity it is very difficult to have an exact figure.  
However I think the "grain size" of the measurement comes into play. For 
example if we have a large gateway implementing several virtual gateways 
if we take an overall measurement then we have the problem determining a 
figure. If the however the virtual gateways were each assigned a 
physical rack and the measurements were taken at a rack level then we 
have a more precise estimate of contribution of each virtual gateway to 
the overall picture.

For me logical entities ultimately will be realised by physical 
hardware. The key is understanding the relationship between these 
entities. Thus I think virtualization can in some way be supported by 
allowing energy consumption reports for physical entities to indicate 
if/what logical entities they relate to. As they say information is 
power (pardon the pun :-) ).

Regards, Christian

On 29/10/2010 12:48 PM, Juergen Quittek wrote:
> Hi Christian,
>
> Thank you for this interesting comment.
>
> It looks like we have to distinguish two cases: power state monitoring and
> energy consumption monitoring.
>
> For a logical entity and a virtual machine it may be well possible to report
> on their power state. However, reporting their energy consumption seems to
> be a tough challenge at least if be base it on real measurements.
>
> It is well feasible to measure energy consumption of physical entities, but
> if you have a logical entity that consumes only partial resources of a
> physical entity, then precise measurement of the energy consumption will be
> hardly possible. Estimations may be possible based on a model of the logical
> entity, but I don't know how good such models can be.
>
> Thanks,
>
>      Juergen
>
>
> On 29.10.10 03:25  "Christian Groves"  wrote:
>
>> Hello
>>
>> I've just started to digest the various drafts of the eman wg and I see
>> the comment below on logical entities. It's not clear to me how/if
>> network virtualization is intended on being handled in the eman work.
>>
>> In networks there's now a trend towards network virtualization and cloud
>> computing with the different "X" as a service models (i.e. Amazon EC2
>> "platform as a service" running different server instances). Even in
>> today's networks we have physical gateways that are virtualized into
>> different logical gateways. For example: H.248/Megaco virtual MG (VMG)
>> concept.
>>
>> I think it would be advantageous to be able to assess the energy
>> consumption of the VMGs or instances (which are logical entities)
>> independent of the physical gateway so that a customers energy use may
>> be recording. Will this sort of functionality be allowed?
>>
>> Regards, Christian
>>
>> On 29/10/2010 1:22 AM, Juergen Quittek wrote:
>>> Hi Chris,
>>>
>>> I think it may become very difficult if we want to assess energy consumption
>>> of logical entities. It seems to be reasonable and practical to limit energy
>>> consumption measurements to physical entities. The ENERGY AWARE MIB module
>>> (draft-parello-eman-energy-aware-mib) and the POWER MIB
>>> (draft-quittek-power-mib-02) went this way.
>>>
>>> Just using entPhysicalIndex solves some of the problem you mentioned.
>>> Particularly, you don't need a mapping table to entities if you restrict
>>> Yourself to entPhysicalIndex.
>>>
>>> Thanks,
>>>
>>>       Juergen
>>>
>>> On 28.10.10 13:34  "Chris Verges"   wrote:
>>>
>>>> Hi Jurgen and all,
>>>>
>>>> The more I've been thinking about these scenarios, the more something
>>>> doesn't seem quite right.  I'll try to explain my thought process behind
>>>> this and see if my concerns/confusions get captured.
>>>>
>>>> ENTITY-MIB provides enumerated lists of physical and logical entities on
>>>> the system.  The indices in both lists are maintained separately, so
>>>> there is not a single, unique identifier provided.  Because of this, the
>>>> MIBs being discussed by the EMAN WG must only reference to one type
>>>> (physical or logical) and are limited to that without additional work.
>>>> At some point in my mind, I'm asking myself the question, "What's the
>>>> point of linking to ENTITY-MIB?"
>>>>
>>>> More on that question in later scenarios below ...
>>>>
>>>> One possibility would be to create a separate mapping table that gives a
>>>> guaranteed unique index based on all entities, regardless of type.  The
>>>> physical vs. logical extensions would then become sparse tables that
>>>> augment this.  For example:
>>>>
>>>>     ENTITY-MIB : entityGeneral.entGeneralTable.entGeneralEntry
>>>>     +-----------------+-----------------+-----+
>>>>     | entGeneralIndex | entGeneralDescr | ... |
>>>>     +-----------------+-----------------+-----+
>>>>     |        1        | PDU Chassis     |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        2        | Meter #1        |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        3        | Meter #2        |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        4        | Remote Meter #1 |     |
>>>>     +-----------------+-----------------+-----+
>>>>
>>>>     ENTITY-MIB : entityPhysical.entPhysicalTable.entPhysicalEntry
>>>>     +-----------------+-----------------+-----+
>>>>     | entGeneralIndex | entVendorType   | ... |
>>>>     +-----------------+-----------------+-----+
>>>>     |        1        | enterprises.foo |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        2        | enterprises.foo |     |
>>>>     +-----------------+-----------------+-----+
>>>>     |        3        | enterprises.foo |     |
>>>>     +-----------------+-----------------+-----+
>>>>
>>>>     ENTITY-MIB : entityLogical.entLogicalTable.entLogicalEntry
>>>>     +-----------------+----------------------+-----+
>>>>     | entGeneralIndex | entLogicalCommunity  | ... |
>>>>     +-----------------+----------------------+-----+
>>>>     |        4        | remote-power-group-1 |     |
>>>>     +-----------------+----------------------+-----+
>>>>
>>>> It seems like this 'entGeneralIndex' concept is what's missing from the
>>>> current ENTITY-MIB, and is causing problems when thinking about local
>>>> and remote power data being reported by the same agent.
>>>>
>>>> Another possibility would be to choose one -- entLogicalIndex, most
>>>> likely -- and require that anyone who wants to implement the EMAN WG
>>>> MIBs to always create an entLogicalEntry for the power data.  In this
>>>> context, the entLogicalTable fills the role of entGeneralTable as
>>>> described above.  For all entPhysicalTable entries, there would need to
>>>> be a corresponding entry in entLogicalTable with a 1:1 mapping between
>>>> them.  For all remote entries, there would be a unique entry in
>>>> entLogicalTable.  Of course, this would add some additional overhead on
>>>> the part of the implementer, but isn't too overburdening.
>>>>
>>>> A third possibility is that ENTITY-MIB just doesn't do what we need in
>>>> its present form and we need to think about enumerating power sensors
>>>> separately from other components/sensors on the system.  It seems like
>>>> entPhysicalTable gives a good starting template for a new
>>>> 'POWER-ENTITY-MIB', but can be extended to include support for remote
>>>> agents.  The difference would be a clean break from the legacy
>>>> ENTITY-MIB structure.
>>>>
>>>> And with that, I look forward to others' feedback and ideas on solving
>>>> this problem!
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>> -----Original Message-----
>>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>>>> Chris Verges
>>>> Sent: Tuesday, October 26, 2010 9:26 PM
>>>> To: Juergen Quittek; Benoit Claise; eman mailing list
>>>> Subject: Re: [eman] Entity identification method (was: EMAN chartered
>>>> itemsversus drafts)
>>>>
>>>> Hi Juergen and all,
>>>>
>>>> Agreed that a common ID method makes sense, and ENTITY-MIB seems to be a
>>>> good choice.  In case (c) from your list, wouldn't the remote agent
>>>> condition be handled by ENTITY-MIB supporting a logical entity that is
>>>> the remote agent iself?  Since the logical entity is in the ENTITY-MIB
>>>> table, it would be given a unique ID mixed amongst the other logical and
>>>> physical entities.
>>>>
>>>> At that point, should all of the MIBs being discussed in the EMAN WG be
>>>> sparse table augmentations of ENTITY-MIB?
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>> -----Original Message-----
>>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>>>> Juergen Quittek
>>>> Sent: Tuesday, October 26, 2010 6:01 AM
>>>> To: Benoit Claise; eman mailing list
>>>> Subject: [eman] Entity identification method (was: EMAN chartered items
>>>> versus drafts)
>>>>
>>>> Hi Benoit and all,
>>>>
>>>> I agree that we should find a common identification method for entities
>>>> used by all MIB modules. This does not apply to the POWER MIB only, but
>>>> to all MIB modules in the eman WG.
>>>> The modules will use an entity ID as index for their tables.
>>>> Which entity is identified by the index can be resolved by other MIB
>>>> modules, such as the POWER AWARE MIB module
>>>> (draft-parello-eman-energy-aware-mib) or the ENTITY MIB module (RFC
>>>> 4133).
>>>>
>>>> I see three basic scenarios for the entity identification:
>>>>
>>>>     a) a device just reports on its own power state and energy
>>>>        consumption and it reports on its own as a single unit.
>>>>
>>>>        Then we have a single index only stating "it's me".
>>>>        Such a device usually does not need further identification
>>>>        of itself, because typically there are sufficient other
>>>>        MIB modules for this purpose running in the same SNMP engine,
>>>>        that provide information about the device's IP address,
>>>>        manufacturer, operating system, etc. In such a case a
>>>>        'trivial' index, such as '0' should be used in order to
>>>>        keep it simple in this most simple case.
>>>>
>>>>     b) a device reports on its own but not just as a single unit
>>>>        but it reports power states and energy consumption for its
>>>>        individual components, for example it may report separately
>>>>        on contained hard drives, line cards, back planes,
>>>>        processor boards, etc.
>>>>
>>>>        In such a case, identification of these components as
>>>>        individual entities would be required. The ENTITY MIB
>>>>        module was designed for this purpose and would be a good
>>>>        choice here. Also the POWER AWARE MIB module would be
>>>>        useful in this case.
>>>>
>>>>     c) a device reports on energy consumption of other, remote
>>>>        devices. Then remote devices (and potentially also their
>>>>        contained components need to be identified. For
>>>>        identifying remote components there is the POWER AWARE MIB
>>>>        module that has been designed for this purpose. As far as
>>>>        I understand, the ENTITY MIB module is not applicable to
>>>>        remote devices.
>>>>
>>>> In summary,
>>>>     - if you need to report on remote entities (case c)),
>>>>       you need the POWER AWARE MIB module,
>>>>     - if you report only on entities locally contained
>>>>       in the reporting device (case b)), you can use
>>>>       the POWER AWARE MIB or the ENTITY MIB
>>>>     - if you report just on your own as a single device
>>>>       (case a)), identification is trivial
>>>>
>>>> Hence, my recommendation (stated for POWER-STATE MIB and ENERGY MIB in
>>>> draft-quittek-power-mib-02) would be:
>>>>
>>>> If there is an implementation of the POWER AWARE MIB module instantiated
>>>> in the local SNMP engine, then you SHOULD (or MUST?) use it for indexing
>>>> (pmIndex).
>>>> If this is not the case but there is an ENTITY MIB instance available,
>>>> then you SHOULD use this one (entPhysicalIndex).
>>>> If neither of this MIB modules is available you should use index 0 only
>>>> and be limited to report on the local device as a single entity only.
>>>>
>>>> That's just my view. Certainly, there are more ways of entity
>>>> identification. I look forward to discussing them.
>>>>
>>>> Thanks,
>>>>
>>>>       Juergen
>>>>
>>>>
>>>> On 26.10.10 11:44  "Benoit Claise"   wrote:
>>>>
>>>>> Hi Juergen,
>>>>>
>>>>> Thanks for the clarification.
>>>>>
>>>>> Something key is to agree on the Power Monitor index for all MIB
>>>>> modules, which IMHO should be part of the Energy-aware Networks and
>>>>> Devices MIB module, but reuse in the other MIB modules.
>>>>>
>>>>> Regards, Benoit.
>>>>>> Hi Benoit,
>>>>>>
>>>>>> Thanks for checking all drafts.
>>>>>>
>>>>>> I don't think that draft-quittek-power-mib-02 makes significant
>>>>>> contributions to the Energy-aware Networks and Devices MIB.
>>>>>> It just covers the Power and Energy Monitoring MIB and the Battery
>>>> MIB.
>>>>>> Thanks,
>>>>>>        Juergen
>>>>>>
>>>>>>
>>>>>> On 26.10.10 08:22  "Benoit Claise"    wrote:
>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I went through the exercise of mapping the existing six chartered
>>>>>>> items with the existing draft content.
>>>>>>>
>>>>>>> _Energy Management Requirements_
>>>>>>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requiremen
>>>>>>> ts-02 https://datatracker.ietf.org/doc/draft-norwin-energy-consider/
>>>>>>> _
>>>>>>> Energy Management Framework_
>>>>>>> http://tools.ietf.org/html/draft-claise-power-management-arch-02
>>>>>>>
>>>>>>> _Energy-aware Networks and Devices MIB_
>>>>>>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
>>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>>>
>>>>>>> _Power and Energy Monitoring MIB_
>>>>>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
>>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>>>
>>>>>>> _Battery MIB_
>>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>>>
>>>>>>> _Energy Management Applicability_
>>>>>>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-stat
>>>>>>> ement/
>>>>>>>
>>>>>>> Please let me know if I made any mistakes or if I missed any draft?
>>>>>>>
>>>>>>> Regards, Benoit.
>>>>>>> _______________________________________________
>>>>>>> eman mailing list
>>>>>>> eman@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>>> _______________________________________________
>>>> eman mailing list
>>>> eman@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/eman
>>>
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman