From Quittek@neclab.eu Mon Oct 1 04:30:20 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDE221F857E for ; Mon, 1 Oct 2012 04:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.874 X-Spam-Level: X-Spam-Status: No, score=-100.874 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, MANGLED_LOW=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zMDBDW-FkCo for ; Mon, 1 Oct 2012 04:30:19 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E524021F850C for ; Mon, 1 Oct 2012 04:30:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 476FBFFF7B; Mon, 1 Oct 2012 13:30:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJjONNOBSoun; Mon, 1 Oct 2012 13:30:18 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 1E870FF93B; Mon, 1 Oct 2012 13:30:03 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.21]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 1 Oct 2012 13:30:02 +0200 From: Juergen Quittek To: Daniel Kharitonov , "John Parello (jparello)" , eman mailing list Thread-Topic: [eman] eman requirements: "max/average" to "typical" Thread-Index: AQHNn8gYrQnS4SMA0UO5b1wAWjGSBg== Date: Mon, 1 Oct 2012 11:30:02 +0000 Message-ID: In-Reply-To: <7C155ACE35869F4A953588C8A4657D7509EDA407@CH1PRD0510MB356.namprd05.prod.outlook.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <09587592286591448B31DE92AC941B5A@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] eman requirements: "max/average" to "typical" X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 11:30:20 -0000 Hi Daniel, So what is your recommnedation: Only have a "typical" power value for a power state? Thanks, Juergen On 29.09.12 04:24, "Daniel Kharitonov" wrote: > >If I may have one comment on power state in network devices, I would say >they are neither linear nor can be fully described with maximum and >average power use. > >The needed descriptive strings for power states should be at least >expressed as changes in operational properties - performance, latency and >such. A less obvious but critical parameter would the time to transition >in/out of this state. > >Example 1. > >A switch consists of interfaces, fabric, lookup engines and power >supplies. Each group of components may have one or more dimensions of >power states that can be changed independently. > >Note, that the knowledge of own power use for a group of components can >be incomplete and/or not sum up to a full system. > >Example 2. > >EnNMS is discovering a device that reports a set of power states along >with max/average power use. Since device describes neither performance >targets nor times to transition between them, EnNMS can only make a >decision based on desired power use in the device. This may lead to >mismatch between power state and device usability. > >________________________________________ >From: eman-bounces@ietf.org on behalf of Juergen Quittek >Sent: Thursday, September 27, 2012 11:45:14 AM >To: John Parello (jparello); eman mailing list >Subject: Re: [eman] eman requirements: "max/average" to "typical" > >Hi John, > >Thank you for your comment. This would look like > >OLD > 5.4.6. Maximum and average power per Power State > > The standard must provide means for retrieving the maximum power and > the average power for each supported Power State. These values may > be static. > >NEW > 5.4.6. Maximum and typical power per Power State > > The standard must provide means for retrieving the maximum power and > the typical power for each supported Power State. > >I don't think we need the sentence on values being static. > > >Who would have a problem with this version? > >Thanks, > Juergen > > >On 27.09.12 19:14, "John Parello (jparello)" wrote: > >>HI Juergen, >> >>Thanks. I agree that typical is more useful than average but you threw >>out max. >> >>In our implementations each power state has a maximum value that the >>device will use for that state. Typical and average is too lose a term >>for management. >> >>If I have three power states say low, medium, high and the device reports >>typical power as 10,20, and 30W. I have no way of knowing that if I set >>the device to low it will not exceed the 10W and run at 30W. >> >>We implemented the Max to allow device vendors to give specifics so that >>the mgt stations can have a hope of controlling the aggregate power. If >>you loosen the requirement to typical you effectively have no predictable >>control. >> >>Having Max is also in line with the way PoE states are communicated where >>depending on which PoE spec you implement you give 3 or 5 states and give >>the maximum at each state. >> >>So yes on typical over average but you must have max as well. >> >>Jp >> >> >> >> >>-----Original Message----- >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >>Juergen Quittek >>Sent: Thursday, September 27, 2012 5:17 AM >>To: eman mailing list >>Subject: [eman] eman requirements: "max/average" to "typical" >> >>Dear all, >> >>Here is an issue from discussing received comments on the eman >>requirements: >> >>The current version asks for means for reporting maximum and average >>power for each power state. The comment raised the point that these may >>not be well defined. Mouli and I discussed this and came up with the >>following >>proposal: >> >>OLD >> 5.4.6. Maximum and average power per Power State >> >> The standard must provide means for retrieving the maximum power and >> the average power for each supported Power State. These values may >> be static. >> >>NEW >> >> 5.4.6. Typical power per Power State >> >> The standard must provide means for retrieving the typical power for >> each supported Power State. >> >>The assumption is that a "typical" power meets more the requirements by >>an energy management system and would be more useful than a not well >>defined "average" value. >> >>Please give us your opinions on this proposal. >> >>Thanks, >> Juergen >> >>_______________________________________________ >>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 dkh@juniper.net Mon Oct 1 07:58:43 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55E1F0D0A for ; Mon, 1 Oct 2012 07:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEmmjugadSLq for ; Mon, 1 Oct 2012 07:58:42 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6E1F0CFD for ; Mon, 1 Oct 2012 07:58:41 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUGmvodXuEFlkyf/m0f5kgGbGehCjx2Wr@postini.com; Mon, 01 Oct 2012 07:58:42 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 1 Oct 2012 07:57:55 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 1 Oct 2012 07:57:55 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 1 Oct 2012 07:59:52 -0700 Received: from mail84-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Oct 2012 14:57:51 +0000 Received: from mail84-ch1 (localhost [127.0.0.1]) by mail84-ch1-R.bigfish.com (Postfix) with ESMTP id 1B3123200D2 for ; Mon, 1 Oct 2012 14:57:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371I542M1432I4015Izz1202h1d1ah1d2ah1082kzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail84-ch1 (localhost.localdomain [127.0.0.1]) by mail84-ch1 (MessageSwitch) id 1349103468987336_6748; Mon, 1 Oct 2012 14:57:48 +0000 (UTC) Received: from CH1EHSMHS040.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail84-ch1.bigfish.com (Postfix) with ESMTP id EF00F160061; Mon, 1 Oct 2012 14:57:48 +0000 (UTC) Received: from CH1PRD0510HT005.namprd05.prod.outlook.com (157.56.244.213) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 1 Oct 2012 14:57:45 +0000 Received: from CH1PRD0510MB356.namprd05.prod.outlook.com ([169.254.9.14]) by CH1PRD0510HT005.namprd05.prod.outlook.com ([10.255.150.40]) with mapi id 14.16.0190.008; Mon, 1 Oct 2012 14:57:45 +0000 From: Daniel Kharitonov To: Juergen Quittek , "John Parello (jparello)" , eman mailing list Thread-Topic: [eman] eman requirements: "max/average" to "typical" Thread-Index: AQHNnemIdQoo0JlqREqjJPb8fjLBj5ekVF4AgAA6CEs= Date: Mon, 1 Oct 2012 14:57:44 +0000 Message-ID: <7C155ACE35869F4A953588C8A4657D7509EDA954@CH1PRD0510MB356.namprd05.prod.outlook.com> References: <7C155ACE35869F4A953588C8A4657D7509EDA407@CH1PRD0510MB356.namprd05.prod.outlook.com>, In-Reply-To: Accept-Language: ru-RU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NECLAB.EU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [eman] eman requirements: "max/average" to "typical" X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:58:43 -0000 My recommendation is to reconsider the concept of "network device power sta= te" as a hierarchy of functional states to be discovered and used by EnNMS. The difference is that EnNMS should be setting the minimum functional level= of device based on the knowledge of current and future network situation, = with energy reduction as a consequence. In the current proposal, the EnNMS is expected to set the target energy con= sumption with no way to learn how this setting affects the function. This o= nly works if EnNMS already has extensive understanding of a managed network= device and somehow knows all functional restrictions of different power st= ates. ________________________________________ From: Juergen Quittek Sent: Monday, October 01, 2012 4:30:02 AM To: Daniel Kharitonov; John Parello (jparello); eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" Hi Daniel, So what is your recommnedation: Only have a "typical" power value for a power state? Thanks, Juergen On 29.09.12 04:24, "Daniel Kharitonov" wrote: > >If I may have one comment on power state in network devices, I would say >they are neither linear nor can be fully described with maximum and >average power use. > >The needed descriptive strings for power states should be at least >expressed as changes in operational properties - performance, latency and >such. A less obvious but critical parameter would the time to transition >in/out of this state. > >Example 1. > >A switch consists of interfaces, fabric, lookup engines and power >supplies. Each group of components may have one or more dimensions of >power states that can be changed independently. > >Note, that the knowledge of own power use for a group of components can >be incomplete and/or not sum up to a full system. > >Example 2. > >EnNMS is discovering a device that reports a set of power states along >with max/average power use. Since device describes neither performance >targets nor times to transition between them, EnNMS can only make a >decision based on desired power use in the device. This may lead to >mismatch between power state and device usability. > >________________________________________ >From: eman-bounces@ietf.org on behalf of Juergen Quittek >Sent: Thursday, September 27, 2012 11:45:14 AM >To: John Parello (jparello); eman mailing list >Subject: Re: [eman] eman requirements: "max/average" to "typical" > >Hi John, > >Thank you for your comment. This would look like > >OLD > 5.4.6. Maximum and average power per Power State > > The standard must provide means for retrieving the maximum power and > the average power for each supported Power State. These values may > be static. > >NEW > 5.4.6. Maximum and typical power per Power State > > The standard must provide means for retrieving the maximum power and > the typical power for each supported Power State. > >I don't think we need the sentence on values being static. > > >Who would have a problem with this version? > >Thanks, > Juergen > > >On 27.09.12 19:14, "John Parello (jparello)" wrote: > >>HI Juergen, >> >>Thanks. I agree that typical is more useful than average but you threw >>out max. >> >>In our implementations each power state has a maximum value that the >>device will use for that state. Typical and average is too lose a term >>for management. >> >>If I have three power states say low, medium, high and the device reports >>typical power as 10,20, and 30W. I have no way of knowing that if I set >>the device to low it will not exceed the 10W and run at 30W. >> >>We implemented the Max to allow device vendors to give specifics so that >>the mgt stations can have a hope of controlling the aggregate power. If >>you loosen the requirement to typical you effectively have no predictable >>control. >> >>Having Max is also in line with the way PoE states are communicated where >>depending on which PoE spec you implement you give 3 or 5 states and give >>the maximum at each state. >> >>So yes on typical over average but you must have max as well. >> >>Jp >> >> >> >> >>-----Original Message----- >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >>Juergen Quittek >>Sent: Thursday, September 27, 2012 5:17 AM >>To: eman mailing list >>Subject: [eman] eman requirements: "max/average" to "typical" >> >>Dear all, >> >>Here is an issue from discussing received comments on the eman >>requirements: >> >>The current version asks for means for reporting maximum and average >>power for each power state. The comment raised the point that these may >>not be well defined. Mouli and I discussed this and came up with the >>following >>proposal: >> >>OLD >> 5.4.6. Maximum and average power per Power State >> >> The standard must provide means for retrieving the maximum power and >> the average power for each supported Power State. These values may >> be static. >> >>NEW >> >> 5.4.6. Typical power per Power State >> >> The standard must provide means for retrieving the typical power for >> each supported Power State. >> >>The assumption is that a "typical" power meets more the requirements by >>an energy management system and would be more useful than a not well >>defined "average" value. >> >>Please give us your opinions on this proposal. >> >>Thanks, >> Juergen >> >>_______________________________________________ >>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 jparello@cisco.com Mon Oct 1 16:16:59 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF5C1F0CF9 for ; Mon, 1 Oct 2012 16:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwhar50NPrVg for ; Mon, 1 Oct 2012 16:16:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1DE1F0CC4 for ; Mon, 1 Oct 2012 16:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7209; q=dns/txt; s=iport; t=1349133418; x=1350343018; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=60NVpVa6Lw3abpSTrXnJYfx6s/1Hw6r0a98nLSQiNcg=; b=i2e8c15l/4rpbNfMDiDypZ97H/W6/srVFjqXQ7PWCA/VjQ0Pm9882M3s N5MeWykvl9VNuZcdd6s5vXJIgTkc6duDd3PvL8o7epS3bYmN0Qn37LhUw ZTk4+JfefexmC7FbTjKKdMXcg9ChwrVyHENsIyQOh70DsEPcoeA0X3c8N s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKIjalCtJV2c/2dsb2JhbABFvkuBCIIgAQEBBAEBAQ8BJzQCFQQCAQgOAwQBAQEKFAkHJwsUCQgCBAESCBqHYgELmRmgNQSLHxuDV4F5YAOkK4FpgloNghc X-IronPort-AV: E=Sophos;i="4.80,520,1344211200"; d="scan'208";a="127279437" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 01 Oct 2012 23:16:58 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q91NGw9v024848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Oct 2012 23:16:58 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.49]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 18:16:57 -0500 From: "John Parello (jparello)" To: Daniel Kharitonov , Juergen Quittek , eman mailing list Thread-Topic: [eman] eman requirements: "max/average" to "typical" Thread-Index: AQHNnemIdQoo0JlqREqjJPb8fjLBj5ekqC8AgAA6CACAADV9YA== Date: Mon, 1 Oct 2012 23:16:57 +0000 Message-ID: <9C213D38848B89428F46808B16F6F0860AD2C4@xmb-aln-x04.cisco.com> References: <7C155ACE35869F4A953588C8A4657D7509EDA407@CH1PRD0510MB356.namprd05.prod.outlook.com>, <7C155ACE35869F4A953588C8A4657D7509EDA954@CH1PRD0510MB356.namprd05.prod.outlook.com> In-Reply-To: <7C155ACE35869F4A953588C8A4657D7509EDA954@CH1PRD0510MB356.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19226.000 x-tm-as-result: No--53.287800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] eman requirements: "max/average" to "typical" X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 23:16:59 -0000 HI, I agree that any state of a device whether they be power state or operation= al state needs to have some context of what the device does and the consequ= ences of a change. What we've found in our implementations and deployments that a simple set o= f context variables (tags and a role) and a maximum power value for state a= re enough for a user of an EnNMS (and simple heuristics) to get significant= power/energy monitoring and control. We have very sophisticate systems bui= lt on these basic attributes. We've found these to be good enough as first start. We have deployments wi= th significant savings, response to demands, and scripted controls all base= d on these values (albeit it primitive) So I encourage the group to start with just simple context values (see fram= ework), typical power, and maximum power. A full modeling of states and con= sequences would be nice but I've yet to see a description proposed that wou= ld suffice significantly better than the simple model we've deployed. Jp =20 -----Original Message----- From: Daniel Kharitonov [mailto:dkh@juniper.net]=20 Sent: Monday, October 01, 2012 7:58 AM To: Juergen Quittek; John Parello (jparello); eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" My recommendation is to reconsider the concept of "network device power sta= te" as a hierarchy of functional states to be discovered and used by EnNMS. The difference is that EnNMS should be setting the minimum functional level= of device based on the knowledge of current and future network situation, = with energy reduction as a consequence. In the current proposal, the EnNMS is expected to set the target energy con= sumption with no way to learn how this setting affects the function. This o= nly works if EnNMS already has extensive understanding of a managed network= device and somehow knows all functional restrictions of different power st= ates. ________________________________________ From: Juergen Quittek Sent: Monday, October 01, 2012 4:30:02 AM To: Daniel Kharitonov; John Parello (jparello); eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" Hi Daniel, So what is your recommnedation: Only have a "typical" power value for a pow= er state? Thanks, Juergen On 29.09.12 04:24, "Daniel Kharitonov" wrote: > >If I may have one comment on power state in network devices, I would=20 >say they are neither linear nor can be fully described with maximum and=20 >average power use. > >The needed descriptive strings for power states should be at least=20 >expressed as changes in operational properties - performance, latency=20 >and such. A less obvious but critical parameter would the time to=20 >transition in/out of this state. > >Example 1. > >A switch consists of interfaces, fabric, lookup engines and power=20 >supplies. Each group of components may have one or more dimensions of=20 >power states that can be changed independently. > >Note, that the knowledge of own power use for a group of components can=20 >be incomplete and/or not sum up to a full system. > >Example 2. > >EnNMS is discovering a device that reports a set of power states along=20 >with max/average power use. Since device describes neither performance=20 >targets nor times to transition between them, EnNMS can only make a=20 >decision based on desired power use in the device. This may lead to=20 >mismatch between power state and device usability. > >________________________________________ >From: eman-bounces@ietf.org on behalf of Juergen Quittek >Sent: Thursday, September 27, 2012 11:45:14 AM >To: John Parello (jparello); eman mailing list >Subject: Re: [eman] eman requirements: "max/average" to "typical" > >Hi John, > >Thank you for your comment. This would look like > >OLD > 5.4.6. Maximum and average power per Power State > > The standard must provide means for retrieving the maximum power and > the average power for each supported Power State. These values may > be static. > >NEW > 5.4.6. Maximum and typical power per Power State > > The standard must provide means for retrieving the maximum power and > the typical power for each supported Power State. > >I don't think we need the sentence on values being static. > > >Who would have a problem with this version? > >Thanks, > Juergen > > >On 27.09.12 19:14, "John Parello (jparello)" wrote: > >>HI Juergen, >> >>Thanks. I agree that typical is more useful than average but you =20 >>threw out max. >> >>In our implementations each power state has a maximum value that the=20 >>device will use for that state. Typical and average is too lose a=20 >>term for management. >> >>If I have three power states say low, medium, high and the device=20 >>reports typical power as 10,20, and 30W. I have no way of knowing that=20 >>if I set the device to low it will not exceed the 10W and run at 30W. >> >>We implemented the Max to allow device vendors to give specifics so=20 >>that the mgt stations can have a hope of controlling the aggregate=20 >>power. If you loosen the requirement to typical you effectively have=20 >>no predictable control. >> >>Having Max is also in line with the way PoE states are communicated=20 >>where depending on which PoE spec you implement you give 3 or 5 states=20 >>and give the maximum at each state. >> >>So yes on typical over average but you must have max as well. >> >>Jp >> >> >> >> >>-----Original Message----- >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf=20 >>Of Juergen Quittek >>Sent: Thursday, September 27, 2012 5:17 AM >>To: eman mailing list >>Subject: [eman] eman requirements: "max/average" to "typical" >> >>Dear all, >> >>Here is an issue from discussing received comments on the eman >>requirements: >> >>The current version asks for means for reporting maximum and average=20 >>power for each power state. The comment raised the point that these=20 >>may not be well defined. Mouli and I discussed this and came up with=20 >>the following >>proposal: >> >>OLD >> 5.4.6. Maximum and average power per Power State >> >> The standard must provide means for retrieving the maximum power and >> the average power for each supported Power State. These values may >> be static. >> >>NEW >> >> 5.4.6. Typical power per Power State >> >> The standard must provide means for retrieving the typical power for >> each supported Power State. >> >>The assumption is that a "typical" power meets more the requirements=20 >>by an energy management system and would be more useful than a not=20 >>well defined "average" value. >> >>Please give us your opinions on this proposal. >> >>Thanks, >> Juergen >> >>_______________________________________________ >>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 dkh@juniper.net Mon Oct 1 17:28:22 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DD71F0D44 for ; Mon, 1 Oct 2012 17:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoxZDlkE5+jS for ; Mon, 1 Oct 2012 17:28:21 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 23A5F1F0D1D for ; Mon, 1 Oct 2012 17:28:21 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUGo1JE9XM1D3/93YVn48SzTToqR2RCCH@postini.com; Mon, 01 Oct 2012 17:28:21 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 1 Oct 2012 17:26:24 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 1 Oct 2012 17:26:24 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.181) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 1 Oct 2012 17:31:54 -0700 Received: from mail82-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 00:26:22 +0000 Received: from mail82-ch1 (localhost [127.0.0.1]) by mail82-ch1-R.bigfish.com (Postfix) with ESMTP id E3E554800E6 for ; Tue, 2 Oct 2012 00:26:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371I542M1432I4015Izz1202h1d1ah1d2ah1082kzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail82-ch1 (localhost.localdomain [127.0.0.1]) by mail82-ch1 (MessageSwitch) id 1349137581264182_23636; Tue, 2 Oct 2012 00:26:21 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail82-ch1.bigfish.com (Postfix) with ESMTP id 3DF39800AF; Tue, 2 Oct 2012 00:26:21 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 00:26:21 +0000 Received: from CH1PRD0510MB356.namprd05.prod.outlook.com ([169.254.9.14]) by CH1PRD0510HT004.namprd05.prod.outlook.com ([10.255.150.39]) with mapi id 14.16.0190.008; Tue, 2 Oct 2012 00:26:20 +0000 From: Daniel Kharitonov To: "John Parello (jparello)" , Juergen Quittek , eman mailing list Thread-Topic: [eman] eman requirements: "max/average" to "typical" Thread-Index: AQHNnemIdQoo0JlqREqjJPb8fjLBj5ekVF4AgAA6CEuAAIt6gIAAE2Pd Date: Tue, 2 Oct 2012 00:26:20 +0000 Message-ID: <7C155ACE35869F4A953588C8A4657D7509EDBA68@CH1PRD0510MB356.namprd05.prod.outlook.com> References: <7C155ACE35869F4A953588C8A4657D7509EDA407@CH1PRD0510MB356.namprd05.prod.outlook.com>, <7C155ACE35869F4A953588C8A4657D7509EDA954@CH1PRD0510MB356.namprd05.prod.outlook.com>, <9C213D38848B89428F46808B16F6F0860AD2C4@xmb-aln-x04.cisco.com> In-Reply-To: <9C213D38848B89428F46808B16F6F0860AD2C4@xmb-aln-x04.cisco.com> Accept-Language: ru-RU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NECLAB.EU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [eman] eman requirements: "max/average" to "typical" X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 00:28:22 -0000 John, I do see how this approach works for a PC or terminal with standartized and= well-known hardware. OTH, I do not see how it works for a generic network device. I will give an= example, so please look at it and respond with your implementation. Let's say we have a simple switch with redundant PS, lookup NPUs and 802.3a= z ports. Even in such a trivial case we have a hierarchy of components and their pro= perties - PS units can be selectively turned off for decreased power capaci= ty, NPU elements can be clock gated for lower performance and 802.3az ports= can be programmed for longer transit delays. If we (a vendor) are designing an energy MIB to manage such device, we cann= ot uniquely assign state S1 to one programming set (PS, NPUs, ports) and S2= to another and call it a day as the number of possible combinations grows = at exponential rate. But let's say we decided to wrap multi-dimensional internal capabilities of= a device to just two states, S1 and S2. Let's assume S1 means reduced numb= er of power supplies for total system power @X watts and S2 means S1 plus h= alf performance and twice the latency @Y watts, X>Y. Now, a 3rd party EnNMS can discover S1 and S2 but will not know the consequ= ences of S1 and S2 unless there is a mechanism to describe the tradeoffs as= sociated with such states. Thus, EnNMS no longer makes educated decisions. = It will either keep the device at S0 or will flip to S2 and risk losing the= user traffic. The issue quickly scales with increased device complexity and modularity as= we include fabric planes, routing engines, and more into the picture. So my suggestion to the group is to modify the draft with a concept of hier= archies of objects and tradeoff/scope description strings. If that is not possible, we should at least make this draft compatible with= EnNMS framework that goes beyond linear ACPI-style states as the latter ar= e not quite useful for independent NMS developers. ________________________________________ From: John Parello (jparello) Sent: Monday, October 01, 2012 4:16:57 PM To: Daniel Kharitonov; Juergen Quittek; eman mailing list Subject: RE: [eman] eman requirements: "max/average" to "typical" HI, I agree that any state of a device whether they be power state or operation= al state needs to have some context of what the device does and the consequ= ences of a change. What we've found in our implementations and deployments that a simple set o= f context variables (tags and a role) and a maximum power value for state a= re enough for a user of an EnNMS (and simple heuristics) to get significant= power/energy monitoring and control. We have very sophisticate systems bui= lt on these basic attributes. We've found these to be good enough as first start. We have deployments wi= th significant savings, response to demands, and scripted controls all base= d on these values (albeit it primitive) So I encourage the group to start with just simple context values (see fram= ework), typical power, and maximum power. A full modeling of states and con= sequences would be nice but I've yet to see a description proposed that wou= ld suffice significantly better than the simple model we've deployed. Jp -----Original Message----- From: Daniel Kharitonov [mailto:dkh@juniper.net] Sent: Monday, October 01, 2012 7:58 AM To: Juergen Quittek; John Parello (jparello); eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" My recommendation is to reconsider the concept of "network device power sta= te" as a hierarchy of functional states to be discovered and used by EnNMS. The difference is that EnNMS should be setting the minimum functional level= of device based on the knowledge of current and future network situation, = with energy reduction as a consequence. In the current proposal, the EnNMS is expected to set the target energy con= sumption with no way to learn how this setting affects the function. This o= nly works if EnNMS already has extensive understanding of a managed network= device and somehow knows all functional restrictions of different power st= ates. ________________________________________ From: Juergen Quittek Sent: Monday, October 01, 2012 4:30:02 AM To: Daniel Kharitonov; John Parello (jparello); eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" Hi Daniel, So what is your recommnedation: Only have a "typical" power value for a pow= er state? Thanks, Juergen On 29.09.12 04:24, "Daniel Kharitonov" wrote: > >If I may have one comment on power state in network devices, I would >say they are neither linear nor can be fully described with maximum and >average power use. > >The needed descriptive strings for power states should be at least >expressed as changes in operational properties - performance, latency >and such. A less obvious but critical parameter would the time to >transition in/out of this state. > >Example 1. > >A switch consists of interfaces, fabric, lookup engines and power >supplies. Each group of components may have one or more dimensions of >power states that can be changed independently. > >Note, that the knowledge of own power use for a group of components can >be incomplete and/or not sum up to a full system. > >Example 2. > >EnNMS is discovering a device that reports a set of power states along >with max/average power use. Since device describes neither performance >targets nor times to transition between them, EnNMS can only make a >decision based on desired power use in the device. This may lead to >mismatch between power state and device usability. > >________________________________________ >From: eman-bounces@ietf.org on behalf of Juergen Quittek >Sent: Thursday, September 27, 2012 11:45:14 AM >To: John Parello (jparello); eman mailing list >Subject: Re: [eman] eman requirements: "max/average" to "typical" > >Hi John, > >Thank you for your comment. This would look like > >OLD > 5.4.6. Maximum and average power per Power State > > The standard must provide means for retrieving the maximum power and > the average power for each supported Power State. These values may > be static. > >NEW > 5.4.6. Maximum and typical power per Power State > > The standard must provide means for retrieving the maximum power and > the typical power for each supported Power State. > >I don't think we need the sentence on values being static. > > >Who would have a problem with this version? > >Thanks, > Juergen > > >On 27.09.12 19:14, "John Parello (jparello)" wrote: > >>HI Juergen, >> >>Thanks. I agree that typical is more useful than average but you >>threw out max. >> >>In our implementations each power state has a maximum value that the >>device will use for that state. Typical and average is too lose a >>term for management. >> >>If I have three power states say low, medium, high and the device >>reports typical power as 10,20, and 30W. I have no way of knowing that >>if I set the device to low it will not exceed the 10W and run at 30W. >> >>We implemented the Max to allow device vendors to give specifics so >>that the mgt stations can have a hope of controlling the aggregate >>power. If you loosen the requirement to typical you effectively have >>no predictable control. >> >>Having Max is also in line with the way PoE states are communicated >>where depending on which PoE spec you implement you give 3 or 5 states >>and give the maximum at each state. >> >>So yes on typical over average but you must have max as well. >> >>Jp >> >> >> >> >>-----Original Message----- >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf >>Of Juergen Quittek >>Sent: Thursday, September 27, 2012 5:17 AM >>To: eman mailing list >>Subject: [eman] eman requirements: "max/average" to "typical" >> >>Dear all, >> >>Here is an issue from discussing received comments on the eman >>requirements: >> >>The current version asks for means for reporting maximum and average >>power for each power state. The comment raised the point that these >>may not be well defined. Mouli and I discussed this and came up with >>the following >>proposal: >> >>OLD >> 5.4.6. Maximum and average power per Power State >> >> The standard must provide means for retrieving the maximum power and >> the average power for each supported Power State. These values may >> be static. >> >>NEW >> >> 5.4.6. Typical power per Power State >> >> The standard must provide means for retrieving the typical power for >> each supported Power State. >> >>The assumption is that a "typical" power meets more the requirements >>by an energy management system and would be more useful than a not >>well defined "average" value. >> >>Please give us your opinions on this proposal. >> >>Thanks, >> Juergen >> >>_______________________________________________ >>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 bnordman@lbl.gov Mon Oct 1 20:56:52 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0174E21F8AB6 for ; Mon, 1 Oct 2012 20:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.826 X-Spam-Level: X-Spam-Status: No, score=-4.826 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdteR5O5HLQM for ; Mon, 1 Oct 2012 20:56:50 -0700 (PDT) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 45AE321F88BB for ; Mon, 1 Oct 2012 20:56:50 -0700 (PDT) X-Ironport-SBRS: 4.7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwBAMBlalDRVdQsk2dsb2JhbABCA4JLsygBiF8IIwEBAQEJCQsJFAQjgiABAQEDAQEBAQ8CBlQCCQwECwsDAwQBAQEnByIFDQEFAQsJCAYTCBqHXQYLmmYJA58Bix8bgwuDJQOIWI0RgRWNNxYphCc X-IronPort-AV: E=Sophos;i="4.80,521,1344236400"; d="scan'208";a="87537219" Received: from mail-vb0-f44.google.com ([209.85.212.44]) by ironport3.lbl.gov with ESMTP; 01 Oct 2012 20:56:48 -0700 Received: by vbbfc26 with SMTP id fc26so6959983vbb.31 for ; Mon, 01 Oct 2012 20:56:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=gBDtzpx4qu1N5H5TkrgudKkMtnmpurTwddh45UxMBzQ=; b=SVnS1XXLPRynMLPWcIqg6gGfrcZBN8ivtnYeyHttFYRckQ8siGxb+C67pDNN9o7Yoj GkJA+TitFgwKloBbOyfdvlqrOhnDmt1cb6Nrfv59KyrmjkJKmskNUfNV3jvpaS5hylWg 5tSAXWfpDypdnkdZsFtzyKizeE9G6fqI0G2Aph1iy8DZGQ/+RTNJEO9LN55/I41visbs oEQussYZGBWjTbWP03vScezlHGdmsIY3hHSJhIVZPhRYrsip0KahbuniWZt0lJ9eGMCE OLpXo8AOShtxo2vnuQgHvKg1u9gH8WzVLVoGnSNB/ov+p7FEh7sdJAL6dVffvd0+NXwT 9JUg== MIME-Version: 1.0 Received: by 10.58.35.166 with SMTP id i6mr9845359vej.10.1349150207773; Mon, 01 Oct 2012 20:56:47 -0700 (PDT) Received: by 10.58.125.73 with HTTP; Mon, 1 Oct 2012 20:56:47 -0700 (PDT) In-Reply-To: <7C155ACE35869F4A953588C8A4657D7509EDBA68@CH1PRD0510MB356.namprd05.prod.outlook.com> References: <7C155ACE35869F4A953588C8A4657D7509EDA407@CH1PRD0510MB356.namprd05.prod.outlook.com> <7C155ACE35869F4A953588C8A4657D7509EDA954@CH1PRD0510MB356.namprd05.prod.outlook.com> <9C213D38848B89428F46808B16F6F0860AD2C4@xmb-aln-x04.cisco.com> <7C155ACE35869F4A953588C8A4657D7509EDBA68@CH1PRD0510MB356.namprd05.prod.outlook.com> Date: Mon, 1 Oct 2012 20:56:47 -0700 Message-ID: From: Bruce Nordman To: Daniel Kharitonov Content-Type: multipart/alternative; boundary=047d7b5d4c40e20acc04cb0b82be X-Gm-Message-State: ALoCoQn4GQXgDPTkn5EQO/KhRxdepO+4bJCn6Deb4NZfun5srzy1PN4h01Mg+Zyv4iHadGN3Gt72 Cc: eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 03:56:52 -0000 --047d7b5d4c40e20acc04cb0b82be Content-Type: text/plain; charset=ISO-8859-1 Apart from this discussion, the "typical" as is being proposed rather than "average" seems like a good choice. Daniel-- I do appreciate that there are contexts that need the sophistication that you describe, but I think that that sort of management is really about the functional purpose of the devices in question first, and energy only secondary. I think there are real limits to how much we can or should try to do in an energy-centric context like EMAN. I think that a precise definition of "maximum" would be difficult or more likely impossible to create that would span the full range of products that EMAN covers. The text for "nameplate" that we now have that defines it as a manufacturer rating I think is the best model we have for this. --Bruce On Mon, Oct 1, 2012 at 5:26 PM, Daniel Kharitonov wrote: > > John, > > I do see how this approach works for a PC or terminal with standartized > and well-known hardware. > > OTH, I do not see how it works for a generic network device. I will give > an example, so please look at it and respond with your implementation. > > Let's say we have a simple switch with redundant PS, lookup NPUs and > 802.3az ports. > > Even in such a trivial case we have a hierarchy of components and their > properties - PS units can be selectively turned off for decreased power > capacity, NPU elements can be clock gated for lower performance and 802.3az > ports can be programmed for longer transit delays. > > If we (a vendor) are designing an energy MIB to manage such device, we > cannot uniquely assign state S1 to one programming set (PS, NPUs, ports) > and S2 to another and call it a day as the number of possible combinations > grows at exponential rate. > > But let's say we decided to wrap multi-dimensional internal capabilities > of a device to just two states, S1 and S2. Let's assume S1 means reduced > number of power supplies for total system power @X watts and S2 means S1 > plus half performance and twice the latency @Y watts, X>Y. > > Now, a 3rd party EnNMS can discover S1 and S2 but will not know the > consequences of S1 and S2 unless there is a mechanism to describe the > tradeoffs associated with such states. Thus, EnNMS no longer makes educated > decisions. It will either keep the device at S0 or will flip to S2 and risk > losing the user traffic. > > The issue quickly scales with increased device complexity and modularity > as we include fabric planes, routing engines, and more into the picture. > > So my suggestion to the group is to modify the draft with a concept of > hierarchies of objects and tradeoff/scope description strings. > > If that is not possible, we should at least make this draft compatible > with EnNMS framework that goes beyond linear ACPI-style states as the > latter are not quite useful for independent NMS developers. > > > ________________________________________ > From: John Parello (jparello) > Sent: Monday, October 01, 2012 4:16:57 PM > To: Daniel Kharitonov; Juergen Quittek; eman mailing list > Subject: RE: [eman] eman requirements: "max/average" to "typical" > > HI, > > I agree that any state of a device whether they be power state or > operational state needs to have some context of what the device does and > the consequences of a change. > > What we've found in our implementations and deployments that a simple set > of context variables (tags and a role) and a maximum power value for state > are enough for a user of an EnNMS (and simple heuristics) to get > significant power/energy monitoring and control. We have very sophisticate > systems built on these basic attributes. > > We've found these to be good enough as first start. We have deployments > with significant savings, response to demands, and scripted controls all > based on these values (albeit it primitive) > > So I encourage the group to start with just simple context values (see > framework), typical power, and maximum power. A full modeling of states and > consequences would be nice but I've yet to see a description proposed that > would suffice significantly better than the simple model we've deployed. > > Jp > > > > > > -----Original Message----- > From: Daniel Kharitonov [mailto:dkh@juniper.net] > Sent: Monday, October 01, 2012 7:58 AM > To: Juergen Quittek; John Parello (jparello); eman mailing list > Subject: Re: [eman] eman requirements: "max/average" to "typical" > > > My recommendation is to reconsider the concept of "network device power > state" as a hierarchy of functional states to be discovered and used by > EnNMS. > > The difference is that EnNMS should be setting the minimum functional > level of device based on the knowledge of current and future network > situation, with energy reduction as a consequence. > > In the current proposal, the EnNMS is expected to set the target energy > consumption with no way to learn how this setting affects the function. > This only works if EnNMS already has extensive understanding of a managed > network device and somehow knows all functional restrictions of different > power states. > > > ________________________________________ > From: Juergen Quittek > Sent: Monday, October 01, 2012 4:30:02 AM > To: Daniel Kharitonov; John Parello (jparello); eman mailing list > Subject: Re: [eman] eman requirements: "max/average" to "typical" > > Hi Daniel, > > So what is your recommnedation: Only have a "typical" power value for a > power state? > > Thanks, > Juergen > > On 29.09.12 04:24, "Daniel Kharitonov" wrote: > > > > >If I may have one comment on power state in network devices, I would > >say they are neither linear nor can be fully described with maximum and > >average power use. > > > >The needed descriptive strings for power states should be at least > >expressed as changes in operational properties - performance, latency > >and such. A less obvious but critical parameter would the time to > >transition in/out of this state. > > > >Example 1. > > > >A switch consists of interfaces, fabric, lookup engines and power > >supplies. Each group of components may have one or more dimensions of > >power states that can be changed independently. > > > >Note, that the knowledge of own power use for a group of components can > >be incomplete and/or not sum up to a full system. > > > >Example 2. > > > >EnNMS is discovering a device that reports a set of power states along > >with max/average power use. Since device describes neither performance > >targets nor times to transition between them, EnNMS can only make a > >decision based on desired power use in the device. This may lead to > >mismatch between power state and device usability. > > > >________________________________________ > >From: eman-bounces@ietf.org on behalf of Juergen Quittek > >Sent: Thursday, September 27, 2012 11:45:14 AM > >To: John Parello (jparello); eman mailing list > >Subject: Re: [eman] eman requirements: "max/average" to "typical" > > > >Hi John, > > > >Thank you for your comment. This would look like > > > >OLD > > 5.4.6. Maximum and average power per Power State > > > > The standard must provide means for retrieving the maximum power and > > the average power for each supported Power State. These values may > > be static. > > > >NEW > > 5.4.6. Maximum and typical power per Power State > > > > The standard must provide means for retrieving the maximum power and > > the typical power for each supported Power State. > > > >I don't think we need the sentence on values being static. > > > > > >Who would have a problem with this version? > > > >Thanks, > > Juergen > > > > > >On 27.09.12 19:14, "John Parello (jparello)" wrote: > > > >>HI Juergen, > >> > >>Thanks. I agree that typical is more useful than average but you > >>threw out max. > >> > >>In our implementations each power state has a maximum value that the > >>device will use for that state. Typical and average is too lose a > >>term for management. > >> > >>If I have three power states say low, medium, high and the device > >>reports typical power as 10,20, and 30W. I have no way of knowing that > >>if I set the device to low it will not exceed the 10W and run at 30W. > >> > >>We implemented the Max to allow device vendors to give specifics so > >>that the mgt stations can have a hope of controlling the aggregate > >>power. If you loosen the requirement to typical you effectively have > >>no predictable control. > >> > >>Having Max is also in line with the way PoE states are communicated > >>where depending on which PoE spec you implement you give 3 or 5 states > >>and give the maximum at each state. > >> > >>So yes on typical over average but you must have max as well. > >> > >>Jp > >> > >> > >> > >> > >>-----Original Message----- > >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > >>Of Juergen Quittek > >>Sent: Thursday, September 27, 2012 5:17 AM > >>To: eman mailing list > >>Subject: [eman] eman requirements: "max/average" to "typical" > >> > >>Dear all, > >> > >>Here is an issue from discussing received comments on the eman > >>requirements: > >> > >>The current version asks for means for reporting maximum and average > >>power for each power state. The comment raised the point that these > >>may not be well defined. Mouli and I discussed this and came up with > >>the following > >>proposal: > >> > >>OLD > >> 5.4.6. Maximum and average power per Power State > >> > >> The standard must provide means for retrieving the maximum power and > >> the average power for each supported Power State. These values may > >> be static. > >> > >>NEW > >> > >> 5.4.6. Typical power per Power State > >> > >> The standard must provide means for retrieving the typical power for > >> each supported Power State. > >> > >>The assumption is that a "typical" power meets more the requirements > >>by an energy management system and would be more useful than a not > >>well defined "average" value. > >> > >>Please give us your opinions on this proposal. > >> > >>Thanks, > >> Juergen > >> > >>_______________________________________________ > >>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 > -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b5d4c40e20acc04cb0b82be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Apart from this discussion, the "typical" as is being proposed ra= ther than "average"
seems like a good choice.

Daniel--<= br>=A0 I do appreciate that there are contexts that need the sophistication= that
you describe, but I think that that sort of management is really about the<= br>functional purpose of the devices in question first, and energy only sec= ondary.
I think there are real limits to how much we can or should try t= o do in an
energy-centric context like EMAN.
=A0 I think that a precise definition = of "maximum" would be difficult or more
likely impossible to c= reate that would span the full range of products that
EMAN covers.=A0 Th= e text for "nameplate" that we now have that defines it
as a manufacturer rating I think is the best model we have for this.
--B= ruce

On Mon, Oct 1, 2012 at 5:26 PM, Dani= el Kharitonov <dkh@juniper.net> wrote:

John,

I do see how this approach works for a PC or terminal with standartized and= well-known hardware.

OTH, I do not see how it works for a generic network device. I will give an= example, so please look at it and respond with your implementation.

Let's say we have a simple switch with redundant PS, lookup NPUs and 80= 2.3az ports.

Even in such a trivial case we have a hierarchy of components and their pro= perties - PS units can be selectively turned off for decreased power capaci= ty, NPU elements can be clock gated for lower performance and 802.3az ports= can be programmed for longer transit delays.

If we (a vendor) are designing an energy MIB to manage such device, we cann= ot uniquely assign state S1 to one programming set (PS, NPUs, ports) and S2= to another and call it a day as the number of possible combinations grows = at exponential rate.

But let's say we decided to wrap multi-dimensional internal capabilitie= s of a device to just two states, S1 and S2. Let's assume S1 means redu= ced number of power supplies for total system power @X watts and S2 means S= 1 plus half performance and twice the latency @Y watts, X>Y.

Now, a 3rd party EnNMS can discover S1 and S2 but will not know the consequ= ences of S1 and S2 unless there is a mechanism to describe the tradeoffs as= sociated with such states. Thus, EnNMS no longer makes educated decisions. = It will either keep the device at S0 or will flip to S2 and risk losing the= user traffic.

The issue quickly scales with increased device complexity and modularity as= we include fabric planes, routing engines, =A0and more into the picture.
So my suggestion to the group is to modify the draft with a concept of hier= archies of objects and tradeoff/scope description strings.

If that is not possible, we should at least make this draft compatible with= EnNMS framework that goes beyond linear ACPI-style states as the latter ar= e not quite useful for independent NMS developers.


________________________________________
From: John Parello (jparello)
Sent: Monday, October 01, 2012 4:16:57 PM
To: Daniel Kharitonov; Juergen Quittek; eman mailing list
Subject: RE: [eman] eman requirements: "max/average" to "typ= ical"

HI,

I agree that any state of a device whether they be power state or operation= al state needs to have some context of what the device does and the consequ= ences of a change.

What we've found in our implementations and deployments that a simple s= et of context variables (tags and a role) and a maximum power value for sta= te are enough for a user of an EnNMS (and simple heuristics) to get signifi= cant power/energy monitoring and control. We have very sophisticate systems= built on these basic attributes.

We've found these to be good enough as =A0first start. We have deployme= nts with significant savings, response to demands, and scripted controls al= l based on these values (albeit it primitive)

So I encourage the group to start with just simple context values (see fram= ework), typical power, and maximum power. A full modeling of states and con= sequences would be nice but I've yet to see a description proposed that= would suffice significantly =A0better than the simple model we've depl= oyed.

Jp





-----Original Message-----
From: Daniel Kharitonov [mailto:dkh@juni= per.net]
Sent: Monday, October 01, 2012 7:58 AM
To: Juergen Quittek; John Parello (jparello); eman mailing list
Subject: Re: [eman] eman requirements: "max/average" to "typ= ical"


My recommendation is to reconsider the concept of "network device powe= r state" as a hierarchy of functional states to be discovered and used= by EnNMS.

The difference is that EnNMS should be setting the minimum functional level= of device based on the knowledge of current and future network situation, = with energy reduction as a consequence.

In the current proposal, the EnNMS is expected to set the target energy con= sumption with no way to learn how this setting affects the function. This o= nly works if EnNMS already has extensive understanding of a managed network= device and somehow knows all functional restrictions of different power st= ates.


________________________________________
From: Juergen Quittek
Sent: Monday, October 01, 2012 4:30:02 AM
To: Daniel Kharitonov; John Parello (jparello); eman mailing list
Subject: Re: [eman] eman requirements: "max/average" to "typ= ical"

Hi Daniel,

So what is your recommnedation: Only have a "typical" power value= for a power state?

Thanks,
=A0 =A0 Juergen

On 29.09.12 04:24, "Daniel Kharitonov" <dkh@juniper.net> wrote:

>
>If I may have one comment on power state in network devices, I would >say they are neither linear nor can be fully described with maximum and=
>average power use.
>
>The needed descriptive strings for power states should be at least
>expressed as changes in operational properties - performance, latency >and such. A less obvious but critical parameter would the time to
>transition in/out of this state.
>
>Example 1.
>
>A switch consists of interfaces, fabric, lookup engines and power
>supplies. Each group of components may have one or more dimensions of >power states that can be changed independently.
>
>Note, that the knowledge of own power use for a group of components can=
>be incomplete and/or not sum up to a full system.
>
>Example 2.
>
>EnNMS is discovering a device that reports a set of power states along<= br> >with max/average power use. Since device describes neither performance<= br> >targets nor times to transition between them, EnNMS can only make a
>decision based on desired power use in the device. This may lead to
>mismatch between power state and device usability.
>
>________________________________________
>From: eman-bounces@ietf.org on behalf of Juergen Quittek
>Sent: Thursday, September 27, 2012 11:45:14 AM
>To: John Parello (jparello); eman mailing list
>Subject: Re: [eman] eman requirements: "max/average" to "= ;typical"
>
>Hi John,
>
>Thank you for your comment. =A0This would look like
>
>OLD
> =A0 5.4.6. =A0Maximum and average power per Power State
>
> =A0 The standard must provide means for retrieving the maximum power a= nd
> =A0 the average power for each supported Power State. =A0These values = may
> =A0 be static.
>
>NEW
> =A0 5.4.6. Maximum and typical power per Power State
>
> =A0 The standard must provide means for retrieving the maximum power a= nd
> =A0 the typical power for each supported Power State.
>
>I don't think we need the sentence on values being static.
>
>
>Who would have a problem with this version?
>
>Thanks,
> =A0 =A0Juergen
>
>
>On 27.09.12 19:14, "John Parello (jparello)" <jparello@cisco.com> wrote:
>
>>HI Juergen,
>>
>>Thanks. I agree that typical is more useful than average but you >>threw out max.
>>
>>In our implementations each power state has a maximum value that th= e
>>device will use for that state. Typical =A0and average is too lose = a
>>term for management.
>>
>>If I have three power states say low, medium, high and the device >>reports typical power as 10,20, and 30W. I have no way of knowing t= hat
>>if I set the device to low it will not exceed the 10W and run at = =A030W.
>>
>>We implemented the Max to allow device vendors to give specifics so=
>>that the mgt stations can have a hope of controlling the aggregate<= br> >>power. If you loosen the requirement to typical you effectively hav= e
>>no predictable control.
>>
>>Having Max is also in line with the way PoE states are communicated=
>>where depending on which PoE spec you implement you give 3 or 5 sta= tes
>>and give the maximum at each state.
>>
>>So yes on typical over average but you must have =A0max as well. >>
>>Jp
>>
>>
>>
>>
>>-----Original Message-----
>>From: eman-bounces@ietf.or= g [mailto:eman-bounces@ietf.or= g] On Behalf
>>Of Juergen Quittek
>>Sent: Thursday, September 27, 2012 5:17 AM
>>To: eman mailing list
>>Subject: [eman] eman requirements: "max/average" to "= ;typical"
>>
>>Dear all,
>>
>>Here is an issue from discussing received comments on the eman
>>requirements:
>>
>>The current version asks for means for reporting maximum and averag= e
>>power for each power state. =A0The comment raised the point that th= ese
>>may not be well defined. =A0Mouli and I discussed this and came up = with
>>the following
>>proposal:
>>
>>OLD
>> =A0 5.4.6. =A0Maximum and average power per Power State
>>
>> =A0 The standard must provide means for retrieving the maximum pow= er and
>> =A0 the average power for each supported Power State. =A0These val= ues may
>> =A0 be static.
>>
>>NEW
>>
>> =A0 5.4.6. =A0Typical power per Power State
>>
>> =A0 The standard must provide means for retrieving the typical pow= er for
>> =A0 each supported Power State.
>>
>>The assumption is that a "typical" power meets more the r= equirements
>>by an energy management system and would be more useful than a not<= br> >>well defined "average" value.
>>
>>Please give us your opinions on this proposal.
>>
>>Thanks,
>> =A0 =A0Juergen
>>
>>_______________________________________________
>>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
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
La= wrence Berkeley National Laboratory
nordman.lbl.g= ov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--047d7b5d4c40e20acc04cb0b82be-- From jparello@cisco.com Tue Oct 2 17:07:01 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C11921F8625 for ; Tue, 2 Oct 2012 17:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrJ-JgmtcQxV for ; Tue, 2 Oct 2012 17:07:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 525D221F8620 for ; Tue, 2 Oct 2012 17:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10441; q=dns/txt; s=iport; t=1349222820; x=1350432420; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BYwjnNstOAs4Qh/IFoDd2vqJLrL8lvOzUkHluWIphZM=; b=AHmfuCQLPQphrsPnfKEjcDMOxdk6rGiUhINPEygOAhSbY3fcPtzzyUwF dCmZTtDuI3JpKJ/FFQyaVboxkdnAeMFgmRsXcYeDgC+U6CJUGd+8cfewq YUPsONfxI3OE3/MdGbOxIFCmb7JBTrDuzAIe7iuL5NwYQSi0brCOqhLhr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJOAa1CtJV2c/2dsb2JhbABFvmeBCIIgAQEBBAEBAQ8BJzQCFQQCAQgOAwQBAQEKFAkHJwsUCQgCBAESCBqHYgELl3mRZY45BIsjG4U/YAOkK4FpgloNghc X-IronPort-AV: E=Sophos;i="4.80,525,1344211200"; d="scan'208";a="127720896" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 03 Oct 2012 00:06:59 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9306xkJ019425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 00:06:59 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.49]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Tue, 2 Oct 2012 19:06:59 -0500 From: "John Parello (jparello)" To: Daniel Kharitonov , Juergen Quittek , eman mailing list Thread-Topic: [eman] eman requirements: "max/average" to "typical" Thread-Index: AQHNnemIdQoo0JlqREqjJPb8fjLBj5ekqC8AgAA6CACAADV9YIAAaWEAgAE3+EA= Date: Wed, 3 Oct 2012 00:06:58 +0000 Message-ID: <9C213D38848B89428F46808B16F6F0860AE1B4@xmb-aln-x04.cisco.com> References: <7C155ACE35869F4A953588C8A4657D7509EDA407@CH1PRD0510MB356.namprd05.prod.outlook.com>, <7C155ACE35869F4A953588C8A4657D7509EDA954@CH1PRD0510MB356.namprd05.prod.outlook.com>, <9C213D38848B89428F46808B16F6F0860AD2C4@xmb-aln-x04.cisco.com> <7C155ACE35869F4A953588C8A4657D7509EDBA68@CH1PRD0510MB356.namprd05.prod.outlook.com> In-Reply-To: <7C155ACE35869F4A953588C8A4657D7509EDBA68@CH1PRD0510MB356.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19230.001 x-tm-as-result: No--45.880200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] eman requirements: "max/average" to "typical" X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 00:07:01 -0000 HI Daniel, Thanks I'll try and write up a description of how we do that. First a question.=20 What if the decision of what to turn off, curtail, tradeoff is left to the = manufacturer and all you advertise is the capability to reduce? That means the EnNMS can simply look at your device spec and if it sees a = level which says operate at 80% of maximum then the EnNMS can request that.= If the device cannot (because of the complexities) then it could ACK or NA= K the request? In a scheme like that the complexity could be hidden from the EnNMS and lef= t to the device to decide with its context and operational knowledge. Thinking along those lines would that change your scenario? Jp -----Original Message----- From: Daniel Kharitonov [mailto:dkh@juniper.net]=20 Sent: Monday, October 01, 2012 5:26 PM To: John Parello (jparello); Juergen Quittek; eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" John, I do see how this approach works for a PC or terminal with standartized and= well-known hardware. OTH, I do not see how it works for a generic network device. I will give an= example, so please look at it and respond with your implementation. Let's say we have a simple switch with redundant PS, lookup NPUs and 802.3a= z ports. Even in such a trivial case we have a hierarchy of components and their pro= perties - PS units can be selectively turned off for decreased power capaci= ty, NPU elements can be clock gated for lower performance and 802.3az ports= can be programmed for longer transit delays. If we (a vendor) are designing an energy MIB to manage such device, we cann= ot uniquely assign state S1 to one programming set (PS, NPUs, ports) and S2= to another and call it a day as the number of possible combinations grows = at exponential rate. But let's say we decided to wrap multi-dimensional internal capabilities of= a device to just two states, S1 and S2. Let's assume S1 means reduced numb= er of power supplies for total system power @X watts and S2 means S1 plus h= alf performance and twice the latency @Y watts, X>Y. Now, a 3rd party EnNMS can discover S1 and S2 but will not know the consequ= ences of S1 and S2 unless there is a mechanism to describe the tradeoffs as= sociated with such states. Thus, EnNMS no longer makes educated decisions. = It will either keep the device at S0 or will flip to S2 and risk losing the= user traffic. The issue quickly scales with increased device complexity and modularity as= we include fabric planes, routing engines, and more into the picture. So my suggestion to the group is to modify the draft with a concept of hier= archies of objects and tradeoff/scope description strings. If that is not possible, we should at least make this draft compatible with= EnNMS framework that goes beyond linear ACPI-style states as the latter ar= e not quite useful for independent NMS developers. ________________________________________ From: John Parello (jparello) Sent: Monday, October 01, 2012 4:16:57 PM To: Daniel Kharitonov; Juergen Quittek; eman mailing list Subject: RE: [eman] eman requirements: "max/average" to "typical" HI, I agree that any state of a device whether they be power state or operation= al state needs to have some context of what the device does and the consequ= ences of a change. What we've found in our implementations and deployments that a simple set o= f context variables (tags and a role) and a maximum power value for state a= re enough for a user of an EnNMS (and simple heuristics) to get significant= power/energy monitoring and control. We have very sophisticate systems bui= lt on these basic attributes. We've found these to be good enough as first start. We have deployments wi= th significant savings, response to demands, and scripted controls all base= d on these values (albeit it primitive) So I encourage the group to start with just simple context values (see fram= ework), typical power, and maximum power. A full modeling of states and con= sequences would be nice but I've yet to see a description proposed that wou= ld suffice significantly better than the simple model we've deployed. Jp -----Original Message----- From: Daniel Kharitonov [mailto:dkh@juniper.net] Sent: Monday, October 01, 2012 7:58 AM To: Juergen Quittek; John Parello (jparello); eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" My recommendation is to reconsider the concept of "network device power sta= te" as a hierarchy of functional states to be discovered and used by EnNMS. The difference is that EnNMS should be setting the minimum functional level= of device based on the knowledge of current and future network situation, = with energy reduction as a consequence. In the current proposal, the EnNMS is expected to set the target energy con= sumption with no way to learn how this setting affects the function. This o= nly works if EnNMS already has extensive understanding of a managed network= device and somehow knows all functional restrictions of different power st= ates. ________________________________________ From: Juergen Quittek Sent: Monday, October 01, 2012 4:30:02 AM To: Daniel Kharitonov; John Parello (jparello); eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" Hi Daniel, So what is your recommnedation: Only have a "typical" power value for a pow= er state? Thanks, Juergen On 29.09.12 04:24, "Daniel Kharitonov" wrote: > >If I may have one comment on power state in network devices, I would=20 >say they are neither linear nor can be fully described with maximum and=20 >average power use. > >The needed descriptive strings for power states should be at least=20 >expressed as changes in operational properties - performance, latency=20 >and such. A less obvious but critical parameter would the time to=20 >transition in/out of this state. > >Example 1. > >A switch consists of interfaces, fabric, lookup engines and power=20 >supplies. Each group of components may have one or more dimensions of=20 >power states that can be changed independently. > >Note, that the knowledge of own power use for a group of components can=20 >be incomplete and/or not sum up to a full system. > >Example 2. > >EnNMS is discovering a device that reports a set of power states along=20 >with max/average power use. Since device describes neither performance=20 >targets nor times to transition between them, EnNMS can only make a=20 >decision based on desired power use in the device. This may lead to=20 >mismatch between power state and device usability. > >________________________________________ >From: eman-bounces@ietf.org on behalf of Juergen Quittek >Sent: Thursday, September 27, 2012 11:45:14 AM >To: John Parello (jparello); eman mailing list >Subject: Re: [eman] eman requirements: "max/average" to "typical" > >Hi John, > >Thank you for your comment. This would look like > >OLD > 5.4.6. Maximum and average power per Power State > > The standard must provide means for retrieving the maximum power and > the average power for each supported Power State. These values may > be static. > >NEW > 5.4.6. Maximum and typical power per Power State > > The standard must provide means for retrieving the maximum power and > the typical power for each supported Power State. > >I don't think we need the sentence on values being static. > > >Who would have a problem with this version? > >Thanks, > Juergen > > >On 27.09.12 19:14, "John Parello (jparello)" wrote: > >>HI Juergen, >> >>Thanks. I agree that typical is more useful than average but you threw=20 >>out max. >> >>In our implementations each power state has a maximum value that the=20 >>device will use for that state. Typical and average is too lose a=20 >>term for management. >> >>If I have three power states say low, medium, high and the device=20 >>reports typical power as 10,20, and 30W. I have no way of knowing that=20 >>if I set the device to low it will not exceed the 10W and run at 30W. >> >>We implemented the Max to allow device vendors to give specifics so=20 >>that the mgt stations can have a hope of controlling the aggregate=20 >>power. If you loosen the requirement to typical you effectively have=20 >>no predictable control. >> >>Having Max is also in line with the way PoE states are communicated=20 >>where depending on which PoE spec you implement you give 3 or 5 states=20 >>and give the maximum at each state. >> >>So yes on typical over average but you must have max as well. >> >>Jp >> >> >> >> >>-----Original Message----- >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf=20 >>Of Juergen Quittek >>Sent: Thursday, September 27, 2012 5:17 AM >>To: eman mailing list >>Subject: [eman] eman requirements: "max/average" to "typical" >> >>Dear all, >> >>Here is an issue from discussing received comments on the eman >>requirements: >> >>The current version asks for means for reporting maximum and average=20 >>power for each power state. The comment raised the point that these=20 >>may not be well defined. Mouli and I discussed this and came up with=20 >>the following >>proposal: >> >>OLD >> 5.4.6. Maximum and average power per Power State >> >> The standard must provide means for retrieving the maximum power and >> the average power for each supported Power State. These values may >> be static. >> >>NEW >> >> 5.4.6. Typical power per Power State >> >> The standard must provide means for retrieving the typical power for >> each supported Power State. >> >>The assumption is that a "typical" power meets more the requirements=20 >>by an energy management system and would be more useful than a not=20 >>well defined "average" value. >> >>Please give us your opinions on this proposal. >> >>Thanks, >> Juergen >> >>_______________________________________________ >>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 dkh@juniper.net Tue Oct 2 17:36:24 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05BE21F8602 for ; Tue, 2 Oct 2012 17:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LOW=2.3, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnU6+k6tbCKs for ; Tue, 2 Oct 2012 17:36:24 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id C6B3921F85F9 for ; Tue, 2 Oct 2012 17:36:23 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUGuIh9S8AtNle+HBtkxPLqW9c/TJ6UYH@postini.com; Tue, 02 Oct 2012 17:36:23 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Oct 2012 17:23:54 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 2 Oct 2012 17:23:53 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 2 Oct 2012 17:25:50 -0700 Received: from mail105-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 00:23:52 +0000 Received: from mail105-va3 (localhost [127.0.0.1]) by mail105-va3-R.bigfish.com (Postfix) with ESMTP id 990151600C7 for ; Wed, 3 Oct 2012 00:23:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371I542M1432I4015Izz1202h1d1ah1d2ah1082kzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail105-va3 (localhost.localdomain [127.0.0.1]) by mail105-va3 (MessageSwitch) id 1349223830155716_6815; Wed, 3 Oct 2012 00:23:50 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.238]) by mail105-va3.bigfish.com (Postfix) with ESMTP id 2129438005A; Wed, 3 Oct 2012 00:23:50 +0000 (UTC) Received: from CH1PRD0510HT003.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 00:23:45 +0000 Received: from CH1PRD0510MB356.namprd05.prod.outlook.com ([169.254.9.14]) by CH1PRD0510HT003.namprd05.prod.outlook.com ([10.255.150.38]) with mapi id 14.16.0190.008; Wed, 3 Oct 2012 00:23:44 +0000 From: Daniel Kharitonov To: "John Parello (jparello)" , Juergen Quittek , eman mailing list Thread-Topic: [eman] eman requirements: "max/average" to "typical" Thread-Index: AQHNnemIdQoo0JlqREqjJPb8fjLBj5ekVF4AgAA6CEuAAIt6gIAAE2PdgAGM7ACAAASvAw== Date: Wed, 3 Oct 2012 00:23:44 +0000 Message-ID: <7C155ACE35869F4A953588C8A4657D7509EDDFAF@CH1PRD0510MB356.namprd05.prod.outlook.com> References: <7C155ACE35869F4A953588C8A4657D7509EDA407@CH1PRD0510MB356.namprd05.prod.outlook.com>, <7C155ACE35869F4A953588C8A4657D7509EDA954@CH1PRD0510MB356.namprd05.prod.outlook.com>, <9C213D38848B89428F46808B16F6F0860AD2C4@xmb-aln-x04.cisco.com> <7C155ACE35869F4A953588C8A4657D7509EDBA68@CH1PRD0510MB356.namprd05.prod.outlook.com>, <9C213D38848B89428F46808B16F6F0860AE1B4@xmb-aln-x04.cisco.com> In-Reply-To: <9C213D38848B89428F46808B16F6F0860AE1B4@xmb-aln-x04.cisco.com> Accept-Language: ru-RU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NECLAB.EU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [eman] eman requirements: "max/average" to "typical" X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 00:36:25 -0000 Hi John, What you are describing is a perfect case of a single-dimensional tradeoff = typical for a PC and quite usable. NMS discovers there is an opportunity to operated at reduced performance le= vel at given savings and requests this from the managed element. The elemen= t transitions or NAKs if unable to do so. Note that even in such a simple case the knowledge of tradeoff is not built= into the EnNMS but read off the element itself. ________________________________________ From: John Parello (jparello) Sent: Tuesday, October 02, 2012 5:06:58 PM To: Daniel Kharitonov; Juergen Quittek; eman mailing list Subject: RE: [eman] eman requirements: "max/average" to "typical" HI Daniel, Thanks I'll try and write up a description of how we do that. First a question. What if the decision of what to turn off, curtail, tradeoff is left to the = manufacturer and all you advertise is the capability to reduce? That means the EnNMS can simply look at your device spec and if it sees a = level which says operate at 80% of maximum then the EnNMS can request that.= If the device cannot (because of the complexities) then it could ACK or NA= K the request? In a scheme like that the complexity could be hidden from the EnNMS and lef= t to the device to decide with its context and operational knowledge. Thinking along those lines would that change your scenario? Jp -----Original Message----- From: Daniel Kharitonov [mailto:dkh@juniper.net] Sent: Monday, October 01, 2012 5:26 PM To: John Parello (jparello); Juergen Quittek; eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" John, I do see how this approach works for a PC or terminal with standartized and= well-known hardware. OTH, I do not see how it works for a generic network device. I will give an= example, so please look at it and respond with your implementation. Let's say we have a simple switch with redundant PS, lookup NPUs and 802.3a= z ports. Even in such a trivial case we have a hierarchy of components and their pro= perties - PS units can be selectively turned off for decreased power capaci= ty, NPU elements can be clock gated for lower performance and 802.3az ports= can be programmed for longer transit delays. If we (a vendor) are designing an energy MIB to manage such device, we cann= ot uniquely assign state S1 to one programming set (PS, NPUs, ports) and S2= to another and call it a day as the number of possible combinations grows = at exponential rate. But let's say we decided to wrap multi-dimensional internal capabilities of= a device to just two states, S1 and S2. Let's assume S1 means reduced numb= er of power supplies for total system power @X watts and S2 means S1 plus h= alf performance and twice the latency @Y watts, X>Y. Now, a 3rd party EnNMS can discover S1 and S2 but will not know the consequ= ences of S1 and S2 unless there is a mechanism to describe the tradeoffs as= sociated with such states. Thus, EnNMS no longer makes educated decisions. = It will either keep the device at S0 or will flip to S2 and risk losing the= user traffic. The issue quickly scales with increased device complexity and modularity as= we include fabric planes, routing engines, and more into the picture. So my suggestion to the group is to modify the draft with a concept of hier= archies of objects and tradeoff/scope description strings. If that is not possible, we should at least make this draft compatible with= EnNMS framework that goes beyond linear ACPI-style states as the latter ar= e not quite useful for independent NMS developers. ________________________________________ From: John Parello (jparello) Sent: Monday, October 01, 2012 4:16:57 PM To: Daniel Kharitonov; Juergen Quittek; eman mailing list Subject: RE: [eman] eman requirements: "max/average" to "typical" HI, I agree that any state of a device whether they be power state or operation= al state needs to have some context of what the device does and the consequ= ences of a change. What we've found in our implementations and deployments that a simple set o= f context variables (tags and a role) and a maximum power value for state a= re enough for a user of an EnNMS (and simple heuristics) to get significant= power/energy monitoring and control. We have very sophisticate systems bui= lt on these basic attributes. We've found these to be good enough as first start. We have deployments wi= th significant savings, response to demands, and scripted controls all base= d on these values (albeit it primitive) So I encourage the group to start with just simple context values (see fram= ework), typical power, and maximum power. A full modeling of states and con= sequences would be nice but I've yet to see a description proposed that wou= ld suffice significantly better than the simple model we've deployed. Jp -----Original Message----- From: Daniel Kharitonov [mailto:dkh@juniper.net] Sent: Monday, October 01, 2012 7:58 AM To: Juergen Quittek; John Parello (jparello); eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" My recommendation is to reconsider the concept of "network device power sta= te" as a hierarchy of functional states to be discovered and used by EnNMS. The difference is that EnNMS should be setting the minimum functional level= of device based on the knowledge of current and future network situation, = with energy reduction as a consequence. In the current proposal, the EnNMS is expected to set the target energy con= sumption with no way to learn how this setting affects the function. This o= nly works if EnNMS already has extensive understanding of a managed network= device and somehow knows all functional restrictions of different power st= ates. ________________________________________ From: Juergen Quittek Sent: Monday, October 01, 2012 4:30:02 AM To: Daniel Kharitonov; John Parello (jparello); eman mailing list Subject: Re: [eman] eman requirements: "max/average" to "typical" Hi Daniel, So what is your recommnedation: Only have a "typical" power value for a pow= er state? Thanks, Juergen On 29.09.12 04:24, "Daniel Kharitonov" wrote: > >If I may have one comment on power state in network devices, I would >say they are neither linear nor can be fully described with maximum and >average power use. > >The needed descriptive strings for power states should be at least >expressed as changes in operational properties - performance, latency >and such. A less obvious but critical parameter would the time to >transition in/out of this state. > >Example 1. > >A switch consists of interfaces, fabric, lookup engines and power >supplies. Each group of components may have one or more dimensions of >power states that can be changed independently. > >Note, that the knowledge of own power use for a group of components can >be incomplete and/or not sum up to a full system. > >Example 2. > >EnNMS is discovering a device that reports a set of power states along >with max/average power use. Since device describes neither performance >targets nor times to transition between them, EnNMS can only make a >decision based on desired power use in the device. This may lead to >mismatch between power state and device usability. > >________________________________________ >From: eman-bounces@ietf.org on behalf of Juergen Quittek >Sent: Thursday, September 27, 2012 11:45:14 AM >To: John Parello (jparello); eman mailing list >Subject: Re: [eman] eman requirements: "max/average" to "typical" > >Hi John, > >Thank you for your comment. This would look like > >OLD > 5.4.6. Maximum and average power per Power State > > The standard must provide means for retrieving the maximum power and > the average power for each supported Power State. These values may > be static. > >NEW > 5.4.6. Maximum and typical power per Power State > > The standard must provide means for retrieving the maximum power and > the typical power for each supported Power State. > >I don't think we need the sentence on values being static. > > >Who would have a problem with this version? > >Thanks, > Juergen > > >On 27.09.12 19:14, "John Parello (jparello)" wrote: > >>HI Juergen, >> >>Thanks. I agree that typical is more useful than average but you threw >>out max. >> >>In our implementations each power state has a maximum value that the >>device will use for that state. Typical and average is too lose a >>term for management. >> >>If I have three power states say low, medium, high and the device >>reports typical power as 10,20, and 30W. I have no way of knowing that >>if I set the device to low it will not exceed the 10W and run at 30W. >> >>We implemented the Max to allow device vendors to give specifics so >>that the mgt stations can have a hope of controlling the aggregate >>power. If you loosen the requirement to typical you effectively have >>no predictable control. >> >>Having Max is also in line with the way PoE states are communicated >>where depending on which PoE spec you implement you give 3 or 5 states >>and give the maximum at each state. >> >>So yes on typical over average but you must have max as well. >> >>Jp >> >> >> >> >>-----Original Message----- >>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf >>Of Juergen Quittek >>Sent: Thursday, September 27, 2012 5:17 AM >>To: eman mailing list >>Subject: [eman] eman requirements: "max/average" to "typical" >> >>Dear all, >> >>Here is an issue from discussing received comments on the eman >>requirements: >> >>The current version asks for means for reporting maximum and average >>power for each power state. The comment raised the point that these >>may not be well defined. Mouli and I discussed this and came up with >>the following >>proposal: >> >>OLD >> 5.4.6. Maximum and average power per Power State >> >> The standard must provide means for retrieving the maximum power and >> the average power for each supported Power State. These values may >> be static. >> >>NEW >> >> 5.4.6. Typical power per Power State >> >> The standard must provide means for retrieving the typical power for >> each supported Power State. >> >>The assumption is that a "typical" power meets more the requirements >>by an energy management system and would be more useful than a not >>well defined "average" value. >> >>Please give us your opinions on this proposal. >> >>Thanks, >> Juergen >> >>_______________________________________________ >>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 internet-drafts@ietf.org Wed Oct 3 05:58:17 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E6E21F86D6; Wed, 3 Oct 2012 05:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjgF53DO0-Mj; Wed, 3 Oct 2012 05:58:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9BE21F86CF; Wed, 3 Oct 2012 05:58:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121003125817.6706.33145.idtracker@ietfa.amsl.com> Date: Wed, 03 Oct 2012 05:58:17 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:58:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Entity MIB (Version 4) Author(s) : Andy Bierman Dan Romascanu Juergen Quittek Mouli Chandramouli Filename : draft-ietf-eman-rfc4133bis-01.txt Pages : 68 Date : 2012-10-03 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version of the Entity MIB, which obsoletes version 3 [RFC4133]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-rfc4133bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-rfc4133bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From moulchan@cisco.com Wed Oct 3 06:04:00 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B8921F84C2 for ; Wed, 3 Oct 2012 06:04:00 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUBz4mWVs8sR for ; Wed, 3 Oct 2012 06:04:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E063621F845F for ; Wed, 3 Oct 2012 06:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2026; q=dns/txt; s=iport; t=1349269440; x=1350479040; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7KpQtn56lm473BJ5f/Ukf0OSO3oQcLa/laxtaAoZmlw=; b=mZVrtbmseZolVMWApcsoujvhqos9/3WaSlm5j3lZ7ayumTplYn5vbrwP qKShDtD4KVHmVWl0+6vnKbjHuIrZjOp2BbAUdXJ30ORI/tGEB144GpK4g v0XEQUJPpEqf7g4B/nvFkRBptkXNVA1NX+INhUJtOHtrvUqYOdg5dXbEw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK82bFCtJV2Z/2dsb2JhbABFvnOBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIAQsOh2MLmBCgBIsjhVpgA5Z+jS2BaYJtghc X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="127859899" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 03 Oct 2012 13:03:59 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q93D3x61011459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Oct 2012 13:03:59 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.137]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 08:03:59 -0500 From: "Mouli Chandramouli (moulchan)" To: "eman@ietf.org" Thread-Topic: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt Thread-Index: AQHNoWbFDEaGDDDb6ECEZS8fpdPEX5enitQw Date: Wed, 3 Oct 2012 13:03:58 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BA13F@xmb-rcd-x08.cisco.com> References: <20121003125817.6706.33145.idtracker@ietfa.amsl.com> In-Reply-To: <20121003125817.6706.33145.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.138] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--34.395300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:04:00 -0000 Hello all, Thanks for the feedback from Nevil Brownlee and Juergen Schoenwaelder.=20 Based on the feedback, a new Textual Convention (TC) PhysicalUUID with the = display hint has been added. =20 Please let us know if you have comments. =20 Thanks Andy, Dan, Juergen Quittek and Mouli =20 -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Wednesday, October 03, 2012 6:28 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Entity MIB (Version 4) Author(s) : Andy Bierman Dan Romascanu Juergen Quittek Mouli Chandramouli Filename : draft-ietf-eman-rfc4133bis-01.txt Pages : 68 Date : 2012-10-03 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version of the Entity MIB, which obsoletes version 3 [RFC4133]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-rfc4133bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-rfc4133bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From trac+eman@trac.tools.ietf.org Wed Oct 3 12:08:19 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4C411E809A for ; Wed, 3 Oct 2012 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pvf9faWtBXSe for ; Wed, 3 Oct 2012 12:08:18 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A86CF11E809B for ; Wed, 3 Oct 2012 12:08:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:39550 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJUIb-0003ME-Hq; Wed, 03 Oct 2012 21:08:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 03 Oct 2012 19:08:01 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/3#comment:2 Message-ID: <079.a21a8b51b69a46dc7e8156185eba1322@trac.tools.ietf.org> References: <064.bd005f282af97c2591665048bba16504@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <064.bd005f282af97c2591665048bba16504@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #3: Nameplate should mention Manufacturer Rating. (ASHRAE) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:08:19 -0000 #3: Nameplate should mention Manufacturer Rating. (ASHRAE) Comment (by jparello@…): 10/3 Meeting : propose to close -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 12:09:16 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178811F041C for ; Wed, 3 Oct 2012 12:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrpTreYGeq9Q for ; Wed, 3 Oct 2012 12:09:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFAA1F0417 for ; Wed, 3 Oct 2012 12:09:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:39561 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJUJh-0007Q5-Rl; Wed, 03 Oct 2012 21:09:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-eman-framework@tools.ietf.org, jparello@cisco.com X-Trac-Project: eman Date: Wed, 03 Oct 2012 19:09:09 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/9#comment:2 Message-ID: <079.166f29522039d48150c42ce8176eb22d@trac.tools.ietf.org> References: <064.7949ab1e6a6993084319176869210214@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <064.7949ab1e6a6993084319176869210214@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-framework@tools.ietf.org, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bclaise@cisco.com, bnordman@lbl.gov, brad@bradschoening.com, jparello@cisco.com, quittek@netlab.nec.de Resent-Message-Id: <20121003190915.5DFAA1F0417@ietfa.amsl.com> Resent-Date: Wed, 3 Oct 2012 12:09:15 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: Re: [eman] #9: Delete incorrect IEEE 1621 definitions X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:09:16 -0000 #9: Delete incorrect IEEE 1621 definitions Comment (by jparello@…): 10/2 Propose to close -- --------------------------+------------------------------------------ Reporter: n.brownlee@… | Owner: draft-ietf-eman-framework@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------------------------ Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 12:38:08 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50EC21F853E for ; Wed, 3 Oct 2012 12:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXnWMbknLwXS for ; Wed, 3 Oct 2012 12:38:08 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5215421F850C for ; Wed, 3 Oct 2012 12:38:08 -0700 (PDT) Received: from localhost ([127.0.0.1]:40950 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJUlT-0003NE-RJ; Wed, 03 Oct 2012 21:37:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 03 Oct 2012 19:37:51 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/11#comment:1 Message-ID: <079.e7f650ed8bb6a018b16bfc4a374f8914@trac.tools.ietf.org> References: <064.3929ae5620b5cbd5fe77d141043968bc@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <064.3929ae5620b5cbd5fe77d141043968bc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #11: Clarify 'aggregation' X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:38:08 -0000 #11: Clarify 'aggregation' Comment (by jparello@…): ADDED: The functions that the aggregation point may perform include values such as average, count, maximum, median, minimum or listing (collection) of the aggregation. -- --------------------------+----------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: new Priority: major | Milestone: Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+----------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 12:39:42 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CFA1F041F for ; Wed, 3 Oct 2012 12:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i7zj641hNN4 for ; Wed, 3 Oct 2012 12:39:42 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF41F0381 for ; Wed, 3 Oct 2012 12:39:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:40968 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJUnD-0002Cu-CO; Wed, 03 Oct 2012 21:39:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 03 Oct 2012 19:39:39 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/11#comment:2 Message-ID: <079.182498798a84d26824425dea4f5defd5@trac.tools.ietf.org> References: <064.3929ae5620b5cbd5fe77d141043968bc@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <064.3929ae5620b5cbd5fe77d141043968bc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #11: Clarify 'aggregation' X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:39:42 -0000 #11: Clarify 'aggregation' Comment (by jparello@…): 10/2 Propose to close -- --------------------------+----------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: new Priority: major | Milestone: Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+----------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 12:40:39 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEFD1F041F for ; Wed, 3 Oct 2012 12:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5GcJQ4fBEeM for ; Wed, 3 Oct 2012 12:40:39 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 20A411F0381 for ; Wed, 3 Oct 2012 12:40:39 -0700 (PDT) Received: from localhost ([127.0.0.1]:41046 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJUo9-0003eR-Oj; Wed, 03 Oct 2012 21:40:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 03 Oct 2012 19:40:37 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/12#comment:1 Message-ID: <079.0472312619044f6460e231cfea9e3c63@trac.tools.ietf.org> References: <064.9a8404aa8b8749382a7ecb93a3197acb@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <064.9a8404aa8b8749382a7ecb93a3197acb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #12: how summation occurs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:40:40 -0000 #12: how summation occurs Comment (by jparello@…): 10/2 Bruce to add text to describe this is what to do when values are missing etc. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bruce Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 12:42:41 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4161F0421 for ; Wed, 3 Oct 2012 12:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FRpLAnPTHSp for ; Wed, 3 Oct 2012 12:42:41 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 587211F0381 for ; Wed, 3 Oct 2012 12:42:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:41079 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJUq7-0005ZX-Tv; Wed, 03 Oct 2012 21:42:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 03 Oct 2012 19:42:39 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/8#comment:1 Message-ID: <079.242dc60742f9160f80340e72045c4ae7@trac.tools.ietf.org> References: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #8: List EMAN curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:42:42 -0000 #8: List EMAN curtailment levels Comment (by jparello@…): 10/2 - Upon resolution of power state and levels tell the router wg that eeman is preferred. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 12:53:32 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EDF11E80A6 for ; Wed, 3 Oct 2012 12:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0fZU46OyJSS for ; Wed, 3 Oct 2012 12:53:31 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 88A2711E80AD for ; Wed, 3 Oct 2012 12:53:31 -0700 (PDT) Received: from localhost ([127.0.0.1]:41915 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJV0U-0006wa-Jf; Wed, 03 Oct 2012 21:53:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 03 Oct 2012 19:53:22 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/14#comment:1 Message-ID: <079.c4ca18b5d8670bed9c5a5d4e6be78f71@trac.tools.ietf.org> References: <064.043b2e5afe430fb3ac1c93c789241a9d@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <064.043b2e5afe430fb3ac1c93c789241a9d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #14: Metering and Power Source both seem to be derivative of wiring topology X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:53:32 -0000 #14: Metering and Power Source both seem to be derivative of wiring topology Comment (by jparello@…): ADDED: - When there is a series of meters for one Energy Object, the Energy Object MAY establish a relationship with one or more of the meters. 10/2 Propose to Close -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 12:56:14 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AB711E80B8 for ; Wed, 3 Oct 2012 12:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhWQAuNDUzhq for ; Wed, 3 Oct 2012 12:56:14 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id EE43D11E80AE for ; Wed, 3 Oct 2012 12:56:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:42273 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJV3A-0008UP-Jr; Wed, 03 Oct 2012 21:56:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 03 Oct 2012 19:56:08 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/17#comment:1 Message-ID: <079.4c35aeaf1285086a20a572ce7c785335@trac.tools.ietf.org> References: <064.056e9f519f85063bc7514e0a8142259d@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <064.056e9f519f85063bc7514e0a8142259d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #17: d. Is aggregation a relationship, or just a function? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:56:14 -0000 #17: d. Is aggregation a relationship, or just a function? Comment (by jparello@…): 10/2 Propose to Close (subset item 12) -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 12:58:03 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46B311E80BF for ; Wed, 3 Oct 2012 12:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJXkaUvHhmbE for ; Wed, 3 Oct 2012 12:58:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id C533E11E80AE for ; Wed, 3 Oct 2012 12:58:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:42419 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJV4y-0000Dv-Rv; Wed, 03 Oct 2012 21:58:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 03 Oct 2012 19:58:00 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/18#comment:1 Message-ID: <079.e83b38994d8ac6e2ebc5d0fd0aa81555@trac.tools.ietf.org> References: <064.2ad61fae1de35f8b0f450b78221319e2@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <064.2ad61fae1de35f8b0f450b78221319e2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #18: e. Clarify relation among aggregation, proxying, and IP/non-IP devices (section 5) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:58:03 -0000 #18: e. Clarify relation among aggregation, proxying, and IP/non-IP devices (section 5) Comment (by jparello@…): Need to define this issue a bit more. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 14:42:36 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AEF21F854F for ; Wed, 3 Oct 2012 14:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWgcHSYOOI9z for ; Wed, 3 Oct 2012 14:42:35 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9364D21F8546 for ; Wed, 3 Oct 2012 14:42:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:48799 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJWhu-0008QB-M2; Wed, 03 Oct 2012 23:42:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 03 Oct 2012 21:42:18 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/3#comment:3 Message-ID: <079.8bc62feac66dc071c5834b66d4df2ea3@trac.tools.ietf.org> References: <064.bd005f282af97c2591665048bba16504@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <064.bd005f282af97c2591665048bba16504@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #3: Nameplate should mention Manufacturer Rating. (ASHRAE) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 21:42:36 -0000 #3: Nameplate should mention Manufacturer Rating. (ASHRAE) Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 3 14:44:22 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68381F0C4C for ; Wed, 3 Oct 2012 14:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql56Z4YaWzZI for ; Wed, 3 Oct 2012 14:44:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 290B91F0421 for ; Wed, 3 Oct 2012 14:44:22 -0700 (PDT) Received: from localhost ([127.0.0.1]:49046 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJWjl-0002J2-S4; Wed, 03 Oct 2012 23:44:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-eman-framework@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 03 Oct 2012 21:44:13 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/9#comment:3 Message-ID: <079.adcc88f08ed57084acb9822a679a8a31@trac.tools.ietf.org> References: <064.7949ab1e6a6993084319176869210214@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <064.7949ab1e6a6993084319176869210214@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-framework@tools.ietf.org, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bclaise@cisco.com, bnordman@lbl.gov, brad@bradschoening.com, jparello@cisco.com, quittek@netlab.nec.de Resent-Message-Id: <20121003214422.290B91F0421@ietfa.amsl.com> Resent-Date: Wed, 3 Oct 2012 14:44:22 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: Re: [eman] #9: Delete incorrect IEEE 1621 definitions X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 21:44:22 -0000 #9: Delete incorrect IEEE 1621 definitions Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed -- --------------------------+------------------------------------------ Reporter: n.brownlee@… | Owner: draft-ietf-eman-framework@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------------------------ Ticket URL: eman From j.schoenwaelder@jacobs-university.de Wed Oct 3 23:43:01 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA61E21F862A for ; Wed, 3 Oct 2012 23:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.215 X-Spam-Level: X-Spam-Status: No, score=-103.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTRxEsl7+n7J for ; Wed, 3 Oct 2012 23:43:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6DB21F8629 for ; Wed, 3 Oct 2012 23:43:01 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E849720C4D; Thu, 4 Oct 2012 08:42:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cFI00d3rOt4y; Thu, 4 Oct 2012 08:42:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71C0C20C4B; Thu, 4 Oct 2012 08:42:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7962A221FB15; Thu, 4 Oct 2012 08:42:54 +0200 (CEST) Date: Thu, 4 Oct 2012 08:42:53 +0200 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20121004064253.GA95589@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , "eman@ietf.org" References: <20121003125817.6706.33145.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BA13F@xmb-rcd-x08.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BA13F@xmb-rcd-x08.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 06:43:02 -0000 On Wed, Oct 03, 2012 at 01:03:58PM +0000, Mouli Chandramouli (moulchan) wrote: > Hello all, > > Thanks for the feedback from Nevil Brownlee and Juergen Schoenwaelder. > Based on the feedback, a new Textual Convention (TC) PhysicalUUID with the display hint has been added. > > Please let us know if you have comments. PhysicalUUID ::= TEXTUAL-CONVENTION DISPLAY-HINT "4x-2x-2x-1x1x-6x" STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains a Universal Unique Identifier, the syntax of this object must conform to RFC 4122, section 4.1. If no additional identification information is known about the physical entity or supported, the object is not instantiated. A zero length octet string may also be returned in this case." SYNTAX OCTET STRING (SIZE (16)) This is not really what I proposed. I proposed to add a separate module defining a generic UUID textual convention that can be reused. Having object semantics embedded in a TC seems to be a rather bad idea. And text saying that a zero length string can be returned in the with a (SIZE (16)) restriction is also plain wrong. What we likely need then is a UUID TC and UUIDOrZero TC. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From moulchan@cisco.com Wed Oct 3 23:52:36 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E9421F8600 for ; Wed, 3 Oct 2012 23:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwcJh2qAe4yZ for ; Wed, 3 Oct 2012 23:52:36 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E9AB921F85FC for ; Wed, 3 Oct 2012 23:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2429; q=dns/txt; s=iport; t=1349333556; x=1350543156; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VgirDZRee5kMBn2whKNGHNfx23bSgrl3p6RXywb1AZE=; b=boG5+/t4ZT4TrhBRiknPCs8VDGj1cTH1g7PnQPy5oJRrGLn1hO2hhUCs bhIWwQOTn6Z9B642qwn+++Grv6qZVrOreomlch0Q9qR0B8vBvC9bzNtGD cYeRi5ZEMBOwHVvjpGIyCPfPocY3ygpQzPrnq76Z1q2DQm5KyAVWT5BPj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADoxbVCtJXG8/2dsb2JhbABCA78TgQiCIAEBAQQSASc/DAICAgEIDgIBBAEBAQoUCQcbFxQJCAIEDgUIARmHYwuYRZ97BIsfGoJdgkVgA6QrgWmCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,532,1344211200"; d="scan'208";a="128160774" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 04 Oct 2012 06:52:35 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q946qZfd000407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Oct 2012 06:52:35 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.137]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 01:52:34 -0500 From: "Mouli Chandramouli (moulchan)" To: Juergen Schoenwaelder Thread-Topic: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt Thread-Index: AQHNoWbFDEaGDDDb6ECEZS8fpdPEX5enitQwgAF9JYD//604wA== Date: Thu, 4 Oct 2012 06:52:34 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BE8F0@xmb-rcd-x08.cisco.com> References: <20121003125817.6706.33145.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BA13F@xmb-rcd-x08.cisco.com> <20121004064253.GA95589@elstar.local> In-Reply-To: <20121004064253.GA95589@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.138] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--60.794400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 06:52:37 -0000 Hello Juergen, Thanks for your quick review. In your previous email, =20 http://www.ietf.org/mail-archive/web/eman/current/msg01537.html you had mentioned that=20 "This can go initially into the RFC 4133 update or be a separate document, I do not really care. However, having a reusable definition including a proper DISPLAY-HINT I think is worth the effort." So, this TC is included in this version of the draft.=20 I want to understand your comment better on the need for 2 TCs. =20 Thanks Mouli -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, October 04, 2012 12:13 PM To: Mouli Chandramouli (moulchan) Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt On Wed, Oct 03, 2012 at 01:03:58PM +0000, Mouli Chandramouli (moulchan) wro= te: > Hello all, >=20 > Thanks for the feedback from Nevil Brownlee and Juergen Schoenwaelder.=20 > Based on the feedback, a new Textual Convention (TC) PhysicalUUID with th= e display hint has been added. =20 >=20 > Please let us know if you have comments. =20 PhysicalUUID ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "4x-2x-2x-1x1x-6x" STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains a Universal Unique Identifier, the syntax of this object must conform to RFC 4122, section 4.1. If no additional identification information is known about the physical entity or supported, the object is not instantiated. A zero length octet string may also be returned in this case." =20 SYNTAX OCTET STRING (SIZE (16)) This is not really what I proposed. I proposed to add a separate module defining a generic UUID textual convention that can be reused. Having object semantics embedded in a TC seems to be a rather bad idea. And text saying that a zero length string can be returned in the with a (SIZE (16)) restriction is also plain wrong. What we likely need then is a UUID TC and UUIDOrZero TC. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Oct 4 00:03:04 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D3A21F8646 for ; Thu, 4 Oct 2012 00:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gtqu4n+Glioi for ; Thu, 4 Oct 2012 00:03:03 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 45A2821F8630 for ; Thu, 4 Oct 2012 00:03:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFYzbVCHCzI1/2dsb2JhbABCA78TgQiCIAEBAQEDAQEBDx4KNAsMAgICAQgNAwEEAQEBCgYMCwEGARoMHwkIAgQBEggBGYdjC5tKnH4Eix8agl2CRWADln6Eb4ongm+BYQ X-IronPort-AV: E=Sophos;i="4.80,533,1344225600"; d="scan'208";a="29847261" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Oct 2012 02:55:57 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Oct 2012 02:41:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Oct 2012 09:02:59 +0200 Message-ID: In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BE8F0@xmb-rcd-x08.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt Thread-Index: AQHNoWbFDEaGDDDb6ECEZS8fpdPEX5enitQwgAF9JYD//604wIAAAyJw References: <20121003125817.6706.33145.idtracker@ietfa.amsl.com><852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BA13F@xmb-rcd-x08.cisco.com><20121004064253.GA95589@elstar.local> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BE8F0@xmb-rcd-x08.cisco.com> From: "Romascanu, Dan (Dan)" To: "Mouli Chandramouli (moulchan)" , "Juergen Schoenwaelder" Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:03:04 -0000 I think that I understand Juergen's concerns.=20 1. The TC in a separate MIB module.=20 Why? What is wrong with including it in the new ENTITY-MIB module. Does it matter where it will be imported from in the future?=20 2. Two TCs. I assumed that what we are defining is the UUIDOrZero TC. Maybe we should call it so. Why do we need two TCs? Where would we use UUID TC and where would we use UUIDOrZero TC in the ENTITY-MIB? Or you have in mind future use? 3. Format. We used the SYNTAX and formatting that was discussed on the list. I thought that we have consensus on it. What would be the alternate proposal?=20 Thanks and Regards, Dan > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Mouli Chandramouli (moulchan) > Sent: Thursday, October 04, 2012 8:53 AM > To: Juergen Schoenwaelder > Cc: eman@ietf.org > Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt >=20 > Hello Juergen, >=20 > Thanks for your quick review. In your previous email, >=20 > http://www.ietf.org/mail-archive/web/eman/current/msg01537.html >=20 > you had mentioned that > "This can go initially into the RFC 4133 update or be a separate > document, I do not really care. However, having a reusable definition > including a proper DISPLAY-HINT I think is worth the effort." >=20 > So, this TC is included in this version of the draft. >=20 > I want to understand your comment better on the need for 2 TCs. >=20 > Thanks > Mouli >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, October 04, 2012 12:13 PM > To: Mouli Chandramouli (moulchan) > Cc: eman@ietf.org > Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt >=20 > On Wed, Oct 03, 2012 at 01:03:58PM +0000, Mouli Chandramouli (moulchan) > wrote: > > Hello all, > > > > Thanks for the feedback from Nevil Brownlee and Juergen Schoenwaelder. > > Based on the feedback, a new Textual Convention (TC) PhysicalUUID with > the display hint has been added. > > > > Please let us know if you have comments. >=20 > PhysicalUUID ::=3D TEXTUAL-CONVENTION > DISPLAY-HINT "4x-2x-2x-1x1x-6x" > STATUS current > DESCRIPTION > "This object contains additional identification information > about the physical entity. The object contains a Universal > Unique Identifier, the syntax of this object must conform to > RFC 4122, section 4.1. >=20 > If no additional identification information is known > about the physical entity or supported, the object is not > instantiated. A zero length octet string may also be > returned in this case." > SYNTAX OCTET STRING (SIZE (16)) >=20 > This is not really what I proposed. I proposed to add a separate module > defining a generic UUID textual convention that can be reused. > Having object semantics embedded in a TC seems to be a rather bad idea. > And text saying that a zero length string can be returned in the with a > (SIZE (16)) restriction is also plain wrong. What we likely need then is > a UUID TC and UUIDOrZero TC. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Thu Oct 4 00:30:13 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CA321F85E6 for ; Thu, 4 Oct 2012 00:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnnU5AwD0BGK for ; Thu, 4 Oct 2012 00:30:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9621F8606 for ; Thu, 4 Oct 2012 00:30:12 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A00DA20C51; Thu, 4 Oct 2012 09:30:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dUNoouSsw2f3; Thu, 4 Oct 2012 09:30:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 140AD20C4F; Thu, 4 Oct 2012 09:30:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DE5F8221FBCC; Thu, 4 Oct 2012 09:30:07 +0200 (CEST) Date: Thu, 4 Oct 2012 09:30:07 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20121004073007.GA95642@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Mouli Chandramouli (moulchan)" , eman@ietf.org References: <20121003125817.6706.33145.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BA13F@xmb-rcd-x08.cisco.com> <20121004064253.GA95589@elstar.local> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BE8F0@xmb-rcd-x08.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:30:13 -0000 On Thu, Oct 04, 2012 at 09:02:59AM +0200, Romascanu, Dan (Dan) wrote: > I think that I understand Juergen's concerns. > > 1. The TC in a separate MIB module. > > Why? What is wrong with including it in the new ENTITY-MIB module. Does > it matter where it will be imported from in the future? Creating a UUID-TC-MIB modules allows people to more easily find the TC and it allows to update the generic UUID TCs indepedently from the ENTITY-MIB. And yes, having a dependency on the ENTITY-MIB just to use a UUID TC seems overkill to some. We have done similar things before, see for example the URI-TC-MIB. > 2. Two TCs. I assumed that what we are defining is the UUIDOrZero TC. > Maybe we should call it so. Why do we need two TCs? Where would we use > UUID TC and where would we use UUIDOrZero TC in the ENTITY-MIB? Or you > have in mind future use? You use a UUID TC in places where you only have to represent UUIDs. You use the UUIDOrZero TC in places where you have to represent a UUID or a zero-length string. Its simply useful to provide them both. (In some MIB modules, non existing objects simply do not exist.) > 3. Format. We used the SYNTAX and formatting that was discussed on the > list. I thought that we have consensus on it. What would be the > alternate proposal? Not sure what your question is. Obviously, SIZE (16) does not go well along with a "zero-length" string. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Oct 4 00:37:48 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DD421F862A for ; Thu, 4 Oct 2012 00:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.796 X-Spam-Level: X-Spam-Status: No, score=-102.796 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucE8vNkFCSUq for ; Thu, 4 Oct 2012 00:37:47 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id A968221F8624 for ; Thu, 4 Oct 2012 00:37:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKk6bVDGmAcF/2dsb2JhbABCA78PgQiCIAEBAQECARIeCj8MAgICAQgNAQIBBAEBAQoGDAsBBgEaKwkIAQEEEwgah10Gm1ecfwSLH4J3gkVgA5Z+hG+KJ4Jv X-IronPort-AV: E=Sophos;i="4.80,534,1344225600"; d="scan'208";a="29849906" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Oct 2012 03:30:41 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Oct 2012 03:29:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Oct 2012 09:37:44 +0200 Message-ID: In-Reply-To: <20121004073007.GA95642@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt Thread-Index: Ac2iAhwnM5uiBSjFQ4ylbxNGE9TBQQAACnQg References: <20121003125817.6706.33145.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BA13F@xmb-rcd-x08.cisco.com> <20121004064253.GA95589@elstar.local> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BE8F0@xmb-rcd-x08.cisco.com> <20121004073007.GA95642@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:37:48 -0000 Hi,=20 Thanks for the quick answer. See in-line.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, October 04, 2012 9:30 AM > To: Romascanu, Dan (Dan) > Cc: Mouli Chandramouli (moulchan); eman@ietf.org > Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt >=20 > On Thu, Oct 04, 2012 at 09:02:59AM +0200, Romascanu, Dan (Dan) wrote: > > I think that I understand Juergen's concerns. > > > > 1. The TC in a separate MIB module. > > > > Why? What is wrong with including it in the new ENTITY-MIB module. > > Does it matter where it will be imported from in the future? >=20 > Creating a UUID-TC-MIB modules allows people to more easily find the TC > and it allows to update the generic UUID TCs indepedently from the > ENTITY-MIB. And yes, having a dependency on the ENTITY-MIB just to use a > UUID TC seems overkill to some. We have done similar things before, see > for example the URI-TC-MIB. [[DR]] What dependency? One does not need to implement the ENTITY-MIB.=20 We've done similar things also the other way. I am not sure that the multiplication of the MIB modules defining TCs is a good thing, to the extreme we would get to defining each TC in a separate MIB module. The ENTITY-MIB is quite generic, so importing from it does not seem that odd to me.=20 >=20 > > 2. Two TCs. I assumed that what we are defining is the UUIDOrZero TC. > > Maybe we should call it so. Why do we need two TCs? Where would we use > > UUID TC and where would we use UUIDOrZero TC in the ENTITY-MIB? Or you > > have in mind future use? >=20 > You use a UUID TC in places where you only have to represent UUIDs. You > use the UUIDOrZero TC in places where you have to represent a UUID or a > zero-length string. Its simply useful to provide them both. (In some MIB > modules, non existing objects simply do not exist.) >=20 [[DR]] OK - so in the Entity MIB would use the UUIDOrZero TC, while the UUID TC will be defined only to be IMPORTed by other modules in the future.=20 > > 3. Format. We used the SYNTAX and formatting that was discussed on the > > list. I thought that we have consensus on it. What would be the > > alternate proposal? >=20 > Not sure what your question is. Obviously, SIZE (16) does not go well > along with a "zero-length" string. >=20 [[DR]] Right. Should be SIZE (0|16) for the UUIDOrZero TC and SIZE (16) for the UUID TC.=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From karagian@cs.utwente.nl Thu Oct 4 00:54:41 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B43621F8605 for ; Thu, 4 Oct 2012 00:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWZY6jyBOlfP for ; Thu, 4 Oct 2012 00:54:40 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4280821F85ED for ; Thu, 4 Oct 2012 00:54:40 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 4 Oct 2012 09:54:38 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.4]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Thu, 4 Oct 2012 09:54:38 +0200 From: To: , Thread-Topic: [eman] #11: Clarify 'aggregation' Thread-Index: AQHNoZ6kzJHLWZJaEk+AldbOISzJ/Jeox5nw Date: Thu, 4 Oct 2012 07:54:38 +0000 Message-ID: References: <064.3929ae5620b5cbd5fe77d141043968bc@trac.tools.ietf.org> <079.e7f650ed8bb6a018b16bfc4a374f8914@trac.tools.ietf.org> In-Reply-To: <079.e7f650ed8bb6a018b16bfc4a374f8914@trac.tools.ietf.org> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: eman@ietf.org Subject: Re: [eman] #11: Clarify 'aggregation' X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:54:41 -0000 SGkgYWxsLA0KDQpJIGFncmVlIHdpdGggdGhlIHByb3Bvc2VkIGNoYW5nZSENCg0KQmVzdCByZWdh cmRzLA0KR2Vvcmdpb3MNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBl bWFuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplbWFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZg0KPiBPZiBlbWFuIGlzc3VlIHRyYWNrZXINCj4gU2VudDogd29lbnNkYWcgMyBva3RvYmVy IDIwMTIgMjE6MzgNCj4gVG86IGpwYXJlbGxvQGNpc2NvLmNvbQ0KPiBDYzogZW1hbkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW2VtYW5dICMxMTogQ2xhcmlmeSAnYWdncmVnYXRpb24nDQo+IA0K PiAjMTE6IENsYXJpZnkgJ2FnZ3JlZ2F0aW9uJw0KPiANCj4gDQo+IENvbW1lbnQgKGJ5IGpwYXJl bGxvQOKApik6DQo+IA0KPiAgQURERUQ6DQo+IA0KPiAgVGhlIGZ1bmN0aW9ucyB0aGF0IHRoZSBh Z2dyZWdhdGlvbiBwb2ludCBtYXkgcGVyZm9ybSBpbmNsdWRlIHZhbHVlcyBzdWNoICBhcw0KPiBh dmVyYWdlLCBjb3VudCwgbWF4aW11bSwgbWVkaWFuLCBtaW5pbXVtIG9yIGxpc3RpbmcgKGNvbGxl Y3Rpb24pIG9mIHRoZQ0KPiBhZ2dyZWdhdGlvbi4NCj4gDQo+IC0tDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICBSZXBvcnRlcjogIG4uYnJv d25sZWVA4oCmICB8ICAgICAgIE93bmVyOiAganBhcmVsbG8NCj4gICAgICBUeXBlOiAgZGVmZWN0 ICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3DQo+ICBQcmlvcml0eTogIG1ham9yICAgICAgICAg fCAgIE1pbGVzdG9uZToNCj4gQ29tcG9uZW50OiAgZnJhbWV3b3JrICAgICB8ICAgICBWZXJzaW9u OiAgMS4wDQo+ICBTZXZlcml0eTogIC0gICAgICAgICAgICAgfCAgUmVzb2x1dGlvbjoNCj4gIEtl eXdvcmRzOiAgICAgICAgICAgICAgICB8DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBUaWNrZXQgVVJMOiA8aHR0cDovL3Rvb2xzLmll dGYub3JnL3dnL2VtYW4vdHJhYy90aWNrZXQvMTEjY29tbWVudDoxPg0KPiBlbWFuIDxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvZW1hbi8+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBlbWFuIG1haWxpbmcgbGlzdA0KPiBlbWFuQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW1hbg0K From j.schoenwaelder@jacobs-university.de Thu Oct 4 01:07:55 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEE021F8679 for ; Thu, 4 Oct 2012 01:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.217 X-Spam-Level: X-Spam-Status: No, score=-103.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gzxmf9jHMusw for ; Thu, 4 Oct 2012 01:07:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 304E321F8674 for ; Thu, 4 Oct 2012 01:07:54 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BB6220C4F; Thu, 4 Oct 2012 10:07:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r36vqvv_kFTt; Thu, 4 Oct 2012 10:07:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2826420C04; Thu, 4 Oct 2012 10:07:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 01FCF221FD2A; Thu, 4 Oct 2012 10:07:49 +0200 (CEST) Date: Thu, 4 Oct 2012 10:07:49 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20121004080749.GA95706@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Mouli Chandramouli (moulchan)" , eman@ietf.org References: <20121003125817.6706.33145.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BA13F@xmb-rcd-x08.cisco.com> <20121004064253.GA95589@elstar.local> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BE8F0@xmb-rcd-x08.cisco.com> <20121004073007.GA95642@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 08:07:55 -0000 On Thu, Oct 04, 2012 at 09:37:44AM +0200, Romascanu, Dan (Dan) wrote: > > [[DR]] What dependency? One does not need to implement the ENTITY-MIB. > > We've done similar things also the other way. I am not sure that the > multiplication of the MIB modules defining TCs is a good thing, to the > extreme we would get to defining each TC in a separate MIB module. The > ENTITY-MIB is quite generic, so importing from it does not seem that odd > to me. Sorry, I only see advantages in keeping truely generic definitions separate from MIB modules defining concrete data models. > > > > > 2. Two TCs. I assumed that what we are defining is the UUIDOrZero > TC. > > > Maybe we should call it so. Why do we need two TCs? Where would we > use > > > UUID TC and where would we use UUIDOrZero TC in the ENTITY-MIB? Or > you > > > have in mind future use? > > > > You use a UUID TC in places where you only have to represent UUIDs. > You > > use the UUIDOrZero TC in places where you have to represent a UUID or > a > > zero-length string. Its simply useful to provide them both. (In some > MIB > > modules, non existing objects simply do not exist.) > > > [[DR]] OK - so in the Entity MIB would use the UUIDOrZero TC, while the > UUID TC will be defined only to be IMPORTed by other modules in the > future. Yes, for example the energy management modules or an update of the host resources module or ... > > > 3. Format. We used the SYNTAX and formatting that was discussed on > the > > > list. I thought that we have consensus on it. What would be the > > > alternate proposal? > > > > Not sure what your question is. Obviously, SIZE (16) does not go well > > along with a "zero-length" string. > > > > [[DR]] Right. Should be SIZE (0|16) for the UUIDOrZero TC and SIZE (16) > for the UUID TC. Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trac+eman@trac.tools.ietf.org Thu Oct 4 13:01:57 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB181F0429 for ; Thu, 4 Oct 2012 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBFeraTPVNIz for ; Thu, 4 Oct 2012 13:01:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 338E811E809A for ; Thu, 4 Oct 2012 13:01:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:53352 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJrc8-0004vM-GS; Thu, 04 Oct 2012 22:01:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brads@coraid.com X-Trac-Project: eman Date: Thu, 04 Oct 2012 20:01:44 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/10#comment:1 Message-ID: <079.26dfcdfcccaf0950557c130a36d24c65@trac.tools.ietf.org> References: <064.3eb407edbc8ae4a48423a7ac22ccd6b8@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <064.3eb407edbc8ae4a48423a7ac22ccd6b8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #10: 6.5.2 - DMTF states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 20:01:57 -0000 #10: 6.5.2 - DMTF states Changes (by brads@…): * owner: all => brads@… -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: brads@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Thu Oct 4 19:12:24 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36BA1F0C44 for ; Thu, 4 Oct 2012 19:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcRzO3mIzyxQ for ; Thu, 4 Oct 2012 19:12:24 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 282651F041F for ; Thu, 4 Oct 2012 19:12:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:58337 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJxOZ-0003rJ-6b; Fri, 05 Oct 2012 04:12:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com, brads@coraid.com X-Trac-Project: eman Date: Fri, 05 Oct 2012 02:12:06 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/14#comment:2 Message-ID: <079.5f53acfe6a2dd649d211fd2d0dc36426@trac.tools.ietf.org> References: <064.043b2e5afe430fb3ac1c93c789241a9d@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <064.043b2e5afe430fb3ac1c93c789241a9d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #14: Metering and Power Source both seem to be derivative of wiring topology X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 02:12:24 -0000 #14: Metering and Power Source both seem to be derivative of wiring topology Comment (by brads@…): Agree, let's close -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Thu Oct 4 19:19:19 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7935D1F0C51 for ; Thu, 4 Oct 2012 19:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDXx1P7c+eGs for ; Thu, 4 Oct 2012 19:19:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E5EB41F0C4C for ; Thu, 4 Oct 2012 19:19:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:58981 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJxVL-0002YE-Gz; Fri, 05 Oct 2012 04:19:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brads@coraid.com X-Trac-Project: eman Date: Fri, 05 Oct 2012 02:19:07 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/25#comment:1 Message-ID: <079.423e0ee87b671c99d806babb7d6309e9@trac.tools.ietf.org> References: <064.63adb5d03338921086f8490c4f50a27b@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <064.63adb5d03338921086f8490c4f50a27b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #25: l. Figure 7 seems unnecessary to include? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 02:19:19 -0000 #25: l. Figure 7 seems unnecessary to include? Comment (by brads@…): Which Figure 7? Figure 7: DMTF / ACPI Power State Mapping Figure 7: Power Source with Power interfaces The DMTF/ACPI power state mapping was included because there was (and still is) much confusion about power states in various standards. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Thu Oct 4 19:19:46 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65911E809B for ; Thu, 4 Oct 2012 19:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYQMzcZqPHHw for ; Thu, 4 Oct 2012 19:19:46 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E32CF11E8091 for ; Thu, 4 Oct 2012 19:19:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:58994 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJxVw-0008Th-IJ; Fri, 05 Oct 2012 04:19:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brads@coraid.com X-Trac-Project: eman Date: Fri, 05 Oct 2012 02:19:44 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/25#comment:2 Message-ID: <079.dd6c8228e31bb80351bd104252c85a61@trac.tools.ietf.org> References: <064.63adb5d03338921086f8490c4f50a27b@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <064.63adb5d03338921086f8490c4f50a27b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #25: l. Figure 7 seems unnecessary to include? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 02:19:46 -0000 #25: l. Figure 7 seems unnecessary to include? Changes (by brads@…): * owner: all => brads@… -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: brads@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Thu Oct 4 19:27:33 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F3E1F0C49 for ; Thu, 4 Oct 2012 19:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0NmDAKsz58w for ; Thu, 4 Oct 2012 19:27:32 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 33F401F041F for ; Thu, 4 Oct 2012 19:27:32 -0700 (PDT) Received: from localhost ([127.0.0.1]:59788 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJxdI-0001iU-6R; Fri, 05 Oct 2012 04:27:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brads@coraid.com X-Trac-Project: eman Date: Fri, 05 Oct 2012 02:27:20 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/10#comment:2 Message-ID: <079.5026be8647191a54e62bbbd9af0aff3c@trac.tools.ietf.org> References: <064.3eb407edbc8ae4a48423a7ac22ccd6b8@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <064.3eb407edbc8ae4a48423a7ac22ccd6b8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #10: 6.5.2 - DMTF states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 02:27:33 -0000 #10: 6.5.2 - DMTF states Comment (by brads@…): I don't undersand the suggestion to condense this. Please provide more rational. It all seems highly relevant esp given the different view points on power states. 6.5.2 DMTF Power State Series DMTF [DMTF] standards organization has defined a power profile standard based on the CIM (Common Information Model) model that consists of 15 power states ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt (11), Off-Soft-Graceful (12), Off-Hard Graceful (13), MasterBus reset Graceful (14), Power- Cycle Off-Soft Graceful (15), PowerCycle-Hard Graceful (16). DMTF standard is targeted for hosts and computers. Details of the semantics of each Power State within the DMTF Power State Series can be obtained from the DMTF Power State Management Profile specification [DMTF]. DMTF power profile extends ACPI power states. The following table provides a mapping between DMTF and ACPI Power State Series and EMAN Power State Sets (described in the next section): -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: brads@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Thu Oct 4 19:38:12 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA4421F8508 for ; Thu, 4 Oct 2012 19:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmqPuSpAi-YN for ; Thu, 4 Oct 2012 19:38:12 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDA021F8503 for ; Thu, 4 Oct 2012 19:38:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:60638 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TJxnW-0001oD-K2; Fri, 05 Oct 2012 04:37:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-eman-framework@tools.ietf.org, brads@coraid.com X-Trac-Project: eman Date: Fri, 05 Oct 2012 02:37:54 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/26 Message-ID: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-eman-framework@tools.ietf.org, brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bclaise@cisco.com, bnordman@lbl.gov, brad@bradschoening.com, jparello@cisco.com, quittek@netlab.nec.de Resent-Message-Id: <20121005023812.0BDA021F8503@ietfa.amsl.com> Resent-Date: Thu, 4 Oct 2012 19:38:12 -0700 (PDT) Resent-From: trac+eman@trac.tools.ietf.org Cc: eman@ietf.org Subject: [eman] #26: ASHRAE 201P Power Quality X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 02:38:12 -0000 #26: ASHRAE 201P Power Quality The ASHRAE/NEMA Standard 201P use of power quality terminology should be normalized or cross-referenced with EMAN terminology. ASHRAE: "This information represents a summary of power quality information typically required by customer facility energy management systems. It is not intended to satisfy the detailed requirements of power quality monitoring. All values are as defined by measurementProtocol during the period. The standards typically also give ranges of allowed values; the information attributes are the raw measurements, not the "yes/no" determination by the various standards." EMAN: "Power Characteristics is not intended to be judgmental with respect to a reference or technical independent of any usage context." -- -----------------------+----------------------------------------- Reporter: brads@… | Owner: draft-ietf-eman-framework@… Type: defect | Status: new Priority: major | Milestone: Component: framework | Version: Severity: - | Keywords: -----------------------+----------------------------------------- Ticket URL: eman From internet-drafts@ietf.org Fri Oct 5 04:29:53 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA1D21F8667; Fri, 5 Oct 2012 04:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRCWlLcuv0Ow; Fri, 5 Oct 2012 04:29:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303B221F854C; Fri, 5 Oct 2012 04:29:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121005112953.13482.42840.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 04:29:53 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:29:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Entity MIB (Version 4) Author(s) : Andy Bierman Dan Romascanu Juergen Quittek Mouli Chandramouli Filename : draft-ietf-eman-rfc4133bis-02.txt Pages : 69 Date : 2012-10-05 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version of the Entity MIB, which obsoletes version 3 [RFC4133]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-rfc4133bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-rfc4133bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From moulchan@cisco.com Fri Oct 5 04:33:59 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2823221F8466 for ; Fri, 5 Oct 2012 04:33:59 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TduZ1BfcuE2 for ; Fri, 5 Oct 2012 04:33:58 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7877221F84C2 for ; Fri, 5 Oct 2012 04:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1942; q=dns/txt; s=iport; t=1349436838; x=1350646438; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JQoMkWRnznlsfmNeLHtorcrYvr/NXFJDYSeb0BhCXd0=; b=RFaXdNk1KBXSvkUi1ogL+iSxrQ2RzLSqRXGdq6/0kDa1Rahq2o97Tgg+ 33Csxsj/x3Qw5lYDCPCVr6LDeIVezjuxdckDQlW6pZkRn4+R8CZde6Hmz MQxFteHITHxfA3x1pbYgTNSZI/D66Ca/9dyPNiN594KR5hvtZwIpkonNH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADrFblCtJXG8/2dsb2JhbABFvyCBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIAQsOh2MLmESgCos+hSlgA5cAjTCBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128634734" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 05 Oct 2012 11:33:58 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q95BXvin022600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 5 Oct 2012 11:33:57 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.137]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 06:33:57 -0500 From: "Mouli Chandramouli (moulchan)" To: "eman@ietf.org" Thread-Topic: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt Thread-Index: AQHNouzAwppao52ZLEuYW5ecsFpMd5eqk7tg Date: Fri, 5 Oct 2012 11:33:57 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BF634@xmb-rcd-x08.cisco.com> References: <20121005112953.13482.42840.idtracker@ietfa.amsl.com> In-Reply-To: <20121005112953.13482.42840.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.138] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--31.740900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:33:59 -0000 Hello all,=20 The draft has been updated with 2 TCs - PhysicalUUID and PhysicalUUIDorZer= o. =20 The TCs are left in the draft and shall go the WG consensus on this.=20 Thanks Andy, Dan, Juergen and Mouli=20 -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, October 05, 2012 5:00 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Entity MIB (Version 4) Author(s) : Andy Bierman Dan Romascanu Juergen Quittek Mouli Chandramouli Filename : draft-ietf-eman-rfc4133bis-02.txt Pages : 69 Date : 2012-10-05 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version of the Entity MIB, which obsoletes version 3 [RFC4133]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-rfc4133bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-rfc4133bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Fri Oct 5 04:46:48 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B8921F86CA for ; Fri, 5 Oct 2012 04:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.217 X-Spam-Level: X-Spam-Status: No, score=-103.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBKOd3uE-yHm for ; Fri, 5 Oct 2012 04:46:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E135121F85C2 for ; Fri, 5 Oct 2012 04:46:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FD1220C81; Fri, 5 Oct 2012 13:46:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fvTdSV8VCnFH; Fri, 5 Oct 2012 13:46:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 924F220C7C; Fri, 5 Oct 2012 13:46:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 89CAA222223C; Fri, 5 Oct 2012 13:46:37 +0200 (CEST) Date: Fri, 5 Oct 2012 13:46:37 +0200 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20121005114637.GB98064@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , "eman@ietf.org" References: <20121005112953.13482.42840.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BF634@xmb-rcd-x08.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BF634@xmb-rcd-x08.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:46:48 -0000 On Fri, Oct 05, 2012 at 11:33:57AM +0000, Mouli Chandramouli (moulchan) wrote: > Hello all, > > The draft has been updated with 2 TCs - PhysicalUUID and PhysicalUUIDorZero. > > The TCs are left in the draft and shall go the WG consensus on this. > Once again, I strongly suggest to create generic UUID TC definitions and I strongly suggest to move them into a separate MIB module. PhysicalUUID ::= TEXTUAL-CONVENTION DISPLAY-HINT "4x-2x-2x-1x1x-6x" STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains a Universal Unique Identifier, the syntax of this object must conform to RFC 4122, section 4.1." SYNTAX OCTET STRING (SIZE (16)) It is wrong to write "this objects" in a TC definition. PhysicalUUIDorZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "4x-2x-2x-1x1x-6x" STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains a Universal Unique Identifier, the syntax of this object must conform to RFC 4122, section 4.1. If no additional identification information is known about the physical entity or supported, the object is not instantiated. A zero length octet string may also be returned in this case." SYNTAX OCTET STRING (SIZE (0|16)) It is not appropriate to talk about object instantiation in a TC definition. Furthermore, leaving it open whether a zero-length string is returned or the object does not exist is not really helping interoperability and it is inconsistent with other objects of the ENTITY-MIB. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Fri Oct 5 07:32:02 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A870221F86EE; Fri, 5 Oct 2012 07:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM1Bupt97r6O; Fri, 5 Oct 2012 07:32:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE8A21F86CF; Fri, 5 Oct 2012 07:32:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121005143202.25033.22611.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 07:32:02 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-requirements-09.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:32:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Requirements for Energy Management Author(s) : Juergen Quittek Mouli Chandramouli Rolf Winter Thomas Dietz Benoit Claise Filename : draft-ietf-eman-requirements-09.txt Pages : 31 Date : 2012-10-05 Abstract: This document defines requirements for standards specifications for energy management. The requirements defined in this document concern monitoring functions as well as control functions. In detail, the focus of the requirements is on the following features: identification of energy-managed devices and their components, monitoring of their Power State, power inlets, power outlets, actual power, power properties, received energy, provided energy, and contained batteries. Further requirements are included to enable control of their power supply and Power State. This document does not specify the features that must be implemented by compliant implementations but rather features that must be supported by standards for energy management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-requirements-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-requirements-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Quittek@neclab.eu Fri Oct 5 08:51:43 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7744221F8764 for ; Fri, 5 Oct 2012 08:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.832 X-Spam-Level: X-Spam-Status: No, score=-101.832 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3ci35ln0Ziw for ; Fri, 5 Oct 2012 08:51:39 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6D81E21F8707 for ; Fri, 5 Oct 2012 08:51:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 825F710207E for ; Fri, 5 Oct 2012 17:51:38 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGev+oLwQQMr for ; Fri, 5 Oct 2012 17:51:38 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 69C3510207D for ; Fri, 5 Oct 2012 17:51:33 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.21]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 5 Oct 2012 17:50:42 +0200 From: Juergen Quittek To: eman mailing list Thread-Topic: [eman] I-D Action: draft-ietf-eman-requirements-09.txt Thread-Index: AQHNoxE+SHFWXI2TKUSJfUInf3w3ZA== Date: Fri, 5 Oct 2012 15:50:42 +0000 Message-ID: In-Reply-To: <20121005143202.25033.22611.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <8DCB72DB57EA604EA7E8836590E1BFD3@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-requirements-09.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:51:43 -0000 Dear all, The new version of the requirements draft addresses a few issues that have been discussed on the mailing list recently: - We reduced the number of basic power states from four to three, see section 3.1 - We replaced the requirement for "average and maximum" power per power state By just the "typical" power per power state, see requirement 5.4.6 Note that this issue is still being argued about on the mailing list. An alternative under discussion is "typical and maximum" power. - We added requirement 5.7.2 on supporting alternative time interval types. - We removed Appendix B on existing standards of other bodies. This topic Will be covered by the applicability draft. Please send your comments. >From the authors point of view the document is mature enough for starting Working group last call. Thanks, Juergen =20 On 05.10.12 16:32, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Energy Management Working Group of the >IETF. > > Title : Requirements for Energy Management > Author(s) : Juergen Quittek > Mouli Chandramouli > Rolf Winter > Thomas Dietz > Benoit Claise > Filename : draft-ietf-eman-requirements-09.txt > Pages : 31 > Date : 2012-10-05 > >Abstract: > This document defines requirements for standards specifications for > energy management. The requirements defined in this document concern > monitoring functions as well as control functions. In detail, the > focus of the requirements is on the following features: > identification of energy-managed devices and their components, > monitoring of their Power State, power inlets, power outlets, actual > power, power properties, received energy, provided energy, and > contained batteries. Further requirements are included to enable > control of their power supply and Power State. This document does > not specify the features that must be implemented by compliant > implementations but rather features that must be supported by > standards for energy management. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-eman-requirements > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-eman-requirements-09 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-requirements-09 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From dromasca@avaya.com Fri Oct 5 09:41:21 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D60621F8698 for ; Fri, 5 Oct 2012 09:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.308 X-Spam-Level: X-Spam-Status: No, score=-103.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2WLRvtwTIxE for ; Fri, 5 Oct 2012 09:41:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1E65121F8692 for ; Fri, 5 Oct 2012 09:41:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK4Lb1DGmAcF/2dsb2JhbABCA78hgQiCIAEBAQEDAQEBDx4KNAsMAgICAQgNAQIBBAEBAQoGDAsBBgEaDB8JCAEBBAESCBqHYwubQ50XBIs6gmOCRmADm2+KKoJv X-IronPort-AV: E=Sophos;i="4.80,541,1344225600"; d="scan'208";a="327482880" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Oct 2012 12:35:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Oct 2012 12:32:53 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 18:41:02 +0200 Message-ID: In-Reply-To: <20121005114637.GB98064@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt Thread-Index: Ac2i7xzdWJoo6SV/S+u5dm6ASNzIOgAJxj4A References: <20121005112953.13482.42840.idtracker@ietfa.amsl.com><852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BF634@xmb-rcd-x08.cisco.com> <20121005114637.GB98064@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Mouli Chandramouli (moulchan)" Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 16:41:21 -0000 Hi Juergen, There are two issues here:=20 - create a separate MIB module for the two TCs - this is just a technical problem, I disagree with you on the need, but it's simple to do this if this will be the WG consensus - generic TCs:=20 What about the following changes in the DESCRIPTION clauses:=20 OLD: DESCRIPTION "This object contains additional identification information about the physical entity. The object contains a Universal Unique Identifier, the syntax of this object must conform to RFC 4122, section 4.1." NEW: DESCRIPTION "Universal Unique Identifier information. The syntax must=20 conform to RFC 4122, section 4.1." and=20 OLD:=20 DESCRIPTION "This object contains additional identification information about the physical entity. The object contains a Universal Unique Identifier, the syntax of this object must conform to RFC 4122, section 4.1. If no additional identification information is known about the physical entity or supported, the object is not instantiated. A zero length octet string may also be returned in this case." NEW:=20 DESCRIPTION " Universal Unique Identifier information. The syntax must=20 conform to RFC 4122, section 4.1. A zero length octet string is returned if no UUID=20 information is known." Maybe we can also drop Physical from the TC name.=20 Thanks and Regards, Dan > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Friday, October 05, 2012 1:47 PM > To: Mouli Chandramouli (moulchan) > Cc: eman@ietf.org > Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt >=20 > On Fri, Oct 05, 2012 at 11:33:57AM +0000, Mouli Chandramouli (moulchan) > wrote: > > Hello all, > > > > The draft has been updated with 2 TCs - PhysicalUUID and > PhysicalUUIDorZero. > > > > The TCs are left in the draft and shall go the WG consensus on this. > > >=20 > Once again, I strongly suggest to create generic UUID TC definitions and > I strongly suggest to move them into a separate MIB module. >=20 > PhysicalUUID ::=3D TEXTUAL-CONVENTION > DISPLAY-HINT "4x-2x-2x-1x1x-6x" > STATUS current > DESCRIPTION > "This object contains additional identification information > about the physical entity. The object contains a Universal > Unique Identifier, the syntax of this object must conform to > RFC 4122, section 4.1." > SYNTAX OCTET STRING (SIZE (16)) >=20 > It is wrong to write "this objects" in a TC definition. >=20 > PhysicalUUIDorZero ::=3D TEXTUAL-CONVENTION > DISPLAY-HINT "4x-2x-2x-1x1x-6x" > STATUS current > DESCRIPTION > "This object contains additional identification information > about the physical entity. The object contains a Universal > Unique Identifier, the syntax of this object must conform to > RFC 4122, section 4.1. >=20 > If no additional identification information is known > about the physical entity or supported, the object is not > instantiated. A zero length octet string may also be > returned in this case." > SYNTAX OCTET STRING (SIZE (0|16)) >=20 > It is not appropriate to talk about object instantiation in a TC > definition. Furthermore, leaving it open whether a zero-length string > is returned or the object does not exist is not really helping > interoperability and it is inconsistent with other objects of the > ENTITY-MIB. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From blueroofmusic@gmail.com Fri Oct 5 10:37:26 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01FA21F87E8 for ; Fri, 5 Oct 2012 10:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXLZIt0au6hg for ; Fri, 5 Oct 2012 10:37:25 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4A21F864A for ; Fri, 5 Oct 2012 10:37:25 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so872918wib.13 for ; Fri, 05 Oct 2012 10:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oCKrkjpOXHE8mFQadSW/y0WFmBLbOYMGJiA/I175CfA=; b=o43qMXplNtLznZixBUctfXhb5KSeuWkWn/u4lO5Ve2DCrbFuKp6gV2645L16ZK3tks YiBj21DRB5xVsf2kZFs0lYOFjDYsq6ydrp3G50lfLbUm1rMpROJJGsxUV478+o6ElWG4 yh/qmevB/5Ny6bDPCJh2LPfFGehzLrq2xtls2osG2y73JWyDeej9eqzpVup1+q5Dn1ND ml6BXD4CSTzg1ivfDmXiUtGnCozzddQYicRrXOUtak+MwV0v6YmKRC0/wD761mPznBnl i9NLtAM4SYOHL66T2NG/TJQPTzmkDYgKqPi9f1Zhe2CSGpb3rqfQ0YAUFflMNHX6AI06 357Q== MIME-Version: 1.0 Received: by 10.180.8.134 with SMTP id r6mr4718125wia.18.1349458644360; Fri, 05 Oct 2012 10:37:24 -0700 (PDT) Received: by 10.216.16.40 with HTTP; Fri, 5 Oct 2012 10:37:24 -0700 (PDT) In-Reply-To: References: <20121005143202.25033.22611.idtracker@ietfa.amsl.com> Date: Fri, 5 Oct 2012 13:37:24 -0400 Message-ID: From: Ira McDonald To: Juergen Quittek , Ira McDonald Content-Type: multipart/alternative; boundary=f46d041827f822de9904cb5353e7 Cc: eman mailing list Subject: Re: [eman] I-D Action: draft-ietf-eman-requirements-09.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:37:27 -0000 --f46d041827f822de9904cb5353e7 Content-Type: text/plain; charset=ISO-8859-1 Hi, About power consumption in a given power state: FWIW, in the IEEE-ISTO Printer Working Group's Imaging System Power MIB [1], we have a table called :powSupportTable with basic characteristics for each power state (either of the whole system or a power managed component of the system). There we have the "inactive", "active", and "maximum" power usage for the entity. The terms "inactive" versus "active" distinguish between idle (doing no work) versus processing (printing, moving paper, etc.) power usage in the given power state (we use DMTF states). The term "maximum" is especially relevant to the whole system, where a number of components may all be active. All of the reported values are as determined by the manufacturer - that is, they are NOT based on actual power usage meters. Cheers, - Ira (editor of PWG Power MIB) [1] PWG Imaging System Power MIB v1.0 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf - terms, requirements, conformance ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib - ASN.1 source of MIB Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 Temporary Cabin *** 2012 only *** 906-494-2523 On Fri, Oct 5, 2012 at 11:50 AM, Juergen Quittek wrote: > Dear all, > > The new version of the requirements draft addresses a few issues that have > been discussed on the mailing list recently: > > - We reduced the number of basic power states from four to three, see > section 3.1 > - We replaced the requirement for "average and maximum" power per power > state > By just the "typical" power per power state, see requirement 5.4.6 > Note that this issue is still being argued about on the mailing list. > An alternative under discussion is "typical and maximum" power. > - We added requirement 5.7.2 on supporting alternative time interval > types. > - We removed Appendix B on existing standards of other bodies. This topic > Will be covered by the applicability draft. > > Please send your comments. > > From the authors point of view the document is mature enough for starting > Working group last call. > > Thanks, > Juergen > > > On 05.10.12 16:32, "internet-drafts@ietf.org" > wrote: > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Energy Management Working Group of the > >IETF. > > > > Title : Requirements for Energy Management > > Author(s) : Juergen Quittek > > Mouli Chandramouli > > Rolf Winter > > Thomas Dietz > > Benoit Claise > > Filename : draft-ietf-eman-requirements-09.txt > > Pages : 31 > > Date : 2012-10-05 > > > >Abstract: > > This document defines requirements for standards specifications for > > energy management. The requirements defined in this document concern > > monitoring functions as well as control functions. In detail, the > > focus of the requirements is on the following features: > > identification of energy-managed devices and their components, > > monitoring of their Power State, power inlets, power outlets, actual > > power, power properties, received energy, provided energy, and > > contained batteries. Further requirements are included to enable > > control of their power supply and Power State. This document does > > not specify the features that must be implemented by compliant > > implementations but rather features that must be supported by > > standards for energy management. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-eman-requirements > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-eman-requirements-09 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=draft-ietf-eman-requirements-09 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >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 > --f46d041827f822de9904cb5353e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

About power consumption in a given power state:

FWIW, in = the IEEE-ISTO Printer Working Group's
Imaging System Power MIB [1], = we have a table
called :powSupportTable with basic characteristics
for each power state (either of the whole system or
a power managed comp= onent of the system).

There we have the "inactive", "= active", and "maximum"
power usage for the entity.=A0
The terms "inactive" versus "active" distinguish be= tween idle
(doing no=A0work) versus processing (printing, moving paper,=
etc.) power usage in the given power state (we use DMTF
states).= =A0

The term "maximum" is especially relevant to the whole system= ,
where a number of components may all be active.=A0 All of the
repo= rted values are as determined by the manufacturer - that is,
they are NO= T based on actual power usage meters.

Cheers,
- Ira (editor of PWG Power MIB)

[1] PWG Imaging Syste= m Power MIB v1.0
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wim= spowermib10-20110214-5106.5.pdf
- terms, requirements, conformance
ftp://ftp.pwg.org/pub/pwg= /candidates/cs-wimspowermib10-20110214-5106.5.mib
- ASN.1 source of = MIB

Ira McDonald (Musician / Software Architect)
Chair - L= inux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working G= roup
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility = Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP &a= mp; Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434
Temporary Cabin= *** 2012 only *** 906-494-2523
=



On Fri, Oct 5, 2012 at 11:50 AM, Juergen= Quittek <Quittek@neclab.eu> wrote:
Dear all,

The new version of the requirements draft addresses a few issues that have<= br> been discussed on the mailing list recently:

=A0 - We reduced the number of basic power states from four to three, see section 3.1
=A0 - We replaced the requirement for "average and maximum" power= per power
state
=A0 =A0 By just the "typical" power per power state, see requirem= ent 5.4.6
=A0 =A0 Note that this issue is still being argued about on the mailing lis= t.
=A0 =A0 An alternative under discussion is "typical and maximum" = power.
=A0 - We added requirement 5.7.2 on supporting alternative time interval types.
=A0 - We removed Appendix B on existing standards of other bodies. This top= ic
=A0 =A0 Will be covered by the applicability draft.

Please send your comments.

>From the authors point of view the document is mature enough for starting Working group last call.

Thanks,
=A0 =A0 Juergen


On 05.10.12 16:32, "intern= et-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Energy Management Working Group of th= e
>IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for Energy Manage= ment
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Juergen Quittek
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mouli Chandramouli<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rolf Winter
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thomas Dietz
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Benoit Claise
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-eman-requirements-09.= txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 31
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-05
>
>Abstract:
> =A0 This document defines requirements for standards specifications fo= r
> =A0 energy management. =A0The requirements defined in this document co= ncern
> =A0 monitoring functions as well as control functions. =A0In detail, t= he
> =A0 focus of the requirements is on the following features:
> =A0 identification of energy-managed devices and their components,
> =A0 monitoring of their Power State, power inlets, power outlets, actu= al
> =A0 power, power properties, received energy, provided energy, and
> =A0 contained batteries. =A0Further requirements are included to enabl= e
> =A0 control of their power supply and Power State. =A0This document do= es
> =A0 not specify the features that must be implemented by compliant
> =A0 implementations but rather features that must be supported by
> =A0 standards for energy management.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-eman-requi= rements
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-eman-requirements-0= 9
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ema= n-requirements-09
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp:/= /ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>eman mailing list
>eman@ietf.org
>https://www.ietf.org/mailman/listinfo/eman

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

--f46d041827f822de9904cb5353e7-- From j.schoenwaelder@jacobs-university.de Mon Oct 8 02:46:14 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E27721F8732 for ; Mon, 8 Oct 2012 02:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.218 X-Spam-Level: X-Spam-Status: No, score=-103.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCjO3h9G7jop for ; Mon, 8 Oct 2012 02:46:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB2021F86B2 for ; Mon, 8 Oct 2012 02:46:13 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D4E120C53; Mon, 8 Oct 2012 11:46:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id td0ZXOOQXJhH; Mon, 8 Oct 2012 11:46:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B04620C41; Mon, 8 Oct 2012 11:46:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 63DC922264F8; Mon, 8 Oct 2012 11:46:08 +0200 (CEST) Date: Mon, 8 Oct 2012 11:46:07 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20121008094607.GE3383@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Mouli Chandramouli (moulchan)" , eman@ietf.org References: <20121005112953.13482.42840.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BF634@xmb-rcd-x08.cisco.com> <20121005114637.GB98064@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 09:46:14 -0000 On Fri, Oct 05, 2012 at 06:41:02PM +0200, Romascanu, Dan (Dan) wrote: > > Hi Juergen, > > There are two issues here: > > - create a separate MIB module for the two TCs - this is just a > technical problem, I disagree with you on the need, but it's simple to > do this if this will be the WG consensus ack, we disagree here > - generic TCs: > > What about the following changes in the DESCRIPTION clauses: > > OLD: > DESCRIPTION > "This object contains additional identification information > about the physical entity. The object contains a Universal > Unique Identifier, the syntax of this object must conform to > RFC 4122, section 4.1." > > NEW: > > DESCRIPTION > "Universal Unique Identifier information. The syntax must > conform to RFC 4122, section 4.1." yep, much better > and > > OLD: > > DESCRIPTION > "This object contains additional identification information > about the physical entity. The object contains a Universal > Unique Identifier, the syntax of this object must conform to > RFC 4122, section 4.1. > > If no additional identification information is known > about the physical entity or supported, the object is not > instantiated. A zero length octet string may also be > returned in this case." > > NEW: > > DESCRIPTION > " Universal Unique Identifier information. The syntax must > conform to RFC 4122, section 4.1. > > A zero length octet string is returned if no UUID > information is known." I prefer a phrasing that is more liberal about the semantics of the zero-length string value and closer to other similar TCs (including PhysicalIndexOrZero): DESCRIPTION "Universal Unique Identifier information. The syntax must conform to RFC 4122, section 4.1. The semantics of the value zero-length OCTET STRING are object-specific and must therefore be defined as part of the description of any object that uses this syntax." > Maybe we can also drop Physical from the TC name. Yes and putting it into a separate small MIB module like we have the URI-TC-MIB, the IPV6-FLOW-LABEL-MIB, the VPN-TC-STD-MIB, ... would be even better. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Mon Oct 8 03:05:17 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9398B21F86B7 for ; Mon, 8 Oct 2012 03:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.312 X-Spam-Level: X-Spam-Status: No, score=-103.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roXNuvkQXPQ9 for ; Mon, 8 Oct 2012 03:05:16 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4E89621F86A5 for ; Mon, 8 Oct 2012 03:05:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL6kclCHCzI1/2dsb2JhbABCA78kgQiCIAEBAQEDEh4KPwwCAgIBCA0BAgEEAQEBCgYMCwEGARorCQgBAQQTCBqHY5xDnCcEi0uCaoJGYAOXAIRviiqCbw X-IronPort-AV: E=Sophos;i="4.80,552,1344225600"; d="scan'208";a="327694065" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Oct 2012 05:59:16 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Oct 2012 05:43:07 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Oct 2012 12:05:11 +0200 Message-ID: In-Reply-To: <20121008094607.GE3383@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt Thread-Index: Ac2lOcI1fpNEOjgrRpqVz8WmL8bAhwAAoP4g References: <20121005112953.13482.42840.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237BF634@xmb-rcd-x08.cisco.com> <20121005114637.GB98064@elstar.local> <20121008094607.GE3383@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 10:05:17 -0000 Makes sense. I will make the changes, probably, by tomorrow (it's a holiday here in Israel today).=20 Thanks and Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, October 08, 2012 11:46 AM > To: Romascanu, Dan (Dan) > Cc: Mouli Chandramouli (moulchan); eman@ietf.org > Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-02.txt >=20 > On Fri, Oct 05, 2012 at 06:41:02PM +0200, Romascanu, Dan (Dan) wrote: > > > > Hi Juergen, > > > > There are two issues here: > > > > - create a separate MIB module for the two TCs - this is just a > > technical problem, I disagree with you on the need, but it's simple to > > do this if this will be the WG consensus >=20 > ack, we disagree here >=20 > > - generic TCs: > > > > What about the following changes in the DESCRIPTION clauses: > > > > OLD: > > DESCRIPTION > > "This object contains additional identification > information > > about the physical entity. The object contains a > Universal > > Unique Identifier, the syntax of this object must conform > to > > RFC 4122, section 4.1." > > > > NEW: > > > > DESCRIPTION > > "Universal Unique Identifier information. The syntax must > > conform to RFC 4122, section 4.1." >=20 > yep, much better >=20 > > and > > > > OLD: > > > > DESCRIPTION > > "This object contains additional identification > information > > about the physical entity. The object contains a > Universal > > Unique Identifier, the syntax of this object must conform > to > > RFC 4122, section 4.1. > > > > If no additional identification information is known > > about the physical entity or supported, the object is not > > instantiated. A zero length octet string may also be > > returned in this case." > > > > NEW: > > > > DESCRIPTION > > " Universal Unique Identifier information. The syntax must > > conform to RFC 4122, section 4.1. > > > > A zero length octet string is returned if no UUID > > information is known." >=20 > I prefer a phrasing that is more liberal about the semantics of the > zero-length string value and closer to other similar TCs (including > PhysicalIndexOrZero): >=20 > DESCRIPTION > "Universal Unique Identifier information. The syntax must > conform to RFC 4122, section 4.1. >=20 > The semantics of the value zero-length OCTET STRING are > object-specific and must therefore be defined as part of > the description of any object that uses this syntax." >=20 > > Maybe we can also drop Physical from the TC name. >=20 > Yes and putting it into a separate small MIB module like we have the > URI-TC-MIB, the IPV6-FLOW-LABEL-MIB, the VPN-TC-STD-MIB, ... would be > even better. ;-) >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From bclaise@cisco.com Tue Oct 9 09:45:33 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F931F0CA2 for ; Tue, 9 Oct 2012 09:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9kTzfeFp5M4 for ; Tue, 9 Oct 2012 09:45:32 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC4D1F0C99 for ; Tue, 9 Oct 2012 09:45:32 -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 q99GjTWH028113 for ; Tue, 9 Oct 2012 18:45:30 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q99GjT9i022717 for ; Tue, 9 Oct 2012 18:45:29 +0200 (CEST) Message-ID: <507454A9.2020806@cisco.com> Date: Tue, 09 Oct 2012 18:45:29 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: eman mailing list Content-Type: multipart/alternative; boundary="------------050009040101080203020509" Subject: [eman] EMAN-REQ: 5.7.2. Time series interval types X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:45:33 -0000 This is a multi-part message in MIME format. --------------050009040101080203020509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I looked at http://tools.ietf.org/rfcdiff?url2=draft-ietf-eman-requirements-09.txt, and I have a question What does the following new requirement mean and imply? 5.7.2. Time series interval types The standard must provide means for supporting alternative interval types. Requirement 5.5.2 applies to every reported time value. >From http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03 There are three eoEnergyParametersIntervalMode types used for energy measurement collection: period, sliding, and total. The choices of the the three different modes of collection are based on IEC standard 61850-7-4. While we can have a new entry in eoEnergyParametersIntervalMode... eoEnergyParametersIntervalMode OBJECT-TYPE SYNTAX INTEGER { period(1), sliding(2), total(3) } MAX-ACCESS read-create ... I'm slightly concerned that the new interval types might involve different indices, so basically new MIB tables. Regards, Benoit (as a contributor) --------------050009040101080203020509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I looked at http://tools.ietf.org/rfcdiff?url2=draft-ietf-eman-requirements-09.txt, and I have a question
What does the following new requirement mean and imply?
5.7.2.  Time series interval types
   The standard must provide means for supporting alternative interval
   types.  Requirement 5.5.2 applies to every reported time value.

From http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03
        There are three eoEnergyParametersIntervalMode types used for
        energy measurement collection: period, sliding, and total. The
        choices of the the three different modes of collection are based
        on IEC standard 61850-7-4.
While we can have a new entry in eoEnergyParametersIntervalMode...
  eoEnergyParametersIntervalMode OBJECT-TYPE
          SYNTAX          INTEGER  {
                              period(1),
                              sliding(2),
                              total(3)
                          }
          MAX-ACCESS      read-create
... I'm slightly concerned that the new interval types might involve different indices, so basically new MIB tables.

Regards, Benoit (as a contributor)
--------------050009040101080203020509-- From jparello@cisco.com Tue Oct 9 10:39:59 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257F021F8740 for ; Tue, 9 Oct 2012 10:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UZ3pxIVN+2o for ; Tue, 9 Oct 2012 10:39:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 534BB21F87B3 for ; Tue, 9 Oct 2012 10:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1079; q=dns/txt; s=iport; t=1349804398; x=1351013998; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=WcuOWJpdmchDPStRJEkjauJGFD+5V6D/hCFbCoBVCQU=; b=RKkGSuuFeeoXt8hKI94KVlxCViSfXc6a0BnKjC36//N0hCFSZ4ZnVUsY 74wyyzrb83lpR3b1YAWXiht4ynrQt85hkwQcnBAJeJJSCIAWaIWq0GTnh QzN4orQ6VDQg4jL6ANt2vVzytVsSMwmypu7+gCdGRdfHVKI1zyW4jPy7+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGNgdFCtJXHB/2dsb2JhbABFvzGBCIIiAQQSASdRASoUQiYBBBsah2IBmiKBKI9WkEKLVIUYYAOkL4Frgm2CFw X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="129628394" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 09 Oct 2012 17:39:57 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q99HdvL1027807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Oct 2012 17:39:57 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 12:39:57 -0500 From: "John Parello (jparello)" To: "eman@ietf.org" Thread-Topic: [eman] Allowing curtailment in draft-ietf-eman-requirements-09 Thread-Index: Ac2mRRdzmj+/+sSURuuuZzIiQAFzog== Date: Tue, 9 Oct 2012 17:39:56 +0000 Message-ID: <9C213D38848B89428F46808B16F6F0860C22D8@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--29.252100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] Allowing curtailment in draft-ietf-eman-requirements-09 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 17:39:59 -0000 Hi Authors, Should Section 3.1 Power states be modified to include curtailment levels? = So something like: "However, more finely grained Power States or Curtailment Levels can be imp= lemented." This would however have implications on section 5.4.* With ASHRAE 201p I'm concerned a device that implements that model would no= t be in line with the requirements. So just say a device complies with 201p: - Implements a power state with values (on,off,pause) with no information a= bout power etc at those states. - implements 5 curtailment levels with power information such as 1) Off, 0% of Max 2) sleep , 10% of Max 3) low, 50% of Max 4) med, 80% of Max 5) high, 100% of Max Would the device fulfill the requirements. The requirements says the states= must report the values but in 201p the curtailments do. Perhaps the requirements should be either (1) made more general as to allo= w the above or (2) include the notion of curtailments. I prefer (1) since requirements don't dictate implementation. Jp From moulchan@cisco.com Tue Oct 9 23:10:05 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A79F21F8582 for ; Tue, 9 Oct 2012 23:10:05 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nh4DLfRpArn for ; Tue, 9 Oct 2012 23:10:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4494621F8581 for ; Tue, 9 Oct 2012 23:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=729; q=dns/txt; s=iport; t=1349849404; x=1351059004; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1doewV5H9T7IUuy+lN/63kEoGayvUanzufenlZ0GCJs=; b=j0Xl+iHNGmF3D2YrfEAo71UTnR4WOKkijvNtp9Dn4UA9Fs7aWoCovLW4 NuOjL2n2m1pGLVBhMtLQ0p7edKZDP8WEOEJNFvLgKYhRoc2CxefC4cNzg fgwCho7oJcgFLzhV8h1PUCn0cJMXU6zkfc5rB81v0ZB5k1HPnclFYa4VG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANMQdVCtJV2a/2dsb2JhbABEvzGBCIIhAQEEEgEnTwIBKhQQMiUCBBsah2OYLqAli2GFJWADpDCBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,563,1344211200"; d="scan'208";a="130030579" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 10 Oct 2012 06:09:55 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9A69tQq011368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Oct 2012 06:09:55 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 01:09:55 -0500 From: "Mouli Chandramouli (moulchan)" To: eman mailing list Thread-Topic: [eman] EMAN-REQ: 5.3.1 and 5.3.5 Thread-Index: AQHNpq3dnt8Mr6NftkOsHfrfv57HQw== Date: Wed, 10 Oct 2012 06:09:54 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237D6A7E@xmb-rcd-x08.cisco.com> References: <20121005143202.25033.22611.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000 x-tm-as-result: No--28.197800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] EMAN-REQ: 5.3.1 and 5.3.5 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 06:10:05 -0000 Hello, As now, some of the requirements are phrased for "entire" entity.=20 5.3.1. Real power=20 The standard must provide means for reporting the real power for each Power Interface as well as for an entire entity. =20 5.3.5. Actual voltage and current The standard must provide means for reporting the actual voltage and actual current for each power interface as well as for an entire entity. =20 If there are implementations, where power, voltage, current and energy mea= surements are collected for every entPhysicalIndex (device and its subcompo= nents), is that implementation compliant with the EMAN requirements 5.3.1 a= nd 5.3.2 ?=20 Please advice. =20 Thanks Mouli=20 From bnordman@lbl.gov Wed Oct 10 00:32:55 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8221F8747 for ; Wed, 10 Oct 2012 00:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlULbFU1SVxO for ; Wed, 10 Oct 2012 00:32:54 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 94EF221F8746 for ; Wed, 10 Oct 2012 00:32:54 -0700 (PDT) X-Ironport-SBRS: 4.8 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0EAGsjdVDRVdyslGdsb2JhbABBA4JLg0enVgGIbAGIVQgjAQEBAQkJCwkSKYI5Ag9NIg03AiQSAQUBIhMih2OXBYJjCQOLVoRLjjmLYYJfghSBEgOIWI0TgRWNOhYphAIt X-IronPort-AV: E=Sophos;i="4.80,564,1344236400"; d="scan'208";a="87795664" Received: from mail-vc0-f172.google.com ([209.85.220.172]) by ironport4.lbl.gov with ESMTP; 10 Oct 2012 00:32:53 -0700 Received: by mail-vc0-f172.google.com with SMTP id fl11so427569vcb.31 for ; Wed, 10 Oct 2012 00:32:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=di4/t3bYvEJjUIsW4TMpWlQsDTW/v86fXXpu2aMKObo=; b=nE+feyQCBO3PO9rZqomBbzf2QSQy2Ed+BmHQOgmuTy+Ig33eQy5gEjr55mZvWEuhHY 8XI7z8zABYozCzk5W6LJJowwZA+FKyZQ/NpU2WbDLHrXrItj6AoqL/ekkrNWn2zRY/ZX lxf6HKcOrQt+1Sh3PBDEtF2bGRn/mj+naMi4lmKUFzDZiNrAnWzxDRPsm0ZJIG9//t9M h8aksxlfdEprbx7PQPReZzgRuVYST5LpeJiTpYdHT8kwZnda4rnOp5XdQ9LSZqFM+7sm xvDbEDV8wPUFFXl3Z/YSEVkrPhnMgSmG1Bpr1wXCybNxI8Xy7jjSVKHLjJqEmIiqJKQB /nWQ== MIME-Version: 1.0 Received: by 10.220.222.206 with SMTP id ih14mr13252392vcb.6.1349854372581; Wed, 10 Oct 2012 00:32:52 -0700 (PDT) Received: by 10.58.125.73 with HTTP; Wed, 10 Oct 2012 00:32:52 -0700 (PDT) Date: Wed, 10 Oct 2012 00:32:52 -0700 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=14dae9cdc10160529704cbaf769f X-Gm-Message-State: ALoCoQmqi9BPk81zb2YP1vJdW3i6vGquHUznrhw0mTfvlBULmlwvN/pR9IT2uDNIqYwVUsakAWVt Subject: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 07:32:56 -0000 --14dae9cdc10160529704cbaf769f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We have spent much time trying to clarify and disentangle states and levels for devices. It seems clear that some applications and several external standards require grid curtailment levels. Several long-standing industry standards define device internal power states. I took the relevant sections of the framework draft, beginning with 6.5, and boiled down the text there to what I think covers what we need. That is shown below. The existing language was retained as much as possible. I did remove redundant text as well as details outside the scope of the framework and some details from the external standards. The intent was to not change the meaning of these sections, just the presentation, except to clarify the difference between power states and curtailment levels. 6.5. Power States An Energy Object can be controlled by setting it to a specific Power State or a specific Curtailment Level (these described in the following section). A Power States Set is an interface by which an Energy Object can be controlled. Each Energy Object should indicate the Power State Sets that it implements. Well known Power State Sets should be registered with IANA When a device is set to a particular Power State, it may be busy. The device will set the desired Power State and then update the actual Power State when it changes. There are thus two Power State variables: actual and desired. There are many existing standards for and implementations of Power State Sets. An Energy Object can support multiple Power State Sets concurrently. This framework identifies three initial Power State Sets: IEEE1621 [IEEE1621], DMTF [DMTF], and PWG [PWG]. 6.5.1 IEEE1621 Power State Set IEEE1621 [IEEE1621] defines three basic power states : on, off, and sleep. 6.5.2 DMTF Power State Set DMTF [DMTF] builds on ACPI states defines 6 core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or =96S2), Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and Hibernate (ACPI-S4). It also defines transitional states and state change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset, Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard Graceful. The DMTF standard is targeted to hosts and computers. 6.5.3 PWG Power State Set The Printer Working Group [PWG] also builds on ACPI states defines 6 stable power states, a series of DMTF =93special=94 power states, a few out-of-ban= d power states, and provision for vendor extensions to power states. The DMTF standard is targeted to printers and other imaging devices. 6.6 Curtailment Levels EMAN defines curtailment levels to provide a standard approach to model the different levels of power of a device. The curtailment levels incorporate non-operational states as defined in [ACPI] and [DMTF] standards, and specify several intermediate operational states. There are twelve curtailment levels: six operational and six non-operational. The lowest non-operational level is 1 and the highest is 6. Each non-operational level corresponds to an ACPI global and system state. Each operational state represents a performance state, and may be mapped to an ACPI processor state. For each level, the level preceding it is expected to have a lower Power value. For levels where the device is non-operational, it is expected that it has a longer delay in returning to an operational state. Characteristics of curtailment levels are as follows. For the first six, no energy object features are available, except for 4, 5, and 6, which may include out-of-band management and device wakeup. mechoff(1): No energy is consumed. The power connector can be removed. Corresponds to ACPI state G3. softoff(2): Some components remain powered. No context is saved. Powering up typically requires a system boot. Corresponds to ACPI state G2/S5. hibernate(3): The device may be woken without requiring a system boot. The time for availability is longer than sleep(4). Corresponds to ACPI state G1/S4. sleep(4): The time for availability is longer than standby(5). Corresponds to ACPI state G1/S3. standby(5): The time for availability is longer than ready(6). Corresponds to ACPI state G1/S2. ready(6): The device can be quickly transitioned into an operational state= . Corresponds to ACPI state G1/S1. For all of the following levels, some features may not be available and power consumption is less than higher numbered levels. All correspond to ACPI S0. The highest power consumption occurs in high(12). These levels are: lowMinus(7), low(8), mediumMinus(9), medium(10), highMinus(11), and high(12). --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --14dae9cdc10160529704cbaf769f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We have spent much time trying to clarify and disentangle states
and lev= els for devices.=C2=A0 It seems clear that some applications and
several= external standards require grid curtailment levels.
Several long-standi= ng industry standards define device internal
power states.

I took the relevant sections of the framework draft, b= eginning with 6.5,
and boiled down the text there to what I think covers= what we need.
That is shown below.=C2=A0 The existing language was reta= ined as much
as possible.=C2=A0 I did remove redundant text as well as details outside t= he
scope of the framework and some details from the external standards.<= br>
The intent was to not change the meaning of these sections, just the=
presentation, except to clarify the difference between=C2=A0 power states <= br>and curtailment levels.


6.5. Power States

An Ene= rgy Object can be controlled by setting it to a specific Power State or a specific Curtailment Level (these described = in the following section). =C2=A0A Power States Set is an interface by which an Energy Object can be controlled.=C2=A0 Each Energy Object should indicate the Power State Sets that it implements.=C2=A0 Well known Power State Sets should be registered with IANA

When a device is set to= a particular Power State, it may be busy.=C2=A0 The device will set the desired Power State and then update the actu= al Power State when it changes.=C2=A0 There are thus two Power State variables: actual and desired.

There are many existing= standards for and implementations of Power State Sets.=C2=A0 An Energy Object can support multiple Power State Sets concurrently.=

This framework identifi= es three initial Power State Sets: IEEE1621 [IEEE1621], DMTF [DMTF], and PWG [PWG].

6.5.1 IEEE1621 Power State Set

IEEE1621 [IEEE1621] def= ines three basic power states : on, off, and sleep.

6.5.2 DMTF Power= State Set

DMTF [DMTF] builds on A= CPI states defines 6 core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or =E2=80= =93S2), Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and Hibernate (ACPI-S4).= =C2=A0 It also defines transitional states and state change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset, Diagnost= ic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus reset Graceful, = Power-Cycle Off-Soft Graceful, and PowerCycle-Hard Graceful.=C2=A0 T= he DMTF standard is targeted to hosts and computers.=C2=A0

6.5.3 PWG Power State Set

The Printer Working Gro= up [PWG] also builds on ACPI states defines 6 stable power states, a series of DMTF =E2= =80=9Cspecial=E2=80=9D power states, a few out-of-band power states, and provision for vendor extensions to power states.=C2=A0 The DMTF standard is targeted to printers and other imaging devices.

=C2=A0

6.6 Curtailment Levels

EMAN defines curtailmen= t levels to provide a standard approach to model the different levels of power of a device. =C2=A0The curtailment levels incorporate non-operational states as defined in [ACPI] and [DMTF] standard= s, and specify several intermediate operational states.

There are twelve curtai= lment levels: six operational and six non-operational.=C2=A0 T= he lowest non-operational level is 1 and the highest is 6.=C2=A0 Each non-operational level corresponds to an ACPI global and system state.=C2=A0 Each operational state represents a performance state, and may be ma= pped to an ACPI processor state.

For each level, the lev= el preceding it is expected to have a lower Power value.=C2=A0 For levels where the device is non-operational, it is expected that it has a longer delay in returning to = an operational state.

Characteristics of curt= ailment levels are as follows.=C2=A0 For the first six, no energy object features are available, except for 4, 5, and 6, which= may include out-of-band management and device wakeup.

mechoff(1): No energy i= s consumed.=C2=A0 The power connector can be removed. =C2=A0Corresponds to ACPI state G3.

softoff(2): Some compon= ents remain powered.=C2=A0 No context is saved.= =C2=A0 Powering up typically requires a system boot. =C2=A0Corresponds to ACPI state G2/S5.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

hibernate(3): The devic= e may be woken without requiring a system boot.=C2=A0 The time for availability is longer than sleep(4). =C2=A0Cor= responds to ACPI state G1/S4.

sleep(4): The time for availability is longer than standby(5). =C2=A0Correspond= s to ACPI state G1/S3.

standby(5): The time fo= r availability is longer than ready(6). =C2=A0Corresponds to ACPI state G1/S2.

ready(6): = =C2=A0The device can be quickly transitioned into an operational state.=C2=A0 Corresponds to ACPI state G1/S1.

For all of the followin= g levels, some features may not be available and power consumption is less than highe= r numbered levels.=C2=A0 All correspond to ACPI S0.=C2=A0 The highest power consumption occurs in high(12).=C2=A0 These levels are:=C2=A0 <= /span>lowMinus(7), low(8), mediumMinus(9), medium(10), highMinus(11), and high(12).

=C2=A0



--
Bruce NordmanLawrence Berkeley National Laboratory<= /span>
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--14dae9cdc10160529704cbaf769f-- From internet-drafts@ietf.org Wed Oct 10 05:04:41 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F405321F8724; Wed, 10 Oct 2012 05:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm9GQu2KpMsC; Wed, 10 Oct 2012 05:04:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F93721F84E6; Wed, 10 Oct 2012 05:04:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2012 05:04:40 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:04:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Entity MIB (Version 4) Author(s) : Andy Bierman Dan Romascanu Juergen Quittek Mouli Chandramouli Filename : draft-ietf-eman-rfc4133bis-03.txt Pages : 70 Date : 2012-10-10 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version of the Entity MIB, which obsoletes version 3 [RFC4133]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-rfc4133bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-rfc4133bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From moulchan@cisco.com Wed Oct 10 05:14:08 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A48F21F86A5 for ; Wed, 10 Oct 2012 05:14:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+05NyAynhTB for ; Wed, 10 Oct 2012 05:14:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6198821F8679 for ; Wed, 10 Oct 2012 05:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2070; q=dns/txt; s=iport; t=1349871246; x=1351080846; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0vC6QJmMLFNUUGLZ4lXGbYZ/GI2F35FZ/apZ1ICIptE=; b=VkmuhFaT0WNyOgjniUhagMAo/0+4iQ8NOTwrILgjp5tTSP/55bGLUDH4 szii8lnJrEeB4ertFieO0XLx/Brgf7qCpawx2DNU8zlhwH2kaYZoxnSY0 Nf4cah2yioItkLfpCL9OevZSl6o3GazzdKYqdz9vbO7WpJitaMryEZEYT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM5ldVCtJV2c/2dsb2JhbABEvyuBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIAQsOh2MLlzCgIItGhUBgA5cAjTCBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="129897586" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 10 Oct 2012 12:14:05 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9ACE5xw022853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Oct 2012 12:14:05 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 07:14:05 -0500 From: "Mouli Chandramouli (moulchan)" To: eman mailing list Thread-Topic: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt Thread-Index: AQHNpt+NjJ2B45Vtqkyx5qBm5EWz0JeycZkA Date: Wed, 10 Oct 2012 12:14:04 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237D6EA3@xmb-rcd-x08.cisco.com> References: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> In-Reply-To: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000 x-tm-as-result: No--33.730900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:14:08 -0000 Hello all,=20 Based on the persuasive comments of Juergen Schoenwaelder the draft has bee= n updated=20 with a separate UUID-TC-MIB which contains the definitions of Textual conve= ntions UUID and UUIDorZero. =20 The descriptions are also modified. =20 Please let us know if you have comments.=20 Thanks Andy, Dan, Juergen and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Wednesday, October 10, 2012 5:35 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Entity MIB (Version 4) Author(s) : Andy Bierman Dan Romascanu Juergen Quittek Mouli Chandramouli Filename : draft-ietf-eman-rfc4133bis-03.txt Pages : 70 Date : 2012-10-10 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version of the Entity MIB, which obsoletes version 3 [RFC4133]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-rfc4133bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-rfc4133bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Wed Oct 10 05:24:18 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24F821F8623 for ; Wed, 10 Oct 2012 05:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB5oRASGrdNk for ; Wed, 10 Oct 2012 05:24:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C3C2821F8588 for ; Wed, 10 Oct 2012 05:24:17 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3B3220C6D; Wed, 10 Oct 2012 14:24:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CrJ85Ydp-4Zd; Wed, 10 Oct 2012 14:24:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 603B120C2D; Wed, 10 Oct 2012 14:24:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 16F2F22402A6; Wed, 10 Oct 2012 14:24:12 +0200 (CEST) Date: Wed, 10 Oct 2012 14:24:12 +0200 From: Juergen Schoenwaelder To: eman@ietf.org Message-ID: <20121010122412.GA59580@elstar.local> Mail-Followup-To: eman@ietf.org References: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:24:19 -0000 On Wed, Oct 10, 2012 at 05:04:40AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Energy Management Working Group of the IETF. > > Title : Entity MIB (Version 4) > Author(s) : Andy Bierman > Dan Romascanu > Juergen Quittek > Mouli Chandramouli > Filename : draft-ietf-eman-rfc4133bis-03.txt > Pages : 70 > Date : 2012-10-10 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) for > use with network management protocols in the Internet community. In > particular, it describes managed objects used for managing multiple > logical and physical entities managed by a single SNMP agent. This > document specifies version of the Entity MIB, which obsoletes version 3 > [RFC4133]. Thanks. In the next revision of the I-D, please collapse the revision statements; revision statements are only added for published versions of a MIB module. I am not sure whether the new entPhysicalUUID object should be added to the examples or not. This text also looks a bit garbled: 2.16.1. MIB module addition Creation of a new MIB module IANA-ENTITY- MIB which makes the PhysicalIndex TC an IANA-maintained Textual Convention. Over time, there is the need to add new enumerated values for PhysicalClass. If the syntax of IANAPhysicalClass were defined in this MIB module then a new version of this MIB would have to be re-issued in order to define new values. There also seems confusion how the new TC is called. Is it PhysicalClass or IANAPhysicalClass? And what has the PhysicalIndex to do with it?? Some descriptions (entPhysicalEntry, entPhysicalVendorType) talk about entIANAPhysicalClass, which does not seem to exist anymore. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Oct 10 05:33:40 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF67821F8625 for ; Wed, 10 Oct 2012 05:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.337 X-Spam-Level: X-Spam-Status: No, score=-103.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slMW-3g6DsgO for ; Wed, 10 Oct 2012 05:33:40 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 144D621F8594 for ; Wed, 10 Oct 2012 05:33:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACdqdVCHCzI1/2dsb2JhbABBA78rgQiCIAEBAQECAQEBAQ8eCjQQBwICAgEIDQECAQQBAQEKBgwLAQYBGgwfCQgBAQQBEggMDoddBguaOp0hBItCgnqCRmADkjqJNYosgm8 X-IronPort-AV: E=Sophos;i="4.80,565,1344225600"; d="scan'208";a="370903463" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Oct 2012 08:27:43 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Oct 2012 08:11:27 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Oct 2012 14:33:37 +0200 Message-ID: In-Reply-To: <20121010122412.GA59580@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt Thread-Index: Ac2m4jf+SCtJotr5Sga6Iwino8fjbgAAPWdA References: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> <20121010122412.GA59580@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:33:41 -0000 Hi Juergen, Thank you for your comments. Can we consider these comments (and other that may follow) as Working Group Last Call comments?=20 This would allow the chairs to start a WGLC and get comments also from other WG participants for the Atlanta meeting.=20 Thanks and Regards, Dan > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Wednesday, October 10, 2012 2:24 PM > To: eman@ietf.org > Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt >=20 > On Wed, Oct 10, 2012 at 05:04:40AM -0700, internet-drafts@ietf.org > wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Energy Management Working Group of > the IETF. > > > > Title : Entity MIB (Version 4) > > Author(s) : Andy Bierman > > Dan Romascanu > > Juergen Quittek > > Mouli Chandramouli > > Filename : draft-ietf-eman-rfc4133bis-03.txt > > Pages : 70 > > Date : 2012-10-10 > > > > Abstract: > > This memo defines a portion of the Management Information Base (MIB) > > for use with network management protocols in the Internet community. > > In particular, it describes managed objects used for managing multiple > > logical and physical entities managed by a single SNMP agent. This > > document specifies version of the Entity MIB, which obsoletes version > > 3 [RFC4133]. >=20 > Thanks. In the next revision of the I-D, please collapse the revision > statements; revision statements are only added for published versions of > a MIB module. >=20 > I am not sure whether the new entPhysicalUUID object should be added to > the examples or not. >=20 > This text also looks a bit garbled: >=20 > 2.16.1. MIB module addition Creation of a new MIB module IANA-ENTITY- > MIB which makes the PhysicalIndex TC an IANA-maintained Textual > Convention. Over time, there is the need to add new enumerated values > for PhysicalClass. If the syntax of IANAPhysicalClass were defined > in this MIB module then a new version of this MIB would have to be > re-issued in order to define new values. >=20 > There also seems confusion how the new TC is called. Is it PhysicalClass > or IANAPhysicalClass? And what has the PhysicalIndex to do with it?? >=20 > Some descriptions (entPhysicalEntry, entPhysicalVendorType) talk about > entIANAPhysicalClass, which does not seem to exist anymore. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Wed Oct 10 05:40:26 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA89321F86D6 for ; Wed, 10 Oct 2012 05:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.22 X-Spam-Level: X-Spam-Status: No, score=-103.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6sKGKOoRumG for ; Wed, 10 Oct 2012 05:40:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3C88721F8623 for ; Wed, 10 Oct 2012 05:40:26 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D17E20C6F; Wed, 10 Oct 2012 14:40:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 33Sj_HUZOl_O; Wed, 10 Oct 2012 14:40:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A3B420C34; Wed, 10 Oct 2012 14:40:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E8FFB22406C7; Wed, 10 Oct 2012 14:40:22 +0200 (CEST) Date: Wed, 10 Oct 2012 14:40:22 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20121010124022.GA59852@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , eman@ietf.org References: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> <20121010122412.GA59580@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-rfc4133bis-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:40:27 -0000 On Wed, Oct 10, 2012 at 02:33:37PM +0200, Romascanu, Dan (Dan) wrote: > Hi Juergen, > > Thank you for your comments. Can we consider these comments (and other > that may follow) as Working Group Last Call comments? > > This would allow the chairs to start a WGLC and get comments also from > other WG participants for the Atlanta meeting. > Sure. Whatever works best to get things into a consistent shape. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From n.brownlee@auckland.ac.nz Wed Oct 10 13:06:00 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C221F854C for ; Wed, 10 Oct 2012 13:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdlwVMzUwRG5 for ; Wed, 10 Oct 2012 13:05:58 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE6221F8562 for ; Wed, 10 Oct 2012 13:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1349899558; x=1381435558; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=WHl7NPVpGoOIETrS7D1skz3ftJjdv1cTZ4K+a4nxBvI=; b=gYVt970IsrZkKaWszYUFXiuamQoAYzIHKSnsyO6bvyz5oh9V+uA68WYz MU0N+HVV2ZGdaRy6LDtLrf5IBsPjTnHT+OU7zBP3n7KhSALgyLsxNodsh CbfQtlss7SeEkubbI/4vHJ+GZSKM0EbbYizmBpqmL99GDUUIOKcjJIDbG g=; X-IronPort-AV: E=Sophos;i="4.80,566,1344168000"; d="scan'208";a="150197750" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 11 Oct 2012 09:05:56 +1300 Message-ID: <5075D51E.9090309@auckland.ac.nz> Date: Thu, 11 Oct 2012 09:05:50 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "eman >> \"eman@ietf.org\"" References: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> <20121010122412.GA59580@elstar.local> <20121010124022.GA59852@elstar.local> In-Reply-To: <20121010124022.GA59852@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] WG Last CAll for draft-ietf-eman-rfc4133bis-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 20:06:00 -0000 Hi all: This begins the WG Last Call for the Entity MIB (Version 4) draft. It will end on Monday, 29 October (a week before IETF 85). Please read it, and send your comments to the eman list. If you think it's OK, let us know that too! Cheers, Nevoil On 11/10/12 1:40 AM, Juergen Schoenwaelder wrote: > On Wed, Oct 10, 2012 at 02:33:37PM +0200, Romascanu, Dan (Dan) wrote: >> Hi Juergen, >> >> Thank you for your comments. Can we consider these comments (and other >> that may follow) as Working Group Last Call comments? >> >> This would allow the chairs to start a WGLC and get comments also from >> other WG participants for the Atlanta meeting. >> > > Sure. Whatever works best to get things into a consistent shape. > > /js -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trac+eman@trac.tools.ietf.org Wed Oct 10 14:08:06 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC13621F8543 for ; Wed, 10 Oct 2012 14:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPWKwmgISe6Z for ; Wed, 10 Oct 2012 14:08:06 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2B08221F8585 for ; Wed, 10 Oct 2012 14:08:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:56077 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TM3VN-00048K-NT; Wed, 10 Oct 2012 23:07:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bclaise@cisco.com X-Trac-Project: eman Date: Wed, 10 Oct 2012 21:07:49 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/6#comment:1 Message-ID: <079.4c347723102ce0577950f3c0aabb4732@trac.tools.ietf.org> References: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bclaise@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #6: States and ASHRAE Curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 21:08:06 -0000 #6: States and ASHRAE Curtailment levels Comment (by bclaise@…): - power states different than curtailment level (% of max) - must have the power states (on/off/pause), and maybe curtailment levels (spectrum of the control) - curtailment levels defined in ASHRAE - curtailment levels could span multiple power states - Question: are there more power state in ACPI than the 3 power states? Juergen: G states are power states, not curtailment levels John: yes, we can. We could have registry of curtailment levels matching ACPI. - Do we want to have a single registry or two different registries? John: want to have a single registry Juergen: some devices are fine with just 3 power states Bruce: a single registry with a flag (power state or curtailment level)? John: will be confusing - Juergen: different concepts - Consensus? power states are more important. we want a single registry of power states and not two different ones Open Issue: do we want to flag the power state that are more curtailment level? what is the semantic of power state? Next Steps: all of us WRITE the power states and how they interact with curtailment levels. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 10 14:14:15 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE001F0429 for ; Wed, 10 Oct 2012 14:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntWVsydX-e2Y for ; Wed, 10 Oct 2012 14:14:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 56A811F041F for ; Wed, 10 Oct 2012 14:14:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:56522 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TM3bH-0003WS-97; Wed, 10 Oct 2012 23:13:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 10 Oct 2012 21:13:55 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/11#comment:3 Message-ID: <079.fda1ff53100ae96ebe24194d4b0cfeb5@trac.tools.ietf.org> References: <064.3929ae5620b5cbd5fe77d141043968bc@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <064.3929ae5620b5cbd5fe77d141043968bc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #11: Clarify 'aggregation' X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 21:14:16 -0000 #11: Clarify 'aggregation' Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed -- --------------------------+----------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: closed Priority: major | Milestone: Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+----------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 10 14:14:35 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2575A1F0429 for ; Wed, 10 Oct 2012 14:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYG+c-HRdfaX for ; Wed, 10 Oct 2012 14:14:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 944991F041F for ; Wed, 10 Oct 2012 14:14:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:56599 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TM3bq-0006tX-AD; Wed, 10 Oct 2012 23:14:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com, brads@coraid.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 10 Oct 2012 21:14:30 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/eman/trac/ticket/14#comment:3 Message-ID: <079.5d254c7d4cc2aa8c3b4da915fa463eb5@trac.tools.ietf.org> References: <064.043b2e5afe430fb3ac1c93c789241a9d@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <064.043b2e5afe430fb3ac1c93c789241a9d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, brads@coraid.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #14: Metering and Power Source both seem to be derivative of wiring topology X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 21:14:35 -0000 #14: Metering and Power Source both seem to be derivative of wiring topology Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From n.brownlee@auckland.ac.nz Wed Oct 10 14:19:28 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60B51F0417 for ; Wed, 10 Oct 2012 14:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFm8UURIRpH9 for ; Wed, 10 Oct 2012 14:19:28 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id F37401F040A for ; Wed, 10 Oct 2012 14:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1349903968; x=1381439968; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=8hqVC2UCdZFDw7iJm869fhz1JaNyRqyGbSjBD+kOMq0=; b=IkTSBbTupXlIC6DIlmkrZY6h2osGZjccsfVSTWF+Liieik78M1WqGv3X IBHhcK9SAvOWGHe6a4zMN+8AxDDQZiUH24UXakR2JzSqU6b7kAPYonnuq UZ297oXelLtKeX4LqmDAJp7Ue+Ch54u2O+Qd+veFFHYmHvkZeuD8olOTA 8=; X-IronPort-AV: E=Sophos;i="4.80,566,1344168000"; d="scan'208";a="150215070" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 11 Oct 2012 10:19:15 +1300 Message-ID: <5075E653.5070907@auckland.ac.nz> Date: Thu, 11 Oct 2012 10:19:15 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "eman >> \"eman@ietf.org\"" References: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> <20121010122412.GA59580@elstar.local> <20121010124022.GA59852@elstar.local> In-Reply-To: <20121010124022.GA59852@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] WG Last Call for draft-ietf-eman-requirements-09 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 21:19:28 -0000 Hi all: This begins the WG Last Call for the EMAN Requirements draft. It will end on Monday, 29 October (a week before IETF 85). Please read it, and send your comments to the eman list. If you think it's OK, let us know that too! Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From blueroofmusic@gmail.com Wed Oct 10 14:58:23 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A0911E808D for ; Wed, 10 Oct 2012 14:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJz3suFD6Dtr for ; Wed, 10 Oct 2012 14:58:21 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5066911E808A for ; Wed, 10 Oct 2012 14:58:21 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so843509lam.31 for ; Wed, 10 Oct 2012 14:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r5Kv9jPYgnnVo+QpyVcwb0rv74qqnQrTfb2JXM83hYU=; b=lOn/qzwugSAqRT5znBvlT9YS9jTtpNzD7oHGV2I3oBaxBkXrUKoGLkkqKinmvpNcsI DU74/+oXIrLkmyLiKUcYixKN9+bCqBVP39jLfrgcqmOHDS0Ian2gL0Db7pESVSrSKZoG WF9L0sLJY55J2MaCnJzuc49vNg9g/tH7J4j0eaDTKCNclh3crHI+oGApNekJqI/pmOVT It7pKkQeHyQeLlATY73krJpP+P8WkX3ouqCOqRXs+wRVfmHwyoKdynXEkht48FY5XzGi dQtfvSLzRu2V5kwTSvUuZrzIVjw4sFuaTJJEjYTSmralLO1PsomToQErkn/dYkRDVZEI cPPg== MIME-Version: 1.0 Received: by 10.152.48.111 with SMTP id k15mr21155383lan.17.1349906300238; Wed, 10 Oct 2012 14:58:20 -0700 (PDT) Received: by 10.112.127.228 with HTTP; Wed, 10 Oct 2012 14:58:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Oct 2012 17:58:20 -0400 Message-ID: From: Ira McDonald To: Bruce Nordman , Ira McDonald Content-Type: multipart/alternative; boundary=bcaec55243b0817caf04cbbb8d0a Cc: eman mailing list Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 21:58:23 -0000 --bcaec55243b0817caf04cbbb8d0a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Bruce, Two corrections to the paragraph on PWG Power States, w/ highlighted changed words below: 6.5.3 PWG Power State Set The Printer Working Group [PWG] also builds on ACPI states and defines 6 stable power states, a series of DMTF =93special=94 power states, a few out-of-band power states, and provision for vendor extensions to power states. The PWG standard is targeted to printers and other imaging devices. Cheers, - Ira (editor of PWG Power MIB) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 Temporary Cabin *** 2012 only *** 906-494-2523 On Wed, Oct 10, 2012 at 3:32 AM, Bruce Nordman wrote: > We have spent much time trying to clarify and disentangle states > and levels for devices. It seems clear that some applications and > several external standards require grid curtailment levels. > Several long-standing industry standards define device internal > power states. > > I took the relevant sections of the framework draft, beginning with 6.5, > and boiled down the text there to what I think covers what we need. > That is shown below. The existing language was retained as much > as possible. I did remove redundant text as well as details outside the > scope of the framework and some details from the external standards. > > The intent was to not change the meaning of these sections, just the > presentation, except to clarify the difference between power states > and curtailment levels. > > > 6.5. Power States > > An Energy Object can be controlled by setting it to a specific Power Stat= e > or a specific Curtailment Level (these described in the following section= ). > A Power States Set is an interface by which an Energy Object can be > controlled. Each Energy Object should indicate the Power State Sets that > it implements. Well known Power State Sets should be registered with IAN= A > > When a device is set to a particular Power State, it may be busy. The > device will set the desired Power State and then update the actual Power > State when it changes. There are thus two Power State variables: actual > and desired. > > There are many existing standards for and implementations of Power State > Sets. An Energy Object can support multiple Power State Sets > concurrently. > > This framework identifies three initial Power State Sets: IEEE1621 > [IEEE1621], DMTF [DMTF], and PWG [PWG]. > 6.5.1 IEEE1621 Power State Set > > IEEE1621 [IEEE1621] defines three basic power states : on, off, and sleep= . > 6.5.2 DMTF Power State Set > > DMTF [DMTF] builds on ACPI states defines 6 core power states: On > (ACPI-S0), Sleep-Light (ACPI-S1 or =96S2), Sleep-Deep (ACPI-S4), Off-Hard > (ACPI-S5), Off-Soft (ACPI-S5), and Hibernate (ACPI-S4). It also defines > transitional states and state change commands: PowerCycle Off-Soft, > PowerCycle, MasterBus reset, Diagnostic Interrupt, Off-Soft-Graceful, > Off-Hard Graceful, MasterBus reset Graceful, Power-Cycle Off-Soft Gracefu= l, > and PowerCycle-Hard Graceful. The DMTF standard is targeted to hosts and > computers. > 6.5.3 PWG Power State Set > > The Printer Working Group [PWG] also builds on ACPI states defines 6 > stable power states, a series of DMTF =93special=94 power states, a few > out-of-band power states, and provision for vendor extensions to power > states. The DMTF standard is targeted to printers and other imaging > devices. > > > 6.6 Curtailment Levels > > EMAN defines curtailment levels to provide a standard approach to model > the different levels of power of a device. The curtailment levels > incorporate non-operational states as defined in [ACPI] and [DMTF] > standards, and specify several intermediate operational states. > > There are twelve curtailment levels: six operational and six > non-operational. The lowest non-operational level is 1 and the highest > is 6. Each non-operational level corresponds to an ACPI global and > system state. Each operational state represents a performance state, and > may be mapped to an ACPI processor state. > > For each level, the level preceding it is expected to have a lower Power > value. For levels where the device is non-operational, it is expected > that it has a longer delay in returning to an operational state. > > Characteristics of curtailment levels are as follows. For the first six, > no energy object features are available, except for 4, 5, and 6, which ma= y > include out-of-band management and device wakeup. > > mechoff(1): No energy is consumed. The power connector can be removed. = Corresponds > to ACPI state G3. > > softoff(2): Some components remain powered. No context is saved. Poweri= ng > up typically requires a system boot. Corresponds to ACPI state G2/S5. > > > hibernate(3): The device may be woken without requiring a system boot. T= he > time for availability is longer than sleep(4). Corresponds to ACPI state > G1/S4. > > sleep(4): The time for availability is longer than standby(5). Correspon= ds > to ACPI state G1/S3. > > standby(5): The time for availability is longer than ready(6). Correspon= ds > to ACPI state G1/S2. > > ready(6): The device can be quickly transitioned into an operational > state. Corresponds to ACPI state G1/S1. > > For all of the following levels, some features may not be available and > power consumption is less than higher numbered levels. All correspond to > ACPI S0. The highest power consumption occurs in high(12). These levels > are: lowMinus(7), low(8), mediumMinus(9), medium(10), highMinus(11), and > high(12). > > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > *nordman.lbl.gov* > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --bcaec55243b0817caf04cbbb8d0a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Bruce,

Two corrections to the paragraph on PWG Power States,
w= / highlighted changed words below:

= 6.5.3 PWG Power State Set

The Printer Working Gro= up [PWG] also builds on ACPI sta= tes and defines 6 st= able power states, a series of DMTF =93special=94 power states, a few out-of-band power states, and provision for vendor extensions to power states.=A0 The PWG standard is targeted to printers and other imaging devices.


Cheers,=
- Ira (editor of PWG Power MIB)


Ira McDonald (= Musician / Software Architect)
Chair - Linux Foundation Open Printing WG=
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP= WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded= Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites= .google.com/site/blueroofmusic
http://si= tes.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 = 734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2= 434
Temporary Cabin *** 2012 only *** 906-494-2523



On Wed, Oct 10, 2012 at 3:32 AM, Bruce N= ordman <bnordman@lbl.gov> wrote:
We have spent much time trying to clarify and disentangle states
and lev= els for devices.=A0 It seems clear that some applications and
several ex= ternal standards require grid curtailment levels.
Several long-standing = industry standards define device internal
power states.

I took the relevant sections of the framework draft, b= eginning with 6.5,
and boiled down the text there to what I think covers= what we need.
That is shown below.=A0 The existing language was retaine= d as much
as possible.=A0 I did remove redundant text as well as details outside the<= br>scope of the framework and some details from the external standards.
=
The intent was to not change the meaning of these sections, just the presentation, except to clarify the difference between=A0 power states
= and curtailment levels.


6.5. Power States

An Ene= rgy Object can be controlled by setting it to a specific Power State or a specific Curtailment Level (these described = in the following section). =A0A Power States Set is an interface by which an Energy Object can be controlled.=A0 <= /span>Each Energy Object should indicate the Power State Sets that it implements.=A0 Well known Power State Sets should be registered with IANA

When a device is set to= a particular Power State, it may be busy.=A0 The device will set the desired Power State and then update the actu= al Power State when it changes.=A0 There are thus two Power State variables: actual and desired.

There are many existing= standards for and implementations of Power State Sets.=A0 An Energy Object can support multiple Power State Sets concurrently.=

This framework identifi= es three initial Power State Sets: IEEE1621 [IEEE1621], DMTF [DMTF], and PWG [PWG].

6.5.1 IEEE1621 Power State <= /a>Set

IEEE1621 [IEEE1621] def= ines three basic power states : on, off, and sleep.

6.5.2 DMTF Power State Set

DMTF [DMTF] builds on A= CPI states defines 6 core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or =96S2), = Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and Hibernate (ACPI-S4).= =A0 It also defines transitional states and state change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset, Diagnost= ic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus reset Graceful, = Power-Cycle Off-Soft Graceful, and PowerCycle-Hard Graceful.=A0 The DMTF s= tandard is targeted to hosts and computers.=A0

6.5.3 PWG Power State Set

The Printer Working Gro= up [PWG] also builds on ACPI states defines 6 stable power states, a series of DMTF =93sp= ecial=94 power states, a few out-of-band power states, and provision for vendor extensions to power states.=A0 The DMTF standard is targeted to printers and other imaging devices.

=A0

6.6 Curtailment Levels

EMAN defines curtailmen= t levels to provide a standard approach to model the different levels of power of a device. =A0The curtailment levels incorporate non-operational states as defined in [ACPI] and [DMTF] standard= s, and specify several intermediate operational states.

There are twelve curtai= lment levels: six operational and six non-operational.=A0 The lowest= non-operational level is 1 and the highest is 6.=A0 Each non-operational level corresponds to an ACPI global and system state.=A0 Each operational state represents a performance state, and may be ma= pped to an ACPI processor state.

For each level, the lev= el preceding it is expected to have a lower Power value.=A0 For l= evels where the device is non-operational, it is expected that it has a longer delay in returning to = an operational state.

Characteristics of curt= ailment levels are as follows.=A0 For the first six, no energy object features are available, except for 4, 5, and 6, which= may include out-of-band management and device wakeup.

mechoff(1): No energy i= s consumed.=A0 The power connector can be removed. =A0Corresponds to ACPI state G3.

softoff(2): Some compon= ents remain powered.=A0 No context is saved.=A0 Poweri= ng up typically requires a system boot. =A0Corresponds to ACPI state G2/S5.=A0=A0=A0=A0=A0=A0=A0= =A0

hibernate(3): The devic= e may be woken without requiring a system boot.=A0 The time for availability is longer than sleep(4). =A0Corresponds = to ACPI state G1/S4.

sleep(4): The time for availability is longer than standby(5). =A0Corresponds to ACPI state G1/S3.

standby(5): The time fo= r availability is longer than ready(6). =A0Corresponds to ACPI state G1/S2.

ready(6): =A0The device can be quickly transitioned into an operational state.=A0 Corresponds to ACPI state G1/S1.

For all of the followin= g levels, some features may not be available and power consumption is less than highe= r numbered levels.=A0 All correspond to ACPI S0.=A0 The highest power consumption occurs in high(12).=A0 These levels are:=A0 lowMinus(7),= low(8), mediumMinus(9), medium(10), highMinus(11), and high(12).

=A0



--
Bruce NordmanLawrence Berkeley National Laboratory<= /span>
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943


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


--bcaec55243b0817caf04cbbb8d0a-- From moulchan@cisco.com Thu Oct 11 05:04:09 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D2421F8618 for ; Thu, 11 Oct 2012 05:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U82vbYygh9WT for ; Thu, 11 Oct 2012 05:04:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8D85C21F8578 for ; Thu, 11 Oct 2012 05:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4897; q=dns/txt; s=iport; t=1349957044; x=1351166644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=n0fAvKZ7+H9qN00QPhB8jISdQbeq6YyAWqGob65OMkU=; b=PE2zYlzUr0jaUmCeqNFKKZ0w83s+hf8t28hj7CL46eTO54edPoDgh6et AZa5VrvqI+Q3J7Wec2AMYzOhJECduS5FpP0i4oJjM5G7B7Glclj0c1VzV YXefosJpY3Q2ByfxVBDOipM9ZwB1DqsJ5Qch8vjRuFsZbhN1aEwxyFz33 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEa1dlCtJXG8/2dsb2JhbABEv0WBCIIgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIGodiC5kQoBuLRxuFJWADlwKNMIFrgm2CFw X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="130526002" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 11 Oct 2012 12:04:04 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9BC43Re032625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 12:04:03 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 07:04:03 -0500 From: "Mouli Chandramouli (moulchan)" To: "hiroto.ogaki@alaxala.com" , "eman@ietf.org" Thread-Topic: Re:Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt Thread-Index: AQHNX0MUsD8/DD8mNE6B4Tg4arITD5cjx/sQgChed46AaGotAA== Date: Thu, 11 Oct 2012 12:04:02 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237D79F3@xmb-rcd-x08.cisco.com> References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000 x-tm-as-result: No--51.375500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:04:09 -0000 Hello Hiroto,=20 Regarding your question - eoEnergyDiscontinuityTime - is defined so that it= can be useful to help in understanding if any of the energy meters in the = device had a discontinuity during the last window. =20 Case 1 - if NMS had rebooted is not an issue; the historical data would hav= e been stored in the disk Case 2- if the table is destroyed; the meters would start afresh=20 Case 3 - when the meters wrap around is time of discontinuity of the energy= meter reading=20 This is object is quite similar to ifCounterDiscontinuityTime .=20 Thanks Mouli -----Original Message----- From: hiroto.ogaki@alaxala.com [mailto:hiroto.ogaki@alaxala.com]=20 Sent: Monday, August 06, 2012 6:56 AM To: Mouli Chandramouli (moulchan); eman@ietf.org Cc: hideo.kodaka@alaxala.com; hiroto.ogaki@alaxala.com; Minoru.Teraoka@jp.y= okogawa.com; John Parello (jparello) Subject: Re:Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03= .txt Hi, Mouli Thank you for updating your draft. Now, we have a problem implementing EMAN monitoring MIB.=20 In your draft, eoEnergyDiscontinuityTime is defined as the value of SysUpTi= me on the most recent occasion at which one or more of this entity's energy consumption counters suffered= a discontinuity.=20 But, we are confused which following case is applied to eoEnergyDiscontinui= tyTime. 1. sysUpTime at which one of the energy consumption counters is deleted=20 because network management portion of the system is re-initialized. 2. sysUpTime at which eoEnergyTable is deleted by setting up the eoEnergyPa= rametersStatus to=20 destroy(1) or notInService(2). 3. sysUpTime at which one of the energy consumption counters is wrapped aro= und. 4. other Please let us know and add to the document. eoEnergyDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION =20 "The value of sysUpTime [RFC3418] on the most recent occasion at which any one or more of this entity's energy counters in this table suffered a discontinuity: eoEnergyConsumed, eoEnergyProduced or eoEnergyNet. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::=3D { eoEnergyEntry 9 } Best regards, Hiroto -- Hiroto Ogaki Alaxala Networks Corp. >Hello all,=20 > >An updated draft of the Power and Energy Monitoring MIB has been submitted= .=20 > >The modifications in this version are:=20 > > - the use of eoMeterCapabilities object which can be useful to quickly i= nfer the capabilities of an "energy object". =20 > - closing the open issues that were discussed at IETF EMAN WG=20 > - terminology definitions deferred to EMAN-FRAMEWORK=20 > >Please let us know if you have questions.=20 > >Thanks >Brad, Juergen, Thomas, Benoit and Mouli > > >-----Original Message----- >From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org >Sent: Wednesday, July 11, 2012 2:27 PM >To: i-d-announce@ietf.org >Cc: eman@ietf.org >Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Energy Management Working Group of the I= ETF. > > Title : Power and Energy Monitoring MIB > Author(s) : Mouli Chandramouli > Brad Schoening > Juergen Quittek > Thomas Dietz > Benoit Claise > Filename : draft-ietf-eman-energy-monitoring-mib-03.txt > Pages : 81 > Date : 2012-07-11 > >Abstract: > This document defines a subset of the Management Information > Base (MIB) for power and energy monitoring of devices. > > =20 > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-monitoring-mib= -03 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >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 moulchan@cisco.com Fri Oct 12 01:42:38 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB7821F8510 for ; Fri, 12 Oct 2012 01:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODVqrpcS5WDi for ; Fri, 12 Oct 2012 01:42:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 608D421F8417 for ; Fri, 12 Oct 2012 01:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6439; q=dns/txt; s=iport; t=1350031357; x=1351240957; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=X8vPdVUmlJhfxmz2Sp/flPLesaHxz2tsx0yIrx5TAHA=; b=KqHOci9wlj+RdS9jZ3DUwu312jE6ytc2DmklTEqWJHvTLr1OaYl+gaKx Ij/HzXiirklITYuA+vQUyDRE3NQLrupu6dovyoBcZKTiUvNMOLJgMWGnE KeZR279JbgpOEXmW6/nuzQA83qhtRhQjYrzItEogoXFBZVs9HNuzrgMup w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFnXd1CtJXHB/2dsb2JhbABEv1yBCIIgAQEBBAEBAQ8BJzEDFwQCAQgRBAEBCxQJBycLFAkIAgQBEggah2ILmWKgFotQGgGFQmADkjyERo0wgWuCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="130920733" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 12 Oct 2012 08:42:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9C8ga6F006507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 08:42:36 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 03:42:36 -0500 From: "Mouli Chandramouli (moulchan)" To: "Minoru.Teraoka@jp.yokogawa.com" , "eman@ietf.org" Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt Thread-Index: AQHNX0MUsD8/DD8mNE6B4Tg4arITD5cjx/sQgCNv8lGAbqwo4A== Date: Fri, 12 Oct 2012 08:42:35 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237DA2B6@xmb-rcd-x08.cisco.com> References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com>, <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA2DC1FD5@EXMAIL01.jp.ykgw.net> In-Reply-To: <92A5C8A0221B31479EB7913C528ACC59017DA2DC1FD5@EXMAIL01.jp.ykgw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--45.816600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 08:42:38 -0000 Hello Minoru, I presume you can use getnext in the table eoEnergyTable to obtain the valu= es of interest - eoEnergyConsumed, eoEnergyProduced , ...=20 Suppose you did getnext of the table eoEnergyEntry Table =20 - getnext (....5.1.1) - you would get the OID and the value of eoEnergyCons= umed.=20 The OID would have eoEnergyParametersIndex and eoEnergyCollectionStartTim= e and eoEnergyCollectionStartTime is not accessible.=20 =20 Thanks Mouli -----Original Message----- From: Minoru.Teraoka@jp.yokogawa.com [mailto:Minoru.Teraoka@jp.yokogawa.com= ]=20 Sent: Friday, August 03, 2012 3:45 AM To: Mouli Chandramouli (moulchan); eman@ietf.org Subject: RE: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.tx= t Hi Mouli, We are trying to implement EMAN monitoring MIB and are having difficulty. In eoEnergyTable, there are two indices, eoEnergyParametersIndex and eoEnergyCollectionStartTime. The indices are needed to show which parameters and when it started and ended. At present, syntax of eoEnergyCollectionStartTime is TimeTicks. In this case, in order for NMS to acquire information, it is necessary to guess the value of the index. Although I am not an expert in MIB, I think that certain regularity is required for the index. eoEnergyTable OBJECT-TYPE SYNTAX SEQUENCE OF EoEnergyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Energy Object energy measurements. Entries in this table are only created if the corresponding value of object eoPowerMeasurementCaliber is active(2), i.e., if the power is actually metered." ::=3D { energyObjectMibObjects 5 } eoEnergyEntry OBJECT-TYPE SYNTAX EoEnergyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing energy measurements." INDEX { eoEnergyParametersIndex, eoEnergyCollectionStartTime } ::=3D { eoEnergyTable 1 } EoEnergyEntry ::=3D SEQUENCE { eoEnergyCollectionStartTime TimeTicks, eoEnergyConsumed Integer32, eoEnergyProduced Integer32, eoEnergyNet Integer32, eoEnergyUnitMultiplier UnitMultiplier, eoEnergyAccuracy Integer32, eoEnergyMaxConsumed Integer32, eoEnergyMaxProduced Integer32, eoEnergyDiscontinuityTime TimeStamp } eoEnergyCollectionStartTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of seconds" MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized, as specified in the sysUpTime [RFC3418]. This object is useful for reference of interval periods for which the energy is measured." ::=3D { eoEnergyEntry 1 } Best regards, Minoru -- Minoru Teraoka Yokogawa Electric Corporation ________________________________________ From: eman-bounces@ietf.org [eman-bounces@ietf.org] On Behalf Of Mouli Chan= dramouli (moulchan) [moulchan@cisco.com] Sent: Wednesday, July 11, 2012 6:04 PM To: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.tx= t Hello all, An updated draft of the Power and Energy Monitoring MIB has been submitted. The modifications in this version are: - the use of eoMeterCapabilities object which can be useful to quickly in= fer the capabilities of an "energy object". - closing the open issues that were discussed at IETF EMAN WG - terminology definitions deferred to EMAN-FRAMEWORK Please let us know if you have questions. Thanks Brad, Juergen, Thomas, Benoit and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Wednesday, July 11, 2012 2:27 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Power and Energy Monitoring MIB Author(s) : Mouli Chandramouli Brad Schoening Juergen Quittek Thomas Dietz Benoit Claise Filename : draft-ietf-eman-energy-monitoring-mib-03.txt Pages : 81 Date : 2012-07-11 Abstract: This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-monitoring-mib-= 03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 ----- CONFIDENTIAL: This e-mail may contain information that is confidential or o= therwise protected from disclosure and intended only for the party to whom = it is addressed. If you are not the intended recipient, please notify the s= ender by return and delete this e-mail. You are hereby formally advised tha= t any unauthorized use, disclosure or copying of this email is strictly pro= hibited and may be unlawful. From bclaise@cisco.com Fri Oct 12 07:26:32 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E20621F8616 for ; Fri, 12 Oct 2012 07:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.869 X-Spam-Level: X-Spam-Status: No, score=-8.869 tagged_above=-999 required=5 tests=[AWL=1.730, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8wpvXdIDVGI for ; Fri, 12 Oct 2012 07:26:31 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3E121F8624 for ; Fri, 12 Oct 2012 07:26: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 q9CEQHIN011787; Fri, 12 Oct 2012 16:26:17 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9CEQEKe022450; Fri, 12 Oct 2012 16:26:15 +0200 (CEST) Message-ID: <50782885.4050300@cisco.com> Date: Fri, 12 Oct 2012 16:26:13 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Nevil Brownlee References: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> <20121010122412.GA59580@elstar.local> <20121010124022.GA59852@elstar.local> <5075D51E.9090309@auckland.ac.nz> In-Reply-To: <5075D51E.9090309@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "eman >> \"eman@ietf.org\"" Subject: Re: [eman] WG Last CAll for draft-ietf-eman-rfc4133bis-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:26:32 -0000 Dear all, You can review the diff directly from RFC4133 by using this URL: http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc4133.txt&url2=http://tools.ietf.org/id/draft-ietf-eman-rfc4133bis-03.txt Really a detail, but I'm not sure what "additional" mean in entPhysicalUUID. I would remove it. entPhysicalUUID OBJECT-TYPE SYNTAX UUIDorZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains a Universal Unique Identifier, the syntax of this object must conform to RFC 4122, section 4.1. A zero length octet string is returned if no UUID information is known." Note: I know where it comes from entPhysicalUris, where I believe it's appropriate. Regards, Benoit (as a contributor) > > This begins the WG Last Call for the Entity MIB (Version 4) draft. > It will end on Monday, 29 October (a week before IETF 85). > > Please read it, and send your comments to the eman list. > If you think it's OK, let us know that too! > > Cheers, Nevoil > > > On 11/10/12 1:40 AM, Juergen Schoenwaelder wrote: >> On Wed, Oct 10, 2012 at 02:33:37PM +0200, Romascanu, Dan (Dan) wrote: >>> Hi Juergen, >>> >>> Thank you for your comments. Can we consider these comments (and other >>> that may follow) as Working Group Last Call comments? >>> >>> This would allow the chairs to start a WGLC and get comments also from >>> other WG participants for the Atlanta meeting. >>> >> >> Sure. Whatever works best to get things into a consistent shape. >> >> /js > From Quittek@neclab.eu Sun Oct 14 23:16:28 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1B321F859E for ; Sun, 14 Oct 2012 23:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.779 X-Spam-Level: X-Spam-Status: No, score=-101.779 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9LKRKhpY1Wu for ; Sun, 14 Oct 2012 23:16:27 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BB48C21F85C3 for ; Sun, 14 Oct 2012 23:16:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 93442102186; Mon, 15 Oct 2012 08:16:25 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbP+Au63qoLm; Mon, 15 Oct 2012 08:16:25 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 676FF1020D9; Mon, 15 Oct 2012 08:16:15 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 15 Oct 2012 08:16:04 +0200 From: Juergen Quittek To: Bruce Nordman , eman mailing list Thread-Topic: [eman] States and Levels Thread-Index: AQHNqpyOQE9VIieW70a3cEAnv3/qZA== Date: Mon, 15 Oct 2012 06:16:04 +0000 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: multipart/alternative; boundary="_000_CCA15F9A616A0quittekneclabeu_" MIME-Version: 1.0 Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 06:16:28 -0000 --_000_CCA15F9A616A0quittekneclabeu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruce and all, Thanks for the proposal. I still have two problems with it. One is clarity of the term "curtailment levels" and the other one is a conflict with ASHRAE standards. What I miss is a clearer differentiation between power level and curtailment level. Since this document is the place where the EMAN document set explains what these are, I would rather like to see more elaboration, particularly on the semantics of curtailment levels. Beyond this, I see a conflict with the ASHRAE 201 specification. Our separation of 'power state' and 'curtailment level' appears to be conflicting with their very clear ASHRAE specification: What we call "power state" seems to be an ASHRAE "curtailment level". ASHRAE 201 gives examples curtailment levels for lights : 'on', 'dimmed', 'off' and for a fan: 'high', medium', 'low' and 'off'. For ASHRAE, there are no fixed sets of curtailment levels. They rather state that curtailment levels shall be defined and named consistent with the operation of an entity. If we separate curtailment from power state, we may not be in line anymore with ASHRAE. However, instead of using curtailment levels, ASHRAE also allows explicit setting of curtailment by specifying absolute or relative (percentage) power values. Thanks, Juergen On 10.10.12 09:32, "Bruce Nordman" > wrote: We have spent much time trying to clarify and disentangle states and levels for devices. It seems clear that some applications and several external standards require grid curtailment levels. Several long-standing industry standards define device internal power states. I took the relevant sections of the framework draft, beginning with 6.5, and boiled down the text there to what I think covers what we need. That is shown below. The existing language was retained as much as possible. I did remove redundant text as well as details outside the scope of the framework and some details from the external standards. The intent was to not change the meaning of these sections, just the presentation, except to clarify the difference between power states and curtailment levels. 6.5. Power States An Energy Object can be controlled by setting it to a specific Power State = or a specific Curtailment Level (these described in the following section).= A Power States Set is an interface by which an Energy Object can be contr= olled. Each Energy Object should indicate the Power State Sets that it imp= lements. Well known Power State Sets should be registered with IANA When a device is set to a particular Power State, it may be busy. The devi= ce will set the desired Power State and then update the actual Power State = when it changes. There are thus two Power State variables: actual and desi= red. There are many existing standards for and implementations of Power State Se= ts. An Energy Object can support multiple Power State Sets concurrently. This framework identifies three initial Power State Sets: IEEE1621 [IEEE162= 1], DMTF [DMTF], and PWG [PWG]. 6.5.1 IEEE1621 Power State Set IEEE1621 [IEEE1621] defines three basic power states : on, off, and sleep. 6.5.2 DMTF Power State Set DMTF [DMTF] builds on ACPI states defines 6 core power states: On (ACPI-S0)= , Sleep-Light (ACPI-S1 or =96S2), Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5),= Off-Soft (ACPI-S5), and Hibernate (ACPI-S4). It also defines transitional= states and state change commands: PowerCycle Off-Soft, PowerCycle, MasterB= us reset, Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, Maste= rBus reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard Gra= ceful. The DMTF standard is targeted to hosts and computers. 6.5.3 PWG Power State Set The Printer Working Group [PWG] also builds on ACPI states defines 6 stable= power states, a series of DMTF =93special=94 power states, a few out-of-ba= nd power states, and provision for vendor extensions to power states. The = DMTF standard is targeted to printers and other imaging devices. 6.6 Curtailment Levels EMAN defines curtailment levels to provide a standard approach to model the= different levels of power of a device. The curtailment levels incorporate= non-operational states as defined in [ACPI] and [DMTF] standards, and spec= ify several intermediate operational states. There are twelve curtailment levels: six operational and six non-operationa= l. The lowest non-operational level is 1 and the highest is 6. Each non-o= perational level corresponds to an ACPI global and system state. Each oper= ational state represents a performance state, and may be mapped to an ACPI = processor state. For each level, the level preceding it is expected to have a lower Power va= lue. For levels where the device is non-operational, it is expected that i= t has a longer delay in returning to an operational state. Characteristics of curtailment levels are as follows. For the first six, n= o energy object features are available, except for 4, 5, and 6, which may i= nclude out-of-band management and device wakeup. mechoff(1): No energy is consumed. The power connector can be removed. Co= rresponds to ACPI state G3. softoff(2): Some components remain powered. No context is saved. Powering= up typically requires a system boot. Corresponds to ACPI state G2/S5. hibernate(3): The device may be woken without requiring a system boot. The= time for availability is longer than sleep(4). Corresponds to ACPI state = G1/S4. sleep(4): The time for availability is longer than standby(5). Corresponds= to ACPI state G1/S3. standby(5): The time for availability is longer than ready(6). Corresponds= to ACPI state G1/S2. ready(6): The device can be quickly transitioned into an operational state= . Corresponds to ACPI state G1/S1. For all of the following levels, some features may not be available and pow= er consumption is less than higher numbered levels. All correspond to ACPI= S0. The highest power consumption occurs in high(12). These levels are: = lowMinus(7), low(8), mediumMinus(9), medium(10), highMinus(11), and high(1= 2). -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_CCA15F9A616A0quittekneclabeu_ Content-Type: text/html; charset="Windows-1252" Content-ID: <57CB8EEC64EE7F428D030BC8A1AFEE13@office.hd> Content-Transfer-Encoding: quoted-printable
Hi Bruce and all,

Thanks for the proposal. I still have two problems with it.
One is clarity of the term "curtailment levels" and the
other one is a conflict with ASHRAE standards.

What I miss is a clearer differentiation between power level = ;
and curtailment level. Since this document is the place where the=  
EMAN document set explains what these are, I would rather like to=  
see more elaboration, particularly on the semantics of curtailmen= t 
levels. 

Beyond this, I see a conflict with the ASHRAE 201 specification.
Our separation of 'power state' and 'curtailment level' appears
to be conflicting with their very clear ASHRAE specification:

What we call "power state" seems to be an ASHRAE "= curtailment level". 
ASHRAE 201 gives examples curtailment levels
for lights : 'on', 'dimmed', 'off' 
and for a fan: 'high', medium', 'low' and 'off'.
For ASHRAE, there are no fixed sets of curtailment levels. They rather=  
state that curtailment levels shall be defined and named consistent&nb= sp;
with the operation of an entity. If we separate curtailment from&= nbsp;
power state, we may not be in line anymore with ASHRAE.

However,  instead of using curtailment levels, ASHRAE also a= llows 
explicit setting of curtailment by specifying absolute or relativ= e 
(percentage) power values.

Thanks,
    Juergen


On 10.10.12 09:32, "Bruce Nordman" <bnordman@lbl.gov> wrote:

We have spent much time trying to clarify and disentangle states
and levels for devices.  It seems clear that some applications and
several external standards require grid curtailment levels.
Several long-standing industry standards define device internal
power states.

I took the relevant sections of the framework draft, beginning with 6.5, and boiled down the text there to what I think covers what we need.
That is shown below.  The existing language was retained as much
as possible.  I did remove redundant text as well as details outside t= he
scope of the framework and some details from the external standards.

The intent was to not change the meaning of these sections, just the
presentation, except to clarify the difference between  power states <= br> and curtailment levels.


= 6.5. Power States

An Energy Object can be controlled by setting it to a specific Power State or= a specific Curtailment Level (these described in the following section).  A Power States Set is an interface by which a= n Energy Object can be controlled.  Each Energy Object should indicate the Power State Sets that it impl= ements.  Well known Power State Sets should be registered with IANA

When a device is set to= a particular Power State, it may be busy.  The device will set the desired Power State and then update the actu= al Power State when it changes.  There are thus two Power State variables: actual and desired.

There are many existing= standards for and implementations of Power State Sets.&nb= sp; An Energy Object can support multiple Power State Sets concurrently.=

This framework identifi= es three initial Power State Sets: IEEE1621 [IEEE1621], DMTF [DMTF], and PW= G [PWG].

6.5.1 IEEE1621 Power State Set

IEEE1621 [IEEE1621] def= ines three basic power states : on, off, and sleep.

6.5.2 DMTF Power= State Set

DMTF [DMTF] builds on A= CPI states defines 6 core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 = or =96S2), Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), an= d Hibernate (ACPI-S4).  It also defines transitional states and state change commands: Power= Cycle Off-Soft, PowerCycle, MasterBus reset, Diagnostic Interrupt, Off-Soft= -Graceful, Off-Hard Graceful, MasterBus reset Graceful, Power-Cycle Off-Sof= t Graceful, and PowerCycle-Hard Graceful.  The DMTF standard is targeted to h= osts and computers. 

6.5.3 PWG Power State Set

The Printer Working Gro= up [PWG] also builds on ACPI states defines 6 stable power states, a series= of DMTF =93special=94 power states, a few out-of-band power states, and pr= ovision for vendor extensions to power states.  The DMTF standard is targeted to printers and other imaging devices.=

 

6.6 Curtailment Levels

EMAN defines curtailmen= t levels to provide a standard approach to model the different levels of po= wer of a device.  The curtailment levels incorporate non-operat= ional states as defined in [ACPI] and [DMTF] standards, and specify several= intermediate operational states.

There are twelve curtai= lment levels: six operational and six non-operational.&nbs= p; The lowest non-operational level is 1 and the highest is 6.  Each non-operational level corresponds to an ACPI global and system = state.  Each operational state represents a performance state, and may be ma= pped to an ACPI processor state.

For each level, the lev= el preceding it is expected to have a lower Power value.&n= bsp; For levels where the device is non-operational, it is expected that = it has a longer delay in returning to an operational state.

Characteristics of curt= ailment levels are as follows.  For the first six, no energy object features are available, except f= or 4, 5, and 6, which may include out-of-band management and device wakeup.=

mechoff(1): No energy i= s consumed.  The power connector can be removed.  Co= rresponds to ACPI state G3.

softoff(2): Some compon= ents remain powered.  No context is saved.  Powering up typic= ally requires a system boot.  Corresponds to ACPI state G2/S5.        

hibernate(3): The devic= e may be woken without requiring a system boot.  The time for availability is longer than sleep(4). =  Corresponds to ACPI state G1/S4.

sleep(4): The time for = availability is longer than standby(5).  Corresponds to ACPI state G1/S3.

standby(5): The time fo= r availability is longer than ready(6).  Corresponds to ACPI state G1/S2.

ready(6):  The device can be quickly transitioned into an operation= al state.  Corresponds to ACPI state G1/S1.

For all of the followin= g levels, some features may not be available and power consumption is less = than higher numbered levels.  All correspond to ACPI S0.  The highest= power consumption occurs in high(12).  These levels are:  lowMinus(7), low(8),= mediumMinus(9), medium(10), highMinus(11), and high(12).

 



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

_______________________________________________ eman mailing list eman@ietf.org ht= tps://www.ietf.org/mailman/listinfo/eman --_000_CCA15F9A616A0quittekneclabeu_-- From Quittek@neclab.eu Sun Oct 14 23:39:48 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A978521F851E for ; Sun, 14 Oct 2012 23:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYckrtVkqiI7 for ; Sun, 14 Oct 2012 23:39:47 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8A55E21F84B8 for ; Sun, 14 Oct 2012 23:39:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id EF16610218D; Mon, 15 Oct 2012 08:39:45 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9uP-bshbgx0; Mon, 15 Oct 2012 08:39:45 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id D02A110218C; Mon, 15 Oct 2012 08:39:35 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 15 Oct 2012 08:39:25 +0200 From: Juergen Quittek To: "John Parello (jparello)" , eman mailing list Thread-Topic: [eman] Allowing curtailment in draft-ietf-eman-requirements-09 Thread-Index: AQHNqp/QnnGM8JBPf0aFTVZGpay3Xg== Date: Mon, 15 Oct 2012 06:39:24 +0000 Message-ID: In-Reply-To: <9C213D38848B89428F46808B16F6F0860C22D8@xmb-aln-x04.cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <54F9F105A404C54BAFBCE408B2743D72@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] Allowing curtailment in draft-ietf-eman-requirements-09 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 06:39:48 -0000 Hi John, Please see replies inline. On 09.10.12 19:39, "John Parello (jparello)" wrote: >Hi Authors, > >Should Section 3.1 Power states be modified to include curtailment >levels? So something like: > >"However, more finely grained Power States or Curtailment Levels can be >implemented." > >This would however have implications on section 5.4.* > >With ASHRAE 201p I'm concerned a device that implements that model would >not be in line with the requirements. I agree, ASHRAE "curtailment levels" include EMAN "power states". >So just say a device complies with 201p: > >- Implements a power state with values (on,off,pause) with no information >about power etc at those states. >- implements 5 curtailment levels with power information such as > 1) Off, 0% of Max > 2) sleep , 10% of Max > 3) low, 50% of Max > 4) med, 80% of Max > 5) high, 100% of Max Yes, these devices would comply with ASHRAE. But these are just examples. Also devices defining 5 curtailment levels without specifying any percentage values would comply. And of course, a device using on,pause,off with absolute or percentage power values would comply as well. >Would the device fulfill the requirements. The requirements says the >states must report the values but in 201p the curtailments do. This is not what the requirements state. The requirements just state that there must be means provided by the standard to report power per state. If power per state is unknown, an entity can report this. >Perhaps the requirements should be either (1) made more general as to >allow the above or (2) include the notion of curtailments. They do already.=20 Thanks, Juergen >I prefer (1) since requirements don't dictate implementation. > >Jp > > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From brads@coraid.com Tue Oct 16 18:13:43 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E821E11E80BF for ; Tue, 16 Oct 2012 18:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9N-nE3NQYxx for ; Tue, 16 Oct 2012 18:13:42 -0700 (PDT) Received: from server505.appriver.com (server505e.appriver.com [98.129.35.9]) by ietfa.amsl.com (Postfix) with ESMTP id 921DD21F860F for ; Tue, 16 Oct 2012 18:13:40 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/16/2012 8:13:39 PM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @coraid.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G321 G322 G323 G324 G328 G329 G340 G436 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 327612688; Tue, 16 Oct 2012 20:13:39 -0500 Received: from MBX22.exg5.exghost.com ([169.254.2.182]) by HT05.exg5.exghost.com ([98.129.23.150]) with mapi; Tue, 16 Oct 2012 20:13:39 -0500 From: Brad Schoening To: Juergen Quittek , Bruce Nordman , eman mailing list Date: Tue, 16 Oct 2012 20:13:35 -0500 Thread-Topic: [eman] States and Levels Thread-Index: Ac2sBKNtFSUXnb/KRLGMZKJ6JP4QNQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CCA34D3E65EC0bradscoraidcom_" MIME-Version: 1.0 Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 01:13:44 -0000 --_000_CCA34D3E65EC0bradscoraidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Juergen, You mention below using absolute or relative (percentage) power levels. Th= ere are no doubt valuable use cases for devices with a linear relationship = between power consumed and effective work, such as perhaps motors or an air= conditioner. However, percentages are less useful for 'bursty' workloads found in the da= ta center such as printers or dedicated servers. What would be the utilit= y of setting a absolute power limit on a printer that rendered it incapable= of printing? Likewise, in the past we've related our discussions with Int= el regarding their "race to finish" philosophy =96 it's more efficient for = a CPU to run at high speed to finish calculations and then enter a pause st= ate, rather than run at a steady but reduced frequency. Finally, idle states are something we haven't discussed much, but they're d= iscussed In Nedevschi, et al. "Skilled in the Art of Being Idle: Reducing Energy Waste in Networked Systems". This paper presents four bas= ic power states: off, sleep, idle, full-on. When looking at ASHRAE, ACPI, DMTF, or IEC 621 what we see is a variety of = models, incorporating some notion of graduated levels. I believe our utili= zation of an IANA registry will support all of these. Regards, Brad Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Juergen Quittek > Date: Mon, 15 Oct 2012 01:16:04 -0500 To: Bruce Nordman >, eman mailing= list > Subject: Re: [eman] States and Levels Hi Bruce and all, Thanks for the proposal. I still have two problems with it. One is clarity of the term "curtailment levels" and the other one is a conflict with ASHRAE standards. What I miss is a clearer differentiation between power level and curtailment level. Since this document is the place where the EMAN document set explains what these are, I would rather like to see more elaboration, particularly on the semantics of curtailment levels. Beyond this, I see a conflict with the ASHRAE 201 specification. Our separation of 'power state' and 'curtailment level' appears to be conflicting with their very clear ASHRAE specification: What we call "power state" seems to be an ASHRAE "curtailment level". ASHRAE 201 gives examples curtailment levels for lights : 'on', 'dimmed', 'off' and for a fan: 'high', medium', 'low' and 'off'. For ASHRAE, there are no fixed sets of curtailment levels. They rather state that curtailment levels shall be defined and named consistent with the operation of an entity. If we separate curtailment from power state, we may not be in line anymore with ASHRAE. However, instead of using curtailment levels, ASHRAE also allows explicit setting of curtailment by specifying absolute or relative (percentage) power values. Thanks, Juergen On 10.10.12 09:32, "Bruce Nordman" > wrote: We have spent much time trying to clarify and disentangle states and levels for devices. It seems clear that some applications and several external standards require grid curtailment levels. Several long-standing industry standards define device internal power states. I took the relevant sections of the framework draft, beginning with 6.5, and boiled down the text there to what I think covers what we need. That is shown below. The existing language was retained as much as possible. I did remove redundant text as well as details outside the scope of the framework and some details from the external standards. The intent was to not change the meaning of these sections, just the presentation, except to clarify the difference between power states and curtailment levels. 6.5. Power States An Energy Object can be controlled by setting it to a specific Power State = or a specific Curtailment Level (these described in the following section).= A Power States Set is an interface by which an Energy Object can be contr= olled. Each Energy Object should indicate the Power State Sets that it imp= lements. Well known Power State Sets should be registered with IANA When a device is set to a particular Power State, it may be busy. The devi= ce will set the desired Power State and then update the actual Power State = when it changes. There are thus two Power State variables: actual and desi= red. There are many existing standards for and implementations of Power State Se= ts. An Energy Object can support multiple Power State Sets concurrently. This framework identifies three initial Power State Sets: IEEE1621 [IEEE162= 1], DMTF [DMTF], and PWG [PWG]. 6.5.1 IEEE1621 Power State Set IEEE1621 [IEEE1621] defines three basic power states : on, off, and sleep. 6.5.2 DMTF Power State Set DMTF [DMTF] builds on ACPI states defines 6 core power states: On (ACPI-S0)= , Sleep-Light (ACPI-S1 or =96S2), Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5),= Off-Soft (ACPI-S5), and Hibernate (ACPI-S4). It also defines transitional= states and state change commands: PowerCycle Off-Soft, PowerCycle, MasterB= us reset, Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, Maste= rBus reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard Gra= ceful. The DMTF standard is targeted to hosts and computers. 6.5.3 PWG Power State Set The Printer Working Group [PWG] also builds on ACPI states defines 6 stable= power states, a series of DMTF =93special=94 power states, a few out-of-ba= nd power states, and provision for vendor extensions to power states. The = DMTF standard is targeted to printers and other imaging devices. 6.6 Curtailment Levels EMAN defines curtailment levels to provide a standard approach to model the= different levels of power of a device. The curtailment levels incorporate= non-operational states as defined in [ACPI] and [DMTF] standards, and spec= ify several intermediate operational states. There are twelve curtailment levels: six operational and six non-operationa= l. The lowest non-operational level is 1 and the highest is 6. Each non-o= perational level corresponds to an ACPI global and system state. Each oper= ational state represents a performance state, and may be mapped to an ACPI = processor state. For each level, the level preceding it is expected to have a lower Power va= lue. For levels where the device is non-operational, it is expected that i= t has a longer delay in returning to an operational state. Characteristics of curtailment levels are as follows. For the first six, n= o energy object features are available, except for 4, 5, and 6, which may i= nclude out-of-band management and device wakeup. mechoff(1): No energy is consumed. The power connector can be removed. Co= rresponds to ACPI state G3. softoff(2): Some components remain powered. No context is saved. Powering= up typically requires a system boot. Corresponds to ACPI state G2/S5. hibernate(3): The device may be woken without requiring a system boot. The= time for availability is longer than sleep(4). Corresponds to ACPI state = G1/S4. sleep(4): The time for availability is longer than standby(5). Corresponds= to ACPI state G1/S3. standby(5): The time for availability is longer than ready(6). Corresponds= to ACPI state G1/S2. ready(6): The device can be quickly transitioned into an operational state= . Corresponds to ACPI state G1/S1. For all of the following levels, some features may not be available and pow= er consumption is less than higher numbered levels. All correspond to ACPI= S0. The highest power consumption occurs in high(12). These levels are: = lowMinus(7), low(8), mediumMinus(9), medium(10), highMinus(11), and high(1= 2). -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_CCA34D3E65EC0bradscoraidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Juergen,
You mention below using absolute or relative (percentage) powe= r levels.  There are no doubt valuable use cases for devices with a li= near relationship between power consumed and effective work, such as perhap= s motors or an air conditioner.   

Howev= er, percentages are less useful for 'bursty' workloads found in the data ce= nter such as printers or dedicated servers.   What would be the utilit= y of setting a absolute power limit on a printer that rendered it incapable= of printing?  Likewise, in the past we've related our discussions wit= h Intel regarding their "race to finish" philosophy =96 it's more= efficient for a CPU to run at high speed to finish calculations and then e= nter a pause state, rather than run at a steady but reduced frequency.

Finally, idle states are something we haven't discusse= d much, but they're discussed In Nedevschi, et al. "Skilled in the Art= of Being Idle:
Reducing Energy Waste in Networked Systems".=   This paper presents four basic power states:  off, sleep, idle= , full-on.

When looking at ASHRAE, ACPI, DMTF, or = IEC 621 what we see is a variety of models, incorporating some notion of gr= aduated levels.  I believe our utilization of an IANA registry will su= pport all of these.

Regards,

<= div>Brad 

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com
<= span style=3D"font-size:9.0pt;font-family:Arial;mso-fareast-font-family: "Times New Roman";color:#00467F;mso-ansi-language:EN-US;mso-farea= st-language: EN-US;mso-bidi-language:AR-SA;mso-bidi-font-style:italic">Coraid: Redefinin= g Storage
From: Juergen Quittek <Quittek@neclab.eu>
Date: Mon, 15 Oct 2012 01:16:04 -0500
T= o: Bruce Nordman <bnordman@l= bl.gov>, eman mailing list <eman= @ietf.org>
Subject: Re: = [eman] States and Levels

Hi Bruce and all,

Thanks for the proposa= l. I still have two problems with it.
One is clarity of the term = "curtailment levels" and the
other one is a conflict wi= th ASHRAE standards.

What I miss is a clearer diff= erentiation between power level 
and curtailment level.= Since this document is the place where the 
EMAN docum= ent set explains what these are, I would rather like to 
see more elaboration, particularly on the semantics of curtailment&n= bsp;
levels. 

Beyond this, I see a = conflict with the ASHRAE 201 specification.
Our separation of 'po= wer state' and 'curtailment level' appears
to be conflicting with= their very clear ASHRAE specification:

What we ca= ll "power state" seems to be an ASHRAE "curtailment lev= el". 
ASHRAE 201 gives examples curtailment levels
for lights : 'on', 'dimmed', 'off' 
and for a fan: 'hi= gh', medium', 'low' and 'off'.
For ASHRAE, there are no fixed set= s of curtailment levels. They rather 
state that curtailment= levels shall be defined and named consistent 
with the= operation of an entity. If we separate curtailment from 
po= wer state, we may not be in line anymore with ASHRAE.

<= div>However,  instead of using curtailment levels, ASHRAE also al= lows 
explicit setting of curtailment by specifying absolute=  or relative 
(percentage) power values.

Thanks,
    Juergen


On 10.10.12 09:32, "Bruce Nordman" <bnordman@lbl.gov> wrote:

We have spent much time trying to clarify and disentangle states
and levels for devices.  It seems clear that some applications and
= several external standards require grid curtailment levels.
Several long-standing industry standards define device internal
power states.

I took the relevant sections of the framework draft, beginning with 6.5, and boiled down the text there to what I think covers what we need.
That is shown below.  The existing language was retained as much
as possible.  I did remove redundant text as well as details outside t= he
scope of the framework and some details from the external standards.
The intent was to not change the meaning of these sections, just the
presentation, except to clarify the difference between  power states <= br> and curtailment levels.


6.5. Power States

An Energy Object can be controlled by setting it to a specific Power State or= a specific Curtailment Level (these described in the following section).  A Power States Set is an interface by which a= n Energy Object can be controlled.  Each Energy Object should indicate the Power State Sets that it impl= ements.  Well known Power State Sets should be registered with IANA

When a device is set t= o a particular Power State, it may be busy.  The device will set the desired Power State and then update the actu= al Power State when it changes.  There are thus two Power State variables: actual and desired.

There are many existing st= andards for and implementations of Power State Sets.  An Energy Object can support multiple Power State Sets concurrently.=

This framework ide= ntifies three initial Power State Sets: IEEE1621 [IEEE1621], DMTF [DMTF], a= nd PWG [PWG].

6.5.1 IEEE1621 Power State Set

IEEE1621 [IEEE1621] defin= es three basic power states : on, off, and sleep.

6.5.2 DMTF P= ower State Set

DMTF [DMTF] bui= lds on ACPI states defines 6 core power states: On (ACPI-S0), Sleep-Light (= ACPI-S1 or =96S2), Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI= -S5), and Hibernate (ACPI-S4).  It also defines transitional states and state change commands: Power= Cycle Off-Soft, PowerCycle, MasterBus reset, Diagnostic Interrupt, Off-Soft= -Graceful, Off-Hard Graceful, MasterBus reset Graceful, Power-Cycle Off-Sof= t Graceful, and PowerCycle-Hard Graceful.  The DMTF standard is targeted to h= osts and computers. 

6.5.3 PWG Power State Set

<= p class=3D"MsoNormal" style=3D"margin-left:22.5pt">The Printer Working Grou= p [PWG] also builds on ACPI states defines 6 stable power states, a series = of DMTF =93special=94 power states, a few out-of-band power states, and pro= vision for vendor extensions to power states.  The DMTF standard is targeted to printers and other imaging devices.=

 

6.6 Curtailment Levels

EMAN defines curtailment levels to provide a = standard approach to model the different levels of power of a device.  The curtailment levels incorporate non-operat= ional states as defined in [ACPI] and [DMTF] standards, and specify several= intermediate operational states.

There are twelve cu= rtailment levels: six operational and six non-operational.=   The lowest non-operational level is 1 and the highest is 6.  Each non-operational level corresponds to an ACPI global and system = state.  Each operational state represents a performance state, and may be ma= pped to an ACPI processor state.

For each level, the= level preceding it is expected to have a lower Power value.  For levels where the device is non-operational, it is expected that = it has a longer delay in returning to an operational state.

Characteristics of curtailment leve= ls are as follows.  For the first six, no energy object features are available, except f= or 4, 5, and 6, which may include out-of-band management and device wakeup.=

mechoff(1): No ener= gy is consumed.  The power connector can be removed.  Co= rresponds to ACPI state G3.

softoff(2): Some co= mponents remain powered.  No context is saved.  Powering up typic= ally requires a system boot.  Corresponds to ACPI state G2/S5.        

hibernate(3): The device may be= woken without requiring a system boot.  The time for availability is longer than sleep(4). =  Corresponds to ACPI state G1/S4.

sleep(4): The time for availability is longer tha= n standby(5).  Corresponds to ACPI state G1/S3.

standby(5): The time for availa= bility is longer than ready(6).  Corresponds to ACPI state G1/S2.

ready(6): &nbs= p;The device can be quickly transitioned into an operational state.<= span style=3D"">  Corresponds to ACPI state G1/S1.

For all of the following levels, some features may not = be available and power consumption is less than higher numbered levels.  All correspond to ACPI S0.  The highest= power consumption occurs in high(12).  These levels are:  lowMinus(7), low(8),= mediumMinus(9), medium(10), highMinus(11), and high(12).

 



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

_______________________________________________ eman mailing list eman@ietf.org ht= tps://www.ietf.org/mailman/listinfo/eman
--_000_CCA34D3E65EC0bradscoraidcom_-- From dkh@juniper.net Tue Oct 16 18:32:27 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063BA21F8672 for ; Tue, 16 Oct 2012 18:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N2pyJrsLgJE for ; Tue, 16 Oct 2012 18:32:25 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0142721F8669 for ; Tue, 16 Oct 2012 18:32:24 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUH4KqAeKKA3B8tqF1LwBDoO/n7f+aocS@postini.com; Tue, 16 Oct 2012 18:32:25 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Oct 2012 18:29:57 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 16 Oct 2012 18:29:56 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 16 Oct 2012 18:36:05 -0700 Received: from mail178-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Wed, 17 Oct 2012 01:29:45 +0000 Received: from mail178-co1 (localhost [127.0.0.1]) by mail178-co1-R.bigfish.com (Postfix) with ESMTP id 8401D9C0168 for ; Wed, 17 Oct 2012 01:29:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zz98dI9371Ic85eh4015I1447Izz1202h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received: from mail178-co1 (localhost.localdomain [127.0.0.1]) by mail178-co1 (MessageSwitch) id 1350437383141897_17407; Wed, 17 Oct 2012 01:29:43 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.233]) by mail178-co1.bigfish.com (Postfix) with ESMTP id 1FFD7A800F9; Wed, 17 Oct 2012 01:29:43 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Oct 2012 01:29:42 +0000 Received: from CH1PRD0510MB356.namprd05.prod.outlook.com ([169.254.9.3]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0224.004; Wed, 17 Oct 2012 01:29:41 +0000 From: Daniel Kharitonov To: Brad Schoening , Juergen Quittek , Bruce Nordman , eman mailing list Thread-Topic: [eman] States and Levels Thread-Index: AQHNprl+AQmQFRQXx0eJ41hwwWYciZe566kAgALQJoCAAAR/aw== Date: Wed, 17 Oct 2012 01:29:41 +0000 Message-ID: <7C155ACE35869F4A953588C8A4657D7510CDD95C@CH1PRD0510MB356.namprd05.prod.outlook.com> References: , In-Reply-To: Accept-Language: ru-RU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: multipart/alternative; boundary="_000_7C155ACE35869F4A953588C8A4657D7510CDD95CCH1PRD0510MB356_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CORAID.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NECLAB.EU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LBL.GOV$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 01:32:27 -0000 --_000_7C155ACE35869F4A953588C8A4657D7510CDD95CCH1PRD0510MB356_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This would be exactly my concern. States are better expressed in functionality levels because this is what dr= ives usability. Expected power figures are estimates (at best) and have little meaning to e= nd users. ________________________________ From: eman-bounces@ietf.org on behalf of Brad Schoening Sent: Tuesday, October 16, 2012 6:13:35 PM To: Juergen Quittek; Bruce Nordman; eman mailing list Subject: Re: [eman] States and Levels Juergen, You mention below using absolute or relative (percentage) power levels. Th= ere are no doubt valuable use cases for devices with a linear relationship = between power consumed and effective work, such as perhaps motors or an air= conditioner. However, percentages are less useful for 'bursty' workloads found in the da= ta center such as printers or dedicated servers. What would be the utilit= y of setting a absolute power limit on a printer that rendered it incapable= of printing? Likewise, in the past we've related our discussions with Int= el regarding their "race to finish" philosophy =96 it's more efficient for = a CPU to run at high speed to finish calculations and then enter a pause st= ate, rather than run at a steady but reduced frequency. Finally, idle states are something we haven't discussed much, but they're d= iscussed In Nedevschi, et al. "Skilled in the Art of Being Idle: Reducing Energy Waste in Networked Systems". This paper presents four bas= ic power states: off, sleep, idle, full-on. When looking at ASHRAE, ACPI, DMTF, or IEC 621 what we see is a variety of = models, incorporating some notion of graduated levels. I believe our utili= zation of an IANA registry will support all of these. Regards, Brad Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Juergen Quittek > Date: Mon, 15 Oct 2012 01:16:04 -0500 To: Bruce Nordman >, eman mailing= list > Subject: Re: [eman] States and Levels Hi Bruce and all, Thanks for the proposal. I still have two problems with it. One is clarity of the term "curtailment levels" and the other one is a conflict with ASHRAE standards. What I miss is a clearer differentiation between power level and curtailment level. Since this document is the place where the EMAN document set explains what these are, I would rather like to see more elaboration, particularly on the semantics of curtailment levels. Beyond this, I see a conflict with the ASHRAE 201 specification. Our separation of 'power state' and 'curtailment level' appears to be conflicting with their very clear ASHRAE specification: What we call "power state" seems to be an ASHRAE "curtailment level". ASHRAE 201 gives examples curtailment levels for lights : 'on', 'dimmed', 'off' and for a fan: 'high', medium', 'low' and 'off'. For ASHRAE, there are no fixed sets of curtailment levels. They rather state that curtailment levels shall be defined and named consistent with the operation of an entity. If we separate curtailment from power state, we may not be in line anymore with ASHRAE. However, instead of using curtailment levels, ASHRAE also allows explicit setting of curtailment by specifying absolute or relative (percentage) power values. Thanks, Juergen On 10.10.12 09:32, "Bruce Nordman" > wrote: We have spent much time trying to clarify and disentangle states and levels for devices. It seems clear that some applications and several external standards require grid curtailment levels. Several long-standing industry standards define device internal power states. I took the relevant sections of the framework draft, beginning with 6.5, and boiled down the text there to what I think covers what we need. That is shown below. The existing language was retained as much as possible. I did remove redundant text as well as details outside the scope of the framework and some details from the external standards. The intent was to not change the meaning of these sections, just the presentation, except to clarify the difference between power states and curtailment levels. 6.5. Power States An Energy Object can be controlled by setting it to a specific Power State = or a specific Curtailment Level (these described in the following section).= A Power States Set is an interface by which an Energy Object can be contr= olled. Each Energy Object should indicate the Power State Sets that it imp= lements. Well known Power State Sets should be registered with IANA When a device is set to a particular Power State, it may be busy. The devi= ce will set the desired Power State and then update the actual Power State = when it changes. There are thus two Power State variables: actual and desi= red. There are many existing standards for and implementations of Power State Se= ts. An Energy Object can support multiple Power State Sets concurrently. This framework identifies three initial Power State Sets: IEEE1621 [IEEE162= 1], DMTF [DMTF], and PWG [PWG]. 6.5.1 IEEE1621 Power State Set IEEE1621 [IEEE1621] defines three basic power states : on, off, and sleep. 6.5.2 DMTF Power State Set DMTF [DMTF] builds on ACPI states defines 6 core power states: On (ACPI-S0)= , Sleep-Light (ACPI-S1 or =96S2), Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5),= Off-Soft (ACPI-S5), and Hibernate (ACPI-S4). It also defines transitional= states and state change commands: PowerCycle Off-Soft, PowerCycle, MasterB= us reset, Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, Maste= rBus reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard Gra= ceful. The DMTF standard is targeted to hosts and computers. 6.5.3 PWG Power State Set The Printer Working Group [PWG] also builds on ACPI states defines 6 stable= power states, a series of DMTF =93special=94 power states, a few out-of-ba= nd power states, and provision for vendor extensions to power states. The = DMTF standard is targeted to printers and other imaging devices. 6.6 Curtailment Levels EMAN defines curtailment levels to provide a standard approach to model the= different levels of power of a device. The curtailment levels incorporate= non-operational states as defined in [ACPI] and [DMTF] standards, and spec= ify several intermediate operational states. There are twelve curtailment levels: six operational and six non-operationa= l. The lowest non-operational level is 1 and the highest is 6. Each non-o= perational level corresponds to an ACPI global and system state. Each oper= ational state represents a performance state, and may be mapped to an ACPI = processor state. For each level, the level preceding it is expected to have a lower Power va= lue. For levels where the device is non-operational, it is expected that i= t has a longer delay in returning to an operational state. Characteristics of curtailment levels are as follows. For the first six, n= o energy object features are available, except for 4, 5, and 6, which may i= nclude out-of-band management and device wakeup. mechoff(1): No energy is consumed. The power connector can be removed. Co= rresponds to ACPI state G3. softoff(2): Some components remain powered. No context is saved. Powering= up typically requires a system boot. Corresponds to ACPI state G2/S5. hibernate(3): The device may be woken without requiring a system boot. The= time for availability is longer than sleep(4). Corresponds to ACPI state = G1/S4. sleep(4): The time for availability is longer than standby(5). Corresponds= to ACPI state G1/S3. standby(5): The time for availability is longer than ready(6). Corresponds= to ACPI state G1/S2. ready(6): The device can be quickly transitioned into an operational state= . Corresponds to ACPI state G1/S1. For all of the following levels, some features may not be available and pow= er consumption is less than higher numbered levels. All correspond to ACPI= S0. The highest power consumption occurs in high(12). These levels are: = lowMinus(7), low(8), mediumMinus(9), medium(10), highMinus(11), and high(1= 2). -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf= .org https://www.ietf.org/mailman/listinfo/eman --_000_7C155ACE35869F4A953588C8A4657D7510CDD95CCH1PRD0510MB356_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This would be exactly my concern.

States are better expressed in functionality levels because this is what dr= ives usability.

Expected power figures are estimates (at best) and have little meaning to e= nd users.
 
From: eman-bounces@ietf.org on beha= lf of Brad Schoening
Sent: Tuesday, October 16, 2012 6:13:35 PM
To: Juergen Quittek; Bruce Nordman; eman mailing list
Subject: Re: [eman] States and Levels

Juergen,

You mention below using absolute or relative (percentage) power levels= .  There are no doubt valuable use cases for devices with a linear rel= ationship between power consumed and effective work, such as perhaps motors= or an air conditioner.   

However, percentages are less useful for 'bursty' workloads found in t= he data center such as printers or dedicated servers.   What would be = the utility of setting a absolute power limit on a printer that rendered it= incapable of printing?  Likewise, in the past we've related our discussions with Intel regarding their "ra= ce to finish" philosophy =96 it's more efficient for a CPU to run at h= igh speed to finish calculations and then enter a pause state, rather than = run at a steady but reduced frequency.

Finally, idle states are something we haven't discussed much, but they= 're discussed In Nedevschi, et al. "Skilled in the Art of Being Idle:<= /div>
Reducing Energy Waste in Networked Systems".   This paper pr= esents four basic power states:  off, sleep, idle, full-on.

When looking at ASHRAE, ACPI, DMTF, or IEC 621 what we see is a variet= y of models, incorporating some notion of graduated levels.  I believe= our utilization of an IANA registry will support all of these.

Regards,

Brad 

Brad S= choening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com
C= oraid: Redefining Storage


From: Juergen Quittek <Quittek@neclab.eu>
Date: Mon, 15 Oct 2012 01:16:04 -05= 00
To: Bruce Nordman <bnordman@lbl.gov>, eman mailing list <eman@ietf.org>
Subject: Re: [eman] States and Leve= ls

Hi Bruce and all,

Thanks for the proposal. I still have two problems with it.
One is clarity of the term "curtailment levels" and the
other one is a conflict with ASHRAE standards.

What I miss is a clearer differentiation between power level = ;
and curtailment level. Since this document is the place where the=  
EMAN document set explains what these are, I would rather like to=  
see more elaboration, particularly on the semantics of curtailmen= t 
levels. 

Beyond this, I see a conflict with the ASHRAE 201 specification.
Our separation of 'power state' and 'curtailment level' appears
to be conflicting with their very clear ASHRAE specification:

What we call "power state" seems to be an ASHRAE "= curtailment level". 
ASHRAE 201 gives examples curtailment levels
for lights : 'on', 'dimmed', 'off' 
and for a fan: 'high', medium', 'low' and 'off'.
For ASHRAE, there are no fixed sets of curtailment levels. They rather=  
state that curtailment levels shall be defined and named consistent&nb= sp;
with the operation of an entity. If we separate curtailment from&= nbsp;
power state, we may not be in line anymore with ASHRAE.

However,  instead of using curtailment levels, ASHRAE also a= llows 
explicit setting of curtailment by specifying absolute or relativ= e 
(percentage) power values.

Thanks,
    Juergen


On 10.10.12 09:32, "Bruce Nordman" <bnordman@lbl.gov> wrote:

We have spent much time trying to clarify and disentangle states
and levels for devices.  It seems clear that some applications and
several external standards require grid curtailment levels.
Several long-standing industry standards define device internal
power states.

I took the relevant sections of the framework draft, beginning with 6.5, and boiled down the text there to what I think covers what we need.
That is shown below.  The existing language was retained as much
as possible.  I did remove redundant text as well as details outside t= he
scope of the framework and some details from the external standards.

The intent was to not change the meaning of these sections, just the
presentation, except to clarify the difference between  power states <= br> and curtailment levels.


= 6.5. Power States

An Energy Object can be controlled by setting it to a specific Power State or= a specific Curtailment Level (these described in the following section).  A Power States Set is an interface by which a= n Energy Object can be controlled.  Each Energy Object should indicate the Power State Sets that it impl= ements.  Well known Power State Sets should be registered with IANA

When a device is set to= a particular Power State, it may be busy.  The device will set the desired Power State and then update the actu= al Power State when it changes.  There are thus two Power State variables: actual and desired.

There are many existing= standards for and implementations of Power State Sets.&nb= sp; An Energy Object can support multiple Power State Sets concurrently.=

This framework identifi= es three initial Power State Sets: IEEE1621 [IEEE1621], DMTF [DMTF], and PW= G [PWG].

6.5.1 IEEE1621 Power State Set

IEEE1621 [IEEE1621] def= ines three basic power states : on, off, and sleep.

6.5.2 DMTF Power= State Set

DMTF [DMTF] builds on A= CPI states defines 6 core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 = or =96S2), Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), an= d Hibernate (ACPI-S4).  It also defines transitional states and state change commands: Power= Cycle Off-Soft, PowerCycle, MasterBus reset, Diagnostic Interrupt, Off-Soft= -Graceful, Off-Hard Graceful, MasterBus reset Graceful, Power-Cycle Off-Sof= t Graceful, and PowerCycle-Hard Graceful.  The DMTF standard is targeted to h= osts and computers. 

6.5.3 PWG Power State Set

The Printer Working Gro= up [PWG] also builds on ACPI states defines 6 stable power states, a series= of DMTF =93special=94 power states, a few out-of-band power states, and pr= ovision for vendor extensions to power states.  The DMTF standard is targeted to printers and other imaging devices.=

 

6.6 Curtailment Levels

EMAN defines curtailmen= t levels to provide a standard approach to model the different levels of po= wer of a device.  The curtailment levels incorporate non-operat= ional states as defined in [ACPI] and [DMTF] standards, and specify several= intermediate operational states.

There are twelve curtai= lment levels: six operational and six non-operational.&nbs= p; The lowest non-operational level is 1 and the highest is 6.  Each non-operational level corresponds to an ACPI global and system = state.  Each operational state represents a performance state, and may be ma= pped to an ACPI processor state.

For each level, the lev= el preceding it is expected to have a lower Power value.&n= bsp; For levels where the device is non-operational, it is expected that = it has a longer delay in returning to an operational state.

Characteristics of curt= ailment levels are as follows.  For the first six, no energy object features are available, except f= or 4, 5, and 6, which may include out-of-band management and device wakeup.=

mechoff(1): No energy i= s consumed.  The power connector can be removed.  Co= rresponds to ACPI state G3.

softoff(2): Some compon= ents remain powered.  No context is saved.  Powering up typic= ally requires a system boot.  Corresponds to ACPI state G2/S5.        

hibernate(3): The devic= e may be woken without requiring a system boot.  The time for availability is longer than sleep(4). =  Corresponds to ACPI state G1/S4.

sleep(4): The time for = availability is longer than standby(5).  Corresponds to ACPI state G1/S3.

standby(5): The time fo= r availability is longer than ready(6).  Corresponds to ACPI state G1/S2.

ready(6):  The device can be quickly transitioned into an operation= al state.  Corresponds to ACPI state G1/S1.

For all of the followin= g levels, some features may not be available and power consumption is less = than higher numbered levels.  All correspond to ACPI S0.  The highest= power consumption occurs in high(12).  These levels are:  lowMinus(7), low(8),= mediumMinus(9), medium(10), highMinus(11), and high(12).

 



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

_______________________________________________ eman mailing list eman@ietf.org ht= tps://www.ietf.org/mailman/listinfo/eman
--_000_7C155ACE35869F4A953588C8A4657D7510CDD95CCH1PRD0510MB356_-- From Quittek@neclab.eu Wed Oct 17 09:31:45 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2124D21F869C for ; Wed, 17 Oct 2012 09:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.708 X-Spam-Level: X-Spam-Status: No, score=-102.708 tagged_above=-999 required=5 tests=[AWL=0.891, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm9Th78fTA9U for ; Wed, 17 Oct 2012 09:31:44 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B1AC821F867F for ; Wed, 17 Oct 2012 09:31:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 696FC102220; Wed, 17 Oct 2012 18:31:41 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYiHpVUJh2S1; Wed, 17 Oct 2012 18:31:41 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 47B2D10221F; Wed, 17 Oct 2012 18:31:31 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 17 Oct 2012 18:31:18 +0200 From: Juergen Quittek To: Bruce Nordman , eman mailing list Thread-Topic: [eman] States and Levels Thread-Index: AQHNrITVTNTRqBjtxkyHkwT+izczOQ== Date: Wed, 17 Oct 2012 16:31:17 +0000 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5655497251DAEF449E695075EE458896@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 16:31:45 -0000 Hi Bruce, Below please find an alternative proposal, that I consider simpler an more open. The basic idea is that any power state or curtailment Level defined by other standards is referred to as Power State and registered in the same plain IANA registry. Specification of power state semantics may vary from State to State according to points a)-c) below. Energy Objects may implement any possible subset of registered states. Thanks, Juergen 6.5. Power States An Energy Object can be controlled by setting it to a specific Power State. An Object implements a set of power states consiting of al least two states, an on stae and an off state. A Power State is an interface by which an Energy Object can be controlled. Each Energy Object should indicate the set of Power States that it implements. Well known Power States should be registered with IANA. When a device is set to a particular Power State, it may be busy. The device will set the desired Power State and then update the actual Power State when it changes. There are thus two Power State variables: actual and desired. There are many existing standards for and implementations of Power Stats. An Energy Object can support a mixed set of power states defined in different standards, A basic example is gien by the three Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF], ACPI [ACPI], and PWG [PWG] define larger numbers of Power States. The semantics of a power state is specified by either a) the functionality provided by an energy object in this state b) a limitation of the power that an energy object uses in this state c) a combination of a) and b) The semantics of a power state should be clearly defined. Power limitation (curtailment) of the power used by an energy object in a state can be specified by - an absolute power value - a percentage value of power relative to the energy object's nameplate power, - an indication of used power relative to another power state, for example, by stating used power in state A is less than in state B. Pwer states can be registered at IANA with a description of their semantics. An Energy Object must indicate which subset of all power states it implements. On 10.10.12 09:32, "Bruce Nordman" wrote: >We have spent much time trying to clarify and disentangle states >and levels for devices. It seems clear that some applications and >several external standards require grid curtailment levels. >Several long-standing industry standards define device internal >power states. > >I took the relevant sections of the framework draft, beginning with 6.5, >and boiled down the text there to what I think covers what we need. >That is shown below. The existing language was retained as much >as possible. I did remove redundant text as well as details outside the >scope of the framework and some details from the external standards. > >The intent was to not change the meaning of these sections, just the >presentation, except to clarify the difference between power states >and curtailment levels. > > >6.5. Power States An Energy Object can be controlled by setting it >to a specific Power State or a specific Curtailment Level (these >described in >the following section). A Power States >Set is an interface by which an Energy Object can be controlled. Each >Energy Object should indicate the Power >State Sets that it implements. Well >known Power State Sets should be registered with IANA >When a device is set to a >particular Power State, it may be busy. >The device will set the desired Power State and then update the actual >Power State when it changes. There are >thus two Power State variables: actual and desired. >There are many existing standards >for and implementations of Power State Sets. >An Energy Object can support multiple Power State Sets concurrently. >This framework identifies three initial >Power State Sets: IEEE1621 [IEEE1621], DMTF [DMTF], and PWG [PWG]. >6.5.1 IEEE1621 Power State SetIEEE1621 [IEEE1621] defines three >basic power states : on, off, and sleep. >6.5.2 DMTF Power State SetDMTF [DMTF] builds on ACPI states >defines 6 core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or =ADS2), >Sleep-Deep >(ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and Hibernate >(ACPI-S4). It also defines transitional states and state >change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset, >Diagnostic >Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus reset >Graceful, Power-Cycle >Off-Soft Graceful, and PowerCycle-Hard Graceful. The DMTF standard is >targeted to hosts and >computers. =20 >6.5.3 PWG Power State SetThe Printer Working Group [PWG] also >builds on ACPI states defines 6 stable power states, a series of DMTF >=B3special=B2 >power states, a few out-of-band power states, and provision for vendor >extensions to power states. The DMTF >standard is targeted to printers and other imaging devices. >=20 >6.6 Curtailment LevelsEMAN defines curtailment levels >to provide a standard approach to model the different levels of power of a >device. The curtailment levels >incorporate non-operational states as defined in [ACPI] and [DMTF] >standards, and >specify several intermediate operational states. >There are twelve curtailment >levels: six operational and six non-operational. The lowest >non-operational level is 1 and the >highest is 6. Each non-operational level >corresponds to an ACPI global and system state. >Each operational state represents a performance state, and may be mapped >to an ACPI processor state. >For each level, the level >preceding it is expected to have a lower Power value. For levels where >the device is >non-operational, it is expected that it has a longer delay in returning >to an >operational state. >Characteristics of curtailment >levels are as follows. For the first >six, no energy object features are available, except for 4, 5, and 6, >which may >include out-of-band management and device wakeup. >mechoff(1): No energy is consumed. The power connector can be removed. >Corresponds to ACPI state G3. >softoff(2): Some components >remain powered. No context is saved. Powering up typically requires a >system boot. > Corresponds to ACPI state G2/S5. >hibernate(3): The device may be woken >without requiring a system boot. The >time for availability is longer than sleep(4). Corresponds to ACPI state >G1/S4. >sleep(4): The time for >availability is longer than standby(5). Corresponds >to ACPI state G1/S3. >standby(5): The time for >availability is longer than ready(6). Corresponds >to ACPI state G1/S2. >ready(6): The device can be quickly transitioned into an >operational state. Corresponds to ACPI state >G1/S1. >For all of the following levels, >some features may not be available and power consumption is less than >higher >numbered levels. All correspond to ACPI >S0. The highest power consumption occurs >in high(12). These levels are: lowMinus(7), low(8), mediumMinus(9), >medium(10), highMinus(11), and high(12). >=20 > > >--=20 >Bruce Nordman >Lawrence Berkeley National Laboratory >nordman.lbl.gov >BNordman@LBL.gov >510-486-7089 >m: 510-501-7943 > >_______________________________________________ >eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman From Quittek@neclab.eu Wed Oct 17 09:31:45 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6254A21F86A3 for ; Wed, 17 Oct 2012 09:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.835 X-Spam-Level: X-Spam-Status: No, score=-102.835 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x5NP-XaB+ds for ; Wed, 17 Oct 2012 09:31:44 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id ADE3621F867A for ; Wed, 17 Oct 2012 09:31:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7F80210221F; Wed, 17 Oct 2012 18:31:41 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku3OsDtT1zF7; Wed, 17 Oct 2012 18:31:41 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 55C6210221E; Wed, 17 Oct 2012 18:31:26 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 17 Oct 2012 18:31:05 +0200 From: Juergen Quittek To: Brad Schoening , Bruce Nordman , eman mailing list Thread-Topic: [eman] States and Levels Thread-Index: AQHNrITRTNTRqBjtxkyHkwT+izczOQ== Date: Wed, 17 Oct 2012 16:31:11 +0000 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 16:31:45 -0000 Hi Brad, I agree with you that fixed power values are of limited use for many kinds of devices. I just pointed out that ASHRAE is using them. BTW: There is almost no different between absolute and percentage values. The only difference is the number space that you use. It doesn't matter much whether a power state of a device with 200 Watts nameplate power limits power to an absolute value of 100 Watts or to a percentage value of 50% nameplate power. Thanks, Juergen On 17.10.12 03:13, "Brad Schoening" wrote: >Juergen, > > >You mention below using absolute or relative (percentage) power levels. >There are no doubt valuable use cases for devices with a linear >relationship between power consumed and effective work, such as perhaps >motors or an air conditioner. > > >However, percentages are less useful for 'bursty' workloads found in the >data center such as printers or dedicated servers. What would be the >utility of setting a absolute power limit on a printer that rendered it >incapable of printing? Likewise, in > the past we've related our discussions with Intel regarding their "race >to finish" philosophy =AD it's more efficient for a CPU to run at high >speed to finish calculations and then enter a pause state, rather than >run at a steady but reduced frequency. > > >Finally, idle states are something we haven't discussed much, but they're >discussed In Nedevschi, et al. "Skilled in the Art of Being Idle: >Reducing Energy Waste in Networked Systems". This paper presents four >basic power states: off, sleep, idle, full-on. > > >When looking at ASHRAE, ACPI, DMTF, or IEC 621 what we see is a variety >of models, incorporating some notion of graduated levels. I believe our >utilization of an IANA registry will support all of these. > > >Regards, > > >Brad=20 > > >Brad > Schoening >Engineering | Coraid >Tel: +1 917 304 7190 >brads@coraid.com | www.coraid.com >Coraid: Redefining Storage > > > > > > > >From: Juergen Quittek >Date: Mon, 15 Oct 2012 01:16:04 -0500 >To: Bruce Nordman , eman mailing list >Subject: Re: [eman] States and Levels > > > >Hi Bruce and all, > > >Thanks for the proposal. I still have two problems with it. >One is clarity of the term "curtailment levels" and the >other one is a conflict with ASHRAE standards. > > >What I miss is a clearer differentiation between power level >and curtailment level. Since this document is the place where the >EMAN document set explains what these are, I would rather like to >see more elaboration, particularly on the semantics of curtailment >levels.=20 > > >Beyond this, I see a conflict with the ASHRAE 201 specification. >Our separation of 'power state' and 'curtailment level' appears >to be conflicting with their very clear ASHRAE specification: > > >What we call "power state" seems to be an ASHRAE "curtailment level". >ASHRAE 201 gives examples curtailment levels >for lights : 'on', 'dimmed', 'off' >and for a fan: 'high', medium', 'low' and 'off'. >For ASHRAE, there are no fixed sets of curtailment levels. They rather >state that curtailment levels shall be defined and named consistent >with the operation of an entity. If we separate curtailment from >power state, we may not be in line anymore with ASHRAE. > > >However, instead of using curtailment levels, ASHRAE also allows >explicit setting of curtailment by specifying absolute or relative >(percentage) power values. > > >Thanks, > Juergen > > > > >On 10.10.12 09:32, "Bruce Nordman" wrote: > > >We have spent much time trying to clarify and disentangle states >and levels for devices. It seems clear that some applications and >several external standards require grid curtailment levels. >Several long-standing industry standards define device internal >power states. > >I took the relevant sections of the framework draft, beginning with 6.5, >and boiled down the text there to what I think covers what we need. >That is shown below. The existing language was retained as much >as possible. I did remove redundant text as well as details outside the >scope of the framework and some details from the external standards. > >The intent was to not change the meaning of these sections, just the >presentation, except to clarify the difference between power states >and curtailment levels. > > >6.5. Power StatesAn > Energy Object can be controlled by setting it to a specific Power State >or a specific Curtailment Level (these described in the following >section). > A Power States Set is an interface by which an Energy Object can be >controlled.=20 >Each Energy Object should indicate the Power State Sets that it >implements.=20 >Well known Power State Sets should be registered with IANA >When a device is set to a particular Power State, it may be busy. >The device will set the desired Power State and then update the actual >Power State when it changes. >There are thus two Power State variables: actual and desired. >There are many existing standards for and implementations of Power State >Sets.=20 >An Energy Object can support multiple Power State Sets concurrently. >This framework identifies three initial Power State Sets: IEEE1621 >[IEEE1621], DMTF [DMTF], and PWG [PWG]. > >6.5.1 IEEE1621 Power State SetIEEE1621 [IEEE1621] defines three basic >power states : on, off, and sleep. > >6.5.2 DMTF Power State >SetDMTF [DMTF] builds on ACPI states defines 6 core power states: On >(ACPI-S0), Sleep-Light (ACPI-S1 or =ADS2), Sleep-Deep (ACPI-S4), Off-Hard >(ACPI-S5), Off-Soft (ACPI-S5), and Hibernate (ACPI-S4). >It also defines transitional states and state change commands: PowerCycle >Off-Soft, PowerCycle, MasterBus reset, Diagnostic Interrupt, >Off-Soft-Graceful, Off-Hard Graceful, MasterBus reset Graceful, >Power-Cycle Off-Soft Graceful, and PowerCycle-Hard > Graceful. The DMTF standard is targeted to hosts and computers. > >6.5.3 PWG Power State SetThe Printer Working Group [PWG] also builds on >ACPI states defines 6 stable power states, a series of DMTF =B3special=B2 >power states, a few out-of-band power states, and provision for vendor >extensions to power states. >The DMTF standard is targeted to printers and other imaging devices. >=20 >6.6 Curtailment LevelsEMAN defines curtailment levels to provide a >standard approach to model the different levels of power of a device. > The curtailment levels incorporate non-operational states as defined in >[ACPI] and [DMTF] standards, and specify several intermediate operational >states. > >There are twelve curtailment levels: six operational and six >non-operational.=20 >The lowest non-operational level is 1 and the highest is 6. >Each non-operational level corresponds to an ACPI global and system >state.=20 >Each operational state represents a performance state, and may be mapped >to an ACPI processor state. > >For each level, the level preceding it is expected to have a lower Power >value.=20 >For levels where the device is non-operational, it is expected that it >has a longer delay in returning to an operational state. >Characteristics of curtailment levels are as follows. >For the first six, no energy object features are available, except for 4, >5, and 6, which may include out-of-band management and device wakeup. >mechoff(1): No energy is consumed. >The power connector can be removed. Corresponds to ACPI state G3. > >softoff(2): Some components remain powered. >No context is saved. Powering up typically requires a system boot. > Corresponds to ACPI state G2/S5. >hibernate(3): The device may be woken without requiring a system boot. >The time for availability is longer than sleep(4). Corresponds to ACPI >state G1/S4. >sleep(4): The time for availability is longer than standby(5). > Corresponds to ACPI state G1/S3. >standby(5): The time for availability is longer than ready(6). > Corresponds to ACPI state G1/S2. >ready(6): The device can be quickly transitioned into an operational >state.=20 >Corresponds to ACPI state G1/S1. >For all of the following levels, some features may not be available and >power consumption is less than higher numbered levels. >All correspond to ACPI S0. The highest power consumption occurs in >high(12).=20 >These levels are: lowMinus(7), low(8), mediumMinus(9), medium(10), >highMinus(11), and high(12). >=20 > > >--=20 >Bruce Nordman >Lawrence Berkeley National Laboratory >nordman.lbl.gov >BNordman@LBL.gov >510-486-7089 >m: 510-501-7943 > >_______________________________________________ eman mailing list >eman@ietf.org >https://www.ietf.org/mailman/listinfo/eman > From jparello@cisco.com Wed Oct 17 14:12:20 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A23F21F8672 for ; Wed, 17 Oct 2012 14:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.736 X-Spam-Level: X-Spam-Status: No, score=-9.736 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igTOL2Ut4O7n for ; Wed, 17 Oct 2012 14:12:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AD51421F86FF for ; Wed, 17 Oct 2012 14:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8821; q=dns/txt; s=iport; t=1350508338; x=1351717938; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gjQhnXVvsqY9m8qEXHSF+s4wFMngJGHeIF8DXk34JeU=; b=iqZx2Geaw+A99aXz/4uZenieEq+No8YAVw2btPj+amlvsYkaHFGOHn4i zpwmpNgJ4jIx0AXj2PRk+aO2oVK/72fus4LGwGV5MA9lI8CWUXIc4bCXg c+wzYfM0ByLYE+IFlqvzDQMuiBzDDSzYwHMhuo5wcNy5AF1Qu91vX4A8H I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPYdf1CtJV2a/2dsb2JhbABCA8AxgQiCIAEBAQQBAQEPAVsCFQQCAQgRBAEBCx0HJwsUCQgCBAESCBqHYQELm3OgNItYG4J/gkhgA4gjjl2NNIFrgm+CFw X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="132790752" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 17 Oct 2012 21:12:18 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9HLCIRc027403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 21:12:18 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 16:12:17 -0500 From: "John Parello (jparello)" To: Juergen Quittek , eman mailing list Thread-Topic: [eman] States and Levels Thread-Index: AQHNprl9FpD1Zjnkkk2eYwFwTD+FU5e+EAiA///3Z9A= Date: Wed, 17 Oct 2012 21:12:17 +0000 Message-ID: <9C213D38848B89428F46808B16F6F0860C75AC@xmb-aln-x04.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--59.339400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:12:20 -0000 Hi Juergen, Thanks so much for the concise proposal. I think that boils down what we ha= ve been discussing for quite some time into a clean statement. I'd like to add a few things so see inline. If you agree or propose somethi= ng better I can add this as the new section for this draft before the deadl= ine Monday. See below prefixed by [jp] Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Jue= rgen Quittek Sent: Wednesday, October 17, 2012 9:31 AM To: Bruce Nordman; eman mailing list Subject: Re: [eman] States and Levels 6.5. Power States An Energy Object can be controlled by setting it to a specific Power State.= An Object implements a set of power states consiting of al least two stat= es, an on stae and an off state. A Power State is an interface by which an Energy Object can be controlled. = Each Energy Object should indicate the set of Power States that it impleme= nts. Well known Power States should be registered with IANA. When a devic= e is set to a particular Power State, it may be busy. The device will set = the desired Power State and then update the actual Power State when it chan= ges. There are thus two Power State variables: actual and desired. There are many existing standards for and implementations of Power Stats. = An Energy Object can support a mixed set of power states defined in differe= nt standards, A basic example is given by the three Power States defined in= IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF], ACPI [ACPI], and PWG [PWG] define larger numbers of Power = States. The semantics of a power state is specified by either a) the functionality provided by an energy object in this state b) a limitation of the power that an energy object uses in this state c) a combination of a) and b) The semantics of a power state should be clearly defined. Power limitation= (curtailment) of the power used by an energy object in a state can be spec= ified by - an absolute power value - a percentage value of power relative to the energy object's nameplate power, - an indication of used power relative to another power state, for example, by stating used power in state A is less than in state B. [jp] Additional attributes like name, time in state, counters, time to ent= er and exit a state, can be specified. Power states can be registered at IANA with a description of their semantic= s. An Energy Object must indicate which subset of all power states it impl= ements. [jp] When requesting to set to a power state an indication of the state by = name, or index can be used. Also a request to enter a state by matching the= closest absolute or relative power can be made. [jp] NOTE: I'd like us to keep the EMAN power States we've had in the draft= for some time now in a separate section. I recommend that as an IANA reg= istered set as we planned. I have an ecosystem (Cisco EnergyWise) of multip= le vendors currently using these since we've found that the existing ones h= ad no operational states like low, medium or high. As a representative of t= hat group, the industrial automation ODVA and working with ASHREA we'd like= to have these defined as a common set in IANA. Thanks! Jp On 10.10.12 09:32, "Bruce Nordman" wrote: >We have spent much time trying to clarify and disentangle states and=20 >levels for devices. It seems clear that some applications and several=20 >external standards require grid curtailment levels. >Several long-standing industry standards define device internal power=20 >states. > >I took the relevant sections of the framework draft, beginning with=20 >6.5, and boiled down the text there to what I think covers what we need. >That is shown below. The existing language was retained as much as=20 >possible. I did remove redundant text as well as details outside the=20 >scope of the framework and some details from the external standards. > >The intent was to not change the meaning of these sections, just the=20 >presentation, except to clarify the difference between power states=20 >and curtailment levels. > > >6.5. Power States An Energy Object can be controlled by setting it to a=20 >specific Power State or a specific Curtailment Level (these described=20 >in the following section). A Power States Set is an interface by which=20 >an Energy Object can be controlled. Each Energy Object should indicate=20 >the Power State Sets that it implements. Well known Power State Sets=20 >should be registered with IANA When a device is set to a particular=20 >Power State, it may be busy. >The device will set the desired Power State and then update the actual=20 >Power State when it changes. There are thus two Power State variables:=20 >actual and desired. >There are many existing standards >for and implementations of Power State Sets. >An Energy Object can support multiple Power State Sets concurrently. >This framework identifies three initial Power State Sets: IEEE1621=20 >[IEEE1621], DMTF [DMTF], and PWG [PWG]. >6.5.1 IEEE1621 Power State SetIEEE1621 [IEEE1621] defines three basic=20 >power states : on, off, and sleep. >6.5.2 DMTF Power State SetDMTF [DMTF] builds on ACPI states defines 6=20 >core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or =ADS2),=20 >Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and=20 >Hibernate (ACPI-S4). It also defines transitional states and state=20 >change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset,=20 >Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus=20 >reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard=20 >Graceful. The DMTF standard is targeted to hosts and computers. >6.5.3 PWG Power State SetThe Printer Working Group [PWG] also builds on=20 >ACPI states defines 6 stable power states, a series of DMTF =B3special=B2= =20 >power states, a few out-of-band power states, and provision for vendor=20 >extensions to power states. The DMTF standard is targeted to printers=20 >and other imaging devices. >=20 >6.6 Curtailment LevelsEMAN defines curtailment levels to provide a=20 >standard approach to model the different levels of power of a device. =20 >The curtailment levels incorporate non-operational states as defined in=20 >[ACPI] and [DMTF] standards, and specify several intermediate=20 >operational states. >There are twelve curtailment >levels: six operational and six non-operational. The lowest=20 >non-operational level is 1 and the highest is 6. Each non-operational=20 >level corresponds to an ACPI global and system state. >Each operational state represents a performance state, and may be=20 >mapped to an ACPI processor state. >For each level, the level >preceding it is expected to have a lower Power value. For levels where=20 >the device is non-operational, it is expected that it has a longer=20 >delay in returning to an operational state. >Characteristics of curtailment >levels are as follows. For the first >six, no energy object features are available, except for 4, 5, and 6,=20 >which may include out-of-band management and device wakeup. >mechoff(1): No energy is consumed. The power connector can be removed. >Corresponds to ACPI state G3. >softoff(2): Some components >remain powered. No context is saved. Powering up typically requires a=20 >system boot. > Corresponds to ACPI state G2/S5. >hibernate(3): The device may be woken >without requiring a system boot. The >time for availability is longer than sleep(4). Corresponds to ACPI=20 >state G1/S4. >sleep(4): The time for >availability is longer than standby(5). Corresponds to ACPI state=20 >G1/S3. >standby(5): The time for >availability is longer than ready(6). Corresponds to ACPI state G1/S2. >ready(6): The device can be quickly transitioned into an operational=20 >state. Corresponds to ACPI state G1/S1. >For all of the following levels, >some features may not be available and power consumption is less than=20 >higher numbered levels. All correspond to ACPI S0. The highest power=20 >consumption occurs in high(12). These levels are: lowMinus(7),=20 >low(8), mediumMinus(9), medium(10), highMinus(11), and high(12). >=20 > > >-- >Bruce Nordman >Lawrence Berkeley National Laboratory >nordman.lbl.gov BNordman@LBL.gov >510-486-7089 >m: 510-501-7943 > >_______________________________________________ >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 blueroofmusic@gmail.com Wed Oct 17 14:55:53 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7541D21F8714 for ; Wed, 17 Oct 2012 14:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEQhohDB7KSM for ; Wed, 17 Oct 2012 14:55:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2383121F871C for ; Wed, 17 Oct 2012 14:55:50 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6112023lbo.31 for ; Wed, 17 Oct 2012 14:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2gyIFQEoNI1u/NmbG9aZ8Ts0O2wL2Dk8fhibon8vGro=; b=LQ+vnvJiQeiACV0PYe/xkIeQkPL1eRzgPTw9akylp+RVjhLXxvWbbrqwCeYC6NlqcZ Og1XNPfC7L/YH1SzSSRURCXUW3flvgzfMDI+ZcfByOXiHQ0pBd2pnh1pC5AkA6R+pqKG qoFejbeXk5KvSpmWeaGcBrbOYJPw+Vp1rvTtJ1JxtHW1NkvzaeP+r1ULlVcUOFCDByzJ anJdMkpvR0K1bEvOLwyY0ZMemvZHdycbWaIF08IvVfabsEtSObM88eR7mqAMlTtHJErc YASK3ojWnMVlFukYmmlzrLR7bIhX9FxvDVtvB4oxM1popXCUG+zL18myvQLLEpgrlTPZ RPjg== MIME-Version: 1.0 Received: by 10.152.162.97 with SMTP id xz1mr16849814lab.38.1350510949910; Wed, 17 Oct 2012 14:55:49 -0700 (PDT) Received: by 10.112.83.7 with HTTP; Wed, 17 Oct 2012 14:55:49 -0700 (PDT) In-Reply-To: <9C213D38848B89428F46808B16F6F0860C75AC@xmb-aln-x04.cisco.com> References: <9C213D38848B89428F46808B16F6F0860C75AC@xmb-aln-x04.cisco.com> Date: Wed, 17 Oct 2012 17:55:49 -0400 Message-ID: From: Ira McDonald To: "John Parello (jparello)" , Ira McDonald Content-Type: multipart/alternative; boundary=f46d043bdaba6f496a04cc485507 Cc: eman mailing list Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:55:53 -0000 --f46d043bdaba6f496a04cc485507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, +1 Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 Temporary Cabin *** 2012 only *** 906-494-2523 On Wed, Oct 17, 2012 at 5:12 PM, John Parello (jparello) wrote: > Hi Juergen, > > Thanks so much for the concise proposal. I think that boils down what we > have been discussing for quite some time into a clean statement. > > I'd like to add a few things so see inline. If you agree or propose > something better I can add this as the new section for this draft before > the deadline Monday. > > See below prefixed by [jp] > > Jp > > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Wednesday, October 17, 2012 9:31 AM > To: Bruce Nordman; eman mailing list > Subject: Re: [eman] States and Levels > > > > > 6.5. Power States > > An Energy Object can be controlled by setting it to a specific Power > State. An Object implements a set of power states consiting of al least > two states, an on stae and an off state. > > A Power State is an interface by which an Energy Object can be controlled= . > Each Energy Object should indicate the set of Power States that it > implements. Well known Power States should be registered with IANA. Whe= n > a device is set to a particular Power State, it may be busy. The device > will set the desired Power State and then update the actual Power State > when it changes. There are thus two Power State variables: actual and > desired. > > There are many existing standards for and implementations of Power Stats. > An Energy Object can support a mixed set of power states defined in > different standards, A basic example is given by the three Power States > defined in IEEE1621 [IEEE1621]: on, off, and sleep. > The DMTF [DMTF], ACPI [ACPI], and PWG [PWG] define larger numbers of Powe= r > States. > > The semantics of a power state is specified by either > a) the functionality provided by an energy object in this state > b) a limitation of the power that an energy object uses in this > state > c) a combination of a) and b) > > The semantics of a power state should be clearly defined. Power > limitation (curtailment) of the power used by an energy object in a state > can be specified by > - an absolute power value > - a percentage value of power relative to the energy object's > nameplate power, > - an indication of used power relative to another power state, > for example, by stating used power in state A is less than in > state B. > [jp] Additional attributes like name, time in state, counters, time to > enter and exit a state, can be specified. > > Power states can be registered at IANA with a description of their > semantics. An Energy Object must indicate which subset of all power stat= es > it implements. > > [jp] When requesting to set to a power state an indication of the state b= y > name, or index can be used. Also a request to enter a state by matching t= he > closest absolute or relative power can be made. > > [jp] NOTE: I'd like us to keep the EMAN power States we've had in the > draft for some time now in a separate section. I recommend that as an > IANA registered set as we planned. I have an ecosystem (Cisco EnergyWise) > of multiple vendors currently using these since we've found that the > existing ones had no operational states like low, medium or high. As a > representative of that group, the industrial automation ODVA and working > with ASHREA we'd like to have these defined as a common set in IANA. > > Thanks! > Jp > > > > On 10.10.12 09:32, "Bruce Nordman" wrote: > > >We have spent much time trying to clarify and disentangle states and > >levels for devices. It seems clear that some applications and several > >external standards require grid curtailment levels. > >Several long-standing industry standards define device internal power > >states. > > > >I took the relevant sections of the framework draft, beginning with > >6.5, and boiled down the text there to what I think covers what we need. > >That is shown below. The existing language was retained as much as > >possible. I did remove redundant text as well as details outside the > >scope of the framework and some details from the external standards. > > > >The intent was to not change the meaning of these sections, just the > >presentation, except to clarify the difference between power states > >and curtailment levels. > > > > > >6.5. Power States An Energy Object can be controlled by setting it to a > >specific Power State or a specific Curtailment Level (these described > >in the following section). A Power States Set is an interface by which > >an Energy Object can be controlled. Each Energy Object should indicate > >the Power State Sets that it implements. Well known Power State Sets > >should be registered with IANA When a device is set to a particular > >Power State, it may be busy. > >The device will set the desired Power State and then update the actual > >Power State when it changes. There are thus two Power State variables: > >actual and desired. > >There are many existing standards > >for and implementations of Power State Sets. > >An Energy Object can support multiple Power State Sets concurrently. > >This framework identifies three initial Power State Sets: IEEE1621 > >[IEEE1621], DMTF [DMTF], and PWG [PWG]. > >6.5.1 IEEE1621 Power State SetIEEE1621 [IEEE1621] defines three basic > >power states : on, off, and sleep. > >6.5.2 DMTF Power State SetDMTF [DMTF] builds on ACPI states defines 6 > >core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or =ADS2), > >Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and > >Hibernate (ACPI-S4). It also defines transitional states and state > >change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset, > >Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus > >reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard > >Graceful. The DMTF standard is targeted to hosts and computers. > >6.5.3 PWG Power State SetThe Printer Working Group [PWG] also builds on > >ACPI states defines 6 stable power states, a series of DMTF =B3special= =B2 > >power states, a few out-of-band power states, and provision for vendor > >extensions to power states. The DMTF standard is targeted to printers > >and other imaging devices. > > > >6.6 Curtailment LevelsEMAN defines curtailment levels to provide a > >standard approach to model the different levels of power of a device. > >The curtailment levels incorporate non-operational states as defined in > >[ACPI] and [DMTF] standards, and specify several intermediate > >operational states. > >There are twelve curtailment > >levels: six operational and six non-operational. The lowest > >non-operational level is 1 and the highest is 6. Each non-operational > >level corresponds to an ACPI global and system state. > >Each operational state represents a performance state, and may be > >mapped to an ACPI processor state. > >For each level, the level > >preceding it is expected to have a lower Power value. For levels where > >the device is non-operational, it is expected that it has a longer > >delay in returning to an operational state. > >Characteristics of curtailment > >levels are as follows. For the first > >six, no energy object features are available, except for 4, 5, and 6, > >which may include out-of-band management and device wakeup. > >mechoff(1): No energy is consumed. The power connector can be removed. > >Corresponds to ACPI state G3. > >softoff(2): Some components > >remain powered. No context is saved. Powering up typically requires a > >system boot. > > Corresponds to ACPI state G2/S5. > >hibernate(3): The device may be woken > >without requiring a system boot. The > >time for availability is longer than sleep(4). Corresponds to ACPI > >state G1/S4. > >sleep(4): The time for > >availability is longer than standby(5). Corresponds to ACPI state > >G1/S3. > >standby(5): The time for > >availability is longer than ready(6). Corresponds to ACPI state G1/S2. > >ready(6): The device can be quickly transitioned into an operational > >state. Corresponds to ACPI state G1/S1. > >For all of the following levels, > >some features may not be available and power consumption is less than > >higher numbered levels. All correspond to ACPI S0. The highest power > >consumption occurs in high(12). These levels are: lowMinus(7), > >low(8), mediumMinus(9), medium(10), highMinus(11), and high(12). > > > > > > > >-- > >Bruce Nordman > >Lawrence Berkeley National Laboratory > >nordman.lbl.gov BNordman@LBL.gov > >510-486-7089 > >m: 510-501-7943 > > > >_______________________________________________ > >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 > --f46d043bdaba6f496a04cc485507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

+1

Cheers,
- Ira


Ira McDonald= (Musician / Software Architect)
Chair - Linux Foundation Open Printing = WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO P= WG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded System= s Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roo= f Music/High North Inc
http://sites.google.= com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434
Temporary Cabin= *** 2012 only *** 906-494-2523
=



On Wed, Oct 17, 2012 at 5:12 PM, John Pa= rello (jparello) <jparello@cisco.com> wrote:
Hi Juergen,

Thanks so much for the concise proposal. I think that boils down what we ha= ve been discussing for quite some time into a clean statement.

I'd like to add a few things so see inline. If you agree or propose som= ething better I can add this as the new section for this draft before the d= eadline Monday.

See below prefixed by [jp]

Jp

-----Original Message-----
From: eman-bounces@ietf.org [m= ailto:eman-bounces@ietf.org] O= n Behalf Of Juergen Quittek
Sent: Wednesday, October 17, 2012 9:31 AM
To: Bruce Nordman; eman mailing list
Subject: Re: [eman] States and Levels

<deletia>


6.5. Power States

An Energy Object can be controlled by setting it to a specific Power State.= =A0An Object implements a set of power states consiting of al least two st= ates, an on stae and an off state.

A Power State is an interface by which an Energy Object can be controlled. = =A0Each Energy Object should indicate the set of Power States that it imple= ments. =A0Well known Power States should be registered with IANA. =A0When a= device is set to a particular Power State, it may be busy. =A0The device w= ill set the desired Power State and then update the actual Power State when= it changes. =A0There are thus two Power State variables: actual and desire= d.

There are many existing standards for and implementations of Power St= ats. =A0An Energy Object can support a mixed set of power states defined in= different standards, A basic example is given by the three Power States de= fined in IEEE1621 [IEEE1621]: on, off, and sleep.
The DMTF [DMTF], ACPI [ACPI], and PWG [PWG] define larger= numbers of Power States.

The semantics of a power state is specified by either
=A0 a) the functionality provided by an energy object in this state
=A0 b) a limitation of the power that an energy object uses in this
=A0 =A0 =A0state
=A0 c) a combination of a) and b)

The semantics of a power state should be clearly defined. =A0Power limitati= on (curtailment) of the power used by an energy object in a state can be sp= ecified by
=A0 - an absolute power value
=A0 - a percentage value of power relative to the energy object's
=A0 =A0 nameplate power,
=A0 - an indication of used power relative to another power state,
=A0 =A0 for example, by stating used power in state A is less than in
=A0 =A0 state B.
[jp] Additional attributes like name, =A0time in state, counters, tim= e to enter and exit a state, can be specified.

Power states can be registered at IANA with a description of their semantic= s. =A0An Energy Object must indicate which subset of all power states it im= plements.

[jp] When requesting to set to a power state an indication of the state by = name, or index can be used. Also a request to enter a state by matching the= closest absolute or relative power can be made.

[jp] NOTE: I'd like us to keep the EMAN power States we've had in t= he draft for some time now in a separate section. =A0I =A0recommend that as= an IANA registered set as we planned. I have an ecosystem (Cisco EnergyWis= e) of multiple vendors currently using these since we've found that the= existing ones had no operational states like low, medium or high. As a rep= resentative of that group, the industrial automation ODVA and working with = ASHREA we'd like to have these defined as a common set in IANA.

Thanks!
Jp



On 10.10.12 09:32, "Bruce Nordman" <bnordman@lbl.gov> wrote:

>We have spent much time trying to clarify and disentangle states and >levels for devices. =A0It seems clear that some applications and severa= l
>external standards require grid curtailment levels.
>Several long-standing industry standards define device internal power >states.
>
>I took the relevant sections of the framework draft, beginning with
>6.5, and boiled down the text there to what I think covers what we need= .
>That is shown below. =A0The existing language was retained as much as >possible. =A0I did remove redundant text as well as details outside the=
>scope of the framework and some details from the external standards. >
>The intent was to not change the meaning of these sections, just the >presentation, except to clarify the difference between =A0power states<= br> >and curtailment levels.
>
>
>6.5. Power States An Energy Object can be controlled by setting it to a=
>specific Power State or a specific Curtailment Level (these described >in the following section). =A0A Power States Set is an interface by whi= ch
>an Energy Object can be controlled. =A0Each Energy Object should indica= te
>the Power State Sets that it implements. =A0Well known Power State Sets=
>should be registered with IANA When a device is set to a particular
>Power State, it may be busy.
>The device will set the desired Power State and then update the actual<= br> >Power State when it changes. =A0There are thus two Power State variable= s:
>actual and desired.
>There are many existing standards
>for and implementations of Power State Sets.
>An Energy Object can support multiple Power State Sets concurrently. >This framework identifies three initial Power State Sets: IEEE1621
>[IEEE1621], DMTF [DMTF], and PWG [PWG].
>6.5.1 IEEE1621 Power State SetIEEE1621 [IEEE1621] defines three basic >power states : on, off, and sleep.
>6.5.2 DMTF Power State SetDMTF [DMTF] builds on ACPI states defines 6 >core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or =ADS2),
>Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and
>Hibernate (ACPI-S4). =A0It also defines transitional states and state >change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset,
>Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus >reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard
>Graceful. =A0The DMTF standard is targeted to hosts and computers.
>6.5.3 PWG Power State SetThe Printer Working Group [PWG] also builds on=
>ACPI states defines 6 stable power states, a series of DMTF =B3special= =B2
>power states, a few out-of-band power states, and provision for vendor<= br> >extensions to power states. =A0The DMTF standard is targeted to printer= s
>and other imaging devices.
>
>6.6 Curtailment LevelsEMAN defines curtailment levels to provide a
>standard approach to model the different levels of power of a device. >The curtailment levels incorporate non-operational states as defined in=
>[ACPI] and [DMTF] standards, and specify several intermediate
>operational states.
>There are twelve curtailment
>levels: six operational and six non-operational. =A0The lowest
>non-operational level is 1 and the highest is 6. =A0Each non-operationa= l
>level corresponds to an ACPI global and system state.
>Each operational state represents a performance state, and may be
>mapped to an ACPI processor state.
>For each level, the level
>preceding it is expected to have a lower Power value. =A0For levels whe= re
>the device is non-operational, it is expected that it has a longer
>delay in returning to an operational state.
>Characteristics of curtailment
>levels are as follows. =A0For the first
>six, no energy object features are available, except for 4, 5, and 6, >which may include out-of-band management and device wakeup.
>mechoff(1): No energy is consumed. =A0The power connector can be remove= d.
>Corresponds to ACPI state G3.
>softoff(2): Some components
>remain powered. =A0No context is saved. =A0Powering up typically requir= es a
>system boot.
> Corresponds to ACPI state G2/S5.
>hibernate(3): The device may be woken
>without requiring a system boot. =A0The
>time for availability is longer than sleep(4). =A0Corresponds to ACPI >state G1/S4.
>sleep(4): The time for
>availability is longer than standby(5). =A0Corresponds to ACPI state >G1/S3.
>standby(5): The time for
>availability is longer than ready(6). =A0Corresponds to ACPI state G1/S= 2.
>ready(6): =A0The device can be quickly transitioned into an operational=
>state. =A0Corresponds to ACPI state G1/S1.
>For all of the following levels,
>some features may not be available and power consumption is less than >higher numbered levels. =A0All correspond to ACPI S0. =A0The highest po= wer
>consumption occurs in high(12). =A0These levels are: =A0lowMinus(7), >low(8), mediumMinus(9), medium(10), highMinus(11), and high(12).
>
>
>
>--
>Bruce Nordman
>Lawrence Berkeley National Laboratory
>nordman.lbl.gov <http://nordman.l= bl.gov> BNordman@LBL.gov
>510-486-7089 >m: 510-501-7943=
>
>_______________________________________________
>eman mailing list
>eman@ietf.org
>https://www.ietf.org/mailman/listinfo/eman

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

--f46d043bdaba6f496a04cc485507-- From internet-drafts@ietf.org Fri Oct 19 03:00:43 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5540421F863F; Fri, 19 Oct 2012 03:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq3oZEwY0O31; Fri, 19 Oct 2012 03:00:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EC921F8634; Fri, 19 Oct 2012 03:00:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019100042.20878.30581.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 03:00:42 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-07.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 10:00:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Object Context MIB Author(s) : John Parello Benoit Claise Mouli Chandramouli Filename : draft-ietf-eman-energy-aware-mib-07.txt Pages : 34 Date : 2012-10-19 Abstract: This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the relationships between reporting devices, remote devices, and monitoring devices. = The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-aware-mib-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Quittek@neclab.eu Fri Oct 19 04:31:19 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6B21F8634 for ; Fri, 19 Oct 2012 04:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.054 X-Spam-Level: X-Spam-Status: No, score=-102.054 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88ZGQXpwF6c6 for ; Fri, 19 Oct 2012 04:31:18 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A151F21F861C for ; Fri, 19 Oct 2012 04:31:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id ADE5A102259; Fri, 19 Oct 2012 13:31:16 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Cb7a3vHoVUi; Fri, 19 Oct 2012 13:31:16 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 836E6102258; Fri, 19 Oct 2012 13:31:06 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 19 Oct 2012 13:31:06 +0200 From: Juergen Quittek To: "John Parello (jparello)" , eman mailing list Thread-Topic: [eman] States and Levels Thread-Index: AQHNre0ibRrc+kuulE6P1YOiGdqTbQ== Date: Fri, 19 Oct 2012 11:30:26 +0000 Message-ID: In-Reply-To: <9C213D38848B89428F46808B16F6F0860C75AC@xmb-aln-x04.cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="euc-kr" Content-ID: <9C9E7A8C74A7A74B8BE2C7A8BC992DD8@office.hd> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:31:19 -0000 SGkgSm9obiwNCg0KSSBzZWUgeW91ciBwb2ludHMuICBJIHRyaWVkIHRvIG1vZGlmeSB0aGUgcHJv cG9zZWQgdGV4dA0KYWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMuICBQbGVhc2Ugc2VlIGlubGlu ZS4NCg0KT24gMTcuMTAuMTIgMjM6MTIsICJKb2huIFBhcmVsbG8gKGpwYXJlbGxvKSIgPGpwYXJl bGxvQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5IaSBKdWVyZ2VuLA0KPg0KPlRoYW5rcyBzbyBtdWNo IGZvciB0aGUgY29uY2lzZSBwcm9wb3NhbC4gSSB0aGluayB0aGF0IGJvaWxzIGRvd24gd2hhdCB3 ZQ0KPmhhdmUgYmVlbiBkaXNjdXNzaW5nIGZvciBxdWl0ZSBzb21lIHRpbWUgaW50byBhIGNsZWFu IHN0YXRlbWVudC4NCj4NCj5JJ2QgbGlrZSB0byBhZGQgYSBmZXcgdGhpbmdzIHNvIHNlZSBpbmxp bmUuIElmIHlvdSBhZ3JlZSBvciBwcm9wb3NlDQo+c29tZXRoaW5nIGJldHRlciBJIGNhbiBhZGQg dGhpcyBhcyB0aGUgbmV3IHNlY3Rpb24gZm9yIHRoaXMgZHJhZnQgYmVmb3JlDQo+dGhlIGRlYWRs aW5lIE1vbmRheS4NCj4NCj5TZWUgYmVsb3cgcHJlZml4ZWQgYnkgW2pwXQ0KPg0KPkpwDQo+DQo+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBlbWFuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzplbWFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPkp1ZXJnZW4gUXVp dHRlaw0KPlNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNywgMjAxMiA5OjMxIEFNDQo+VG86IEJy dWNlIE5vcmRtYW47IGVtYW4gbWFpbGluZyBsaXN0DQo+U3ViamVjdDogUmU6IFtlbWFuXSBTdGF0 ZXMgYW5kIExldmVscw0KPg0KPjxkZWxldGlhPg0KPg0KPg0KPjYuNS4gUG93ZXIgU3RhdGVzDQo+ DQo+QW4gRW5lcmd5IE9iamVjdCBjYW4gYmUgY29udHJvbGxlZCBieSBzZXR0aW5nIGl0IHRvIGEg c3BlY2lmaWMgUG93ZXINCj5TdGF0ZS4gIEFuIE9iamVjdCBpbXBsZW1lbnRzIGEgc2V0IG9mIHBv d2VyIHN0YXRlcyBjb25zaXRpbmcgb2YgYWwgbGVhc3QNCj50d28gc3RhdGVzLCBhbiBvbiBzdGFl IGFuZCBhbiBvZmYgc3RhdGUuDQo+DQo+QSBQb3dlciBTdGF0ZSBpcyBhbiBpbnRlcmZhY2UgYnkg d2hpY2ggYW4gRW5lcmd5IE9iamVjdCBjYW4gYmUNCj5jb250cm9sbGVkLiAgRWFjaCBFbmVyZ3kg T2JqZWN0IHNob3VsZCBpbmRpY2F0ZSB0aGUgc2V0IG9mIFBvd2VyIFN0YXRlcw0KPnRoYXQgaXQg aW1wbGVtZW50cy4gIFdlbGwga25vd24gUG93ZXIgU3RhdGVzIHNob3VsZCBiZSByZWdpc3RlcmVk IHdpdGgNCj5JQU5BLiAgV2hlbiBhIGRldmljZSBpcyBzZXQgdG8gYSBwYXJ0aWN1bGFyIFBvd2Vy IFN0YXRlLCBpdCBtYXkgYmUgYnVzeS4NCj5UaGUgZGV2aWNlIHdpbGwgc2V0IHRoZSBkZXNpcmVk IFBvd2VyIFN0YXRlIGFuZCB0aGVuIHVwZGF0ZSB0aGUgYWN0dWFsDQo+UG93ZXIgU3RhdGUgd2hl biBpdCBjaGFuZ2VzLiAgVGhlcmUgYXJlIHRodXMgdHdvIFBvd2VyIFN0YXRlIHZhcmlhYmxlczoN Cj5hY3R1YWwgYW5kIGRlc2lyZWQuDQo+DQo+VGhlcmUgYXJlIG1hbnkgZXhpc3Rpbmcgc3RhbmRh cmRzIGZvciBhbmQgaW1wbGVtZW50YXRpb25zIG9mIFBvd2VyIFN0YXRzLg0KPiBBbiBFbmVyZ3kg T2JqZWN0IGNhbiBzdXBwb3J0IGEgbWl4ZWQgc2V0IG9mIHBvd2VyIHN0YXRlcyBkZWZpbmVkIGlu DQo+ZGlmZmVyZW50IHN0YW5kYXJkcywgQSBiYXNpYyBleGFtcGxlIGlzIGdpdmVuIGJ5IHRoZSB0 aHJlZSBQb3dlciBTdGF0ZXMNCj5kZWZpbmVkIGluIElFRUUxNjIxIFtJRUVFMTYyMV06IG9uLCBv ZmYsIGFuZCBzbGVlcC4NCj5UaGUgRE1URiBbRE1URl0sIEFDUEkgW0FDUEldLCBhbmQgUFdHIFtQ V0ddIGRlZmluZSBsYXJnZXIgbnVtYmVycyBvZg0KPlBvd2VyIFN0YXRlcy4NCj4NCj5UaGUgc2Vt YW50aWNzIG9mIGEgcG93ZXIgc3RhdGUgaXMgc3BlY2lmaWVkIGJ5IGVpdGhlcg0KPiAgYSkgdGhl IGZ1bmN0aW9uYWxpdHkgcHJvdmlkZWQgYnkgYW4gZW5lcmd5IG9iamVjdCBpbiB0aGlzIHN0YXRl DQo+ICBiKSBhIGxpbWl0YXRpb24gb2YgdGhlIHBvd2VyIHRoYXQgYW4gZW5lcmd5IG9iamVjdCB1 c2VzIGluIHRoaXMNCj4gICAgIHN0YXRlDQo+ICBjKSBhIGNvbWJpbmF0aW9uIG9mIGEpIGFuZCBi KQ0KPg0KPlRoZSBzZW1hbnRpY3Mgb2YgYSBwb3dlciBzdGF0ZSBzaG91bGQgYmUgY2xlYXJseSBk ZWZpbmVkLiAgUG93ZXINCj5saW1pdGF0aW9uIChjdXJ0YWlsbWVudCkgb2YgdGhlIHBvd2VyIHVz ZWQgYnkgYW4gZW5lcmd5IG9iamVjdCBpbiBhIHN0YXRlDQo+Y2FuIGJlIHNwZWNpZmllZCBieQ0K PiAgLSBhbiBhYnNvbHV0ZSBwb3dlciB2YWx1ZQ0KPiAgLSBhIHBlcmNlbnRhZ2UgdmFsdWUgb2Yg cG93ZXIgcmVsYXRpdmUgdG8gdGhlIGVuZXJneSBvYmplY3Qncw0KPiAgICBuYW1lcGxhdGUgcG93 ZXIsDQo+ICAtIGFuIGluZGljYXRpb24gb2YgdXNlZCBwb3dlciByZWxhdGl2ZSB0byBhbm90aGVy IHBvd2VyIHN0YXRlLA0KPiAgICBmb3IgZXhhbXBsZSwgYnkgc3RhdGluZyB1c2VkIHBvd2VyIGlu IHN0YXRlIEEgaXMgbGVzcyB0aGFuIGluDQo+ICAgIHN0YXRlIEIuDQo+W2pwXSBBZGRpdGlvbmFs IGF0dHJpYnV0ZXMgbGlrZSBuYW1lLCAgdGltZSBpbiBzdGF0ZSwgY291bnRlcnMsIHRpbWUgdG8N Cj5lbnRlciBhbmQgZXhpdCBhIHN0YXRlLCBjYW4gYmUgc3BlY2lmaWVkLg0KDQpBZ3JlZWQuICBI b3dldmVyLCAidGltZSBpbiBzdGF0ZSIgaXMgbm90IHNwZWNpZnlpbmcNCnNlbWFudGljcyBvZiBh IHN0YXRlLiAgSXQgaXMgYWJvdXQgc3RhdGlzdGljcy4NCldlIG5lZWQgYSBzZXBhcmF0ZSBwYXJh Z3JhcGggZm9yIHRoaXMuICBJIHN1Z2dlc3QgYWRkaW5nDQppdCBhZnRlciB0aGUgSUFOQSBwYXJh Z3JhcGggYmVsb3cuICBQbGVhc2UgZmluZCBhIHRleHQNCnByb3Bvc2FsIHRoZXJlLg0KDQo+UG93 ZXIgc3RhdGVzIGNhbiBiZSByZWdpc3RlcmVkIGF0IElBTkEgd2l0aCBhIGRlc2NyaXB0aW9uIG9m IHRoZWlyDQo+c2VtYW50aWNzLiAgQW4gRW5lcmd5IE9iamVjdCBtdXN0IGluZGljYXRlIHdoaWNo IHN1YnNldCBvZiBhbGwgcG93ZXINCj5zdGF0ZXMgaXQgaW1wbGVtZW50cy4NCg0KQmFzZWQgb24g Sm9obidzIGNvbW1lbnQgSSBzdWdnZXN0IGFwcGVuZGluZyB0aGUgZm9sbG93aW5nDQp0ZXh0IHRv IHRoZSBwcmV2aW91cyBwYXJhZ3JhcGg6DQoNCiAgICJQb3dlciBzdGF0ZXMgc2hvdWxkIGJlIHJl Z2lzdGVyZWQgYXQgSUFOQSB3aXRoIGEgbmFtZSBhbmQgYQ0KICAgIG51bWJlci4gICBXaGVuIHJl cXVlc3RpbmcgYW4gRW5lcmd5IG9iamVjdCB0byBlbnRlciBhIHBvd2VyDQogICAgc3RhdGUgYW4g aW5kaWNhdGlvbiBvZiBpdHMgbmFtZSBvciBpdHMgbnVtYmVyIGNhbiBiZSB1c2VkLiINCg0KVGhl biBhIG5ldyBwYXJhZ3JhcGggd291bGQgYmUgbmVlZGVkIGZvciBwb3dlciBzdGF0ZSBzdGF0aXN0 aWNzOg0KICAgIkZvciBzdXBwb3J0aW5nIHBvd2VyIHN0YXRlIG1hbmFnZW1lbnQgaXQgaXMgdXNl ZnVsIHRvIHByb3ZpZGUNCiAgICBzdGF0aXN0aWNzIG9uIHBvd2VyIHN0YXRlcyBpbmNsdWRpbmcg dGhlIHRpbWUgYW4gRW5lcmd5IE9iamVjdA0KICAgIHNwZW50IGluIGEgY2VydGFpbiBwb3dlciBz dGF0ZSBhbmQgdGhlIG51bWJlciBvZiB0aW1lcyBhbg0KICAgIEVuZXJneSBPYmplY3QgZW50ZXJl ZCBhIHBvd2VyIHN0YXRlLiINCg0KDQo+W2pwXSBXaGVuIHJlcXVlc3RpbmcgdG8gc2V0IHRvIGEg cG93ZXIgc3RhdGUgYW4gaW5kaWNhdGlvbiBvZiB0aGUgc3RhdGUNCj5ieSBuYW1lLCBvciBpbmRl eCBjYW4gYmUgdXNlZC4NCg0KQWdyZWVkLiAgSSB1c2VkIHlvdXIgdGV4dCBpbiB0aGUgcHJvcG9z YWwgdG8gYXBwZW5kIHRoZSBJQU5BDQpwYXJhZ3JhcGguDQoNCg0KPkFsc28gYSByZXF1ZXN0IHRv IGVudGVyIGEgc3RhdGUgYnkgbWF0Y2hpbmcgdGhlIGNsb3Nlc3QgYWJzb2x1dGUgb3INCj5yZWxh dGl2ZSBwb3dlciBjYW4gYmUgbWFkZS4NCg0KVGhpcyBzb3VuZHMgdmVyeSB1c2VmdWwuICBIb3dl dmVyLCAgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQNCnRoZSBob3cgaXQgd291bGQgd29yay4gIENv dWxkIHlvdSBlbGFib3JhdGUgb3IgZ2l2ZSBhbiBleGFtcGxlPw0KDQo+W2pwXSBOT1RFOiBJJ2Qg bGlrZSB1cyB0byBrZWVwIHRoZSBFTUFOIHBvd2VyIFN0YXRlcyB3ZSd2ZSBoYWQgaW4gdGhlDQo+ ZHJhZnQgZm9yIHNvbWUgdGltZSBub3cgaW4gYSBzZXBhcmF0ZSBzZWN0aW9uLiAgSSAgcmVjb21t ZW5kIHRoYXQgYXMgYW4NCj5JQU5BIHJlZ2lzdGVyZWQgc2V0IGFzIHdlIHBsYW5uZWQuIEkgaGF2 ZSBhbiBlY29zeXN0ZW0gKENpc2NvIEVuZXJneVdpc2UpDQo+b2YgbXVsdGlwbGUgdmVuZG9ycyBj dXJyZW50bHkgdXNpbmcgdGhlc2Ugc2luY2Ugd2UndmUgZm91bmQgdGhhdCB0aGUNCj5leGlzdGlu ZyBvbmVzIGhhZCBubyBvcGVyYXRpb25hbCBzdGF0ZXMgbGlrZSBsb3csIG1lZGl1bSBvciBoaWdo LiBBcyBhDQo+cmVwcmVzZW50YXRpdmUgb2YgdGhhdCBncm91cCwgdGhlIGluZHVzdHJpYWwgYXV0 b21hdGlvbiBPRFZBIGFuZCB3b3JraW5nDQo+d2l0aCBBU0hSRUEgd2UnZCBsaWtlIHRvIGhhdmUg dGhlc2UgZGVmaW5lZCBhcyBhIGNvbW1vbiBzZXQgaW4gSUFOQS4NCg0KSSB0aGluayBpdCBjb21t b25seSBhZ3JlZWQgdGhhdCB3ZSB3YW50IHRvIHN1cHBvcnQgY29uc29ydGlhDQpyZWdpc3Rlcmlu ZyB0aGVpciBhZ3JlZWQgcG93ZXIgc3RhdGVzIGF0IElBTkEuICBUaGF0J3MgbXVjaA0KYmV0dGVy IHRoYW4gaGF2aW5nIGV2ZXJ5IG9yZ2FuaXphdGlvbiByZWdpc3RlcmluZyB0aGVpciBvd24NCnN0 YXRlcy4gIEhvd2V2ZXIsIGhhdmluZyBhIHNpbmdsZSBjb21wYW55IHJlZ2lzdGVyaW5nIHBvd2Vy DQpzdGF0ZXMgc2hvdWxkIG5vdCBiZSBleGNsdWRlZC4NCg0KVGV4dCBleHBsYWluaW5nIHRoaXMg cHJvYmFibHkgbmVlZHMgdG8gZ28gdG8gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMNClNlY3Rpb24u DQoNClRoYW5rcywNCiAgICBKdWVyZ2VuDQoNCj5UaGFua3MhDQo+SnANCj4NCj4NCj4NCj5PbiAx MC4xMC4xMiAwOTozMiwgIkJydWNlIE5vcmRtYW4iIDxibm9yZG1hbkBsYmwuZ292PiB3cm90ZToN Cj4NCj4+V2UgaGF2ZSBzcGVudCBtdWNoIHRpbWUgdHJ5aW5nIHRvIGNsYXJpZnkgYW5kIGRpc2Vu dGFuZ2xlIHN0YXRlcyBhbmQNCj4+bGV2ZWxzIGZvciBkZXZpY2VzLiAgSXQgc2VlbXMgY2xlYXIg dGhhdCBzb21lIGFwcGxpY2F0aW9ucyBhbmQgc2V2ZXJhbA0KPj5leHRlcm5hbCBzdGFuZGFyZHMg cmVxdWlyZSBncmlkIGN1cnRhaWxtZW50IGxldmVscy4NCj4+U2V2ZXJhbCBsb25nLXN0YW5kaW5n IGluZHVzdHJ5IHN0YW5kYXJkcyBkZWZpbmUgZGV2aWNlIGludGVybmFsIHBvd2VyDQo+PnN0YXRl cy4NCj4+DQo+PkkgdG9vayB0aGUgcmVsZXZhbnQgc2VjdGlvbnMgb2YgdGhlIGZyYW1ld29yayBk cmFmdCwgYmVnaW5uaW5nIHdpdGgNCj4+Ni41LCBhbmQgYm9pbGVkIGRvd24gdGhlIHRleHQgdGhl cmUgdG8gd2hhdCBJIHRoaW5rIGNvdmVycyB3aGF0IHdlIG5lZWQuDQo+PlRoYXQgaXMgc2hvd24g YmVsb3cuICBUaGUgZXhpc3RpbmcgbGFuZ3VhZ2Ugd2FzIHJldGFpbmVkIGFzIG11Y2ggYXMNCj4+ cG9zc2libGUuICBJIGRpZCByZW1vdmUgcmVkdW5kYW50IHRleHQgYXMgd2VsbCBhcyBkZXRhaWxz IG91dHNpZGUgdGhlDQo+PnNjb3BlIG9mIHRoZSBmcmFtZXdvcmsgYW5kIHNvbWUgZGV0YWlscyBm cm9tIHRoZSBleHRlcm5hbCBzdGFuZGFyZHMuDQo+Pg0KPj5UaGUgaW50ZW50IHdhcyB0byBub3Qg Y2hhbmdlIHRoZSBtZWFuaW5nIG9mIHRoZXNlIHNlY3Rpb25zLCBqdXN0IHRoZQ0KPj5wcmVzZW50 YXRpb24sIGV4Y2VwdCB0byBjbGFyaWZ5IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gIHBvd2VyIHN0 YXRlcw0KPj5hbmQgY3VydGFpbG1lbnQgbGV2ZWxzLg0KPj4NCj4+DQo+PjYuNS4gUG93ZXIgU3Rh dGVzIEFuIEVuZXJneSBPYmplY3QgY2FuIGJlIGNvbnRyb2xsZWQgYnkgc2V0dGluZyBpdCB0byBh DQo+PnNwZWNpZmljIFBvd2VyIFN0YXRlIG9yIGEgc3BlY2lmaWMgQ3VydGFpbG1lbnQgTGV2ZWwg KHRoZXNlIGRlc2NyaWJlZA0KPj5pbiB0aGUgZm9sbG93aW5nIHNlY3Rpb24pLiAgQSBQb3dlciBT dGF0ZXMgU2V0IGlzIGFuIGludGVyZmFjZSBieSB3aGljaA0KPj5hbiBFbmVyZ3kgT2JqZWN0IGNh biBiZSBjb250cm9sbGVkLiAgRWFjaCBFbmVyZ3kgT2JqZWN0IHNob3VsZCBpbmRpY2F0ZQ0KPj50 aGUgUG93ZXIgU3RhdGUgU2V0cyB0aGF0IGl0IGltcGxlbWVudHMuICBXZWxsIGtub3duIFBvd2Vy IFN0YXRlIFNldHMNCj4+c2hvdWxkIGJlIHJlZ2lzdGVyZWQgd2l0aCBJQU5BIFdoZW4gYSBkZXZp Y2UgaXMgc2V0IHRvIGEgcGFydGljdWxhcg0KPj5Qb3dlciBTdGF0ZSwgaXQgbWF5IGJlIGJ1c3ku DQo+PlRoZSBkZXZpY2Ugd2lsbCBzZXQgdGhlIGRlc2lyZWQgUG93ZXIgU3RhdGUgYW5kIHRoZW4g dXBkYXRlIHRoZSBhY3R1YWwNCj4+UG93ZXIgU3RhdGUgd2hlbiBpdCBjaGFuZ2VzLiAgVGhlcmUg YXJlIHRodXMgdHdvIFBvd2VyIFN0YXRlIHZhcmlhYmxlczoNCj4+YWN0dWFsIGFuZCBkZXNpcmVk Lg0KPj5UaGVyZSBhcmUgbWFueSBleGlzdGluZyBzdGFuZGFyZHMNCj4+Zm9yIGFuZCBpbXBsZW1l bnRhdGlvbnMgb2YgUG93ZXIgU3RhdGUgU2V0cy4NCj4+QW4gRW5lcmd5IE9iamVjdCBjYW4gc3Vw cG9ydCBtdWx0aXBsZSBQb3dlciBTdGF0ZSBTZXRzIGNvbmN1cnJlbnRseS4NCj4+VGhpcyBmcmFt ZXdvcmsgaWRlbnRpZmllcyB0aHJlZSBpbml0aWFsIFBvd2VyIFN0YXRlIFNldHM6IElFRUUxNjIx DQo+PltJRUVFMTYyMV0sIERNVEYgW0RNVEZdLCBhbmQgUFdHIFtQV0ddLg0KPj42LjUuMSBJRUVF MTYyMSBQb3dlciBTdGF0ZSBTZXRJRUVFMTYyMSBbSUVFRTE2MjFdIGRlZmluZXMgdGhyZWUgYmFz aWMNCj4+cG93ZXIgc3RhdGVzIDogb24sIG9mZiwgYW5kIHNsZWVwLg0KPj42LjUuMiBETVRGIFBv d2VyIFN0YXRlIFNldERNVEYgW0RNVEZdIGJ1aWxkcyBvbiBBQ1BJIHN0YXRlcyBkZWZpbmVzIDYN Cj4+Y29yZSBwb3dlciBzdGF0ZXM6IE9uIChBQ1BJLVMwKSwgU2xlZXAtTGlnaHQgKEFDUEktUzEg b3IgoalTMiksDQo+PlNsZWVwLURlZXAgKEFDUEktUzQpLCBPZmYtSGFyZCAoQUNQSS1TNSksIE9m Zi1Tb2Z0IChBQ1BJLVM1KSwgYW5kDQo+PkhpYmVybmF0ZSAoQUNQSS1TNCkuICBJdCBhbHNvIGRl ZmluZXMgdHJhbnNpdGlvbmFsIHN0YXRlcyBhbmQgc3RhdGUNCj4+Y2hhbmdlIGNvbW1hbmRzOiBQ b3dlckN5Y2xlIE9mZi1Tb2Z0LCBQb3dlckN5Y2xlLCBNYXN0ZXJCdXMgcmVzZXQsDQo+PkRpYWdu b3N0aWMgSW50ZXJydXB0LCBPZmYtU29mdC1HcmFjZWZ1bCwgT2ZmLUhhcmQgR3JhY2VmdWwsIE1h c3RlckJ1cw0KPj5yZXNldCBHcmFjZWZ1bCwgUG93ZXItQ3ljbGUgT2ZmLVNvZnQgR3JhY2VmdWws IGFuZCBQb3dlckN5Y2xlLUhhcmQNCj4+R3JhY2VmdWwuICBUaGUgRE1URiBzdGFuZGFyZCBpcyB0 YXJnZXRlZCB0byBob3N0cyBhbmQgY29tcHV0ZXJzLg0KPj42LjUuMyBQV0cgUG93ZXIgU3RhdGUg U2V0VGhlIFByaW50ZXIgV29ya2luZyBHcm91cCBbUFdHXSBhbHNvIGJ1aWxkcyBvbg0KPj5BQ1BJ IHN0YXRlcyBkZWZpbmVzIDYgc3RhYmxlIHBvd2VyIHN0YXRlcywgYSBzZXJpZXMgb2YgRE1URiCp +HNwZWNpYWyp9w0KPj5wb3dlciBzdGF0ZXMsIGEgZmV3IG91dC1vZi1iYW5kIHBvd2VyIHN0YXRl cywgYW5kIHByb3Zpc2lvbiBmb3IgdmVuZG9yDQo+PmV4dGVuc2lvbnMgdG8gcG93ZXIgc3RhdGVz LiAgVGhlIERNVEYgc3RhbmRhcmQgaXMgdGFyZ2V0ZWQgdG8gcHJpbnRlcnMNCj4+YW5kIG90aGVy IGltYWdpbmcgZGV2aWNlcy4NCj4+IA0KPj42LjYgQ3VydGFpbG1lbnQgTGV2ZWxzRU1BTiBkZWZp bmVzIGN1cnRhaWxtZW50IGxldmVscyB0byBwcm92aWRlIGENCj4+c3RhbmRhcmQgYXBwcm9hY2gg dG8gbW9kZWwgdGhlIGRpZmZlcmVudCBsZXZlbHMgb2YgcG93ZXIgb2YgYSBkZXZpY2UuDQo+PlRo ZSBjdXJ0YWlsbWVudCBsZXZlbHMgaW5jb3Jwb3JhdGUgbm9uLW9wZXJhdGlvbmFsIHN0YXRlcyBh cyBkZWZpbmVkIGluDQo+PltBQ1BJXSBhbmQgW0RNVEZdIHN0YW5kYXJkcywgYW5kIHNwZWNpZnkg c2V2ZXJhbCBpbnRlcm1lZGlhdGUNCj4+b3BlcmF0aW9uYWwgc3RhdGVzLg0KPj5UaGVyZSBhcmUg dHdlbHZlIGN1cnRhaWxtZW50DQo+PmxldmVsczogc2l4IG9wZXJhdGlvbmFsIGFuZCBzaXggbm9u LW9wZXJhdGlvbmFsLiAgVGhlIGxvd2VzdA0KPj5ub24tb3BlcmF0aW9uYWwgbGV2ZWwgaXMgMSBh bmQgdGhlIGhpZ2hlc3QgaXMgNi4gIEVhY2ggbm9uLW9wZXJhdGlvbmFsDQo+PmxldmVsIGNvcnJl c3BvbmRzIHRvIGFuIEFDUEkgZ2xvYmFsIGFuZCBzeXN0ZW0gc3RhdGUuDQo+PkVhY2ggb3BlcmF0 aW9uYWwgc3RhdGUgcmVwcmVzZW50cyBhIHBlcmZvcm1hbmNlIHN0YXRlLCBhbmQgbWF5IGJlDQo+ Pm1hcHBlZCB0byBhbiBBQ1BJIHByb2Nlc3NvciBzdGF0ZS4NCj4+Rm9yIGVhY2ggbGV2ZWwsIHRo ZSBsZXZlbA0KPj5wcmVjZWRpbmcgaXQgaXMgZXhwZWN0ZWQgdG8gaGF2ZSBhIGxvd2VyIFBvd2Vy IHZhbHVlLiAgRm9yIGxldmVscyB3aGVyZQ0KPj50aGUgZGV2aWNlIGlzIG5vbi1vcGVyYXRpb25h bCwgaXQgaXMgZXhwZWN0ZWQgdGhhdCBpdCBoYXMgYSBsb25nZXINCj4+ZGVsYXkgaW4gcmV0dXJu aW5nIHRvIGFuIG9wZXJhdGlvbmFsIHN0YXRlLg0KPj5DaGFyYWN0ZXJpc3RpY3Mgb2YgY3VydGFp bG1lbnQNCj4+bGV2ZWxzIGFyZSBhcyBmb2xsb3dzLiAgRm9yIHRoZSBmaXJzdA0KPj5zaXgsIG5v IGVuZXJneSBvYmplY3QgZmVhdHVyZXMgYXJlIGF2YWlsYWJsZSwgZXhjZXB0IGZvciA0LCA1LCBh bmQgNiwNCj4+d2hpY2ggbWF5IGluY2x1ZGUgb3V0LW9mLWJhbmQgbWFuYWdlbWVudCBhbmQgZGV2 aWNlIHdha2V1cC4NCj4+bWVjaG9mZigxKTogTm8gZW5lcmd5IGlzIGNvbnN1bWVkLiAgVGhlIHBv d2VyIGNvbm5lY3RvciBjYW4gYmUgcmVtb3ZlZC4NCj4+Q29ycmVzcG9uZHMgdG8gQUNQSSBzdGF0 ZSBHMy4NCj4+c29mdG9mZigyKTogU29tZSBjb21wb25lbnRzDQo+PnJlbWFpbiBwb3dlcmVkLiAg Tm8gY29udGV4dCBpcyBzYXZlZC4gIFBvd2VyaW5nIHVwIHR5cGljYWxseSByZXF1aXJlcyBhDQo+ PnN5c3RlbSBib290Lg0KPj4gQ29ycmVzcG9uZHMgdG8gQUNQSSBzdGF0ZSBHMi9TNS4NCj4+aGli ZXJuYXRlKDMpOiBUaGUgZGV2aWNlIG1heSBiZSB3b2tlbg0KPj53aXRob3V0IHJlcXVpcmluZyBh IHN5c3RlbSBib290LiAgVGhlDQo+PnRpbWUgZm9yIGF2YWlsYWJpbGl0eSBpcyBsb25nZXIgdGhh biBzbGVlcCg0KS4gIENvcnJlc3BvbmRzIHRvIEFDUEkNCj4+c3RhdGUgRzEvUzQuDQo+PnNsZWVw KDQpOiBUaGUgdGltZSBmb3INCj4+YXZhaWxhYmlsaXR5IGlzIGxvbmdlciB0aGFuIHN0YW5kYnko NSkuICBDb3JyZXNwb25kcyB0byBBQ1BJIHN0YXRlDQo+PkcxL1MzLg0KPj5zdGFuZGJ5KDUpOiBU aGUgdGltZSBmb3INCj4+YXZhaWxhYmlsaXR5IGlzIGxvbmdlciB0aGFuIHJlYWR5KDYpLiAgQ29y cmVzcG9uZHMgdG8gQUNQSSBzdGF0ZSBHMS9TMi4NCj4+cmVhZHkoNik6ICBUaGUgZGV2aWNlIGNh biBiZSBxdWlja2x5IHRyYW5zaXRpb25lZCBpbnRvIGFuIG9wZXJhdGlvbmFsDQo+PnN0YXRlLiAg Q29ycmVzcG9uZHMgdG8gQUNQSSBzdGF0ZSBHMS9TMS4NCj4+Rm9yIGFsbCBvZiB0aGUgZm9sbG93 aW5nIGxldmVscywNCj4+c29tZSBmZWF0dXJlcyBtYXkgbm90IGJlIGF2YWlsYWJsZSBhbmQgcG93 ZXIgY29uc3VtcHRpb24gaXMgbGVzcyB0aGFuDQo+PmhpZ2hlciBudW1iZXJlZCBsZXZlbHMuICBB bGwgY29ycmVzcG9uZCB0byBBQ1BJIFMwLiAgVGhlIGhpZ2hlc3QgcG93ZXINCj4+Y29uc3VtcHRp b24gb2NjdXJzIGluIGhpZ2goMTIpLiAgVGhlc2UgbGV2ZWxzIGFyZTogIGxvd01pbnVzKDcpLA0K Pj5sb3coOCksIG1lZGl1bU1pbnVzKDkpLCBtZWRpdW0oMTApLCBoaWdoTWludXMoMTEpLCBhbmQg aGlnaCgxMikuDQo+PiANCj4+DQo+Pg0KPj4tLQ0KPj5CcnVjZSBOb3JkbWFuDQo+Pkxhd3JlbmNl IEJlcmtlbGV5IE5hdGlvbmFsIExhYm9yYXRvcnkNCj4+bm9yZG1hbi5sYmwuZ292IDxodHRwOi8v bm9yZG1hbi5sYmwuZ292PiBCTm9yZG1hbkBMQkwuZ292DQo+PjUxMC00ODYtNzA4OQ0KPj5tOiA1 MTAtNTAxLTc5NDMNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PmVtYW4gbWFpbGluZyBsaXN0DQo+PmVtYW5AaWV0Zi5vcmcNCj4+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbWFuDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5lbWFuIG1haWxpbmcgbGlzdA0KPmVt YW5AaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtYW4N Cg0K From internet-drafts@ietf.org Fri Oct 19 06:16:32 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603AB21F8632; Fri, 19 Oct 2012 06:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIn6CoEG1Nl1; Fri, 19 Oct 2012 06:16:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EBB21F85F7; Fri, 19 Oct 2012 06:16:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019131631.23306.94125.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 06:16:31 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:16:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Management (EMAN) Applicability Statement Author(s) : Brad Schoening Mouli Chandramouli Bruce Nordman Filename : draft-ietf-eman-applicability-statement-02.txt Pages : 30 Date : 2012-10-19 Abstract: The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework to a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-statement-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jparello@cisco.com Fri Oct 19 19:03:56 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779EB21F8834 for ; Fri, 19 Oct 2012 19:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, MANGLED_LOW=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZUsO3nKjkAU for ; Fri, 19 Oct 2012 19:03:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DCCE921F882B for ; Fri, 19 Oct 2012 19:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12894; q=dns/txt; s=iport; t=1350698634; x=1351908234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TBkz3h26FA1oYmVWPMrLHQXdtscX5JveYsDeUMXd7nU=; b=O8QMmnzkqe7fxjWUesEcHBRUYv2yXXyjpbWRQ9oz+x5dYHf2M+O+7oT5 cLdn8PNj/XH5H+yGXl/HQ5WG3GQVkpg+Rvl9NFhmDAP4kRPob2DjE9ua2 7R8hupln/D2+U1Y+1P7pYFPYgBhzULD/ib5hYyNzOTEkrnZVBkOfFDSbx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIMFglCtJV2c/2dsb2JhbABCA8ENgQiCIAEBAQMBAQEBDwFbAgkFBwQCAQgRBAEBAScHJwsUCQgCBA4FIodcBgucFZ9/i1obgyyCSGADiCWNSoEXjTaBa4Jv X-IronPort-AV: E=Sophos;i="4.80,618,1344211200"; d="scan'208";a="133602182" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 20 Oct 2012 02:03:54 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9K23sD8006286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Oct 2012 02:03:54 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 21:03:53 -0500 From: "John Parello (jparello)" To: Juergen Quittek Thread-Topic: [eman] States and Levels Thread-Index: AQHNprl9FpD1Zjnkkk2eYwFwTD+FU5e+EAiA///3Z9CAAtk0AIAAoDgM Date: Sat, 20 Oct 2012 02:03:53 +0000 Message-ID: <5DA16DBB-9C36-481A-84D0-2B88EA78ABAC@cisco.com> References: <9C213D38848B89428F46808B16F6F0860C75AC@xmb-aln-x04.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--72.570100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] States and Levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 02:03:56 -0000 Hi Juergen, Agree with your proposals below. The one item you asked for was an explanat= ion of asking for a power state change based on percent of maximum. See ashrae for setting curtailment. They have recognized that some device h= ave the ability to work at power levels,specified by percent of maximum. For example a light may have the simple on,off states but you can control i= t as a dimmer. If I ask to go to 0% of max it would turn off. If I ask for 50% of max it w= ould go to the on state. If I later ask for 100% of max it would still rema= in on. If this light were Poe powered and had the 5 predefined states, I should be= able to request lighting based on percentages the state should change to = the closest. So say there are 5 states define as state@maximum s.t.=20 {1@0W,2@15W,3@20W,4@25W,5@30w} .=20 I should be able to request the light to go,to 50% of maximum and it would = show the state as 2. If I ask for 51% of maximum it should show as 3. That allows control for variable devices as well. >From experience with our Cisco energy spec we only published states at firs= t and the variable control devices became a problem. So we went with the as= hrae type model as well to get this variable control. Industrial automatio= n has the same dual way of requesting control. An analogy would be a car radio. I can change the frequency value based on = a "dial" or based on a set of presets. Two ways of controlling the same thi= ng. I should be able to set the power based on preset states or a variable = "dial" based on percentages. If the device cannot support the variable power setting it can opt to go t= o the closet preset or ignore the request with error/info. Jp Sent from my iPad=20 (expect ridiculous spelling mistakes)=20 On Oct 19, 2012, at 4:31 AM, "Juergen Quittek" wrote: > Hi John, >=20 > I see your points. I tried to modify the proposed text > according to your comments. Please see inline. >=20 > On 17.10.12 23:12, "John Parello (jparello)" wrote: >=20 >> Hi Juergen, >>=20 >> Thanks so much for the concise proposal. I think that boils down what we >> have been discussing for quite some time into a clean statement. >>=20 >> I'd like to add a few things so see inline. If you agree or propose >> something better I can add this as the new section for this draft before >> the deadline Monday. >>=20 >> See below prefixed by [jp] >>=20 >> Jp >>=20 >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of >> Juergen Quittek >> Sent: Wednesday, October 17, 2012 9:31 AM >> To: Bruce Nordman; eman mailing list >> Subject: Re: [eman] States and Levels >>=20 >> >>=20 >>=20 >> 6.5. Power States >>=20 >> An Energy Object can be controlled by setting it to a specific Power >> State. An Object implements a set of power states consiting of al least >> two states, an on stae and an off state. >>=20 >> A Power State is an interface by which an Energy Object can be >> controlled. Each Energy Object should indicate the set of Power States >> that it implements. Well known Power States should be registered with >> IANA. When a device is set to a particular Power State, it may be busy. >> The device will set the desired Power State and then update the actual >> Power State when it changes. There are thus two Power State variables: >> actual and desired. >>=20 >> There are many existing standards for and implementations of Power Stats= . >> An Energy Object can support a mixed set of power states defined in >> different standards, A basic example is given by the three Power States >> defined in IEEE1621 [IEEE1621]: on, off, and sleep. >> The DMTF [DMTF], ACPI [ACPI], and PWG [PWG] define larger numbers of >> Power States. >>=20 >> The semantics of a power state is specified by either >> a) the functionality provided by an energy object in this state >> b) a limitation of the power that an energy object uses in this >> state >> c) a combination of a) and b) >>=20 >> The semantics of a power state should be clearly defined. Power >> limitation (curtailment) of the power used by an energy object in a stat= e >> can be specified by >> - an absolute power value >> - a percentage value of power relative to the energy object's >> nameplate power, >> - an indication of used power relative to another power state, >> for example, by stating used power in state A is less than in >> state B. >> [jp] Additional attributes like name, time in state, counters, time to >> enter and exit a state, can be specified. >=20 > Agreed. However, "time in state" is not specifying > semantics of a state. It is about statistics. > We need a separate paragraph for this. I suggest adding > it after the IANA paragraph below. Please find a text > proposal there. >=20 >> Power states can be registered at IANA with a description of their >> semantics. An Energy Object must indicate which subset of all power >> states it implements. >=20 > Based on John's comment I suggest appending the following > text to the previous paragraph: >=20 > "Power states should be registered at IANA with a name and a > number. When requesting an Energy object to enter a power > state an indication of its name or its number can be used." >=20 > Then a new paragraph would be needed for power state statistics: > "For supporting power state management it is useful to provide > statistics on power states including the time an Energy Object > spent in a certain power state and the number of times an > Energy Object entered a power state." >=20 >=20 >> [jp] When requesting to set to a power state an indication of the state >> by name, or index can be used. >=20 > Agreed. I used your text in the proposal to append the IANA > paragraph. >=20 >=20 >> Also a request to enter a state by matching the closest absolute or >> relative power can be made. >=20 > This sounds very useful. However, do not fully understand > the how it would work. Could you elaborate or give an example? >=20 >> [jp] NOTE: I'd like us to keep the EMAN power States we've had in the >> draft for some time now in a separate section. I recommend that as an >> IANA registered set as we planned. I have an ecosystem (Cisco EnergyWise= ) >> of multiple vendors currently using these since we've found that the >> existing ones had no operational states like low, medium or high. As a >> representative of that group, the industrial automation ODVA and working >> with ASHREA we'd like to have these defined as a common set in IANA. >=20 > I think it commonly agreed that we want to support consortia > registering their agreed power states at IANA. That's much > better than having every organization registering their own > states. However, having a single company registering power > states should not be excluded. >=20 > Text explaining this probably needs to go to the IANA considerations > Section. >=20 > Thanks, > Juergen >=20 >> Thanks! >> Jp >>=20 >>=20 >>=20 >> On 10.10.12 09:32, "Bruce Nordman" wrote: >>=20 >>> We have spent much time trying to clarify and disentangle states and >>> levels for devices. It seems clear that some applications and several >>> external standards require grid curtailment levels. >>> Several long-standing industry standards define device internal power >>> states. >>>=20 >>> I took the relevant sections of the framework draft, beginning with >>> 6.5, and boiled down the text there to what I think covers what we need= . >>> That is shown below. The existing language was retained as much as >>> possible. I did remove redundant text as well as details outside the >>> scope of the framework and some details from the external standards. >>>=20 >>> The intent was to not change the meaning of these sections, just the >>> presentation, except to clarify the difference between power states >>> and curtailment levels. >>>=20 >>>=20 >>> 6.5. Power States An Energy Object can be controlled by setting it to a >>> specific Power State or a specific Curtailment Level (these described >>> in the following section). A Power States Set is an interface by which >>> an Energy Object can be controlled. Each Energy Object should indicate >>> the Power State Sets that it implements. Well known Power State Sets >>> should be registered with IANA When a device is set to a particular >>> Power State, it may be busy. >>> The device will set the desired Power State and then update the actual >>> Power State when it changes. There are thus two Power State variables: >>> actual and desired. >>> There are many existing standards >>> for and implementations of Power State Sets. >>> An Energy Object can support multiple Power State Sets concurrently. >>> This framework identifies three initial Power State Sets: IEEE1621 >>> [IEEE1621], DMTF [DMTF], and PWG [PWG]. >>> 6.5.1 IEEE1621 Power State SetIEEE1621 [IEEE1621] defines three basic >>> power states : on, off, and sleep. >>> 6.5.2 DMTF Power State SetDMTF [DMTF] builds on ACPI states defines 6 >>> core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or =ADS2), >>> Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and >>> Hibernate (ACPI-S4). It also defines transitional states and state >>> change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset, >>> Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus >>> reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard >>> Graceful. The DMTF standard is targeted to hosts and computers. >>> 6.5.3 PWG Power State SetThe Printer Working Group [PWG] also builds on >>> ACPI states defines 6 stable power states, a series of DMTF =B3special= =B2 >>> power states, a few out-of-band power states, and provision for vendor >>> extensions to power states. The DMTF standard is targeted to printers >>> and other imaging devices. >>>=20 >>> 6.6 Curtailment LevelsEMAN defines curtailment levels to provide a >>> standard approach to model the different levels of power of a device. >>> The curtailment levels incorporate non-operational states as defined in >>> [ACPI] and [DMTF] standards, and specify several intermediate >>> operational states. >>> There are twelve curtailment >>> levels: six operational and six non-operational. The lowest >>> non-operational level is 1 and the highest is 6. Each non-operational >>> level corresponds to an ACPI global and system state. >>> Each operational state represents a performance state, and may be >>> mapped to an ACPI processor state. >>> For each level, the level >>> preceding it is expected to have a lower Power value. For levels where >>> the device is non-operational, it is expected that it has a longer >>> delay in returning to an operational state. >>> Characteristics of curtailment >>> levels are as follows. For the first >>> six, no energy object features are available, except for 4, 5, and 6, >>> which may include out-of-band management and device wakeup. >>> mechoff(1): No energy is consumed. The power connector can be removed. >>> Corresponds to ACPI state G3. >>> softoff(2): Some components >>> remain powered. No context is saved. Powering up typically requires a >>> system boot. >>> Corresponds to ACPI state G2/S5. >>> hibernate(3): The device may be woken >>> without requiring a system boot. The >>> time for availability is longer than sleep(4). Corresponds to ACPI >>> state G1/S4. >>> sleep(4): The time for >>> availability is longer than standby(5). Corresponds to ACPI state >>> G1/S3. >>> standby(5): The time for >>> availability is longer than ready(6). Corresponds to ACPI state G1/S2. >>> ready(6): The device can be quickly transitioned into an operational >>> state. Corresponds to ACPI state G1/S1. >>> For all of the following levels, >>> some features may not be available and power consumption is less than >>> higher numbered levels. All correspond to ACPI S0. The highest power >>> consumption occurs in high(12). These levels are: lowMinus(7), >>> low(8), mediumMinus(9), medium(10), highMinus(11), and high(12). >>>=20 >>>=20 >>>=20 >>> -- >>> Bruce Nordman >>> Lawrence Berkeley National Laboratory >>> nordman.lbl.gov BNordman@LBL.gov >>> 510-486-7089 >>> m: 510-501-7943 >>>=20 >>> _______________________________________________ >>> 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 >=20 From bnordman@lbl.gov Fri Oct 19 23:51:43 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0521F865C for ; Fri, 19 Oct 2012 23:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=-1.396, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iluqgjSMYvuB for ; Fri, 19 Oct 2012 23:51:42 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 897AE21F861D for ; Fri, 19 Oct 2012 23:51:42 -0700 (PDT) X-Ironport-SBRS: 2.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikGAJhIglDRVaDGemdsb2JhbABCAw6CPIMDAalvAYhzAYhTCCMBAQsJDAgUBCOCFyICCXoBAgVdEgEFASIBEggah2KdRQkDniGPIYMoA4hajRSBF41AFimDVF0 X-IronPort-AV: E=Sophos;i="4.80,619,1344236400"; d="scan'208";a="454829" Received: from mail-gh0-f198.google.com ([209.85.160.198]) by fe1.lbl.gov with ESMTP; 19 Oct 2012 23:51:37 -0700 Received: by mail-gh0-f198.google.com with SMTP id g21so2731011ghb.5 for ; Fri, 19 Oct 2012 23:51:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=O4tAm4rv+4v+GIKkyl6ft6Iwi2i82GsuyV8l9yd3CsE=; b=ma7Db3ufTeGge3pLR0xvGwlU9xSLsKXDFpwnIGm1oq6mY3YszGW0i1/rqFaAh1VtJf MSOrX9EjxgRO8x1SmkgZhyT7tA+DODc8cqQ2DmA7P4oAI02Z8kkIcmDqJbS22GdObGYd 0X2xU2gDGQ4mpyRMvjq+Dayn78Pg22RmDCT9gO1cC+euhOM9zPslXrVY7sD2VtKkRBpy j9IX9X3U4mYBMtKEAQBxgDD+WIKc4zZPYLr3JOSzFctOLm5YLtd//dbv2/eAebfvFCh0 BAwCgC7hW+lTmcS2jf10GRxZvYuznF4AgqRPj6zp1RdAMhzTi4oggOdjEXcjij6cX9Oe RO6w== Received: by 10.220.157.15 with SMTP id z15mr4460290vcw.38.1350715896950; Fri, 19 Oct 2012 23:51:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.157.15 with SMTP id z15mr4460286vcw.38.1350715896874; Fri, 19 Oct 2012 23:51:36 -0700 (PDT) Received: by 10.58.125.73 with HTTP; Fri, 19 Oct 2012 23:51:36 -0700 (PDT) Date: Fri, 19 Oct 2012 23:51:36 -0700 Message-ID: From: Bruce Nordman To: eman mailing list , Nevil Brownlee Content-Type: multipart/alternative; boundary=f46d043bdf4c39c68404cc780dc3 X-Gm-Message-State: ALoCoQkeVygfTVRFWxEgvJ9fKPVh/5vq2Dnn7L5SXig1YwRuF4YzrqGNFmoPxGtfRiEHNVc3hdP0HYn9Y3a7hZhzPEehpvdc31NT4BRKujDCv7xRBnSw/xRYIjuzDDm1g7e0OJt926mY Subject: [eman] Call for EMAN agenda items X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 06:51:43 -0000 --f46d043bdf4c39c68404cc780dc3 Content-Type: text/plain; charset=ISO-8859-1 The EMAN agenda will include all charter drafts. If you have any proposals for additional agenda items, please send them to Nevil and myself. Thanks, --Bruce -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --f46d043bdf4c39c68404cc780dc3 Content-Type: text/html; charset=ISO-8859-1 The EMAN agenda will include all charter drafts.
If you have any proposals for additional agenda items,
please send them to Nevil and myself.
Thanks,
--Bruce

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

--f46d043bdf4c39c68404cc780dc3-- From trac+eman@trac.tools.ietf.org Sun Oct 21 16:57:17 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9837521F8A47 for ; Sun, 21 Oct 2012 16:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpcnuUVmq68G for ; Sun, 21 Oct 2012 16:57:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id DDA1E21F8A41 for ; Sun, 21 Oct 2012 16:57:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:40103 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TQ5O7-0007gd-Qr; Mon, 22 Oct 2012 01:56:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bclaise@cisco.com, jparello@cisco.com X-Trac-Project: eman Date: Sun, 21 Oct 2012 23:56:59 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/6#comment:2 Message-ID: <079.e7a1950a786fafad0f2b8e3cbe757aec@trac.tools.ietf.org> References: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bclaise@cisco.com, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #6: States and ASHRAE Curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 23:57:17 -0000 #6: States and ASHRAE Curtailment levels Comment (by jparello@…): Proposed Text: 6.5. Power States An Energy Object can be controlled by setting it to a specific Power State. An Object implements a set of Power States consiting of at least two states, an on state and an off state. A Power State is an interface by which an Energy Object can be controlled. Each Energy Object should indicate the set of Power States that it implements. Well known Power States / Sets should be registered with IANA. When a device is set to a particular Power State, it may be busy. The device will set the desired Power State and then update the actual Power State when it changes. There are then two types of Power State control variables: actual and desired. There are many existing standards for and implementations of Power States. An Energy Object can support a mixed set of Power States defined in different standards. A basic example is given by the three Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF], ACPI [ACPI], and PWG [PWG] define larger numbers of Power States. The semantics of a power state is specified by a) the functionality provided by an Energy Object in this state, b) a limitation of the power that an Energy Object uses in this state, c) a combination of a) and b) The semantics of a Power State should be clearly defined. Limitation (curtailment) of the power used by an Energy Object in a state can be specified by - an absolute power value - a percentage value of power relative to the energy object's nameplate power - an indication of used power relative to another power state - for example by stating used power in state A is less than in state B. For supporting Power State management it is useful to provide statistics on Power States including the time an Energy Object spent in a certain Power State and/or the number of times an Energy Object entered a power state. Power states should be registered at IANA with a name and a number. When requesting an Energy object to enter a Power State an indication of its name or its number can be used. Optionally an absolute or percentage of Nameplate Power can be provided to allow the Energy Object to transition to a nearest or equivalent Power State. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Sun Oct 21 20:46:41 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4921F21F8908 for ; Sun, 21 Oct 2012 20:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyjPSY7D-mrN for ; Sun, 21 Oct 2012 20:46:40 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A20D721F88DC for ; Sun, 21 Oct 2012 20:46:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:60722 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TQ8y8-0004YV-CO; Mon, 22 Oct 2012 05:46:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Mon, 22 Oct 2012 03:46:24 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/4#comment:4 Message-ID: <079.275533f07164523436b451a66f771423@trac.tools.ietf.org> References: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #4: Reorganise sections X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 03:46:41 -0000 #4: Reorganise sections Comment (by jparello@…): Minor: Fixed section numbering and outline. Moved relationship text out of state section. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From jparello@cisco.com Sun Oct 21 21:20:45 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056F621F8B17 for ; Sun, 21 Oct 2012 21:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.909 X-Spam-Level: X-Spam-Status: No, score=-9.909 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csDjw66vEpiE for ; Sun, 21 Oct 2012 21:20:44 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 384AB21F8B10 for ; Sun, 21 Oct 2012 21:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2418; q=dns/txt; s=iport; t=1350879644; x=1352089244; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=U0vKpktuH0jNwwXixcEfN9Zacsf/9YnngerLTqJT4II=; b=Nflnh+kF6kYZwdqsTMN363w533e9rTcSoZ5HCrUeWKVzSAusi3SeRCg4 Sf6KXGkdInDnVdnAGSWGxKby5hokQnaYVNugvIMWCYsHj4eW/eGpCkiZc JVD7nXzj1Fw3JMomEAwgs0thTmkI6Zs0MlpVSsLsfZNeQiUHa1gf5cMqP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAA/JhFCtJV2a/2dsb2JhbABEhhS5fXqBCIIgAQEBBBIBEBFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBGYdhAQubKY0hkXCBIIo/G4VCMmADlwiNN4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="133978578" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2012 04:20:43 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9M4Kh7Y030193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 04:20:43 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Sun, 21 Oct 2012 23:20:43 -0500 From: "John Parello (jparello)" To: "eman@ietf.org" Thread-Topic: New Version Notification for draft-parello-eman-definitions-07.txt Thread-Index: AQHNsAwLAxS3/vC3SUa+nCEls96tiZfEuBNw Date: Mon, 22 Oct 2012 04:20:43 +0000 Message-ID: <9C213D38848B89428F46808B16F6F0860C94C5@xmb-aln-x04.cisco.com> References: <20121022041636.7000.88146.idtracker@ietfa.amsl.com> In-Reply-To: <20121022041636.7000.88146.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19292.004 x-tm-as-result: No--30.550100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [eman] FW: New Version Notification for draft-parello-eman-definitions-07.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 04:20:45 -0000 SEksDQoNCkkgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRlZmluaXRpb25zLg0KDQpUaGUg b25seSBjaGFuZ2Ugd2FzIGEgbWlub3IgZWRpdCBvbiBOYW1lcGxhdGUgUG93ZXIgc3RhdGluZyBp dCBpcyB0aGUgbm9taW5hbCBwb3dlciBhcyBzcGVjaWZpZWQgYnkgYSBtYW51ZmFjdHVyZXIuDQoN ClRoaXMgZHJhZnQgaXMgYmVjb21pbmcgcXVpZXNjZW50IHNvIHRoaXMgaXMgcHJvbWlzaW5nIGZv ciB0aGUgZW50aXJlIHNldCBvZiBkcmFmdHMuDQoNClRoYW5rcw0KSnANCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFN1bmRheSwgT2N0b2JlciAyMSwgMjAx MiA5OjE3IFBNDQpUbzogSm9obiBQYXJlbGxvIChqcGFyZWxsbykNClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGFyZWxsby1lbWFuLWRlZmluaXRpb25zLTA3LnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wYXJlbGxvLWVtYW4tZGVmaW5pdGlv bnMtMDcudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEpvaG4gUGFyZWxs byBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQt cGFyZWxsby1lbWFuLWRlZmluaXRpb25zDQpSZXZpc2lvbjoJIDA3DQpUaXRsZToJCSBFbmVyZ3kg TWFuYWdlbWVudCBUZXJtaW5vbG9neQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMjENCldHIElE OgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNw0KVVJMOiAgICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wYXJlbGxv LWVtYW4tZGVmaW5pdGlvbnMtMDcudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGFyZWxsby1lbWFuLWRlZmluaXRpb25zDQpIdG1saXpl ZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhcmVsbG8tZW1hbi1k ZWZpbml0aW9ucy0wNw0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1wYXJlbGxvLWVtYW4tZGVmaW5pdGlvbnMtMDcNCg0KQWJzdHJhY3Q6DQog ICAgICAgIFRoaXMgZG9jdW1lbnQgY29udGFpbnMgZGVmaW5pdGlvbnMgYW5kIHRlcm1zIHVzZWQg aW4NCiAgICAgICAgdGhlIEVuZXJneSBNYW5hZ2VtZW50IFdvcmtpbmcgR3JvdXAuIEVhY2ggdGVy bQ0KICAgICAgICBjb250YWlucyBhIGRlZmluaXRpb24ocyksIGV4YW1wbGUsIGFuZCByZWZlcmVu Y2UgdG8gYQ0KICAgICAgICBub3JtYXRpdmUsIGluZm9ybWF0aXZlIG9yIHdlbGwga25vdyBzb3Vy Y2UuIFRlcm1zDQogICAgICAgIG9yaWdpbmF0aW5nIGluIHRoaXMgZHJhZnQgc2hvdWxkIGJlIGVp dGhlciBjb21wb3NlZCBvZg0KICAgICAgICBvciBhZGFwdGVkIGZyb20gb3RoZXIgdGVybXMgaW4g dGhlIGRyYWZ0IHdpdGggYQ0KICAgICAgICBzb3VyY2UuIFRoZSBkZWZpbmVkIHRlcm1zIHdpbGwg dGhlbiBiZSB1c2VkIGluIG90aGVyDQogICAgICAgIGRyYWZ0cyBhcyBkZWZpbmVkIGhlcmUuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From internet-drafts@ietf.org Sun Oct 21 22:02:27 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1156E21F8B3A; Sun, 21 Oct 2012 22:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1kIVGlfWlW4; Sun, 21 Oct 2012 22:02:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8AE21F8B33; Sun, 21 Oct 2012 22:02:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022050226.26606.35728.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 22:02:26 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-framework-06.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 05:02:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Management Framework Author(s) : Benoit Claise John Parello Brad Schoening Juergen Quittek Bruce Nordman Filename : draft-ietf-eman-framework-06.txt Pages : 70 Date : 2012-10-21 Abstract: This document defines a framework for providing Energy Management for devices within or connected to communication networks, and components thereof. The framework defines an Energy Management Domain as a set of Energy Objects, for which each Energy Object is identified, classified and given context. Energy Objects can be monitored and/or controlled with respect to Power, Power State, Energy, Demand, Power Quality, and battery. Additionally the framework models relationships and capabilities between Energy Objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-framework-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-framework-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jparello@cisco.com Sun Oct 21 22:08:42 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD5D21F8B28 for ; Sun, 21 Oct 2012 22:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.024 X-Spam-Level: X-Spam-Status: No, score=-10.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7pkzwkgGlz7 for ; Sun, 21 Oct 2012 22:08:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A1D0D21F88FE for ; Sun, 21 Oct 2012 22:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2398; q=dns/txt; s=iport; t=1350882521; x=1352092121; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=559Z1JD88+pmW/mY4wGoURl1xhiN921du4IwVPT2jT4=; b=dAxZ6G7/9bcXbrXXEDoQMiuGYKvkf7qVjI6bzysaYUVAw9/BblbKVM+J I8ZASZh1BHFEvkEx2Q/q6xnC0TD9E+GEQDcSmW+vwAMiKV8K+RbA9yVpD VovZDuPwOAERmHihn7kBv72pHT1qzKhM8VxnJ7ZpgZCA3UwDZkpLobuzO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACDUhFCtJV2Y/2dsb2JhbABEwQuBCIIgAQEBBAEBAQ8BJzQEEwQCAQgRBAEBCxQJBycLFAcBAQUDAgQTCAEZh2EBC5sxnxWLXwUWCYVrYAOXCI03gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="133944576" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 22 Oct 2012 05:08:24 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9M58OAJ026196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 05:08:24 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 00:08:24 -0500 From: "John Parello (jparello)" To: "eman@ietf.org" Thread-Topic: [eman] I-D Action: draft-ietf-eman-framework-06.txt Thread-Index: AQHNsBJ+1A8IT1QcBEa9Bf3zlbX24JfExUtw Date: Mon, 22 Oct 2012 05:08:23 +0000 Message-ID: <9C213D38848B89428F46808B16F6F0860C94F9@xmb-aln-x04.cisco.com> References: <20121022050226.26606.35728.idtracker@ietfa.amsl.com> In-Reply-To: <20121022050226.26606.35728.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--21.989700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] FW: I-D Action: draft-ietf-eman-framework-06.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 05:08:42 -0000 Hi, New version of the framework have been uploaded. We are tracking issues and changes in the issues tool so see this link for = details: http://trac.tools.ietf.org/wg/eman/trac/report/1 We will mark items closed this week. Major change is the inclusion of the simplified Power State text we have be= en discussing on the list.=20 http://trac.tools.ietf.org/wg/eman/trac/ticket/6 Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Sunday, October 21, 2012 10:02 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-framework-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Management Framework Author(s) : Benoit Claise John Parello Brad Schoening Juergen Quittek Bruce Nordman Filename : draft-ietf-eman-framework-06.txt Pages : 70 Date : 2012-10-21 Abstract: This document defines a framework for providing Energy Management for devices within or connected to communication networks, and components thereof. The framework defines an Energy Management Domain as a set of Energy Objects, for which each Energy Object is identified, classified and given context. Energy Objects can be monitored and/or controlled with respect to Power, Power State, Energy, Demand, Power Quality, and battery. Additionally the framework models relationships and capabilities between Energy Objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-framework-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-framework-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From jparello@cisco.com Sun Oct 21 22:12:19 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7E221F8908 for ; Sun, 21 Oct 2012 22:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.106 X-Spam-Level: X-Spam-Status: No, score=-10.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfN7AKEyh1ML for ; Sun, 21 Oct 2012 22:12:18 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C588D21F8906 for ; Sun, 21 Oct 2012 22:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2842; q=dns/txt; s=iport; t=1350882738; x=1352092338; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=G/uGEvGKVW4/5Klv1hVA/IlOA7mr1WxqDCPWKzQEB4M=; b=kGsHUpDcDM69dZCB5XTWo1011vjh6zzhKhkFsBDINrPnmSR8TRlwLCtQ 2yvcZskSXoAh/aqSyV4FLJqVMbAeDrnqfIrGg/6sLSG94CaAW5QPJwduk AYtrxpN5DK/JgvHLCWtQv+YKTKj1JRfkWFWZizpGQ4YVWldSAMYLb3So3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFALzUhFCtJXHA/2dsb2JhbABEhhS5fXqBCIIgAQEBBBIBEBE+BQ4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIARmHUAMOAQubMo0hkXSBIIlWaQUWCYU5MmADlwiNN4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="133949055" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 22 Oct 2012 05:12:18 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9M5CIkW024088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 05:12:18 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 00:12:17 -0500 From: "John Parello (jparello)" To: "eman@ietf.org" Thread-Topic: New Version Notification for draft-ietf-eman-framework-06.txt Thread-Index: AQHNsBJwZtGGkKFjJkiABQw5vxXlDpfEx2BA Date: Mon, 22 Oct 2012 05:12:16 +0000 Message-ID: <9C213D38848B89428F46808B16F6F0860C950F@xmb-aln-x04.cisco.com> References: <20121022050226.26606.26539.idtracker@ietfa.amsl.com> In-Reply-To: <20121022050226.26606.26539.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--19.770200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [eman] FW: New Version Notification for draft-ietf-eman-framework-06.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 05:12:19 -0000 TmV3IHZlcnNpb24gb2YgdGhlIGZyYW1ld29yayBoYXMgYmVlbiB1cGxvYWRlZC4NCg0KV2UgYXJl IHRyYWNraW5nIGlzc3VlcyBhbmQgY2hhbmdlcyBpbiB0aGUgaXNzdWVzIHRvb2wgc28gc2VlIHRo aXMgbGluayBmb3IgZGV0YWlsczoNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2VtYW4v dHJhYy9yZXBvcnQvMQ0KV2Ugd2lsbCBtYXJrIGl0ZW1zIGNsb3NlZCB0aGlzIHdlZWsuDQoNCk1h am9yIGNoYW5nZSBpcyB0aGUgaW5jbHVzaW9uIG9mIHRoZSBzaW1wbGlmaWVkIFBvd2VyIFN0YXRl IHRleHQgd2UgaGF2ZSBiZWVuIGRpc2N1c3Npbmcgb24gdGhlIGxpc3QuIA0KaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvd2cvZW1hbi90cmFjL3RpY2tldC82DQoNCkpwDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTdW5kYXksIE9jdG9iZXIgMjEsIDIw MTIgMTA6MDIgUE0NClRvOiBKb2huIFBhcmVsbG8gKGpwYXJlbGxvKQ0KQ2M6IEJlbm9pdCBDbGFp c2UgKGJjbGFpc2UpOyBicmFkLnNjaG9lbmluZ0B2ZXJpem9uLm5ldDsgYm5vcmRtYW5AbGJsLmdv djsgcXVpdHRla0BuZXRsYWIubmVjLmRlDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtZW1hbi1mcmFtZXdvcmstMDYudHh0DQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWlldGYtZW1hbi1mcmFtZXdvcmstMDYudHh0IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9obiBQYXJlbGxvIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1pZXRmLWVtYW4tZnJhbWV3b3JrDQpSZXZp c2lvbjoJIDA2DQpUaXRsZToJCSBFbmVyZ3kgTWFuYWdlbWVudCBGcmFtZXdvcmsNCkNyZWF0aW9u IGRhdGU6CSAyMDEyLTEwLTIxDQpXRyBJRDoJCSBlbWFuDQpOdW1iZXIgb2YgcGFnZXM6IDcwDQpV Ukw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtZW1hbi1mcmFtZXdvcmstMDYudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1lbWFuLWZyYW1ld29yaw0KSHRtbGl6ZWQ6 ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVtYW4tZnJhbWV3 b3JrLTA2DQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtZW1hbi1mcmFtZXdvcmstMDYNCg0KQWJzdHJhY3Q6DQogICAgICAgIFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBhIGZyYW1ld29yayBmb3IgcHJvdmlkaW5nIEVuZXJneQ0KICAgICAg ICBNYW5hZ2VtZW50IGZvciBkZXZpY2VzIHdpdGhpbiBvciBjb25uZWN0ZWQgdG8gY29tbXVuaWNh dGlvbg0KICAgICAgICBuZXR3b3JrcywgYW5kIGNvbXBvbmVudHMgdGhlcmVvZi4gIFRoZSBmcmFt ZXdvcmsgZGVmaW5lcyBhbg0KICAgICAgICBFbmVyZ3kgTWFuYWdlbWVudCBEb21haW4gYXMgYSBz ZXQgb2YgRW5lcmd5IE9iamVjdHMsIGZvciB3aGljaA0KICAgICAgICBlYWNoIEVuZXJneSBPYmpl Y3QgaXMgaWRlbnRpZmllZCwgY2xhc3NpZmllZCBhbmQgZ2l2ZW4NCiAgICAgICAgY29udGV4dC4g ICBFbmVyZ3kgT2JqZWN0cyBjYW4gYmUgbW9uaXRvcmVkIGFuZC9vciBjb250cm9sbGVkDQogICAg ICAgIHdpdGggcmVzcGVjdCB0byBQb3dlciwgUG93ZXIgU3RhdGUsIEVuZXJneSwgRGVtYW5kLCBQ b3dlcg0KICAgICAgICBRdWFsaXR5LCBhbmQgYmF0dGVyeS4gIEFkZGl0aW9uYWxseSB0aGUgZnJh bWV3b3JrIG1vZGVscw0KICAgICAgICByZWxhdGlvbnNoaXBzIGFuZCBjYXBhYmlsaXRpZXMgYmV0 d2VlbiBFbmVyZ3kgT2JqZWN0cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From moulchan@cisco.com Sun Oct 21 22:53:46 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD44221F8B57 for ; Sun, 21 Oct 2012 22:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyJ0lHNWrC6U for ; Sun, 21 Oct 2012 22:53:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 227FD21F8B37 for ; Sun, 21 Oct 2012 22:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2634; q=dns/txt; s=iport; t=1350885226; x=1352094826; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NzQOMGB7IKfkUm8Bg+nww9PmUh/LkTwC7VRS731EqOw=; b=jZ5N7cZ6A9D44C5plsOgogt6axJdsDcwOrOw9HlIrdbW9ZIO61o2Vp9E l5iP1yH9kv3DqFq0DdjUmlx8kNjmWFjeJm1E/4yYGX1umQToLAq32THzx om6LWhsVDKgZ6O1T+BMKtTygmUvHF+uLgqRV1nG2aPok/0tbm3+nzwBS0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH/ehFCtJXHB/2dsb2JhbABEwQyBCIIgAQEBBAEBAQ8BJzQEEwQCAQgRBAEBCxQJBycLFAkIAgQTCAEZh2ILmzmfGotfGoV1YAOXCI03gWuCb4FjNQ X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="133954422" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 22 Oct 2012 05:53:45 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9M5rjvt028719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 05:53:45 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 00:53:45 -0500 From: "Mouli Chandramouli (moulchan)" To: "eman@ietf.org" Thread-Topic: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt Thread-Index: AQHNrfwPRGcxBDPT00ONe2JSs+H455fE1LIw Date: Mon, 22 Oct 2012 05:53:44 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E2F03@xmb-rcd-x08.cisco.com> References: <20121019131631.23306.94125.idtracker@ietfa.amsl.com> In-Reply-To: <20121019131631.23306.94125.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--26.373500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 05:53:46 -0000 Hello all,=20 An updated version of the applicability statement has been submitted.=20 Several editorial changes to improve the readability of the draft and also = consolidating the section on the related standards from the requirements to= applicability statement=20 http://www.ietf.org/mail-archive/web/eman/current/msg01595.html The only remaining open issue is - the applicability of ASHRAE 201P standa= rds to EMAN. Are any concepts that can be reused ?=20 which we hope address after the WG meeting.=20 Please send your comments.=20 Thanks Brad, Bruce and Mouli=20 -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, October 19, 2012 6:47 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-applicability-statement-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Management (EMAN) Applicability Statement Author(s) : Brad Schoening Mouli Chandramouli Bruce Nordman Filename : draft-ietf-eman-applicability-statement-02.txt Pages : 30 Date : 2012-10-19 Abstract: The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework to a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-applicability-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-applicability-statement-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Sun Oct 21 23:23:15 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2181321F8B91 for ; Sun, 21 Oct 2012 23:23:15 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVxQ26d8-PMf for ; Sun, 21 Oct 2012 23:23:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 552A321F8480 for ; Sun, 21 Oct 2012 23:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2320; q=dns/txt; s=iport; t=1350886994; x=1352096594; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iWHM/pAktLcjd+WKjfuTPcHaJiXeQ2e3740WemqvQo8=; b=QemhadGB0cLx2oWn/Ls7HGzzxZ6nLxM7AVefejfv0UZdpoIHGfObjHiu zlxu2DuFMfLzqjbHaKs0P2VoZYF63D0u/yNcDBIrzEgP/X5EOndT+xkJq Is44MYr4/jEitREqiz5Sx7yoMohzDQDyKXzstwgV4uPTtFvrAhhBic/ZZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPnkhFCtJV2a/2dsb2JhbABFwQyBCIIgAQEBBAEBAQ8BJzQEEwQCAQgRBAEBCxQJBycLFAkIAgQTCAEZh2ILmzyfGYtfhg9gA5cIjTeBa4Jvghg X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="133992608" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2012 06:23:14 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9M6NDQx025932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 06:23:13 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 01:23:13 -0500 From: "Mouli Chandramouli (moulchan)" To: "eman@ietf.org" Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-07.txt Thread-Index: AQHNreCjF0WXy1BwOUyuz3KtOlQF6JfE3bbA Date: Mon, 22 Oct 2012 06:23:12 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E2F8E@xmb-rcd-x08.cisco.com> References: <20121019100042.20878.30581.idtracker@ietfa.amsl.com> In-Reply-To: <20121019100042.20878.30581.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--36.764100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-07.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 06:23:15 -0000 Hello all,=20 An updated version of the Energy Aware MIB has been submitted.=20 A couple significant updates - =20 1. closed the open issue - persistence is only applied to read-write MIB ob= ject and not use the global persistence with eoTablePersistence. (this is = in reference to the comment of Juergen Quittek)=20 2. Updated the Energy Aware MIB module reusing entPhysicalUUID MIB object f= rom the ENTITY-MIB v4 http://tools.ietf.org/html/draft-ietf-eman-rfc4133bis= -03 and=20 Conformance to ENTITY MIB using the compliance of entity4CRCompliance a= s also specified Please provide comments.=20 Thanks John, Benoit and Mouli=20 -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, October 19, 2012 3:31 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-energy-aware-mib-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Energy Object Context MIB Author(s) : John Parello Benoit Claise Mouli Chandramouli Filename : draft-ietf-eman-energy-aware-mib-07.txt Pages : 34 Date : 2012-10-19 Abstract: This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the relationships between reporting devices, remote devices, and monitoring devices. =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-aware-mib-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From internet-drafts@ietf.org Mon Oct 22 02:51:57 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6782B21F855C; Mon, 22 Oct 2012 02:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSVxoTJqRxKZ; Mon, 22 Oct 2012 02:51:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF74221F895A; Mon, 22 Oct 2012 02:51:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022095156.6787.25662.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 02:51:56 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-04.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:51:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Power and Energy Monitoring MIB Author(s) : Mouli Chandramouli Brad Schoening Juergen Quittek Thomas Dietz Benoit Claise Filename : draft-ietf-eman-energy-monitoring-mib-04.txt Pages : 82 Date : 2012-10-22 Abstract: This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. = The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-monitoring-mib-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From moulchan@cisco.com Mon Oct 22 03:01:08 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5165121F89FD for ; Mon, 22 Oct 2012 03:01:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlxhGkcVPi+n for ; Mon, 22 Oct 2012 03:01:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 97F5121F851F for ; Mon, 22 Oct 2012 03:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2121; q=dns/txt; s=iport; t=1350900067; x=1352109667; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aHaWMB50+HzOE7qapPJG30FAfzYTEUOnc4q70Qfm/2Y=; b=CKf6g6zcRjsxG6ULLjedXbThuszktuAubT/zj2z7GX1O0F+nV4gvW8F+ V2+8PnBUhLjeuhWfJGN0BIXrsS9TSdzmTcxGfd64Wu7OlI1wyBOralVAp uejWcXY5I6wezm1b+NiddO4VNVn3ujlHE24JPlmKZNQxwbCELYuALyNtX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJEYhVCtJV2Z/2dsb2JhbABFwQyBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIARmHYgubWZ8ni18bhXRgA5cIjTeBa4Jvghg X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="134042871" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2012 10:01:07 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9MA17t0021878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 10:01:07 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 05:01:06 -0500 From: "Mouli Chandramouli (moulchan)" To: "eman@ietf.org" Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-04.txt Thread-Index: AQHNsDr2mjCncfZ3VEewRNJMX1UCMZfFFZnA Date: Mon, 22 Oct 2012 10:01:06 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E3209@xmb-rcd-x08.cisco.com> References: <20121022095156.6787.25662.idtracker@ietfa.amsl.com> In-Reply-To: <20121022095156.6787.25662.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--31.261900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-04.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:01:08 -0000 Hello all,=20 An updated version of the Monitoring MIB draft has been submitted.=20 The updates are -=20 - Updating the Monitoring MIB in compliance to ENTITY MIB v4 using the comp= liance of entity4CRCompliance specified for Energy objects.=20 - expanding the abbreviated name of the Table and objects in the table as e= oACPwrCharacteristicsTable=20 Once the requirements are baselined, this draft is almost complete.=20 Please provide comments.=20 Thanks Brad, Juergen, Thomas, Benoit and Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Monday, October 22, 2012 3:22 PM To: i-d-announce@ietf.org Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Power and Energy Monitoring MIB Author(s) : Mouli Chandramouli Brad Schoening Juergen Quittek Thomas Dietz Benoit Claise Filename : draft-ietf-eman-energy-monitoring-mib-04.txt Pages : 82 Date : 2012-10-22 Abstract: This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-energy-monitoring-mib-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From internet-drafts@ietf.org Mon Oct 22 13:26:03 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C259421F8949; Mon, 22 Oct 2012 13:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir+rw4DUGjRY; Mon, 22 Oct 2012 13:26:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6800D21F8972; Mon, 22 Oct 2012 13:26:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022202601.24058.73317.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 13:26:01 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action: draft-ietf-eman-battery-mib-07.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 20:26:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Energy Management Working Group of the IE= TF. Title : Definition of Managed Objects for Battery Monitoring Author(s) : Juergen Quittek Rolf Winter Thomas Dietz Filename : draft-ietf-eman-battery-mib-07.txt Pages : 30 Date : 2012-10-22 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eman-battery-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eman-battery-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eman-battery-mib-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bnordman@lbl.gov Mon Oct 22 22:34:22 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA20321F856C for ; Mon, 22 Oct 2012 22:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.964 X-Spam-Level: X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=-0.988, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDSxgNc9-NRW for ; Mon, 22 Oct 2012 22:34:21 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id DC2DD21F8568 for ; Mon, 22 Oct 2012 22:34:21 -0700 (PDT) X-Ironport-SBRS: 2.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsADAIErhlDRVdjGemdsb2JhbABBAw6CPINKsmYBiF8IIwEBCwkMCBQEI4IgAQEBAwEBAQEPAgkGSwsOAgkCCwM0AgIbBwUNAQUBHAYTGweHXAYLngAJA4tZkwkEi1QbgyxPgUeBEgOIWo0XgReNQRYpg1QwLQ X-IronPort-AV: E=Sophos;i="4.80,633,1344236400"; d="scan'208";a="559607" Received: from mail-qc0-f198.google.com ([209.85.216.198]) by fe1.lbl.gov with ESMTP; 22 Oct 2012 22:34:20 -0700 Received: by mail-qc0-f198.google.com with SMTP id e13so6614039qcs.1 for ; Mon, 22 Oct 2012 22:34:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8gaOijWyQu+PMnnj0Gn6UQ1K3qc06h3n6/jpfrPe4gI=; b=WPeQksL6OUf5OHoaibQkDLDv2HttJ6pygeZ5U6OpeRg6v2owdjO6HHr6aAPeNh1f2W G6mZBLskf/mzsonWX03wxwQwYYs8k4vQZIehVpQ97CwHz5HuiAv7r32qAmw9jSTHaeEm k90nYECbWzq83hmDgMEtFVl8ln3jo4Zcf568VwbidV4EpvIqU69buqevcvq/HmR7mNk0 K+A5NBmODq+WstMd+Ufm+6C4hkfsjZa8UyCVd6bnTwldnZ6j4WBiQT8QMrgGxx0iHx4G CXJL8u/ypcda0EM5CKH3rqcV76JUdt3XBeOR00a66TiF/VJ/bWmOrJ57+YWmfuUduxIi AvkA== Received: by 10.58.143.12 with SMTP id sa12mr8785703veb.43.1350970460602; Mon, 22 Oct 2012 22:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.143.12 with SMTP id sa12mr8785694veb.43.1350970460441; Mon, 22 Oct 2012 22:34:20 -0700 (PDT) Received: by 10.58.125.73 with HTTP; Mon, 22 Oct 2012 22:34:20 -0700 (PDT) In-Reply-To: <5075E653.5070907@auckland.ac.nz> References: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> <20121010122412.GA59580@elstar.local> <20121010124022.GA59852@elstar.local> <5075E653.5070907@auckland.ac.nz> Date: Mon, 22 Oct 2012 22:34:20 -0700 Message-ID: From: Bruce Nordman To: Nevil Brownlee Content-Type: multipart/alternative; boundary=047d7b676650658de304ccb3522b X-Gm-Message-State: ALoCoQm4lj2lCIdQAwxPvmpv7sygZqqMeQ1coBRij1eYWkRaByAmLlWeJluCgh6jKympB1vdtK1Bxt6K993dFbiFDlS8KjOs5iVFnZmqgMIfIoGXo6DoDwDbVk7toZT8WpQUgkLJw9ZP Cc: "eman >> \"eman@ietf.org\"" Subject: Re: [eman] WG Last Call for draft-ietf-eman-requirements-09 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 05:34:22 -0000 --047d7b676650658de304ccb3522b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have the following comments on the -09 version of the Requirements draft. These comments are not sufficient to warrant a new WGLC. I congratulate the authors on their hard work and quality product. Only the first item (7.6) suggests a substantive change. Note that deleting this would not preclude EMAN including this feature - it just would not mandate it. Section 7.6. I fail to see the need for this requirement. One can simply ask the other entity for the information and avoid the substantial complexity this would entail. Sometimes =93entity=94 refers to a device or component (or also power interface). Sometimes it refers to just a device. The latter should be changed to =93device=94. When referring to both power inlets and outlets, can simply to just power interfaces. This occurs in several places. Section 5.2. Add =93 only differing by the sign of their power value=94 to = the first sentence of section 5.2. Purpose to clarify that there is only one underlying concept, a PI. The word =93domain=94 occurs only once in the draft. Is it clear what this= is to mean? I suggest that a descriptive phrase of the intended concept be included instead of this potentially ambiguous word (I see nothing wrong with defining and using the word in other drafts). Sections 5.2.2 and 5.2.3 should be combined. There needs to be just a single list of PIs, not separated by whether they are inlets or outlets at a particular point in time. Also, the current language implies that an inlet can be connected to one providing outlet; this is usual but not strictly required =96 can be plural. In any case, combining the two to jus= t a list of connected interfaces will eliminate this issue. Section 5.3.3. With the accuracy data available, it seems unnecessary to include the measurement method. Section 5.5.2. Reporting on energy used over intervals could be useful, but even more basic is reporting of an accumulated energy use value (=93met= er reading=94) and a time stamp. The best solution may be to add to 5.5.1, since an energy value in isolation is not particularly useful =96 it needs = to be associated with time somehow, so a simple time stamp of the meter reading is the most simple and basic way to do this. Section 7 =96 =93Accumulated=94 to =93Aggregated=94. Note: The first author of the applicability statement reference is still erroneous. This is a database problem that we think has been fixed and should be correct the next time the requirements document is updated. In the Appendix, a level can be collapsed =96 A.1.1 can be come A.1. --Bruce (as contributor) On Wed, Oct 10, 2012 at 2:19 PM, Nevil Brownlee wrote: > > Hi all: > > This begins the WG Last Call for the EMAN Requirements draft. > It will end on Monday, 29 October (a week before IETF 85). > > Please read it, and send your comments to the eman list. > If you think it's OK, let us know that too! > > Cheers, Nevil > > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b676650658de304ccb3522b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have the fol= lowing comments on the -09 version of the Requirements draft.
These comm= ents are not sufficient to warrant a new WGLC.
I congratulate the = authors on their hard work and quality product.


Only the first item (7.6)=C2=A0 suggests a substantive change.=C2=A0 Note that deleting this
w= ould not preclude EMAN including this feature - it just would not man= date it.

Section 7.= 6.=C2=A0 I fail to see the need for this requirement.=C2=A0 One can simply ask the other entity
for the information and avoid the substantial complexity this would entail.

=C2=A0

Sometimes =E2=80=9Centity=E2=80=9D refers to a device or component= (or also power interface).=C2=A0 Sometimes it refers to just a device.=C2=A0 The latter should be changed to =E2=80=9Cdevice=E2=80=9D.

When referring to both power inlets and outlets, can simply to just power interfaces. This occurs

in several places.


Section 5.2. Add =E2=80=9C only differing by the sign of their pow= er value=E2=80=9D to the first sentence of section 5.2.=C2=A0 Purpose to clarify that there is only one underlying concept, a PI.<= /span>

=C2=A0

The word =E2=80=9Cdomain=E2=80=9D occurs only once in the draft.=C2=A0 Is it clear what this is to mean?=C2=A0 I suggest that a = descriptive

phrase of the intended conce= pt be included instead of this potentially ambiguous word (I see nothing wr= ong

with defining and using the word in = other drafts).

=C2=A0

Sections 5.2.2 and 5.2.3 should be combined.=C2=A0 Th= ere needs to be just a single list of PIs, not separated by whether they are inlets or outlets at a particular point i= n time.=C2=A0 Also, the current language implies that an inlet can be connected to one providing outlet; this is usual but n= ot strictly required =E2=80=93 can be plural.=C2=A0 In any case, combining the two to just a list of connected interfaces will eliminate this issue.

=C2=A0

Section 5.3.3.=C2=A0 With the accuracy data available, it seems unnecessary to include
the measurement method.

=C2=A0

Section 5.5.2.=C2=A0 Reporting on energy used over intervals could be useful, but even mo= re basic is reporting of an accumulated energy use value (=E2=80=9Cmeter readi= ng=E2=80=9D) and a time stamp.=C2=A0 The best solution may be to add to 5.5.1, since an energy value in isolation is not particularly useful= =E2=80=93 it needs to be associated with time somehow, so a simple time stamp of the meter reading is the most simple and basic way to do this.

=C2=A0

Section 7 =E2=80=93 =E2=80=9CAccumulated=E2=80=9D to =E2=80=9CAggr= egated=E2=80=9D.

=C2=A0

Note: The first author of the applicabi= lity statement reference is still erroneous.=C2=A0 This is a database problem that we think has been fixed and should be correct the nex= t time the requirements document is updated.

=C2=A0

In the Appendix, a level can be collapsed =E2=80=93 A.1.1 can be come A.1.

=C2=A0

--Bruce (as contributor)<= /font>



On Wed, Oct 10, 2012 at 2:19 PM, Nevil Brownlee <n.brownlee@auckland.ac.nz> wrote:

Hi all:

This begins the WG Last Call for the EMAN Requirements draft.
It will end on Monday, 29 October (a week before IETF 85).

Please read it, and send your comments to the eman list.
If you think it's OK, let us know that too!

Cheers, Nevil

--
---------------------------------------------------------------------
=C2=A0Nevil Brownlee =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Computer Science Department | ITS
=C2=A0Phone: +64 9 373 7599 x88941 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 The University of Auckland
=C2=A0FAX: +64 9 373 7453 =C2=A0 Private Bag 92019, Auckland 1142, = New Zealand
_______________________________________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman



--
Bruce = Nordman
Lawrence Berkeley Nationa= l Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-4= 86-7089
m: 510-501-7943

 --047d7b676650658de304ccb3522b-- From brads@coraid.com Tue Oct 23 07:07:13 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A6311E80A5 for ; Tue, 23 Oct 2012 07:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmlWZji+sXs8 for ; Tue, 23 Oct 2012 07:07:10 -0700 (PDT) Received: from server505.appriver.com (server505h.appriver.com [98.129.35.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7F321F86A7 for ; Tue, 23 Oct 2012 07:07:09 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/23/2012 9:07:08 AM X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Policy: GLOBAL - coraid.com X-Primary: brads@coraid.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @coraid.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: brads@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G329 G330 G331 G332 G336 G337 G348 G444 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 262108492; Tue, 23 Oct 2012 09:07:08 -0500 Received: from MBX22.exg5.exghost.com ([169.254.2.182]) by HT06.exg5.exghost.com ([98.129.23.206]) with mapi; Tue, 23 Oct 2012 09:07:07 -0500 From: Brad Schoening To: Bruce Nordman , Nevil Brownlee Date: Tue, 23 Oct 2012 09:07:02 -0500 Thread-Topic: [eman] WG Last Call for draft-ietf-eman-requirements-09 Thread-Index: Ac2xJ69QIB0PnKOgT6WGl4DJhapmrA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CCABF04F66C17bradscoraidcom_" MIME-Version: 1.0 Cc: "eman >> \"eman@ietf.org\"" Subject: Re: [eman] WG Last Call for draft-ietf-eman-requirements-09 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 14:07:13 -0000 --_000_CCABF04F66C17bradscoraidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 5.5.2. Time intervals The standard must provide means for reporting the time interval for which an energy value is reported. B.N. - Section 5.5.2. Reporting on energy used over intervals could be use= ful, but even more basic is reporting of an accumulated energy use value (= =93meter reading=94) and a time stamp. The best solution may be to add to = 5.5.1, since an energy value in isolation is not particularly useful =96 it= needs to be associated with time somehow, so a simple time stamp of the me= ter reading is the most simple and basic way to do this. Bruce, It seems clear that the requirement allows for a single time interval actin= g as an odometer. How this is done is an implementation detail. Probably = best to leave 'solutions' to other documents. Brad Schoening Engineering | Coraid Tel: +1 917 304 7190 brads@coraid.com | www.coraid.com Coraid: Redefining Storage From: Bruce Nordman > Date: Tue, 23 Oct 2012 00:34:20 -0500 To: Nevil Brownlee > Cc: "eman >> \"eman@ietf.org\"" > Subject: Re: [eman] WG Last Call for draft-ietf-eman-requirements-09 I have the following comments on the -09 version of the Requirements draft. These comments are not sufficient to warrant a new WGLC. I congratulate the authors on their hard work and quality product. Only the first item (7.6) suggests a substantive change. Note that deleti= ng this would not preclude EMAN including this feature - it just would not mandate = it. Section 7.6. I fail to see the need for this requirement. One can simply = ask the other entity for the information and avoid the substantial complexity this would entail. Sometimes =93entity=94 refers to a device or component (or also power inter= face). Sometimes it refers to just a device. The latter should be changed= to =93device=94. When referring to both power inlets and outlets, can simply to just power i= nterfaces. This occurs in several places. Section 5.2. Add =93 only differing by the sign of their power value=94 to = the first sentence of section 5.2. Purpose to clarify that there is only o= ne underlying concept, a PI. The word =93domain=94 occurs only once in the draft. Is it clear what this= is to mean? I suggest that a descriptive phrase of the intended concept be included instead of this potentially ambi= guous word (I see nothing wrong with defining and using the word in other drafts). Sections 5.2.2 and 5.2.3 should be combined. There needs to be just a sing= le list of PIs, not separated by whether they are inlets or outlets at a pa= rticular point in time. Also, the current language implies that an inlet c= an be connected to one providing outlet; this is usual but not strictly req= uired =96 can be plural. In any case, combining the two to just a list of = connected interfaces will eliminate this issue. Section 5.3.3. With the accuracy data available, it seems unnecessary to i= nclude the measurement method. Section 5.5.2. Reporting on energy used over intervals could be useful, bu= t even more basic is reporting of an accumulated energy use value (=93meter= reading=94) and a time stamp. The best solution may be to add to 5.5.1, s= ince an energy value in isolation is not particularly useful =96 it needs t= o be associated with time somehow, so a simple time stamp of the meter read= ing is the most simple and basic way to do this. Section 7 =96 =93Accumulated=94 to =93Aggregated=94. Note: The first author of the applicability statement reference is still er= roneous. This is a database problem that we think has been fixed and shoul= d be correct the next time the requirements document is updated. In the Appendix, a level can be collapsed =96 A.1.1 can be come A.1. --Bruce (as contributor) On Wed, Oct 10, 2012 at 2:19 PM, Nevil Brownlee > wrote: Hi all: This begins the WG Last Call for the EMAN Requirements draft. It will end on Monday, 29 October (a week before IETF 85). Please read it, and send your comments to the eman list. If you think it's OK, let us know that too! Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 = The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckl= and 1142, New Zealand _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory nordman.lbl.gov BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --_000_CCABF04F66C17bradscoraidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 
5.5.2.  Time=
 intervals


   The standard must provide means for reporting the time interval for
   which an energy value is reported.

B.N. - Se= ction 5.5.2.  Reporting on energy used over interval= s could be useful, but even more basic is reporting of an accumulated energ= y use value (=93meter reading=94) and a time stamp.  The best solution may be to add to 5.5.1, since an energy value in isolati= on is not particularly useful =96 it needs to be associated with time someh= ow, so a simple time stamp of the meter reading is the most simple and basi= c way to do this.

= Bruce,

It seems clear that the requirement allows = for a single time interval acting as an odometer.   How this is done i= s an implementation detail. Probab= ly best to leave 'solutions' to other documents. 


Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
brads@coraid.com | www.coraid.com
<= span style=3D"font-size:9.0pt;font-family:Arial;mso-fareast-font-family: "Times New Roman";color:#00467F;mso-ansi-language:EN-US;mso-farea= st-language: EN-US;mso-bidi-language:AR-SA;mso-bidi-font-style:italic">Coraid: Redefinin= g Storage

From: Bru= ce Nordman <bnordman@lbl.gov>=
Date: Tue, 23 Oct 2012 00:34:2= 0 -0500
To: Nevil Brownlee <= n.brownlee@auckland.ac.nz&= gt;
Cc: "eman >> \&q= uot;eman@ietf.org\"" <eman@ietf.org>
Subject: Re: [eman] WG Last Call for draft-ietf-eman-r= equirements-09

I have the following comments on the -09 vers= ion of the Requirements draft.
These comments are not sufficient to warr= ant a new WGLC.
I congratulate the authors on their hard work and = quality product.


Only the first item (7.6)  suggests a substantive change.  Note tha= t deleting this
would not preclude EMAN including this feature - i= t just would not mandate it.

= Section 7= .6.  I fail to see the need for this requirement.  One can simply ask the other entity
for the information and avoid the substantial complexity this would entail.

 

= Sometimes =93en= tity=94 refers to a device or component (or also power interface).  Sometimes it refers to just a device.  The latter should be changed to =93device=94.

=

When referring to both power inlets and outlets,= can simply to just power interfaces. This occurs

in several places.


= Section 5.2. Ad= d =93 only differing by the sign of their power value=94 to the first sentence of section 5.2.  Purpose to clarify that there is only one underlying concept, a PI.<= /span>

 

The wo= rd =93domain=94 occurs only once in the draft.  Is it cle= ar what this is to mean?  I suggest that a descriptive

phrase of the intended concept be included instead of this potentially ambiguous wo= rd (I see nothing wrong

= with defining and using the word in other drafts).<= /font>

 = ;

Sections 5.2.2 and 5.2.3 should be combine= d.  There needs to be just a single list of PIs, not separated by whether they are inlets or outlets at a particular point i= n time.  Also, the current language implies that an inlet can be connected to one providing outlet; this is usual but n= ot strictly required =96 can be plural.  In any case, combining the two to just a list of connected interfaces will eliminate this issue.

 

Section 5.3.3.  With the accuracy data available, it seems unnecessary to include
the measurement method.

 =

Section 5.5.2.  Reporting on energy used over intervals could be useful, but even mo= re basic is reporting of an accumulated energy use value (=93meter reading=94)= and a time stamp.  The best solution may be to add to 5.5.1, since an energy value in isolation is not particularly useful= =96 it needs to be associated with time somehow, so a simple time stamp of the meter reading is the most simple and basic way to do this.

 

Section 7 =96 =93Accum= ulated=94 to =93Aggregated=94.

 =

Note: The first au= thor of the applicability statement reference is still erroneous.  This is a database problem that we think has been fixed and should be correct the nex= t time the requirements document is updated.

&= nbsp;

In the Appendix, a level can be collap= sed =96 A.1.1 can be come A.1.

 

--Bruce (as contributor)



On Wed, Oct 10, 2012 at 2:19 PM, Nevil Brownlee <n.brownlee@auckland.ac.nz> wrote:

Hi all:

This begins the WG Last Call for the EMAN Requirements draft.
It will end on Monday, 29 October (a week before IETF 85).

Please read it, and send your comments to the eman list.
If you think it's OK, let us know that too!

Cheers, Nevil=

--
---------------------------------------------------------------------
 Nevil Brownlee                = ;    Computer Science Department | ITS
 Phone: +64 9 373 7599 x88941     &= nbsp;       The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Aucklan= d 1142, New Zealand
_______________________________________________
eman mailing list
ema= n@ietf.org
https://www.ietf.org/mailman/listinfo/eman



--
Bruce Nord= man
Lawrence Berkeley National La= boratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 51= 0-501-7943

 --_000_CCABF04F66C17bradscoraidcom_-- From moulchan@cisco.com Tue Oct 23 23:10:32 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0020B21F8C29 for ; Tue, 23 Oct 2012 23:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0VJt-stUHzr for ; Tue, 23 Oct 2012 23:10:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27721F8C1C for ; Tue, 23 Oct 2012 23:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9160; q=dns/txt; s=iport; t=1351059014; x=1352268614; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gMf3ql09uN7LmTFlAg69CdAW+vhTNGK+GCXJzSyp8Zw=; b=L0lWySRH6GzOvGHmJNzoKzFyugLehvY7cH/c9ZAYnVivTiyvBba1zRGD dNBCcLIBGKW3LRgsMEv5AXp0QiPjbNKmfyZVYw/xFG3OzCYmg2d8mpkFP 89NY2fC3GuPtyHDkHl55XKey2r1+3T3InF/88AK0ezXvVuBCHE3xfhwoX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPqEh1CtJV2Z/2dsb2JhbABEDoI8g0q6boEEgQiCHgEBAQQSAQoGCkwQAgEIDgMEAQELHQMCAgIwFAkIAgQBDQUIARmHYgubBI0hklaLYBoBhT4yYAOkQYFrgjI9gWMXHg X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208,217";a="134757585" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 24 Oct 2012 06:10:03 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9O6A3T1003417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 06:10:03 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 01:10:02 -0500 From: "Mouli Chandramouli (moulchan)" To: Bruce Nordman , Nevil Brownlee Thread-Topic: [eman] WG Last Call for draft-ietf-eman-requirements-09 Thread-Index: AQHNsOAR9syBXSHEhEygzA9Pn/IEp5fH854A Date: Wed, 24 Oct 2012 06:10:02 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E4036@xmb-rcd-x08.cisco.com> References: <20121010120440.32681.99850.idtracker@ietfa.amsl.com> <20121010122412.GA59580@elstar.local> <20121010124022.GA59852@elstar.local> <5075E653.5070907@auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--35.124400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E4036xmbrcdx08ciscoc_" MIME-Version: 1.0 Cc: "eman@ietf.org" Subject: Re: [eman] WG Last Call for draft-ietf-eman-requirements-09 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 06:10:32 -0000 --_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E4036xmbrcdx08ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJ1Y2UsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NClJlcGxpZXMgaW5saW5lLg0KDQpU aGFua3MNCk1vdWxpDQoNCkZyb206IGVtYW4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZW1hbi1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmVtYW4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEJydWNlIE5vcmRtYW4NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjMsIDIwMTIgMTE6MDQg QU0NClRvOiBOZXZpbCBCcm93bmxlZQ0KQ2M6IGVtYW4gPj4gImVtYW5AaWV0Zi5vcmc8bWFpbHRv OmVtYW5AaWV0Zi5vcmc+Ig0KU3ViamVjdDogUmU6IFtlbWFuXSBXRyBMYXN0IENhbGwgZm9yIGRy YWZ0LWlldGYtZW1hbi1yZXF1aXJlbWVudHMtMDkNCg0KDQpTb21ldGltZXMg4oCcZW50aXR54oCd IHJlZmVycyB0byBhIGRldmljZSBvciBjb21wb25lbnQgKG9yIGFsc28gcG93ZXIgaW50ZXJmYWNl KS4gIFNvbWV0aW1lcyBpdCByZWZlcnMgdG8ganVzdCBhIGRldmljZS4gIFRoZSBsYXR0ZXIgc2hv dWxkIGJlIGNoYW5nZWQgdG8g4oCcZGV2aWNl4oCdLg0KDQpbeWNtXSBJIGFncmVlLiAgSSB0aGlu ayBzb21lIG1vcmUgY2xhcml0eSBvbiB0aGlzIHRvcGljIHdvdWxkIGhlbHAuICBTb21lIHJlcXVp cmVtZW50cyBhcmUgc3BlY2lmaWVkIGZvciDigJxlbnRpcmUgZW50aXR54oCdLCBzb21lIHJlcXVp cmVtZW50cyBmb3IgYW4g4oCcIGVudGl0eeKAnSAgYW5kIHNvbWUgb3RoZXIgcmVxdWlyZW1lbnRz IGZvciDigJxwb3dlciBpbnRlcmZhY2Vz4oCdLg0KW3ljbV0gSG93ZXZlciwgaWYgYSBkZXZpY2Ug d2VyZSB0byBoYXZlIHRoZSBjYXBhYmlsaXR5LCB0aGUgcG93ZXIgbWVhc3VyZW1lbnQgY2FuIGJl IGltcGxlbWVudGVkIGZvciBhbiBlbnRpdHkgb3IgYSBjb21wb25lbnQgb2YgYSBkZXZpY2UuDQoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9lbWFuL2N1cnJlbnQvbXNnMDE1 OTUuaHRtbA0KDQoNClt5Y21dIFRoYW5rcyAgTW91bGkNCg== --_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E4036xmbrcdx08ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5CcnVjZSwgPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZv ciB5b3VyIGNvbW1lbnRzLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+ UmVwbGllcyBpbmxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj5Nb3VsaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOmVtYW4t Ym91bmNlc0BpZXRmLm9yZyI+ZW1hbi1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFp bHRvOmVtYW4tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmVtYW4tYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJydWNlIE5vcmRtYW48YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgT2N0b2JlciAyMywgMjAxMiAxMTowNCBBTTxicj4NCjxiPlRvOjwvYj4gTmV2aWwg QnJvd25sZWU8YnI+DQo8Yj5DYzo8L2I+IGVtYW4gJmd0OyZndDsgJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOmVtYW5AaWV0Zi5vcmciPmVtYW5AaWV0Zi5vcmc8L2E+JnF1b3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbZW1hbl0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLWVtYW4tcmVxdWly ZW1lbnRzLTA5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+U29tZXRpbWVzIOKAnGVudGl0eeKAnSByZWZlcnMgdG8gYSBkZXZpY2Ugb3IgY29tcG9u ZW50IChvciBhbHNvIHBvd2VyIGludGVyZmFjZSkuJm5ic3A7IFNvbWV0aW1lcyBpdCByZWZlcnMg dG8ganVzdCBhIGRldmljZS4mbmJzcDsgVGhlIGxhdHRlciBzaG91bGQgYmUgY2hhbmdlZCB0byDi gJxkZXZpY2XigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPlt5Y21dIEkgYWdyZWUuJm5ic3A7IEkgdGhpbmsgc29tZSBtb3JlIGNs YXJpdHkgb24gdGhpcyB0b3BpYyB3b3VsZCBoZWxwLiZuYnNwOyBTb21lIHJlcXVpcmVtZW50cyBh cmUgc3BlY2lmaWVkIGZvciDigJxlbnRpcmUgZW50aXR54oCdLCBzb21lIHJlcXVpcmVtZW50cyBm b3IgYW4g4oCcIGVudGl0eeKAnSZuYnNwOyBhbmQgc29tZSBvdGhlciByZXF1aXJlbWVudHMNCiBm b3Ig4oCccG93ZXIgaW50ZXJmYWNlc+KAnS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9pPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjojMUY0OTdEIj5beWNtXSBIb3dldmVyLCBpZiBhIGRldmljZSB3ZXJlIHRv IGhhdmUgdGhlIGNhcGFiaWxpdHksIHRoZSBwb3dlciBtZWFzdXJlbWVudCBjYW4gYmUgaW1wbGVt ZW50ZWQgZm9yIGFuIGVudGl0eSBvciBhIGNvbXBvbmVudCBvZiBhIGRldmljZS4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZW1hbi9jdXJyZW50L21zZzAxNTk1Lmh0bWwiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9lbWFuL2N1cnJlbnQvbXNnMDE1OTUuaHRt bDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5beWNtXSBUaGFua3Mm bmJzcDsgTW91bGk8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_852AF0ED49D9F24BBBFA1B4DEEBE3BA4237E4036xmbrcdx08ciscoc_-- From trac+eman@trac.tools.ietf.org Wed Oct 24 11:28:09 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D8921F8830 for ; Wed, 24 Oct 2012 11:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpLZYXQBw52W for ; Wed, 24 Oct 2012 11:28:08 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8A65221F8816 for ; Wed, 24 Oct 2012 11:28:08 -0700 (PDT) Received: from localhost ([127.0.0.1]:52238 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR5gJ-0007LC-IP; Wed, 24 Oct 2012 20:27:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bclaise@cisco.com, jparello@cisco.com X-Trac-Project: eman Date: Wed, 24 Oct 2012 18:27:55 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/6#comment:3 Message-ID: <079.71126040c1ec0c929e8006917e41b8bf@trac.tools.ietf.org> References: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bclaise@cisco.com, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #6: States and ASHRAE Curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 18:28:09 -0000 #6: States and ASHRAE Curtailment levels Comment (by jparello@…): need text to describe curtailment. (JQ) -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 11:39:02 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C2121F8783 for ; Wed, 24 Oct 2012 11:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9VgiJru1mfi for ; Wed, 24 Oct 2012 11:39:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE0D21F8782 for ; Wed, 24 Oct 2012 11:39:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:53136 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR5qh-0006d9-UF; Wed, 24 Oct 2012 20:38:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz, quittek@neclab.eu, jparello@cisco.com X-Trac-Project: eman Date: Wed, 24 Oct 2012 18:38:39 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/7#comment:3 Message-ID: <079.65354480e272a63eb276b9f057d81899@trac.tools.ietf.org> References: <064.0286cc8ffe2a823c965c5977746402d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <064.0286cc8ffe2a823c965c5977746402d8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, quittek@neclab.eu, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #7: Clarify power interfaces X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 18:39:02 -0000 #7: Clarify power interfaces Comment (by jparello@…): JQ sent text elaborating model #4 -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bclaise Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 11:51:25 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25FF21F85C2 for ; Wed, 24 Oct 2012 11:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB9dmbA8ba2k for ; Wed, 24 Oct 2012 11:51:23 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1841521F85ED for ; Wed, 24 Oct 2012 11:51:21 -0700 (PDT) Received: from localhost ([127.0.0.1]:54091 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR62i-0008BE-Ci; Wed, 24 Oct 2012 20:51:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 24 Oct 2012 18:51:04 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/12#comment:2 Message-ID: <079.5cc21e4c35e82daba90ced26098fdf59@trac.tools.ietf.org> References: <064.9a8404aa8b8749382a7ecb93a3197acb@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <064.9a8404aa8b8749382a7ecb93a3197acb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #12: how summation occurs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 18:51:25 -0000 #12: how summation occurs Comment (by jparello@…): check for consistency on term aggregation in the doc. List any changes - BN -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bruce Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 12:04:45 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65FC21F86E5 for ; Wed, 24 Oct 2012 12:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsoAIGstWWJf for ; Wed, 24 Oct 2012 12:04:45 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 519DD21F86D8 for ; Wed, 24 Oct 2012 12:04:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:55880 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR6Fl-0000ky-AV; Wed, 24 Oct 2012 21:04:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com X-Trac-Project: eman Date: Wed, 24 Oct 2012 19:04:33 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/20#comment:1 Message-ID: <079.25aae7390abb321f07ed91639af5222c@trac.tools.ietf.org> References: <064.800bc0481e0d9df1845e35ac65157339@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <064.800bc0481e0d9df1845e35ac65157339@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #20: g. Add a reference to some external definition X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 19:04:45 -0000 #20: g. Add a reference to some external definition Comment (by jparello@…): JP - add reference to cisco energywise for eman states. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 13:57:18 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DA621F8A49 for ; Wed, 24 Oct 2012 13:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovgF2Vvm937U for ; Wed, 24 Oct 2012 13:57:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 669DB21F87DC for ; Wed, 24 Oct 2012 13:57:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:37480 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR80R-00070K-AU; Wed, 24 Oct 2012 22:56:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brad@coraid.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 20:56:51 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/26#comment:1 Message-ID: <070.6246af68ef78c7f8076cad584235870d@trac.tools.ietf.org> References: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brad@coraid.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #26: ASHRAE 201P Power Quality X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 20:57:18 -0000 #26: ASHRAE 201P Power Quality Changes (by n.brownlee@…): * owner: draft-ietf-eman-framework@… => brad@… * version: => 1.0 * milestone: => milestone1 Comment: Brad: please add text to do this -- -----------------------+------------------------- Reporter: brads@… | Owner: brad@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | -----------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 13:59:08 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A021F87DB for ; Wed, 24 Oct 2012 13:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfWqMTMr1xlq for ; Wed, 24 Oct 2012 13:59:08 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id D49C821F86E8 for ; Wed, 24 Oct 2012 13:59:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:37635 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR82Z-0007CF-Rh; Wed, 24 Oct 2012 22:59:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz, jparello@cisco.com X-Trac-Project: eman Date: Wed, 24 Oct 2012 20:59:03 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/4#comment:5 Message-ID: <079.1d0dfbf1134a92d2f6b3765b7de4efda@trac.tools.ietf.org> References: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <064.7a9d450cca2046de189ad1ffa76f63de@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, jparello@cisco.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #4: Reorganise sections X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 20:59:08 -0000 #4: Reorganise sections Comment (by n.brownlee@…): John has changed section numbering, is anything more needed? -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 13:59:59 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D04821F8A62 for ; Wed, 24 Oct 2012 13:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALfs7OE89hAF for ; Wed, 24 Oct 2012 13:59:59 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1A35221F8A49 for ; Wed, 24 Oct 2012 13:59:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:37699 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR83R-0007DG-OJ; Wed, 24 Oct 2012 22:59:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 20:59:57 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/5#comment:2 Message-ID: <079.b3f6133017d2db50f4b50403aa7c5150@trac.tools.ietf.org> References: <064.8a16c0d42ca3152971660ffdd608afc8@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <064.8a16c0d42ca3152971660ffdd608afc8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #5: Review UML with latest draft from Monitoring MIB/Aware. X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 20:59:59 -0000 #5: Review UML with latest draft from Monitoring MIB/Aware. Comment (by n.brownlee@…): Benoit: please add text. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bclaise Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:01:33 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6455D21F8B46 for ; Wed, 24 Oct 2012 14:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fq8UZS1wFdZ for ; Wed, 24 Oct 2012 14:01:33 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id CC23821F8B32 for ; Wed, 24 Oct 2012 14:01:32 -0700 (PDT) Received: from localhost ([127.0.0.1]:37922 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR84r-0001Ac-CV; Wed, 24 Oct 2012 23:01:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: quittek@neclab.eu, bclaise@cisco.com, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:01:25 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/6#comment:4 Message-ID: <079.ff21500e92be5f73c6b086194d2220c0@trac.tools.ietf.org> References: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <064.3a9e930207302af0939a4d9d1c602749@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: quittek@neclab.eu, bclaise@cisco.com, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #6: States and ASHRAE Curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:01:33 -0000 #6: States and ASHRAE Curtailment levels Changes (by n.brownlee@…): * owner: jparello => quittek@… -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: quittek@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:05:58 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8262221F8B71 for ; Wed, 24 Oct 2012 14:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb9LVRo8eZ3c for ; Wed, 24 Oct 2012 14:05:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id D506021F88EB for ; Wed, 24 Oct 2012 14:05:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:38710 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR88z-0001Vy-1O; Wed, 24 Oct 2012 23:05:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:05:40 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/8#comment:2 Message-ID: <079.45d796a37a1aa91c9b9f3623280c5b51@trac.tools.ietf.org> References: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #8: List EMAN curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:05:58 -0000 #8: List EMAN curtailment levels Comment (by n.brownlee@…): Juergen to improve the text (agreed that it specify curtailment levels?) Concerning the rtgrg wg: once eman has defined its set of power states, rtgrg can make normative references to 'the eman states.' -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: jparello Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:06:06 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA68E21F8B6C for ; Wed, 24 Oct 2012 14:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7njs+b1a9pX for ; Wed, 24 Oct 2012 14:06:05 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0EF21F88EB for ; Wed, 24 Oct 2012 14:06:05 -0700 (PDT) Received: from localhost ([127.0.0.1]:38719 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR89G-000770-Sv; Wed, 24 Oct 2012 23:05:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: quittek@neclab.eu, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:05:58 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/8#comment:3 Message-ID: <079.20fe7ae2be63352766b17b15ed57bdb7@trac.tools.ietf.org> References: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <064.cbeb4b04599adc4564503ec585a112d7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: quittek@neclab.eu, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #8: List EMAN curtailment levels X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:06:06 -0000 #8: List EMAN curtailment levels Changes (by n.brownlee@…): * owner: jparello => quittek@… -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: quittek@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:06:42 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A5D21F88EB for ; Wed, 24 Oct 2012 14:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYu3-X-2aC7M for ; Wed, 24 Oct 2012 14:06:42 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4956121F88C8 for ; Wed, 24 Oct 2012 14:06:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:38731 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR89w-0003Af-Uc; Wed, 24 Oct 2012 23:06:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brads@coraid.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:06:40 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/10#comment:3 Message-ID: <079.b2d319ca01c0c782ce456a80be88de55@trac.tools.ietf.org> References: <064.3eb407edbc8ae4a48423a7ac22ccd6b8@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <064.3eb407edbc8ae4a48423a7ac22ccd6b8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brads@coraid.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #10: 6.5.2 - DMTF states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:06:42 -0000 #10: 6.5.2 - DMTF states Changes (by n.brownlee@…): * status: new => closed * resolution: => fixed Comment: Fixed by the -06 draft -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: brads@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:08:16 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAF021F8B6C for ; Wed, 24 Oct 2012 14:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZuRKxyQK+MS for ; Wed, 24 Oct 2012 14:08:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 149B421F8A62 for ; Wed, 24 Oct 2012 14:08:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:38737 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8B4-0006jk-Gb; Wed, 24 Oct 2012 23:07:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bnordman@lbl.gov, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:07:50 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/12#comment:3 Message-ID: <079.429087ba3d60a9219c271ebf49a07daf@trac.tools.ietf.org> References: <064.9a8404aa8b8749382a7ecb93a3197acb@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <064.9a8404aa8b8749382a7ecb93a3197acb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bnordman@lbl.gov, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #12: how summation occurs X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:08:17 -0000 #12: how summation occurs Changes (by n.brownlee@…): * owner: bruce => bnordman@… -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bnordman@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:10:11 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D86721F8903 for ; Wed, 24 Oct 2012 14:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qn8NdL5euZ9 for ; Wed, 24 Oct 2012 14:10:10 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 529FF21F8691 for ; Wed, 24 Oct 2012 14:10:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:38807 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8DI-00077S-QU; Wed, 24 Oct 2012 23:10:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:10:08 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/16#comment:1 Message-ID: <079.a61bc58b72fc5173e4b05bbb775a19d7@trac.tools.ietf.org> References: <064.e0edb6f25a043000c8d23b23fb4ed6cf@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <064.e0edb6f25a043000c8d23b23fb4ed6cf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:10:11 -0000 #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Comment (by n.brownlee@…): Everyone to comment -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:11:57 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B77721F8BA7 for ; Wed, 24 Oct 2012 14:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNsizy7cqDhi for ; Wed, 24 Oct 2012 14:11:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62B21F8B70 for ; Wed, 24 Oct 2012 14:11:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:38858 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8Ek-0001BV-Vt; Wed, 24 Oct 2012 23:11:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bnordman@lbl.gov, jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:11:38 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/17#comment:2 Message-ID: <079.1b89c8ab7299fdf82cdf6c41bf266484@trac.tools.ietf.org> References: <064.056e9f519f85063bc7514e0a8142259d@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <064.056e9f519f85063bc7514e0a8142259d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bnordman@lbl.gov, jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #17: d. Is aggregation a relationship, or just a function? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:11:57 -0000 #17: d. Is aggregation a relationship, or just a function? Changes (by n.brownlee@…): * owner: all => bnordman@… Comment: Bruce to check that 'aggregation relationship' and 'aggregation function' are clear throughout the draft -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: bnordman@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:12:49 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B7421F8BB8 for ; Wed, 24 Oct 2012 14:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjBTEXosxKyK for ; Wed, 24 Oct 2012 14:12:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 701D921F8BB4 for ; Wed, 24 Oct 2012 14:12:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:38956 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8Fr-0005Ex-3h; Wed, 24 Oct 2012 23:12:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:12:47 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/19#comment:1 Message-ID: <079.cb8af043032a69ce41face59d7e53b66@trac.tools.ietf.org> References: <064.df6b3e9b9b553a88f83bed1f3bf4f52e@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <064.df6b3e9b9b553a88f83bed1f3bf4f52e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #19: f. Possibility to merge some keyword variables? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:12:49 -0000 #19: f. Possibility to merge some keyword variables? Comment (by n.brownlee@…): Everyone to comment -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:13:35 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3F621F8B97 for ; Wed, 24 Oct 2012 14:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2Osa-ug2aBN for ; Wed, 24 Oct 2012 14:13:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB4521F8B8A for ; Wed, 24 Oct 2012 14:13:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:39096 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8GZ-0002c1-Dw; Wed, 24 Oct 2012 23:13:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jparello@cisco.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:13:31 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/20#comment:2 Message-ID: <079.92dea0794c00f921cfcf7684e0aefd95@trac.tools.ietf.org> References: <064.800bc0481e0d9df1845e35ac65157339@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <064.800bc0481e0d9df1845e35ac65157339@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jparello@cisco.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #20: g. Add a reference to some external definition X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:13:35 -0000 #20: g. Add a reference to some external definition Changes (by n.brownlee@…): * owner: all => jparello@… -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: jparello@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:14:31 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26E21F8673 for ; Wed, 24 Oct 2012 14:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GpWu2-LhcCJ for ; Wed, 24 Oct 2012 14:14:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id BE4D421F85AE for ; Wed, 24 Oct 2012 14:14:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:39266 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8HV-0004a7-Dv; Wed, 24 Oct 2012 23:14:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:14:29 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/21#comment:1 Message-ID: <079.c8a7c712626b3500187e0f29ad8412fd@trac.tools.ietf.org> References: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #21: h. Clarify the intended application of the Domain concept? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:14:31 -0000 #21: h. Clarify the intended application of the Domain concept? Comment (by n.brownlee@…): Everyone to comment -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:14:46 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAB121F863B for ; Wed, 24 Oct 2012 14:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeF+QT6F+46C for ; Wed, 24 Oct 2012 14:14:46 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 62FCC21F85AF for ; Wed, 24 Oct 2012 14:14:46 -0700 (PDT) Received: from localhost ([127.0.0.1]:39316 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8Hl-0001xY-2D; Wed, 24 Oct 2012 23:14:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:14:45 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/21#comment:2 Message-ID: <079.dee7b7ad635c346aa48fe4776187627c@trac.tools.ietf.org> References: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <064.71cdaa9804b4d5542ef8cf6433ee0054@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #21: h. Clarify the intended application of the Domain concept? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:14:47 -0000 #21: h. Clarify the intended application of the Domain concept? Comment (by n.brownlee@…): Everyone to comment -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:15:07 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B8421F8BB4 for ; Wed, 24 Oct 2012 14:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck4T9Auw4uFA for ; Wed, 24 Oct 2012 14:15:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 178ED21F863F for ; Wed, 24 Oct 2012 14:15:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:39392 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8I5-0000p3-Nv; Wed, 24 Oct 2012 23:15:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:15:05 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/22#comment:1 Message-ID: <079.d7536ce6ed9d35167f67ba07bef3115b@trac.tools.ietf.org> References: <064.71f954de497add7ce356c6764dff7588@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <064.71f954de497add7ce356c6764dff7588@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #22: i. Are there any power source or metering relationships that are not covered by data present about the wiring topology? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:15:08 -0000 #22: i. Are there any power source or metering relationships that are not covered by data present about the wiring topology? Comment (by n.brownlee@…): Everyone to comment -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:15:31 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D750821F86BE for ; Wed, 24 Oct 2012 14:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBvyQq4v1yK1 for ; Wed, 24 Oct 2012 14:15:31 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id EDDF721F863F for ; Wed, 24 Oct 2012 14:15:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:39482 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8IO-0008QR-KE; Wed, 24 Oct 2012 23:15:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:15:24 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/23#comment:1 Message-ID: <079.67182aec8fec0fd5d92c4d98adab51e7@trac.tools.ietf.org> References: <064.17f7a3002a261261e6002556e68c70b0@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <064.17f7a3002a261261e6002556e68c70b0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #23: Figure 6. Clarify that Parent/Child communication can be accomplished via EMAN X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:15:32 -0000 #23: Figure 6. Clarify that Parent/Child communication can be accomplished via EMAN Comment (by n.brownlee@…): Everyone to comment -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:15:54 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068EB21F8BBE for ; Wed, 24 Oct 2012 14:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-Jkzw6SxbVV for ; Wed, 24 Oct 2012 14:15:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4C41E21F8620 for ; Wed, 24 Oct 2012 14:15:53 -0700 (PDT) Received: from localhost ([127.0.0.1]:39498 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8Ik-0000Bz-Or; Wed, 24 Oct 2012 23:15:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:15:46 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/24#comment:1 Message-ID: <079.20b5494b75c3e18ca199332fb8291e26@trac.tools.ietf.org> References: <064.ca336c45f21b50f12ec09f9571e0a99a@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <064.ca336c45f21b50f12ec09f9571e0a99a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #24: no need for a separate concept of a meter X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:15:54 -0000 #24: no need for a separate concept of a meter Comment (by n.brownlee@…): Everyone to comment -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 14:17:12 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F72B21F863F for ; Wed, 24 Oct 2012 14:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjF6CfUBcVEP for ; Wed, 24 Oct 2012 14:17:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9D021F863B for ; Wed, 24 Oct 2012 14:17:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:39512 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TR8Jv-0000j7-RC; Wed, 24 Oct 2012 23:16:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brads@coraid.com, n.brownlee@auckland.ac.nz X-Trac-Project: eman Date: Wed, 24 Oct 2012 21:16:59 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/25#comment:3 Message-ID: <079.dc15271c72acb89a6ca597ef674aa150@trac.tools.ietf.org> References: <064.63adb5d03338921086f8490c4f50a27b@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <064.63adb5d03338921086f8490c4f50a27b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brads@coraid.com, n.brownlee@auckland.ac.nz, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #25: l. Figure 7 seems unnecessary to include? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:17:12 -0000 #25: l. Figure 7 seems unnecessary to include? Comment (by n.brownlee@…): Brad: what's happening with this? Everyone to comment -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: brads@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 19:48:06 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F351F0C4A for ; Wed, 24 Oct 2012 19:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtzRq1W-B9E8 for ; Wed, 24 Oct 2012 19:48:06 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E8B4D21F8F5B for ; Wed, 24 Oct 2012 19:48:05 -0700 (PDT) Received: from localhost ([127.0.0.1]:41982 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TRDU8-00031y-CO; Thu, 25 Oct 2012 04:47:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: n.brownlee@auckland.ac.nz, brads@coraid.com X-Trac-Project: eman Date: Thu, 25 Oct 2012 02:47:52 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/16#comment:2 Message-ID: <079.bcac537536af509ab30e5d720bdf398d@trac.tools.ietf.org> References: <064.e0edb6f25a043000c8d23b23fb4ed6cf@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <064.e0edb6f25a043000c8d23b23fb4ed6cf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: n.brownlee@auckland.ac.nz, brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 02:48:06 -0000 #16: c. What does parent/child mean when the direction of power flow between two devices can reverse? Comment (by brads@…): I presume the the question regards when a child uses its battery to power a parent. This seems a limited duration use case that doesn't change the normal flow of power from parent to child. -- --------------------------+------------------------- Reporter: n.brownlee@… | Owner: all Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------+------------------------- Ticket URL: eman From trac+eman@trac.tools.ietf.org Wed Oct 24 20:00:24 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A0221F8ACD for ; Wed, 24 Oct 2012 20:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8jVAsJp5JI5 for ; Wed, 24 Oct 2012 20:00:23 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A9B3F21F8546 for ; Wed, 24 Oct 2012 20:00:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:43329 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TRDfw-0005Kz-2t; Thu, 25 Oct 2012 05:00:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com X-Trac-Project: eman Date: Thu, 25 Oct 2012 03:00:04 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/26#comment:2 Message-ID: <070.8c3b91194781301f2796f06cc4132a69@trac.tools.ietf.org> References: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #26: ASHRAE 201P Power Quality X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 03:00:24 -0000 #26: ASHRAE 201P Power Quality Comment (by brads@…): I suggest we use the ASHRAE term "power quality" instead of our own term "power characteristics". -- -----------------------+------------------------- Reporter: brads@… | Owner: brad@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | -----------------------+------------------------- Ticket URL: eman From bnordman@lbl.gov Wed Oct 24 22:27:27 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C555521F906B for ; Wed, 24 Oct 2012 22:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KMA+vuoD4xb for ; Wed, 24 Oct 2012 22:27:27 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) by ietfa.amsl.com (Postfix) with ESMTP id 17E2C21F9069 for ; Wed, 24 Oct 2012 22:27:26 -0700 (PDT) X-Ironport-SBRS: 2.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAGjNiFDRVdXGemdsb2JhbABBAw6CPK11AYh0AYhiCCMBAQsJDAgUBCOCNwKBBAcDWhIBBQEiARIih2KeBWAJA55Ci2EFFoMpgykDiFyNF4EXjUEWKYNUXQ X-IronPort-AV: E=Sophos;i="4.80,645,1344236400"; d="scan'208";a="803608" Received: from mail-ye0-f198.google.com ([209.85.213.198]) by fe1.lbl.gov with ESMTP; 24 Oct 2012 22:27:25 -0700 Received: by mail-ye0-f198.google.com with SMTP id q10so2010390yen.1 for ; Wed, 24 Oct 2012 22:27:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=OA4TbSo9Ei5drOYSwY30AQdTiGCPzEbtvVhtibGd3vk=; b=cmn0b8Jwxqu44HQlEAtTD/TQoh3Ha8ihQLURoGLRoEvdaJIaqv/MKieEFBKjIKh142 VizBM/mkjmiF9it4zZA9OHpQOwXlaXfbU0rQ7HQglnwevi1WLCkTHRRWS41bSPiNP7zT Spzfrj/JaCxgNsayBy+Sqsb69kUe+CM5ZFEE5cp+C3HRV75U0b8IpWpVZtcgjrahkk7I j2eGYpZ8+Qxx36viXJn/VrERRB5i822OvDZNLJ80OV+LwDSU0auUSg++a6Zfnsk2/8i6 yhzXKZamVlnvYzt75OAUfuc75Z4oiGOeSIM1KTHQw/poMYtVUSw39Vh5UUsW7VK2jev/ QSxA== Received: by 10.58.173.41 with SMTP id bh9mr23805642vec.40.1351142845648; Wed, 24 Oct 2012 22:27:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.173.41 with SMTP id bh9mr23805638vec.40.1351142845547; Wed, 24 Oct 2012 22:27:25 -0700 (PDT) Received: by 10.58.125.73 with HTTP; Wed, 24 Oct 2012 22:27:25 -0700 (PDT) Date: Wed, 24 Oct 2012 22:27:25 -0700 Message-ID: From: Bruce Nordman To: Nevil Brownlee , eman mailing list Content-Type: multipart/alternative; boundary=047d7b5d857959862a04ccdb7512 X-Gm-Message-State: ALoCoQk7rsHw5HZXcJLZOCxt7UMmwgpObsZg9QYuOCbWCBYHnsJIFdAwp6SAYxGJu3ON7SeHX/P7+6R6qeJMq01OnYPJGwPJo91+xbglp/7huVcmzWlsYr55tYajtLWN4nwZJVUaSYdH Subject: [eman] Draft EMAN agenda for IETF 85 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 05:27:27 -0000 --047d7b5d857959862a04ccdb7512 Content-Type: text/plain; charset=ISO-8859-1 Please send Nevil and I any comments. --Bruce EMAN agenda, IETF 84 Wednesday, 8 November 2012, Salon A 1. Note well, agenda bashing, note takers, blue sheets, 5 min 2. Update from last meeting / WG Status 5 min 3. Requirements for Energy Management, draft-ietf-eman-requirements-08, Juergen Quittek, 20 min 4. Energy Management Framework, draft-ietf-eman-framework-06, John Parello, 30 min 5. MIBs 5.a. Energy-aware Networks and Devices MIB draft-ietf-eman-energy-aware-mib-07, John Parello, 10 min 5.b. Entity MIB (Version 4) draft-chandramouli-eman-rfc4133bis-03, Dan Romascanu, 10 min 5.c. Power and Energy Monitoring MIB draft-ietf-eman-energy-monitoring-mib-04, Mouli Chandramouli, 10 min 5.d. Definition of Managed Objects for Battery Monitoring draft-ietf-eman-battery-mib-07, Rolf Winter, 10 min 6. Energy Management (EMAN) Applicability Statement, draft-ietf-eman-applicability-statement-02, Mouli Chandramouli, 5 min 7. Review Milestones 8. Non-charter drafts (if time) 8.a. Use Cases for Power-Aware Networks draft-zhang-panet-use-cases-00.txt, Mingui Zhang, 5 min 8.b. Requirements for Power Aware Network draft-dong-panet-requirement-09, Jie Dong, 5 min 8.c. Nanogrids draft-nordman-nanogrids-00, Bruce Nordman, 5 min 9. Open microphone: whatever time is left -- *Bruce Nordman* Lawrence Berkeley National Laboratory *nordman.lbl.gov* BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --047d7b5d857959862a04ccdb7512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please send Nevil and I any comments.
--Bruce


EMAN agenda, IE= TF 84
Wednesday, 8 November 2012, Salon A

1. Note well, agenda ba= shing, note takers, blue sheets, 5 min

2. Update from last meeting /= WG Status=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 5 min

3. Requirements for Energy Management,
=A0=A0 draft-ietf-eman-requir= ements-08, Juergen Quittek, 20 min

4. Energy Management Framework, <= br>=A0=A0 draft-ietf-eman-framework-06, John Parello, 30 min

5. MIBs=

=A0 5.a. Energy-aware Networks and Devices MIB
=A0 draft-ietf-eman-e= nergy-aware-mib-07, John Parello, 10 min

=A0 5.b. Entity MIB (Versio= n 4)
=A0 draft-chandramouli-eman-rfc4133bis-03, Dan Romascanu, 10 min=A0
=A0 5.c. Power and Energy Monitoring MIB
=A0 draft-ietf-eman-energy-moni= toring-mib-04, Mouli Chandramouli, 10 min

=A0 5.d. Definition of Man= aged Objects for Battery Monitoring
=A0 draft-ietf-eman-battery-mib-07, = Rolf Winter, 10 min

6. Energy Management (EMAN) Applicability Statement,
=A0=A0 draft-ie= tf-eman-applicability-statement-02, Mouli Chandramouli, 5 min
=A0=A0 7. Review Milestones

8. Non-charter drafts (if time)

=A0=A0 = 8.a. Use Cases for Power-Aware Networks
=A0=A0=A0=A0=A0=A0=A0 draft-zhang-panet-use-cases-00.txt, Mingui Zhang, 5 m= in

=A0=A0 8.b. Requirements for Power Aware Network
=A0=A0=A0=A0= =A0=A0=A0 draft-dong-panet-requirement-09, Jie Dong, 5 min

=A0=A0 8.= c. Nanogrids
=A0=A0=A0=A0=A0=A0=A0 draft-nordman-nanogrids-00, Bruce Nor= dman, 5 min

9. Open microphone: whatever time is left



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

--047d7b5d857959862a04ccdb7512-- From Minoru.Teraoka@jp.yokogawa.com Thu Oct 25 01:51:27 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9081F21F899F for ; Thu, 25 Oct 2012 01:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDBRTc9AQ1E8 for ; Thu, 25 Oct 2012 01:51:26 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by ietfa.amsl.com (Postfix) with ESMTP id 4642921F8998 for ; Thu, 25 Oct 2012 01:51:26 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (localhost.localdomain [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.13.8/8.13.8) with ESMTP id q9P8pMvN021091; Thu, 25 Oct 2012 17:51:22 +0900 Received: from zex001-0m9025.jp.ykgw.net (zex001-0m9025.jp.ykgw.net [10.0.11.44]) by zns001-0m9001.yokogawa.co.jp (8.13.8/8.13.8) with ESMTP id q9P8pM8I021080; Thu, 25 Oct 2012 17:51:22 +0900 Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9025.jp.ykgw.net ([10.0.11.44]) with mapi; Thu, 25 Oct 2012 17:51:21 +0900 From: To: , Date: Thu, 25 Oct 2012 17:49:43 +0900 Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt Thread-Index: AQHNX0MUsD8/DD8mNE6B4Tg4arITD5cjx/sQgCNv8lGAbqwo4IAUdw2g Message-ID: <92A5C8A0221B31479EB7913C528ACC59017DA7A04462@EXMAIL01.jp.ykgw.net> References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com>, <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA2DC1FD5@EXMAIL01.jp.ykgw.net> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237DA2B6@xmb-rcd-x08.cisco.com> In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237DA2B6@xmb-rcd-x08.cisco.com> Accept-Language: en-US, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, ja-JP Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:51:27 -0000 Hello Mouli, Thank you for your comments. I understood the operation of the table. By the way, I'm concerned about using eoEnergyCollectionStartTime (SYNTAX TimeTicks) as an index of eoEnergyTable. Description of the eoEnergyParametersIntervalNumber object says that when the eoEnergyMaxConsumed and/or eoEnergyMaxProduced are in (one of) the two oldest measurement(s), they are left untouched and the next oldest measurement is replaced. When sysUpTime wraps, it may be possible that a value of eoEnergyCollectionStartTime repeats. I'm sorry if I have not been clear. Best regards, Minoru -- Minoru Teraoka Yokogawa Electric Corporation > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Friday, October 12, 2012 5:43 PM > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com); eman@ietf.org > Subject: RE: [eman] I-D Action: > draft-ietf-eman-energy-monitoring-mib-03.txt > > Hello Minoru, > > I presume you can use getnext in the table eoEnergyTable to obtain the values > of interest - eoEnergyConsumed, eoEnergyProduced , ... > > Suppose you did getnext of the table eoEnergyEntry Table > > - getnext (....5.1.1) - you would get the OID and the value of > eoEnergyConsumed. > The OID would have eoEnergyParametersIndex and > eoEnergyCollectionStartTime and eoEnergyCollectionStartTime is not > accessible. > > Thanks > Mouli > > -----Original Message----- > From: Minoru.Teraoka@jp.yokogawa.com > [mailto:Minoru.Teraoka@jp.yokogawa.com] > Sent: Friday, August 03, 2012 3:45 AM > To: Mouli Chandramouli (moulchan); eman@ietf.org > Subject: RE: [eman] I-D Action: > draft-ietf-eman-energy-monitoring-mib-03.txt > > Hi Mouli, > > We are trying to implement EMAN monitoring MIB and are having difficulty. > In eoEnergyTable, there are two indices, eoEnergyParametersIndex and > eoEnergyCollectionStartTime. The indices are needed to show which > parameters and when it started and ended. At present, syntax of > eoEnergyCollectionStartTime is TimeTicks. In this case, in order for NMS > to acquire information, it is necessary to guess the value of the index. > Although I am not an expert in MIB, I think that certain regularity is > required for the index. > > > eoEnergyTable OBJECT-TYPE > SYNTAX SEQUENCE OF EoEnergyEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table lists Energy Object energy measurements. > Entries in this table are only created if the > corresponding value of object eoPowerMeasurementCaliber > is active(2), i.e., if the power is actually metered." > ::= { energyObjectMibObjects 5 } > > eoEnergyEntry OBJECT-TYPE > SYNTAX EoEnergyEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry describing energy measurements." > INDEX { eoEnergyParametersIndex, > eoEnergyCollectionStartTime } > ::= { eoEnergyTable 1 } > > EoEnergyEntry ::= SEQUENCE { > eoEnergyCollectionStartTime TimeTicks, > eoEnergyConsumed Integer32, > eoEnergyProduced Integer32, > eoEnergyNet Integer32, > eoEnergyUnitMultiplier UnitMultiplier, > eoEnergyAccuracy Integer32, > eoEnergyMaxConsumed Integer32, > eoEnergyMaxProduced Integer32, > eoEnergyDiscontinuityTime TimeStamp > } > > eoEnergyCollectionStartTime OBJECT-TYPE > SYNTAX TimeTicks > UNITS "hundredths of seconds" > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The time (in hundredths of a second) since the > network management portion of the system was last > re-initialized, as specified in the sysUpTime [RFC3418]. > This object is useful for reference of interval periods > for which the energy is measured." > ::= { eoEnergyEntry 1 } > > > Best regards, > Minoru > -- > Minoru Teraoka > Yokogawa Electric Corporation > > > ________________________________________ > From: eman-bounces@ietf.org [eman-bounces@ietf.org] On Behalf Of Mouli > Chandramouli (moulchan) [moulchan@cisco.com] > Sent: Wednesday, July 11, 2012 6:04 PM > To: eman@ietf.org > Subject: Re: [eman] I-D Action: > draft-ietf-eman-energy-monitoring-mib-03.txt > > Hello all, > > An updated draft of the Power and Energy Monitoring MIB has been submitted. > > The modifications in this version are: > > - the use of eoMeterCapabilities object which can be useful to quickly > infer the capabilities of an "energy object". > - closing the open issues that were discussed at IETF EMAN WG > - terminology definitions deferred to EMAN-FRAMEWORK > > Please let us know if you have questions. > > Thanks > Brad, Juergen, Thomas, Benoit and Mouli > > > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, July 11, 2012 2:27 PM > To: i-d-announce@ietf.org > Cc: eman@ietf.org > Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Energy Management Working Group of the > IETF. > > Title : Power and Energy Monitoring MIB > Author(s) : Mouli Chandramouli > Brad Schoening > Juergen Quittek > Thomas Dietz > Benoit Claise > Filename : draft-ietf-eman-energy-monitoring-mib-03.txt > Pages : 81 > Date : 2012-07-11 > > Abstract: > This document defines a subset of the Management Information > Base (MIB) for power and energy monitoring of devices. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-eman-energy-monitoring-m > ib-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > > ----- > CONFIDENTIAL: This e-mail may contain information that is confidential or > otherwise protected from disclosure and intended only for the party to whom > it is addressed. If you are not the intended recipient, please notify the > sender by return and delete this e-mail. You are hereby formally advised > that any unauthorized use, disclosure or copying of this email is strictly > prohibited and may be unlawful. ----- CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful. From j.schoenwaelder@jacobs-university.de Thu Oct 25 01:56:18 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED25421F89B9 for ; Thu, 25 Oct 2012 01:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZG2LDOKaa4I for ; Thu, 25 Oct 2012 01:56:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7121F89B7 for ; Thu, 25 Oct 2012 01:56:18 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A34D20C0B; Thu, 25 Oct 2012 10:56:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qydgv3SMEhZa; Thu, 25 Oct 2012 10:56:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5A3920C06; Thu, 25 Oct 2012 10:56:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BCBAA227EB3C; Thu, 25 Oct 2012 10:56:16 +0200 (CEST) Date: Thu, 25 Oct 2012 10:56:16 +0200 From: Juergen Schoenwaelder To: Minoru.Teraoka@jp.yokogawa.com Message-ID: <20121025085616.GB85599@elstar.local> Mail-Followup-To: Minoru.Teraoka@jp.yokogawa.com, moulchan@cisco.com, eman@ietf.org References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA2DC1FD5@EXMAIL01.jp.ykgw.net> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237DA2B6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA7A04462@EXMAIL01.jp.ykgw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92A5C8A0221B31479EB7913C528ACC59017DA7A04462@EXMAIL01.jp.ykgw.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:56:19 -0000 On Thu, Oct 25, 2012 at 05:49:43PM +0900, Minoru.Teraoka@jp.yokogawa.com wrote: > Hello Mouli, > > Thank you for your comments. I understood the operation of the table. > By the way, I'm concerned about using eoEnergyCollectionStartTime > (SYNTAX TimeTicks) as an index of eoEnergyTable. > Description of the eoEnergyParametersIntervalNumber object says that > when the eoEnergyMaxConsumed and/or eoEnergyMaxProduced are in (one of) > the two oldest measurement(s), they are left untouched and the next > oldest measurement is replaced. When sysUpTime wraps, it may be > possible that a value of eoEnergyCollectionStartTime repeats. > I'm sorry if I have not been clear. > RFC 2578: 7.1.8. TimeTicks The TimeTicks type represents a non-negative integer which represents the time, modulo 2^32 (4294967296 decimal), in hundredths of a second between two epochs. When objects are defined which use this ASN.1 type, the description of the object identifies both of the reference epochs. For example, [3] defines the TimeStamp textual convention which is based on the TimeTicks type. With a TimeStamp, the first reference epoch is defined as the time when sysUpTime [5] was zero, and the second reference epoch is defined as the current value of sysUpTime. Note that TimeTicks itself is not linked to sysUpTime. TimeStamp is but TimeTicks is not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Minoru.Teraoka@jp.yokogawa.com Thu Oct 25 03:25:37 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7CD21F8962 for ; Thu, 25 Oct 2012 03:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UsqHAVxkiEj for ; Thu, 25 Oct 2012 03:25:36 -0700 (PDT) Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEEB21F893B for ; Thu, 25 Oct 2012 03:25:35 -0700 (PDT) Received: from zns001-0m9002.yokogawa.co.jp (localhost.localdomain [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.13.8/8.13.8) with ESMTP id q9PAPSUI005569; Thu, 25 Oct 2012 19:25:28 +0900 Received: from zex001-0m9026.jp.ykgw.net (zex001-0m9026.jp.ykgw.net [10.0.11.15]) by zns001-0m9002.yokogawa.co.jp (8.13.8/8.13.8) with ESMTP id q9PAPSIV005566; Thu, 25 Oct 2012 19:25:28 +0900 Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9026.jp.ykgw.net ([10.0.11.15]) with mapi; Thu, 25 Oct 2012 19:25:27 +0900 From: To: Date: Thu, 25 Oct 2012 19:25:26 +0900 Thread-Topic: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt Thread-Index: Ac2yjptFyo8dRN0yQcS9pys4y12VXwADBqwg Message-ID: <92A5C8A0221B31479EB7913C528ACC59017DA7A044BA@EXMAIL01.jp.ykgw.net> References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA2DC1FD5@EXMAIL01.jp.ykgw.net> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237DA2B6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA7A04462@EXMAIL01.jp.ykgw.net> <20121025085616.GB85599@elstar.local> In-Reply-To: <20121025085616.GB85599@elstar.local> Accept-Language: en-US, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, ja-JP Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 10:25:37 -0000 Hello Juergen, I see I did not understand correctly about TimeTicks. In EoEnergyCollectionStartTime, it begins from 0 at the time of an observation start. What I just wanted to say is that if there is an entry that updated maximum 16 months ago in the table, old and new index may exist. Is it too strict? Best regards, Minoru -- Minoru Teraoka Yokogawa Electric Corporation > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, October 25, 2012 5:56 PM > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com) > Cc: moulchan@cisco.com; eman@ietf.org > Subject: Re: [eman] I-D Action: > draft-ietf-eman-energy-monitoring-mib-03.txt > > On Thu, Oct 25, 2012 at 05:49:43PM +0900, Minoru.Teraoka@jp.yokogawa.com > wrote: > > Hello Mouli, > > > > Thank you for your comments. I understood the operation of the table. > > By the way, I'm concerned about using eoEnergyCollectionStartTime > > (SYNTAX TimeTicks) as an index of eoEnergyTable. > > Description of the eoEnergyParametersIntervalNumber object says that > > when the eoEnergyMaxConsumed and/or eoEnergyMaxProduced are in (one > > of) the two oldest measurement(s), they are left untouched and the > > next oldest measurement is replaced. When sysUpTime wraps, it may be > > possible that a value of eoEnergyCollectionStartTime repeats. > > I'm sorry if I have not been clear. > > > > RFC 2578: > > 7.1.8. TimeTicks > > The TimeTicks type represents a non-negative integer which represents > the time, modulo 2^32 (4294967296 decimal), in hundredths of a second > between two epochs. When objects are defined which use this ASN.1 > type, the description of the object identifies both of the reference > epochs. > > For example, [3] defines the TimeStamp textual convention which is > based on the TimeTicks type. With a TimeStamp, the first reference > epoch is defined as the time when sysUpTime [5] was zero, and the > second reference epoch is defined as the current value of sysUpTime. > > Note that TimeTicks itself is not linked to sysUpTime. TimeStamp is but > TimeTicks is not. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 ----- CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful. From j.schoenwaelder@jacobs-university.de Thu Oct 25 03:53:12 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4850A21F899A for ; Thu, 25 Oct 2012 03:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOWP5Hf7l3Fr for ; Thu, 25 Oct 2012 03:53:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E57D621F889E for ; Thu, 25 Oct 2012 03:53:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C11520C26; Thu, 25 Oct 2012 12:53:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NFrtLwya3JjM; Thu, 25 Oct 2012 12:53:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7B8C20C25; Thu, 25 Oct 2012 12:53:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 00883227F0B3; Thu, 25 Oct 2012 12:53:08 +0200 (CEST) Date: Thu, 25 Oct 2012 12:53:08 +0200 From: Juergen Schoenwaelder To: Minoru.Teraoka@jp.yokogawa.com Message-ID: <20121025105307.GA85900@elstar.local> Mail-Followup-To: Minoru.Teraoka@jp.yokogawa.com, moulchan@cisco.com, eman@ietf.org References: <20120711085632.3934.80262.idtracker@ietfa.amsl.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA402D2E6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA2DC1FD5@EXMAIL01.jp.ykgw.net> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4237DA2B6@xmb-rcd-x08.cisco.com> <92A5C8A0221B31479EB7913C528ACC59017DA7A04462@EXMAIL01.jp.ykgw.net> <20121025085616.GB85599@elstar.local> <92A5C8A0221B31479EB7913C528ACC59017DA7A044BA@EXMAIL01.jp.ykgw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92A5C8A0221B31479EB7913C528ACC59017DA7A044BA@EXMAIL01.jp.ykgw.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 10:53:12 -0000 My point here was that TimeTicks does not imply sysUpTime. I did not look at the object in question. Now that I do that, I read: eoEnergyCollectionStartTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of seconds" MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized, as specified in the sysUpTime [RFC3418]. This object is useful for reference of interval periods for which the energy is measured." ::= { eoEnergyEntry 1 } This really seems to be a TimeStamp object. I do agree that using sysUpTime as an epoch needs to be carefully thought through since any discontinuity that resets sysUpTime makes the value of this object meaningless. I am also not sure I understand the meaning of "for reference of interval periods". /js On Thu, Oct 25, 2012 at 07:25:26PM +0900, Minoru.Teraoka@jp.yokogawa.com wrote: > Hello Juergen, > > I see I did not understand correctly about TimeTicks. > In EoEnergyCollectionStartTime, it begins from 0 at the time of an > observation start. What I just wanted to say is that if there is an entry > that updated maximum 16 months ago in the table, old and new index may exist. > Is it too strict? > > Best regards, > Minoru > -- > Minoru Teraoka > Yokogawa Electric Corporation > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, October 25, 2012 5:56 PM > > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com) > > Cc: moulchan@cisco.com; eman@ietf.org > > Subject: Re: [eman] I-D Action: > > draft-ietf-eman-energy-monitoring-mib-03.txt > > > > On Thu, Oct 25, 2012 at 05:49:43PM +0900, Minoru.Teraoka@jp.yokogawa.com > > wrote: > > > Hello Mouli, > > > > > > Thank you for your comments. I understood the operation of the table. > > > By the way, I'm concerned about using eoEnergyCollectionStartTime > > > (SYNTAX TimeTicks) as an index of eoEnergyTable. > > > Description of the eoEnergyParametersIntervalNumber object says that > > > when the eoEnergyMaxConsumed and/or eoEnergyMaxProduced are in (one > > > of) the two oldest measurement(s), they are left untouched and the > > > next oldest measurement is replaced. When sysUpTime wraps, it may be > > > possible that a value of eoEnergyCollectionStartTime repeats. > > > I'm sorry if I have not been clear. > > > > > > > RFC 2578: > > > > 7.1.8. TimeTicks > > > > The TimeTicks type represents a non-negative integer which represents > > the time, modulo 2^32 (4294967296 decimal), in hundredths of a second > > between two epochs. When objects are defined which use this ASN.1 > > type, the description of the object identifies both of the reference > > epochs. > > > > For example, [3] defines the TimeStamp textual convention which is > > based on the TimeTicks type. With a TimeStamp, the first reference > > epoch is defined as the time when sysUpTime [5] was zero, and the > > second reference epoch is defined as the current value of sysUpTime. > > > > Note that TimeTicks itself is not linked to sysUpTime. TimeStamp is but > > TimeTicks is not. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > ----- > CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jparello@cisco.com Thu Oct 25 11:44:45 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A294F21F85C0 for ; Thu, 25 Oct 2012 11:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.168 X-Spam-Level: X-Spam-Status: No, score=-10.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pPQ0EhptSZJ for ; Thu, 25 Oct 2012 11:44:43 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BE47321F858F for ; Thu, 25 Oct 2012 11:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=327; q=dns/txt; s=iport; t=1351190683; x=1352400283; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=/C8VnVCK6FLDcezz3+m0VVTJbKED1UsdZrR8p10AfhE=; b=JMh+BCK/yWMOiJJETddm9+1GIwT7muo7k0zOCFwtZGf7nZY3QHb4k168 QiG5A98MURfv2BTa2+V77/FF9QQCekjhzKYfGUH12JsT1SpowbyCaaHjU 4xvb+m9ikbH2orYMRH/Rik9KTFLdbakf+QrnQ8Ecvb2pJWGXeuF0XFyIL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKGHiVCtJXG8/2dsb2JhbABEhU+8YYEIgiABAgISASdRASoUQiYBBBsah2EBC5xwgSygHZFtYQOXDY07gWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="135390039" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 25 Oct 2012 18:44:43 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9PIihfC018439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 25 Oct 2012 18:44:43 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.95]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 13:44:43 -0500 From: "John Parello (jparello)" To: "eman@ietf.org" Thread-Topic: Work from the Energy SIG at ODVA Thread-Index: Ac2y4Mt3Ktm5B/7nSWSJZKOPSg26jQ== Date: Thu, 25 Oct 2012 18:44:42 +0000 Message-ID: <9C213D38848B89428F46808B16F6F0860CC9DE@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.223.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19306.000 x-tm-as-result: No--24.607100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] Work from the Energy SIG at ODVA X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:44:45 -0000 Presentation from the annual meeting. Exactly the same work we are doing here in the industrial side in conjuncti= on with ASHRAE etc... Well worth the read. http://odva.org/Portals/0/Library/Annual%20Meeting%202012/2012_ODVA_Confere= nce_Technical%20Approach_Optimization%20of%20Energy%20Usage_FINAL_PPT.pdf JP From trac+eman@trac.tools.ietf.org Thu Oct 25 11:52:18 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD1121F867E for ; Thu, 25 Oct 2012 11:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 170dD8Mk2WTQ for ; Thu, 25 Oct 2012 11:52:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7825621F8662 for ; Thu, 25 Oct 2012 11:52:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:48851 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TRSX6-00029g-Ql; Thu, 25 Oct 2012 20:51:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "eman issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com X-Trac-Project: eman Date: Thu, 25 Oct 2012 18:51:56 -0000 X-URL: http://tools.ietf.org/eman/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/eman/trac/ticket/26#comment:3 Message-ID: <070.1ef77edb492dca934dc11dd91a0c03be@trac.tools.ietf.org> References: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <055.1ebf9c4bc8a3a981d504d2e1cfb60986@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brad@coraid.com, n.brownlee@auckland.ac.nz, brads@coraid.com, eman@ietf.org X-SA-Exim-Mail-From: trac+eman@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: eman@ietf.org Subject: Re: [eman] #26: ASHRAE 201P Power Quality X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:52:18 -0000 #26: ASHRAE 201P Power Quality Comment (by brads@…): While discussed at Vancouver, that discussion occurred before ASHRAE 201P was released. In light of 201P, the reasons for the Vancouver decision appear now erroneous. The question Bruce raised in our discussion prior to Vancouver, was "What are the reference values for each then?" [eman mailing list March 13, 2012]. 201P answers this, defining these as the raw measurements, not the determination once they're applied to a reference value. The attributes here are raw quality metrics like frequency, voltage, power factor, active, reactive, apparent power, phase impedance. At the very least, we should cross-reference our invented term with the standard one. Even better would be to use the standard terminology. -- -----------------------+------------------------- Reporter: brads@… | Owner: brad@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: Keywords: | -----------------------+------------------------- Ticket URL: eman From Rolf.Winter@neclab.eu Wed Oct 31 05:44:58 2012 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4F21F86A6 for ; Wed, 31 Oct 2012 05:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwcdGu8z8WBz for ; Wed, 31 Oct 2012 05:44:57 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A33EB21F865E for ; Wed, 31 Oct 2012 05:44:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 02A291023B5 for ; Wed, 31 Oct 2012 13:44:57 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x49PQyxlIC4D for ; Wed, 31 Oct 2012 13:44:56 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D76D210065E for ; Wed, 31 Oct 2012 13:44:51 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 31 Oct 2012 13:44:51 +0100 From: Rolf Winter To: eman mailing list Thread-Topic: (late) comments on the requirements document Thread-Index: Ac23ZX3q5itfIy7oTY2KbOshWXwVDg== Date: Wed, 31 Oct 2012 12:44:40 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D554FC004@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [eman] (late) comments on the requirements document X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 12:44:58 -0000 Hi, sorry for a bunch of late comments. Most are smaller ones: The term "Power State" stands out strangely since it is capitalized whereas= most other terms are not. I would align this and not capitalize the term p= ower state. It doesn't seem to be a new/special term that would require the= capitalization. In section 3.5 there is no bullet point for controlling power provided at p= ower outles. This would be useful function I guess and I am sure is impleme= nted in PDUs etc. Maybe adding a bullet point "controlling power provided a= t power outles" would make a lot of sense. In section 5.2 second para, start of sentence need to begin with capital le= tter. Also the term entity and device seem to be used interchangeably. Mayb= e stick to device. In section 5.3 "power characteristics" and "power parameters" seem to be us= ed interchangeably. I seem to remember we wanted to stick to characteristic= s. In section 5.3.5 you refer to an "entire entity". I think "device" would be= the better term here. Also in section 6 I think the term entity should be = replaced with device where appropriate. At least with the edits suggested b= efore this would be consistent. Isn't what 7.6 requires sometimes really hard to implement. E.g. how will y= ou signal that a THD value is available at one of the meters measuring for = you and not at another meter in the same power distribution tree? Some of the appendix could move the main text. Since this is the requiremen= ts document and not a particular solution, the document could argue why or = why not these standards do fulfill the requirements. An alternative is to r= emove some of this. In particular the entity MIB bit needs an update since = it is under revision right now. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20