From ietf@quittek.at Tue Mar 1 00:17:24 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80ECD3A69C2 for ; Tue, 1 Mar 2011 00:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nA9w8Z8Gptk for ; Tue, 1 Mar 2011 00:17:14 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 727213A6A03 for ; Tue, 1 Mar 2011 00:17:13 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MGVFc-1Ppuwo0fZI-00DhW5; Tue, 01 Mar 2011 09:18:14 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Tue, 1 Mar 2011 09:18:15 +0100 To: John Parello (jparello) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:iTvv0Wma85eFtEV21sQLngix9aA0Dz6sPi5n0OfYhsD 3/fz/naVywCvDRX56DXPCFU4L35uX088WhmH5sZaNqVcK3c1Gm Dr5ACY9AiOtPTuWN3kDsOKpitRt3W054JczBGGuU76kS67QciA VVQplo7Bz7twp9AGq2u8wQneSGdEM67mLQvMniCttYEVIqA2PG GH/qGCOHnM1RF9zTp9pcA== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 08:17:26 -0000 Hi John, this seems to be a misunderstanding. I said it is not a technical argument that if we do not follow your = proposal we would not need an EMAN WG. I agree that indeed it is a technical argument that your proposal may = help building great management applications.=20 My comment on this one is that is certainly is an objective of our work = in EMAN, but probably not the one with top priority. Thanks, Juergen Am 01.03.2011 um 00:54 schrieb John Parello (jparello): > Hi Juergen, >=20 > Thanks that's where we disagree :) >=20 > IMO it is a technical argument. Without adding an common interface for > devices *and* the ability to manage devices attached to a = communication > network you can achieve your goals with simple data models added to > sensor, entity and even UPS mib. >=20 > Interface vs implementation abstraction, retrieval, all partitioning = of > data is a technical decision. It's not a business, time to market or > artistic argument. >=20 > I'll leave the debate to the rest of the group as you can see where my > opinion goes. >=20 > Looking forward to feedback! > Jp >=20 >=20 > -----Original Message----- > From: Juergen Quittek [mailto:ietf@quittek.at]=20 > Sent: Monday, February 28, 2011 1:08 PM > To: John Parello (jparello) > Cc: eman mailing list > Subject: Re: [eman] modeling power states >=20 > Hi John, >=20 > Thanks for your comments. Please find replies inline. >=20 > Am 28.02.2011 um 18:22 schrieb John Parello (jparello): >=20 >> Thanks Juergen for summarizing this.=20 >>=20 >> I think the stall we've seen on the proposals is directly related to > not >> converging on an agreement for power states and parent child >> aggregation. >>=20 >> We've asked this question on the list before with no dialogue and our >> conversations have come down to two differences >>=20 >> The proposal submitted, by verges, quittek, parello, claise are very >> similar. The similarities are in data elements and only vary by >> partitioning (ie class). The only differences exist in two items >>=20 >> 1) Power states / Interfaces >> 2) Parent Child relationship (or aggregator as specified in > references) >>=20 >> IMO any work in EMAN must contain the addition of an IETF power >> interface as described in claise architecture (or some compromise as > you >> listed with IANA interfaces). It must also contain the addition of >> parent/child/aggregator relationship for non SNMP energy management. >=20 > You say we MUST adopt the power states from the claise architecture=20 > and we MUST adopt the parent/child concept. >=20 > The reasons you give for this in the paragraphs below are > - Otherwise we would not need an EMAN WG. > - This helps manufacturers to build sophisticated energy management > systems. >=20 > I would not accept the first one as a technical argument,=20 > On your second argument I would reply that providing good interfaces > for building sophisticated applications is certainly an objective=20 > of our work in EMAN, but probably not the one with top priority. >=20 > Thanks, >=20 > Juergen >=20 >=20 >> Without those two additions the work in this group can easily be > covered >> by two additions to existing SNMP objects. First would be adding > energy >> related fields (watts units or Kwh) to the sensor mib. The seconds > would >> be to add better the context information (see energy aware proposal) > to >> the entity mib. A simple on/off/standby state already exists in oper >> status. >>=20 >> So in short without an IETF EMAN set of power states / interfaces to >> unify or map to the states from other orgs as you listed, *and* the >> ability to monitor/aggregate non SNMP devices - the work here can > easily >> be absorbed into the sensor and entity mibs with minor additions. >>=20 >> The experience I've personally had with energy management and running >> code with exactly these additions has shown that manufacturers can > build >> sophisticated energy management systems and devices for many = different >> network connected devices with a converged set of states and the > parent >> child relationship.=20 >>=20 >> Having run a program which adds these features I'm strongly in favor > of >> a solution that has a unified power interface and the concept of a >> parent / child to allow for non-snmp management of power. >>=20 >> Jp >>=20 >>=20 >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of >> Juergen Quittek >> Sent: Monday, February 28, 2011 4:07 AM >> To: eman mailing list >> Subject: [eman] modeling power states >>=20 >> Dear all, >>=20 >> We have two proposals for a Power/Energy MIB module: >>=20 >> - draft-claise-energy-monitoring-mib-06 >> - draft-quittek-power-mib-02 >>=20 >> Among the authors of both documents we are currently trying to merge >> them. >> But there are some open issues that should be discussed on the = mailing >> list. Here is the probably biggest of them: modeling power states. >>=20 >> For simplifying energy management we want to introduce the concept of >> power states (aka power levels). A power state will indicate roughly >> how >> much power a device consumes. Examples for simple power states are > off, >> sleep, and operational states. >>=20 >> In the envisioned EMAN MIB modules, a power state is characterized by > a >> descriptive name and the device's expected power input in this state >> (max/min/average). >>=20 >> Power states are not a new concept. The DMTF has already defined a > set >> of >> power states and there is the Other standards bodies as the DMTF >> (Distributed Management Task Force) and there is the ACPI (Advanced >> Configuration and Power Interface) for PC motherboards. And there = may >> be >> more than these out there. I listed some DMTF and ACPI states at the >> end >> of this message. >>=20 >> An easy solution for EMAN would be just adopting one of these sets. >> However, there are issues with the ones we looked at. ACPI was >> developed >> for PC motherboards and is quite PC-centric. Also it defines states >> that >> seem to be superfluous, because so far, almost no one has implemented >> them. Also the DMTF model seems to have a narrower scope than >> envisioned >> by the EMAN WG. >>=20 >> At some point in time, the EMAN WG hast to make a decision, which > power >> state model to adopt. Here is a set of alternatives. The first four >> have >> fixed sets of power states. >>=20 >> Option 1: fixed minimum >> Just support three power states (off, sleep (stand-by), operational) >> This has clear semantics, but there are several people claiming it's > too >> restrictive. >>=20 >> Option 2: fixed DMTF >> Just use the states defined by DMTF. >> Might be too much focussed n PCs. >>=20 >> Option 3: fixed ACPI >> Just use the states defined by ACPI. >> Might be too much focussed n PCs. >>=20 >>=20 >>=20 >> Option 4: fixed EMAN >> Define a new fixed set of power levels within the EMAN WG. >>=20 >> Option 5: IANA-registered power states >> Have power states be registered at IANA. >> We would start with registering (off, sleep, operational, the DMTF > set, >> and the ACPI set. >> Manufacturers can then register further ones. >>=20 >>=20 >> There has been discussions pointing out that these fixed sets may not > be >> sufficient, particularly if non-IT equipment should also be covered. >>=20 >> For being more open, the idea to support user-defined or >> manufacturer-defined power states of devices has been developed. In >> such >> a state, for example, certain components of a device may be switched > off >> or put to sleep. Which ones are switched off in which state is to be >> defined by the user/operator/manufacturer and may be chosen such that >> operational needs are met. >>=20 >> Again, there are several proposals how to do this. All of them favor > a >> two-level approach that distinguishes between rather flexible > functional >> power states and rather fixed basic power states. Functional power >> states >> would be defined by the manufacturer, operator, or user. These would > be >> the power states that would be reported by a device. However, in > order >> to >> better define the semantics of functional power states, Each of these >> would be mapped to exactly one basic power states. This means that a >> property of any functional state would be the basic state it maps to. >> Basic power states would be fixed, such as the ones used in options > 1-5. >> An easy example would be functional power states defined by >> user/operator/manufacturer with each state indicating whether it is = an >> off >> state, a sleep state or an operational state. >>=20 >> Here are the corresponding options: >>=20 >> Option 6: flexible functional states mapped to a fixed set of basic >> states >> States could be defined flexibly. But each state would indicate a > basic >> state to which it corresponds. Basic states could be either basic >> (off/sleep/operational) or the DMTF set or the ACPI set >>=20 >> Option 7: flexible functional states mapped to a IANA registered set > of >> basic states >> This is like Option 6, but basic states would be registered at IANA > and >> can be extended. We would register all DMTF and ACPI states and >> probably >> some more at IANA. Manufacturers could add more. >>=20 >> Option 8: IANA-registered sets of functional states, only three basic >> states >> The main reasoning behind this option is that is should always be > clear >> whether a power state is an off state, a sleep state, or an > operational >> state. Therefore, only these three basic states are supported. This >> would be in line with an instance of Option 6. However, this option > has >> an extension for the functional states. It suggests that for >> customizing >> devices in order to be compliant with given management systems, for >> example a DMTF-based system, it should be possible to restrict >> functional >> power states to a given set that is registered at IANA. An example >> would >> be the DMTF states. We would register a flag at IANA that indicates > we >> are using DMTF states only. This would signal the management >> application >> that all power state IDs are in line with power state numbering as >> defined >> by IANA. Analogously, ACPI and further sets could be registered at >> IANA. >> A fallback to Option 6 could be realized by registering a set number > of >> 0 >> at IANA that does not impose any limit for functional states. >>=20 >> Obviously, there are more possible options. If you think there is a >> better one, please send it to this list. >>=20 >> I know this discussion is not easy, but we have to have it in order = to >> make the right decision in the EMAN WG. Please take some time and > think >> about what you consider to be the best way to go. And of course send >> questions on the issue. >>=20 >> Thanks. >>=20 >> Juergen >>=20 >>=20 >> DMTF (Distributed Management Task Force) power states: >> - 2 (Power On) >> - 3 (Sleep - Light) >> - 4 (Sleep - Deep) >> - 5 (Power Cycle (Off Soft)) >> - 6 (Power Off - Hard) >> - 7 (Hibernate) >> - 8 (Power Off - Soft) >> - 9 (Power Cycle (Off Hard)) >> - 10 (Master Bus Reset) >> - 11 (Diagnostic Interrupt (NMI)) >> - 12 (Power Off - Soft Graceful) >> - 13 (Power Off - Hard Graceful) >> - 14 (Master Bus Reset Graceful) >> - 15 (Power Cycle (Off - Soft Graceful)) >> - 16 (Power Cycle (Off - Hard Graceful)) >>=20 >> ACPI (Advanced Configuration and Power Interface Specification) power >> states for PC motherboards: >> - G3-S5 (Off-Hard) >> - G2-S5 (Off-Soft) >> - G1-S4 (Hibernate) >> - G1-S3 (Sleep-Deep) >> - G1-S2 (Sleep-Light) >> - G1-S1 (Sleep-Light) >> - G0-S0-P5 >> - G0-S0-P4 >> - G0-S0-P3 >> - G0-S0-P2 >> - G0-S0-P2 >> - G0-S0-P2 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 >=20 From ietf@quittek.at Tue Mar 1 00:42:07 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5433A6A66 for ; Tue, 1 Mar 2011 00:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB-ykmF1wlI2 for ; Tue, 1 Mar 2011 00:42:05 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id BF1C03A6969 for ; Tue, 1 Mar 2011 00:42:02 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MaFzQ-1PacSi29HM-00Jrwn; Tue, 01 Mar 2011 09:43:00 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> In-Reply-To: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Tue, 1 Mar 2011 09:43:01 +0100 To: chrisv@cyberswitching.com X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:gQC62ZJeZilOyi80vYrJ4hwxjZou5kGAm7dvHt6cVlS rGdep5Q8BIkdTRaoPlXT3NGmPmaMac9O8sHJrGc4rlfiIKmY4e cyd/VRk8TlQENpHqLz5+ce//uqlH9jqDrz+AIyGu0NDZkk96/J LUdlAf/goqlWlD0FHAp+ymDk8PW2KFTSACbldNvliNV6pc7OAG UOMRcAdNUMzuAXK7BkNPA== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 08:42:07 -0000 Hi Chris, Thank you for your thoughts. I have three comments: - I do not think that anyone in this WG is still proposing seriously to = go for an extension of the ENTITY-MIB. It seems to be clear that this = is not sufficient. Maybe the chairs can check if we have consensus on = this issue. I guess we have it. - I like your example below and yes, we should be able to support this. = But this is not a problem of power states. This is about the = parent/child concept which we have not discussed so far on this list. My = concern about parent child is that it may be too simple to model complex = cases like the one you describe and others. This is why I try to have a = clean reference model.=20 - Yes, you are right, the reference model currently has very few example = scenarios with multiple instances of a port or a PC. But the only = purpose of section 3.4 is to explain how the scenarios and figures = expand to multiple instances. If think this is not sufficient, I can add = more explanations to it. If you think it would be helpful in any aspect = to provide a figure with the PDU with 24 ports you describe in your = message, I will be glad to draw this figure for you and include it in = the next revision. Thanks, Juergen Am 01.03.2011 um 06:06 schrieb chrisv@cyberswitching.com: > Hi John and Juergen, >=20 >>> Without those two additions the work in this group can easily be = covered >>> by two additions to existing SNMP objects. First would be adding = energy >>> related fields (watts units or Kwh) to the sensor mib. The seconds = would >>> be to add better the context information (see energy aware proposal) = to >>> the entity mib. A simple on/off/standby state already exists in oper >>> status. >>>=20 >>> So in short without an IETF EMAN set of power states / interfaces to >>> unify or map to the states from other orgs as you listed, *and* the >>> ability to monitor/aggregate non SNMP devices - the work here can = easily >>> be absorbed into the sensor and entity mibs with minor additions. >=20 > I disagree with the argument that ENTITY-MIB can be extended to = support > power data properly. ENTITY-MIB contains an inherent flaw, in that it > separates physical and logical entities into distinct buckets that > cannot overlap in sparse tables. >=20 > WHEN -- not if -- the IETF decides to provide a meter hook for logical > entities (individual programs, virtual machines on a shared server, > etc.), an EMAN schema based on ENTITY-MIB would have to be forked to > support this. That duplication of effort is pointless. >=20 > And I say "when" because it's a matter of time. Lots of people are > already working on this problem because there is a huge amount of = money > involved: >=20 > 30-second internet search: > http://research.microsoft.com/apps/pubs/default.aspx?id=3D120435 >=20 > The IETF exists to enable others' innovation and interoperability in > those pursuits. It is not our responsibility to debate the merits of > this undertaking. It is, however, our duty to acknowledge this = pursuit > and prepare to integrate it into schema. >=20 > So while it's good to make a nod to the predecessor ENTITY-MIB, I urge > us to make a structural break from it. >=20 >>> IMO any work in EMAN must contain the addition of an IETF power >>> interface as described in claise architecture (or some compromise as = you >>> listed with IANA interfaces). It must also contain the addition of >>> parent/child/aggregator relationship for non SNMP energy management. >>=20 >> You say we MUST adopt the power states from the claise architecture >> and we MUST adopt the parent/child concept. >>=20 >> The reasons you give for this in the paragraphs below are >> - Otherwise we would not need an EMAN WG. >> - This helps manufacturers to build sophisticated energy management >> systems. >>=20 >> I would not accept the first one as a technical argument, >> On your second argument I would reply that providing good interfaces >> for building sophisticated applications is certainly an objective >> of our work in EMAN, but probably not the one with top priority. >=20 > I agree with John's first point ("otherwise EMAN wouldn't exist") in = the > light that, even though it may not yet be fully and properly > articulated, there is a sense that EMAN is needed because the existing > solution architecture just doesn't quite do what is needed. I mean, = why > does your MIB draft exist? You see a problem and have tried to solve = it > because a solution doesn't yet exist. >=20 > Here's a structural example to illustrate the point: >=20 > Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor = types, > the data COULD be represented. For a single intelligent power supply = on > a server that monitors voltage, amperage, real power, apparent power, > power factor, and frequency, we'd have 6 entities enumerated in > ENTITY-MIB. And all of this would need to be tied together logically > into a "Power Supply" concept, so that'd be another entity -- 7 in > total. >=20 > For a single server, sure, fine, do-able. Tiny scale. >=20 > What about a 24-outlet PDU? Or a 84-circuit panelboard? >=20 > http://www.kondra.com/circuit/circuit.html >=20 > Eaton Branch Circuit Monitoring Whitepaper: > http://tinyurl.com/5rpmhrp >=20 > Managing 168 entities on a PDU or 588 entities on a panelboard is > a ridiculous burden on the user who is consuming the agent's data. >=20 > "Bonding" these entities that are a common purpose reduces the = magnitude > by a factor of 7, and simplifies the conceptual use of the framework. > Users don't need to think in terms of "voltage sensor for Outlet 1" = but > instead can refer to that same data as "Outlet 1's voltage." >=20 > Juergen, it seems like you're so busy focused on a conceptual model = that > real-world usability may be getting sacrificed. Each of your examples > only reflects a single entity at a time. Why not kick up the examples = a > notch and model something like an intelligent PDU with the following > properties? >=20 > 1. 24 outlets, single phase > 2. 6 banks (4 outlets per bank), single phase > 3. 2 inputs (3 banks per input), three phase > 4. "Ganged" outlets (multiple outlets that are managed as one > construct) > 5. High current alerts, low current alerts, circuit breaker alerts, > high voltage alerts (spikes), low voltage alerts (sags) -- all of > which can be applied to a physical entity or a logical entity > (like an outlet "gang") > 6. Internal network card and metering logic > 7. Outlets "owned" by different users (think co-location facility, > "context") > 8. Manage power via 5 different interface modalities/mechanisms > 9. Except for the existence of the outlets/banks/inputs/"gangs", all > other properties are potentially optional >=20 > I challenge you -- everyone participating in the EMAN list -- to model > this level of complexity. If your MIB can withstand this, it's a good > MIB (IMO, of course). > Thanks, > Chris From jparello@cisco.com Tue Mar 1 01:38:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCD83A63CA for ; Tue, 1 Mar 2011 01:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhPi7ctyIb2p for ; Tue, 1 Mar 2011 01:38:20 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 742C13A6359 for ; Tue, 1 Mar 2011 01:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=7753; q=dns/txt; s=iport; t=1298972363; x=1300181963; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mRKnh4CAeUxRitSt+sY4iunUONQkyvmUBueI9UYqy0A=; b=KBJX5drvz+REILPwk4/a2VJL98T0QpAxmX8Cc80mMrJLBDqk2g3INjgY jv4HSGo08QdT6F5I5wop9/SCcWoU79ZooT8Bm3MSBq543ybhQ2twmjv1n zG2CgrC0pAKvcwnvgG1RRA7alPh2BHlhaJHa9j013TgTdJ6usGhZVjKnr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAPtNbE2rR7H+/2dsb2JhbACXdY5VdJ5xnBOCdoJrBIUSilI X-IronPort-AV: E=Sophos;i="4.62,246,1297036800"; d="scan'208";a="336844918" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2011 09:39:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p219d5qJ000051; Tue, 1 Mar 2011 09:39:05 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 01:39:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 01:35:22 -0800 Message-ID: In-Reply-To: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvXzmY1iAEwyPN+QRSyhhZVaq7dugAI5jLw References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> From: "John Parello (jparello)" To: X-OriginalArrivalTime: 01 Mar 2011 09:39:05.0593 (UTC) FILETIME=[8190BE90:01CBD7F4] Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 09:38:22 -0000 Hi Chris, Thanks I think that's a great challenge to throw down and we should use that as a reference case. I was specifically terse in my reply because I don't want to take up the discussion or poison the pool if you will with an issue we've been discussion off alias for almost a year. Fresh opinions are needed Just to clarify a point though... My concern is that in presenting the architecture in claise we made a case to the OPSAWG that the entity mib, sensor mib and UPS mib are insufficient to model energy management. Specifically we proposed that we need a model(s) of power state interface(s) *and* a parent/child model to handle implementation that will not support SNMP. That supposition let to the formation of this group and the need to create a new class of data.=20 This is a data modeling exercise. If you have attributes to add to a model you first look at your existing classes to see if there's a fit. You create a new class when there's a need to model something new ( anew actor etc) not just because you have a few more attributes. So with the addition of power states and parent/child we postulated that a new class of data was needed. That would mean we could also factor data in that class that might readily have resided in the entity, sensor and UPS objects. My challenge then would be that if those concepts are removed then the burden of justifying a new class has to be taken up again.=20 I presented an argument for a new class of data due to these concepts and reason you pointed out. The sum total of those justifies a new class of data. If those concepts are removed then IMO any object model and proposal must re-affirm/prove the need for the new class and justify why the existing classes are insufficient. I don't think you can remove the assumptions and then retain the conclusion. HTH to clarify... Thanks Jp -----Original Message----- From: chrisv@cyberswitching.com [mailto:chrisv@cyberswitching.com]=20 Sent: Monday, February 28, 2011 9:06 PM To: John Parello (jparello) Cc: Juergen Quittek; eman mailing list Subject: Re: [eman] modeling power states Hi John and Juergen, > > Without those two additions the work in this group can easily be covered > > by two additions to existing SNMP objects. First would be adding energy > > related fields (watts units or Kwh) to the sensor mib. The seconds would > > be to add better the context information (see energy aware proposal) to > > the entity mib. A simple on/off/standby state already exists in oper > > status. > > > > So in short without an IETF EMAN set of power states / interfaces to > > unify or map to the states from other orgs as you listed, *and* the > > ability to monitor/aggregate non SNMP devices - the work here can easily > > be absorbed into the sensor and entity mibs with minor additions. I disagree with the argument that ENTITY-MIB can be extended to support power data properly. ENTITY-MIB contains an inherent flaw, in that it separates physical and logical entities into distinct buckets that cannot overlap in sparse tables. WHEN -- not if -- the IETF decides to provide a meter hook for logical entities (individual programs, virtual machines on a shared server, etc.), an EMAN schema based on ENTITY-MIB would have to be forked to support this. That duplication of effort is pointless. And I say "when" because it's a matter of time. Lots of people are already working on this problem because there is a huge amount of money involved: 30-second internet search: http://research.microsoft.com/apps/pubs/default.aspx?id=3D120435 The IETF exists to enable others' innovation and interoperability in those pursuits. It is not our responsibility to debate the merits of this undertaking. It is, however, our duty to acknowledge this pursuit and prepare to integrate it into schema. So while it's good to make a nod to the predecessor ENTITY-MIB, I urge us to make a structural break from it. > > IMO any work in EMAN must contain the addition of an IETF power > > interface as described in claise architecture (or some compromise as you > > listed with IANA interfaces). It must also contain the addition of > > parent/child/aggregator relationship for non SNMP energy management. > > You say we MUST adopt the power states from the claise architecture > and we MUST adopt the parent/child concept. > > The reasons you give for this in the paragraphs below are > - Otherwise we would not need an EMAN WG. > - This helps manufacturers to build sophisticated energy management > systems. > > I would not accept the first one as a technical argument, > On your second argument I would reply that providing good interfaces > for building sophisticated applications is certainly an objective > of our work in EMAN, but probably not the one with top priority. I agree with John's first point ("otherwise EMAN wouldn't exist") in the light that, even though it may not yet be fully and properly articulated, there is a sense that EMAN is needed because the existing solution architecture just doesn't quite do what is needed. I mean, why does your MIB draft exist? You see a problem and have tried to solve it because a solution doesn't yet exist. Here's a structural example to illustrate the point: Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor types, the data COULD be represented. For a single intelligent power supply on a server that monitors voltage, amperage, real power, apparent power, power factor, and frequency, we'd have 6 entities enumerated in ENTITY-MIB. And all of this would need to be tied together logically into a "Power Supply" concept, so that'd be another entity -- 7 in total. For a single server, sure, fine, do-able. Tiny scale. What about a 24-outlet PDU? Or a 84-circuit panelboard? http://www.kondra.com/circuit/circuit.html Eaton Branch Circuit Monitoring Whitepaper: http://tinyurl.com/5rpmhrp Managing 168 entities on a PDU or 588 entities on a panelboard is a ridiculous burden on the user who is consuming the agent's data. "Bonding" these entities that are a common purpose reduces the magnitude by a factor of 7, and simplifies the conceptual use of the framework. Users don't need to think in terms of "voltage sensor for Outlet 1" but instead can refer to that same data as "Outlet 1's voltage." Juergen, it seems like you're so busy focused on a conceptual model that real-world usability may be getting sacrificed. Each of your examples only reflects a single entity at a time. Why not kick up the examples a notch and model something like an intelligent PDU with the following properties? 1. 24 outlets, single phase 2. 6 banks (4 outlets per bank), single phase 3. 2 inputs (3 banks per input), three phase 4. "Ganged" outlets (multiple outlets that are managed as one construct) 5. High current alerts, low current alerts, circuit breaker alerts, high voltage alerts (spikes), low voltage alerts (sags) -- all of which can be applied to a physical entity or a logical entity (like an outlet "gang") 6. Internal network card and metering logic 7. Outlets "owned" by different users (think co-location facility, "context") 8. Manage power via 5 different interface modalities/mechanisms 9. Except for the existence of the outlets/banks/inputs/"gangs", all other properties are potentially optional I challenge you -- everyone participating in the EMAN list -- to model this level of complexity. If your MIB can withstand this, it's a good MIB (IMO, of course). Thanks, Chris From ietf@quittek.at Tue Mar 1 01:57:20 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05E43A63CB for ; Tue, 1 Mar 2011 01:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL9NJkK56ihD for ; Tue, 1 Mar 2011 01:57:19 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id C0D9A3A6359 for ; Tue, 1 Mar 2011 01:57:17 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MEJOW-1PnotC2JOi-00FtRq; Tue, 01 Mar 2011 10:58:15 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <37079FFC-6255-4484-8E18-24A4B4DD8273@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Tue, 1 Mar 2011 10:58:15 +0100 To: "John Parello (jparello)" X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:537Xvcs9mFzqxWaMYv5y23EMnYtIQJ53B9xvUGade0C f0WKnHJuIe2NhymQ4qfx3fd2/d/Z9feGjbekO8+4heAUzFDcEC yvveU36KadU809t5YAJ92ig+sENpRLQrVxSifbA9WetP0SV6eN LAswQe/JfBecZx/7hYWbZVzoWcVzxmHkIWktMedJY+xAlGsPnI 9jXYcm7iMCGGTA1qqr9qw== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 09:57:20 -0000 Hi John, I entirely agree with you that this is a data (and information) modeling = exercise. And we should stop discussing whether to do it or not,=20 we should just work on the models. There are two big issues in modeling. One is modeling power states. I sent a message with alternative models for power states.=20 Let's start discussing which of them is the best one for EMAN. The other one is modeling the relations between parents/powerMonitors=20 and childs/powered devices. Here we have a model in the architecture = draft=20 and we have the reference model that I posted yesterday.=20 Also here discussion is needed. Thanks, Juergen Am 01.03.2011 um 10:35 schrieb John Parello (jparello): > Hi Chris, >=20 > Thanks I think that's a great challenge to throw down and we should = use > that as a reference case. >=20 > I was specifically terse in my reply because I don't want to take up = the > discussion or poison the pool if you will with an issue we've been > discussion off alias for almost a year. Fresh opinions are needed >=20 > Just to clarify a point though... >=20 > My concern is that in presenting the architecture in claise we made a > case to the OPSAWG that the entity mib, sensor mib and UPS mib are > insufficient to model energy management. Specifically we proposed that > we need a model(s) of power state interface(s) *and* a parent/child > model to handle implementation that will not support SNMP. >=20 > That supposition let to the formation of this group and the need to > create a new class of data.=20 >=20 > This is a data modeling exercise. If you have attributes to add to a > model you first look at your existing classes to see if there's a fit. > You create a new class when there's a need to model something new ( = anew > actor etc) not just because you have a few more attributes. >=20 > So with the addition of power states and parent/child we postulated = that > a new class of data was needed. That would mean we could also factor > data in that class that might readily have resided in the entity, = sensor > and UPS objects. >=20 > My challenge then would be that if those concepts are removed then the > burden of justifying a new class has to be taken up again.=20 >=20 > I presented an argument for a new class of data due to these concepts > and reason you pointed out. The sum total of those justifies a new = class > of data. If those concepts are removed then IMO any object model and > proposal must re-affirm/prove the need for the new class and justify = why > the existing classes are insufficient. >=20 > I don't think you can remove the assumptions and then retain the > conclusion. >=20 > HTH to clarify... > Thanks > Jp >=20 >=20 > -----Original Message----- > From: chrisv@cyberswitching.com [mailto:chrisv@cyberswitching.com]=20 > Sent: Monday, February 28, 2011 9:06 PM > To: John Parello (jparello) > Cc: Juergen Quittek; eman mailing list > Subject: Re: [eman] modeling power states >=20 > Hi John and Juergen, >=20 >>> Without those two additions the work in this group can easily be > covered >>> by two additions to existing SNMP objects. First would be adding > energy >>> related fields (watts units or Kwh) to the sensor mib. The seconds > would >>> be to add better the context information (see energy aware proposal) > to >>> the entity mib. A simple on/off/standby state already exists in oper >>> status. >>>=20 >>> So in short without an IETF EMAN set of power states / interfaces to >>> unify or map to the states from other orgs as you listed, *and* the >>> ability to monitor/aggregate non SNMP devices - the work here can > easily >>> be absorbed into the sensor and entity mibs with minor additions. >=20 > I disagree with the argument that ENTITY-MIB can be extended to = support > power data properly. ENTITY-MIB contains an inherent flaw, in that it > separates physical and logical entities into distinct buckets that > cannot overlap in sparse tables. >=20 > WHEN -- not if -- the IETF decides to provide a meter hook for logical > entities (individual programs, virtual machines on a shared server, > etc.), an EMAN schema based on ENTITY-MIB would have to be forked to > support this. That duplication of effort is pointless. >=20 > And I say "when" because it's a matter of time. Lots of people are > already working on this problem because there is a huge amount of = money > involved: >=20 > 30-second internet search: > http://research.microsoft.com/apps/pubs/default.aspx?id=3D120435 >=20 > The IETF exists to enable others' innovation and interoperability in > those pursuits. It is not our responsibility to debate the merits of > this undertaking. It is, however, our duty to acknowledge this = pursuit > and prepare to integrate it into schema. >=20 > So while it's good to make a nod to the predecessor ENTITY-MIB, I urge > us to make a structural break from it. >=20 >>> IMO any work in EMAN must contain the addition of an IETF power >>> interface as described in claise architecture (or some compromise as > you >>> listed with IANA interfaces). It must also contain the addition of >>> parent/child/aggregator relationship for non SNMP energy management. >>=20 >> You say we MUST adopt the power states from the claise architecture >> and we MUST adopt the parent/child concept. >>=20 >> The reasons you give for this in the paragraphs below are >> - Otherwise we would not need an EMAN WG. >> - This helps manufacturers to build sophisticated energy management >> systems. >>=20 >> I would not accept the first one as a technical argument, >> On your second argument I would reply that providing good interfaces >> for building sophisticated applications is certainly an objective >> of our work in EMAN, but probably not the one with top priority. >=20 > I agree with John's first point ("otherwise EMAN wouldn't exist") in = the > light that, even though it may not yet be fully and properly > articulated, there is a sense that EMAN is needed because the existing > solution architecture just doesn't quite do what is needed. I mean, = why > does your MIB draft exist? You see a problem and have tried to solve = it > because a solution doesn't yet exist. >=20 > Here's a structural example to illustrate the point: >=20 > Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor = types, > the data COULD be represented. For a single intelligent power supply = on > a server that monitors voltage, amperage, real power, apparent power, > power factor, and frequency, we'd have 6 entities enumerated in > ENTITY-MIB. And all of this would need to be tied together logically > into a "Power Supply" concept, so that'd be another entity -- 7 in > total. >=20 > For a single server, sure, fine, do-able. Tiny scale. >=20 > What about a 24-outlet PDU? Or a 84-circuit panelboard? >=20 > http://www.kondra.com/circuit/circuit.html >=20 > Eaton Branch Circuit Monitoring Whitepaper: > http://tinyurl.com/5rpmhrp >=20 > Managing 168 entities on a PDU or 588 entities on a panelboard is > a ridiculous burden on the user who is consuming the agent's data. >=20 > "Bonding" these entities that are a common purpose reduces the = magnitude > by a factor of 7, and simplifies the conceptual use of the framework. > Users don't need to think in terms of "voltage sensor for Outlet 1" = but > instead can refer to that same data as "Outlet 1's voltage." >=20 > Juergen, it seems like you're so busy focused on a conceptual model = that > real-world usability may be getting sacrificed. Each of your examples > only reflects a single entity at a time. Why not kick up the examples = a > notch and model something like an intelligent PDU with the following > properties? >=20 > 1. 24 outlets, single phase > 2. 6 banks (4 outlets per bank), single phase > 3. 2 inputs (3 banks per input), three phase > 4. "Ganged" outlets (multiple outlets that are managed as one > construct) > 5. High current alerts, low current alerts, circuit breaker alerts, > high voltage alerts (spikes), low voltage alerts (sags) -- all of > which can be applied to a physical entity or a logical entity > (like an outlet "gang") > 6. Internal network card and metering logic > 7. Outlets "owned" by different users (think co-location facility, > "context") > 8. Manage power via 5 different interface modalities/mechanisms > 9. Except for the existence of the outlets/banks/inputs/"gangs", all > other properties are potentially optional >=20 > I challenge you -- everyone participating in the EMAN list -- to model > this level of complexity. If your MIB can withstand this, it's a good > MIB (IMO, of course). >=20 > Thanks, > Chris From dromasca@avaya.com Tue Mar 1 01:58:02 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8348C3A63C9 for ; Tue, 1 Mar 2011 01:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxTO15eg1Xj6 for ; Tue, 1 Mar 2011 01:58:01 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1B53D3A63D2 for ; Tue, 1 Mar 2011 01:58:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AALtRbE3GmAcF/2dsb2JhbACXdY5VdKEoAplfgnaCawSPeA X-IronPort-AV: E=Sophos;i="4.62,246,1297054800"; d="scan'208";a="267162247" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Mar 2011 04:59:03 -0500 X-IronPort-AV: E=Sophos;i="4.62,246,1297054800"; d="scan'208";a="588188445" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Mar 2011 04:59:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 10:58:56 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvX7LbLxWh1XTRuTnOdNXCgb5P4mQACg63g References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at><20110301050601.GA2638@cslinux-build01.cyberswitching.local> From: "Romascanu, Dan (Dan)" To: "Juergen Quittek" , Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 09:58:02 -0000 I am still to be convinced that an ENTITY-MIB extension is not possible. What I understood from previous discussions is that the current indexation scheme and mapping tables are not sufficient, but this does not mean that an extension cannot be built. It looks like we are trying to solve here to solve a modeling problem that is not specific only for power entities.=20 Dan =20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Juergen Quittek > Sent: Tuesday, March 01, 2011 10:43 AM > To: chrisv@cyberswitching.com > Cc: eman mailing list > Subject: Re: [eman] modeling power states >=20 > Hi Chris, >=20 > Thank you for your thoughts. I have three comments: >=20 > - I do not think that anyone in this WG is still proposing=20 > seriously to go for an extension of the ENTITY-MIB. It seems=20 > to be clear that this is not sufficient. Maybe the chairs=20 > can check if we have consensus on this issue. I guess we have it. >=20 > - I like your example below and yes, we should be able to=20 > support this. But this is not a problem of power states. This=20 > is about the parent/child concept which we have not discussed=20 > so far on this list. My concern about parent child is that it=20 > may be too simple to model complex cases like the one you=20 > describe and others. This is why I try to have a clean=20 > reference model.=20 >=20 > - Yes, you are right, the reference model currently has very=20 > few example scenarios with multiple instances of a port or a=20 > PC. But the only purpose of section 3.4 is to explain how the=20 > scenarios and figures expand to multiple instances. If think=20 > this is not sufficient, I can add more explanations to it. If=20 > you think it would be helpful in any aspect to provide a=20 > figure with the PDU with 24 ports you describe in your=20 > message, I will be glad to draw this figure for you and=20 > include it in the next revision. >=20 > Thanks, >=20 > Juergen >=20 >=20 > Am 01.03.2011 um 06:06 schrieb chrisv@cyberswitching.com: >=20 > > Hi John and Juergen, > >=20 > >>> Without those two additions the work in this group can easily be=20 > >>> covered by two additions to existing SNMP objects. First would be=20 > >>> adding energy related fields (watts units or Kwh) to the=20 > sensor mib.=20 > >>> The seconds would be to add better the context information (see=20 > >>> energy aware proposal) to the entity mib. A simple on/off/standby=20 > >>> state already exists in oper status. > >>>=20 > >>> So in short without an IETF EMAN set of power states /=20 > interfaces to=20 > >>> unify or map to the states from other orgs as you listed,=20 > *and* the=20 > >>> ability to monitor/aggregate non SNMP devices - the work here can=20 > >>> easily be absorbed into the sensor and entity mibs with=20 > minor additions. > >=20 > > I disagree with the argument that ENTITY-MIB can be extended to=20 > > support power data properly. ENTITY-MIB contains an=20 > inherent flaw, in=20 > > that it separates physical and logical entities into=20 > distinct buckets=20 > > that cannot overlap in sparse tables. >=20 > >=20 >=20 > > WHEN -- not if -- the IETF decides to provide a meter hook=20 > for logical=20 > > entities (individual programs, virtual machines on a shared server,=20 > > etc.), an EMAN schema based on ENTITY-MIB would have to be=20 > forked to=20 > > support this. That duplication of effort is pointless. > >=20 > > And I say "when" because it's a matter of time. Lots of people are=20 > > already working on this problem because there is a huge amount of=20 > > money > > involved: > >=20 > > 30-second internet search: > > http://research.microsoft.com/apps/pubs/default.aspx?id=3D120435 > >=20 > > The IETF exists to enable others' innovation and=20 > interoperability in=20 > > those pursuits. It is not our responsibility to debate the=20 > merits of=20 > > this undertaking. It is, however, our duty to acknowledge this=20 > > pursuit and prepare to integrate it into schema. > >=20 > > So while it's good to make a nod to the predecessor=20 > ENTITY-MIB, I urge=20 > > us to make a structural break from it. > >=20 > >>> IMO any work in EMAN must contain the addition of an IETF power=20 > >>> interface as described in claise architecture (or some=20 > compromise as=20 > >>> you listed with IANA interfaces). It must also contain=20 > the addition=20 > >>> of parent/child/aggregator relationship for non SNMP=20 > energy management. > >>=20 > >> You say we MUST adopt the power states from the claise=20 > architecture=20 > >> and we MUST adopt the parent/child concept. > >>=20 > >> The reasons you give for this in the paragraphs below are > >> - Otherwise we would not need an EMAN WG. > >> - This helps manufacturers to build sophisticated energy=20 > management=20 > >> systems. > >>=20 > >> I would not accept the first one as a technical argument, On your=20 > >> second argument I would reply that providing good interfaces for=20 > >> building sophisticated applications is certainly an=20 > objective of our=20 > >> work in EMAN, but probably not the one with top priority. > >=20 > > I agree with John's first point ("otherwise EMAN wouldn't=20 > exist") in=20 > > the light that, even though it may not yet be fully and properly=20 > > articulated, there is a sense that EMAN is needed because=20 > the existing=20 > > solution architecture just doesn't quite do what is needed.=20 > I mean,=20 > > why does your MIB draft exist? You see a problem and have tried to=20 > > solve it because a solution doesn't yet exist. > >=20 > > Here's a structural example to illustrate the point: > >=20 > > Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor=20 > > types, the data COULD be represented. For a single=20 > intelligent power=20 > > supply on a server that monitors voltage, amperage, real power,=20 > > apparent power, power factor, and frequency, we'd have 6 entities=20 > > enumerated in ENTITY-MIB. And all of this would need to be tied=20 > > together logically into a "Power Supply" concept, so that'd=20 > be another=20 > > entity -- 7 in total. > >=20 > > For a single server, sure, fine, do-able. Tiny scale. > >=20 > > What about a 24-outlet PDU? Or a 84-circuit panelboard? > >=20 > > http://www.kondra.com/circuit/circuit.html > >=20 > > Eaton Branch Circuit Monitoring Whitepaper: > > http://tinyurl.com/5rpmhrp > >=20 > > Managing 168 entities on a PDU or 588 entities on a panelboard is a=20 > > ridiculous burden on the user who is consuming the agent's data. > >=20 > > "Bonding" these entities that are a common purpose reduces the=20 > > magnitude by a factor of 7, and simplifies the conceptual=20 > use of the framework. > > Users don't need to think in terms of "voltage sensor for Outlet 1"=20 > > but instead can refer to that same data as "Outlet 1's voltage." > >=20 > > Juergen, it seems like you're so busy focused on a conceptual model=20 > > that real-world usability may be getting sacrificed. Each of your=20 > > examples only reflects a single entity at a time. Why not=20 > kick up the=20 > > examples a notch and model something like an intelligent=20 > PDU with the=20 > > following properties? > >=20 > > 1. 24 outlets, single phase > > 2. 6 banks (4 outlets per bank), single phase > > 3. 2 inputs (3 banks per input), three phase > > 4. "Ganged" outlets (multiple outlets that are managed as one > > construct) > > 5. High current alerts, low current alerts, circuit=20 > breaker alerts, > > high voltage alerts (spikes), low voltage alerts=20 > (sags) -- all of > > which can be applied to a physical entity or a logical entity > > (like an outlet "gang") > > 6. Internal network card and metering logic > > 7. Outlets "owned" by different users (think co-location facility, > > "context") > > 8. Manage power via 5 different interface modalities/mechanisms > > 9. Except for the existence of the=20 > outlets/banks/inputs/"gangs", all > > other properties are potentially optional > >=20 > > I challenge you -- everyone participating in the EMAN list=20 > -- to model=20 > > this level of complexity. If your MIB can withstand this,=20 > it's a good=20 > > MIB (IMO, of course). >=20 >=20 > > Thanks, > > Chris >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 From dromasca@avaya.com Tue Mar 1 02:00:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786FE3A63D2 for ; Tue, 1 Mar 2011 02:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzDB709RdSaE for ; Tue, 1 Mar 2011 02:00:10 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 6A8C13A63C9 for ; Tue, 1 Mar 2011 02:00:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AADJSbE3GmAcF/2dsb2JhbACXdY5VdKErAplfhWEEj3g X-IronPort-AV: E=Sophos;i="4.62,246,1297054800"; d="scan'208";a="61265209" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 01 Mar 2011 05:01:12 -0500 X-IronPort-AV: E=Sophos;i="4.62,246,1297054800"; d="scan'208";a="588189512" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Mar 2011 05:01:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 11:01:04 +0100 Message-ID: In-Reply-To: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvXzmGSpej3/z2JSIaCAR9F/aTJ8QAJeXLA References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> From: "Romascanu, Dan (Dan)" To: , "John Parello (jparello)" Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:00:11 -0000 Hi Chris, See in-line.=20 Regards, Dan (speaking as contributor)=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of chrisv@cyberswitching.com > Sent: Tuesday, March 01, 2011 7:06 AM > To: John Parello (jparello) > Cc: eman mailing list > Subject: Re: [eman] modeling power states >=20 > Hi John and Juergen, >=20 > > > Without those two additions the work in this group can easily be=20 > > > covered by two additions to existing SNMP objects. First would be=20 > > > adding energy related fields (watts units or Kwh) to the=20 > sensor mib.=20 > > > The seconds would be to add better the context information (see=20 > > > energy aware proposal) to the entity mib. A simple on/off/standby=20 > > > state already exists in oper status. > > > > > > So in short without an IETF EMAN set of power states /=20 > interfaces to=20 > > > unify or map to the states from other orgs as you listed,=20 > *and* the=20 > > > ability to monitor/aggregate non SNMP devices - the work here can=20 > > > easily be absorbed into the sensor and entity mibs with=20 > minor additions. >=20 > I disagree with the argument that ENTITY-MIB can be extended=20 > to support power data properly. ENTITY-MIB contains an=20 > inherent flaw, in that it separates physical and logical=20 > entities into distinct buckets that cannot overlap in sparse tables. >=20 Can you detail what is this inherent flaw? I am afraid that I do not understand what 'distinct buckets that ... overlap in sparse tables' are. Maybe an example would help. > WHEN -- not if -- the IETF decides to provide a meter hook=20 > for logical entities (individual programs, virtual machines=20 > on a shared server, etc.), an EMAN schema based on ENTITY-MIB=20 > would have to be forked to support this. That duplication of=20 > effort is pointless. >=20 You seem to be saying that the Entity MIB as it stands is not fit for modeling virtual machines on a shared server. I tend to agree. My question is however how is this related to the Power MIB? I do not think it's a good idea to develop a data model for VMs in the Power MIB. The WG is not chartered for this either, I think. > And I say "when" because it's a matter of time. Lots of=20 > people are already working on this problem because there is a=20 > huge amount of money > involved: >=20 > 30-second internet search: > http://research.microsoft.com/apps/pubs/default.aspx?id=3D120435 >=20 > The IETF exists to enable others' innovation and=20 > interoperability in those pursuits. It is not our=20 > responsibility to debate the merits of this undertaking. It=20 > is, however, our duty to acknowledge this pursuit and prepare=20 > to integrate it into schema. >=20 > So while it's good to make a nod to the predecessor=20 > ENTITY-MIB, I urge us to make a structural break from it. I tend to disagree here. If there is something missing in the Entity MIB it should be added there. There is merit in providing a consistent way of addressing managed entities. Being able to point to a managed power entity using the Entity MIB indexation seems to be a useful thing from an operational perspective.=20 >=20 > > > IMO any work in EMAN must contain the addition of an IETF power=20 > > > interface as described in claise architecture (or some=20 > compromise as=20 > > > you listed with IANA interfaces). It must also contain=20 > the addition=20 > > > of parent/child/aggregator relationship for non SNMP=20 > energy management. > > Yes, but all these do not seem to be specific only to managed power devices.=20 ... From ietf@quittek.at Tue Mar 1 02:07:41 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34333A6407 for ; Tue, 1 Mar 2011 02:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwJ4G21lfeVg for ; Tue, 1 Mar 2011 02:07:40 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 0ADF93A6405 for ; Tue, 1 Mar 2011 02:07:40 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MCucZ-1PmQHK194F-009g87; Tue, 01 Mar 2011 11:08:42 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at><20110301050601.GA2638@cslinux-build01.cyberswitching.local> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Tue, 1 Mar 2011 11:08:42 +0100 To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:Ngtj7KfCt8dKQ1V8ZRxl4kqb5B7h+C42wLTuQ7aqzzr 6pnKa2bY8Mxajo10DNzZKPAdAssDri9FBUF71x1APlCH8Yx0CA Be4StD5FYBg+2btOleZoyhpHhlEeD9+98vU6Oij6n/iA2wh95Y 5bROFlCtrE3RB6+qZ/QXs2pcbAHxQ5J2GxOLwQqyDE1LG/ge9Q /g7rskb5JaadYY5JWTT2A== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:07:41 -0000 Hi Dan, The problem with the Entity MIB is that we cannot use it for reporting on remote devices, for example, a PoE switch reporting on PoE powered devices connected to it. We will still provide means to use indices provided by Entity MIB (entPhysicalIndex) when a device reports on internal components. Juergen Am 01.03.2011 um 10:58 schrieb Romascanu, Dan (Dan): > I am still to be convinced that an ENTITY-MIB extension is not possible. > What I understood from previous discussions is that the current > indexation scheme and mapping tables are not sufficient, but this does > not mean that an extension cannot be built. It looks like we are trying > to solve here to solve a modeling problem that is not specific only for > power entities. > > Dan > > >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On >> Behalf Of Juergen Quittek >> Sent: Tuesday, March 01, 2011 10:43 AM >> To: chrisv@cyberswitching.com >> Cc: eman mailing list >> Subject: Re: [eman] modeling power states >> >> Hi Chris, >> >> Thank you for your thoughts. I have three comments: >> >> - I do not think that anyone in this WG is still proposing >> seriously to go for an extension of the ENTITY-MIB. It seems >> to be clear that this is not sufficient. Maybe the chairs >> can check if we have consensus on this issue. I guess we have it. >> >> - I like your example below and yes, we should be able to >> support this. But this is not a problem of power states. This >> is about the parent/child concept which we have not discussed >> so far on this list. My concern about parent child is that it >> may be too simple to model complex cases like the one you >> describe and others. This is why I try to have a clean >> reference model. >> >> - Yes, you are right, the reference model currently has very >> few example scenarios with multiple instances of a port or a >> PC. But the only purpose of section 3.4 is to explain how the >> scenarios and figures expand to multiple instances. If think >> this is not sufficient, I can add more explanations to it. If >> you think it would be helpful in any aspect to provide a >> figure with the PDU with 24 ports you describe in your >> message, I will be glad to draw this figure for you and >> include it in the next revision. >> >> Thanks, >> >> Juergen >> >> >> Am 01.03.2011 um 06:06 schrieb chrisv@cyberswitching.com: >> >>> Hi John and Juergen, >>> >>>>> Without those two additions the work in this group can easily be >>>>> covered by two additions to existing SNMP objects. First would be >>>>> adding energy related fields (watts units or Kwh) to the >> sensor mib. >>>>> The seconds would be to add better the context information (see >>>>> energy aware proposal) to the entity mib. A simple on/off/standby >>>>> state already exists in oper status. >>>>> >>>>> So in short without an IETF EMAN set of power states / >> interfaces to >>>>> unify or map to the states from other orgs as you listed, >> *and* the >>>>> ability to monitor/aggregate non SNMP devices - the work here can >>>>> easily be absorbed into the sensor and entity mibs with >> minor additions. >>> >>> I disagree with the argument that ENTITY-MIB can be extended to >>> support power data properly. ENTITY-MIB contains an >> inherent flaw, in >>> that it separates physical and logical entities into >> distinct buckets >>> that cannot overlap in sparse tables. >> >>> >> >>> WHEN -- not if -- the IETF decides to provide a meter hook >> for logical >>> entities (individual programs, virtual machines on a shared server, >>> etc.), an EMAN schema based on ENTITY-MIB would have to be >> forked to >>> support this. That duplication of effort is pointless. >>> >>> And I say "when" because it's a matter of time. Lots of people are >>> already working on this problem because there is a huge amount of >>> money >>> involved: >>> >>> 30-second internet search: >>> http://research.microsoft.com/apps/pubs/default.aspx?id=120435 >>> >>> The IETF exists to enable others' innovation and >> interoperability in >>> those pursuits. It is not our responsibility to debate the >> merits of >>> this undertaking. It is, however, our duty to acknowledge this >>> pursuit and prepare to integrate it into schema. >>> >>> So while it's good to make a nod to the predecessor >> ENTITY-MIB, I urge >>> us to make a structural break from it. >>> >>>>> IMO any work in EMAN must contain the addition of an IETF power >>>>> interface as described in claise architecture (or some >> compromise as >>>>> you listed with IANA interfaces). It must also contain >> the addition >>>>> of parent/child/aggregator relationship for non SNMP >> energy management. >>>> >>>> You say we MUST adopt the power states from the claise >> architecture >>>> and we MUST adopt the parent/child concept. >>>> >>>> The reasons you give for this in the paragraphs below are >>>> - Otherwise we would not need an EMAN WG. >>>> - This helps manufacturers to build sophisticated energy >> management >>>> systems. >>>> >>>> I would not accept the first one as a technical argument, On your >>>> second argument I would reply that providing good interfaces for >>>> building sophisticated applications is certainly an >> objective of our >>>> work in EMAN, but probably not the one with top priority. >>> >>> I agree with John's first point ("otherwise EMAN wouldn't >> exist") in >>> the light that, even though it may not yet be fully and properly >>> articulated, there is a sense that EMAN is needed because >> the existing >>> solution architecture just doesn't quite do what is needed. >> I mean, >>> why does your MIB draft exist? You see a problem and have tried to >>> solve it because a solution doesn't yet exist. >>> >>> Here's a structural example to illustrate the point: >>> >>> Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor >>> types, the data COULD be represented. For a single >> intelligent power >>> supply on a server that monitors voltage, amperage, real power, >>> apparent power, power factor, and frequency, we'd have 6 entities >>> enumerated in ENTITY-MIB. And all of this would need to be tied >>> together logically into a "Power Supply" concept, so that'd >> be another >>> entity -- 7 in total. >>> >>> For a single server, sure, fine, do-able. Tiny scale. >>> >>> What about a 24-outlet PDU? Or a 84-circuit panelboard? >>> >>> http://www.kondra.com/circuit/circuit.html >>> >>> Eaton Branch Circuit Monitoring Whitepaper: >>> http://tinyurl.com/5rpmhrp >>> >>> Managing 168 entities on a PDU or 588 entities on a panelboard is a >>> ridiculous burden on the user who is consuming the agent's data. >>> >>> "Bonding" these entities that are a common purpose reduces the >>> magnitude by a factor of 7, and simplifies the conceptual >> use of the framework. >>> Users don't need to think in terms of "voltage sensor for Outlet 1" >>> but instead can refer to that same data as "Outlet 1's voltage." >>> >>> Juergen, it seems like you're so busy focused on a conceptual model >>> that real-world usability may be getting sacrificed. Each of your >>> examples only reflects a single entity at a time. Why not >> kick up the >>> examples a notch and model something like an intelligent >> PDU with the >>> following properties? >>> >>> 1. 24 outlets, single phase >>> 2. 6 banks (4 outlets per bank), single phase >>> 3. 2 inputs (3 banks per input), three phase >>> 4. "Ganged" outlets (multiple outlets that are managed as one >>> construct) >>> 5. High current alerts, low current alerts, circuit >> breaker alerts, >>> high voltage alerts (spikes), low voltage alerts >> (sags) -- all of >>> which can be applied to a physical entity or a logical entity >>> (like an outlet "gang") >>> 6. Internal network card and metering logic >>> 7. Outlets "owned" by different users (think co-location facility, >>> "context") >>> 8. Manage power via 5 different interface modalities/mechanisms >>> 9. Except for the existence of the >> outlets/banks/inputs/"gangs", all >>> other properties are potentially optional >>> >>> I challenge you -- everyone participating in the EMAN list >> -- to model >>> this level of complexity. If your MIB can withstand this, >> it's a good >>> MIB (IMO, of course). >> >> >>> Thanks, >>> Chris >> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> From dromasca@avaya.com Tue Mar 1 02:17:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10D83A65A5 for ; Tue, 1 Mar 2011 02:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGUB3Mzs3LZm for ; Tue, 1 Mar 2011 02:17:22 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D062B3A6359 for ; Tue, 1 Mar 2011 02:17:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAKdWbE2HCzI1/2dsb2JhbACXdY5VdKEeAplhhWEEj3g X-IronPort-AV: E=Sophos;i="4.62,246,1297054800"; d="scan'208";a="234612524" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Mar 2011 05:18:23 -0500 X-IronPort-AV: E=Sophos;i="4.62,246,1297054800"; d="scan'208";a="607867096" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Mar 2011 05:18:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 11:18:20 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvX+Kb/lvru6v8zQUSzUzPZgGhA9QAANmaw References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at><20110301050601.GA2638@cslinux-build01.cyberswitching.local> From: "Romascanu, Dan (Dan)" To: "Juergen Quittek" Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:17:22 -0000 Hi Juergen, But we can do this using something similar to the LLDP-MIB and LLDP-MED-MIB. True, these are not IETF MIB modules (they were developped in the IEEE 802.1 and TIA 41.4 respectively), but they have solved this modeling problem, and also developped the protocol to report on the state of devices connected to a switch. Actually the LLDP-MED-MIB (ANSI TIA 1057) reports power information from end-devices.=20 Regards, Dan > -----Original Message----- > From: Juergen Quittek [mailto:ietf@quittek.at]=20 > Sent: Tuesday, March 01, 2011 12:09 PM > To: Romascanu, Dan (Dan) > Cc: chrisv@cyberswitching.com; eman mailing list > Subject: Re: [eman] modeling power states >=20 > Hi Dan, >=20 > The problem with the Entity MIB is that we cannot use it for=20 > reporting on remote devices, for example, a PoE switch=20 > reporting on PoE powered devices connected to it.=20 >=20 From j.schoenwaelder@jacobs-university.de Tue Mar 1 02:19:47 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C402C3A65A5 for ; Tue, 1 Mar 2011 02:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbMfB2hq7Jvv for ; Tue, 1 Mar 2011 02:19:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 941393A6452 for ; Tue, 1 Mar 2011 02:19:46 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAE08C000E; Tue, 1 Mar 2011 11:20:48 +0100 (CET) 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 ovYFdFZ+Oc-0; Tue, 1 Mar 2011 11:20:48 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04E9BC000D; Tue, 1 Mar 2011 11:20:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2270816D3C91; Tue, 1 Mar 2011 11:20:32 +0100 (CET) Date: Tue, 1 Mar 2011 11:20:32 +0100 From: Juergen Schoenwaelder To: eman mailing list Message-ID: <20110301102032.GA9233@elstar.local> Mail-Followup-To: eman mailing list , "Romascanu, Dan (Dan)" , Juergen Quittek , chrisv@cyberswitching.com References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.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) Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:19:47 -0000 On Tue, Mar 01, 2011 at 10:58:56AM +0100, Romascanu, Dan (Dan) wrote: > I am still to be convinced that an ENTITY-MIB extension is not possible. > What I understood from previous discussions is that the current > indexation scheme and mapping tables are not sufficient, but this does > not mean that an extension cannot be built. It looks like we are trying > to solve here to solve a modeling problem that is not specific only for > power entities. I guess like Dan, I would appreciate a clear and yet concise explanation why the ENTITY-MIB does not work and why it is not possible or awkward to extend the ENTITY-MIB to make it work. If someone can write this up as a 2-page I-D (plus N page boilerplate of the day ;-), I think we will have a much easier time to put this discussion to an end. Perhaps this text can be based on the text currently in section 3 of with some more details added. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Mar 1 02:21:31 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735653A6452 for ; Tue, 1 Mar 2011 02:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD8wEdY5VaE7 for ; Tue, 1 Mar 2011 02:21:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5FD233A6359 for ; Tue, 1 Mar 2011 02:21:28 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAAD6C000E; Tue, 1 Mar 2011 11:22:30 +0100 (CET) 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 y-kMPyeokw0e; Tue, 1 Mar 2011 11:22:30 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26F95C000D; Tue, 1 Mar 2011 11:22:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0548816D3D21; Tue, 1 Mar 2011 11:22:25 +0100 (CET) Date: Tue, 1 Mar 2011 11:22:25 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20110301102225.GB9233@elstar.local> Mail-Followup-To: Juergen Quittek , "Romascanu, Dan (Dan)" , eman mailing list References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.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 mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:21:31 -0000 On Tue, Mar 01, 2011 at 11:08:42AM +0100, Juergen Quittek wrote: > The problem with the Entity MIB is that we cannot use it for reporting > on remote devices, for example, a PoE switch reporting on PoE > powered devices connected to it. Would contexts not work? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Rolf.Winter@neclab.eu Tue Mar 1 02:23:28 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109A33A6452 for ; Tue, 1 Mar 2011 02:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.028 X-Spam-Level: X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVK1ui6MWNOK for ; Tue, 1 Mar 2011 02:23:26 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9EF863A672E for ; Tue, 1 Mar 2011 02:23:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id CB66F2C000204; Tue, 1 Mar 2011 11:25:34 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WKGDfy8lbgi; Tue, 1 Mar 2011 11:25:34 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id AFA162C0001D8; Tue, 1 Mar 2011 11:25:24 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 1 Mar 2011 11:24:18 +0100 From: Rolf Winter To: Juergen Schoenwaelder , eman mailing list Thread-Topic: [eman] modeling power states Thread-Index: AQHL10AQEO6KgxJClUmx3jb0i6rbx5QXI7jwgAA0RACAAC59gIAAVvqAgAA8oYCAABU2AIAABgkAgAARY8A= Date: Tue, 1 Mar 2011 10:24:18 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DE0962@DAPHNIS.office.hd> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> In-Reply-To: <20110301102032.GA9233@elstar.local> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:23:28 -0000 Sounds like a reasonable request. Could also go into the requirements draft= , either section 3 or section 7? NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Dienstag, 1. M=E4rz 2011 11:21 > To: eman mailing list > Subject: Re: [eman] modeling power states >=20 > On Tue, Mar 01, 2011 at 10:58:56AM +0100, Romascanu, Dan (Dan) wrote: >=20 > > I am still to be convinced that an ENTITY-MIB extension is not > possible. > > What I understood from previous discussions is that the current > > indexation scheme and mapping tables are not sufficient, but this > does > > not mean that an extension cannot be built. It looks like we are > trying > > to solve here to solve a modeling problem that is not specific only > for > > power entities. >=20 > I guess like Dan, I would appreciate a clear and yet concise > explanation why the ENTITY-MIB does not work and why it is not > possible or awkward to extend the ENTITY-MIB to make it work. If > someone can write this up as a 2-page I-D (plus N page boilerplate of > the day ;-), I think we will have a much easier time to put this > discussion to an end. >=20 > Perhaps this text can be based on the text currently in section 3 of > with some more details > added. >=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 Rolf.Winter@neclab.eu Tue Mar 1 02:38:57 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CFC13A679F for ; Tue, 1 Mar 2011 02:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.924 X-Spam-Level: X-Spam-Status: No, score=-101.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rRJG3EwuZ3M for ; Tue, 1 Mar 2011 02:38:56 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id C6C2D3A6784 for ; Tue, 1 Mar 2011 02:38:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A92642800018E; Tue, 1 Mar 2011 11:41:14 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldqwnaF6xdCV; Tue, 1 Mar 2011 11:41:14 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8BA472800017B; Tue, 1 Mar 2011 11:40:59 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Tue, 1 Mar 2011 11:39:43 +0100 From: Rolf Winter To: "chrisv@cyberswitching.com" , "John Parello (jparello)" Thread-Topic: [eman] modeling power states Thread-Index: AQHL10AQEO6KgxJClUmx3jb0i6rbx5QXI7jwgAA0RACAAC59gIAAVvqAgABsqxA= Date: Tue, 1 Mar 2011 10:39:43 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DE0986@DAPHNIS.office.hd> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> In-Reply-To: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:38:57 -0000 Hi, I think acid test-type of questions like this are very useful and I wish mo= re "customers" of this work would throw them at the EMAN WG. Some of this r= elates to the type of information that needs to be presented which is the e= asy part I would assume. The structural aspect of is (parent-child/aggregat= ion etc.) has not received a lot of attention, other than that people seem = to agree that "something in this direction" is indeed needed for energy man= agement.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > chrisv@cyberswitching.com > Sent: Dienstag, 1. M=E4rz 2011 06:06 > To: John Parello (jparello) > Cc: eman mailing list > Subject: Re: [eman] modeling power states >=20 > Hi John and Juergen, >=20 > > > Without those two additions the work in this group can easily be > covered > > > by two additions to existing SNMP objects. First would be adding > energy > > > related fields (watts units or Kwh) to the sensor mib. The seconds > would > > > be to add better the context information (see energy aware > proposal) to > > > the entity mib. A simple on/off/standby state already exists in > oper > > > status. > > > > > > So in short without an IETF EMAN set of power states / interfaces > to > > > unify or map to the states from other orgs as you listed, *and* the > > > ability to monitor/aggregate non SNMP devices - the work here can > easily > > > be absorbed into the sensor and entity mibs with minor additions. >=20 > I disagree with the argument that ENTITY-MIB can be extended to support > power data properly. ENTITY-MIB contains an inherent flaw, in that it > separates physical and logical entities into distinct buckets that > cannot overlap in sparse tables. >=20 > WHEN -- not if -- the IETF decides to provide a meter hook for logical > entities (individual programs, virtual machines on a shared server, > etc.), an EMAN schema based on ENTITY-MIB would have to be forked to > support this. That duplication of effort is pointless. >=20 > And I say "when" because it's a matter of time. Lots of people are > already working on this problem because there is a huge amount of money > involved: >=20 > 30-second internet search: > http://research.microsoft.com/apps/pubs/default.aspx?id=3D120435 >=20 > The IETF exists to enable others' innovation and interoperability in > those pursuits. It is not our responsibility to debate the merits of > this undertaking. It is, however, our duty to acknowledge this pursuit > and prepare to integrate it into schema. >=20 > So while it's good to make a nod to the predecessor ENTITY-MIB, I urge > us to make a structural break from it. >=20 > > > IMO any work in EMAN must contain the addition of an IETF power > > > interface as described in claise architecture (or some compromise > as you > > > listed with IANA interfaces). It must also contain the addition of > > > parent/child/aggregator relationship for non SNMP energy management. > > > > You say we MUST adopt the power states from the claise architecture > > and we MUST adopt the parent/child concept. > > > > The reasons you give for this in the paragraphs below are > > - Otherwise we would not need an EMAN WG. > > - This helps manufacturers to build sophisticated energy management > > systems. > > > > I would not accept the first one as a technical argument, > > On your second argument I would reply that providing good interfaces > > for building sophisticated applications is certainly an objective > > of our work in EMAN, but probably not the one with top priority. >=20 > I agree with John's first point ("otherwise EMAN wouldn't exist") in > the > light that, even though it may not yet be fully and properly > articulated, there is a sense that EMAN is needed because the existing > solution architecture just doesn't quite do what is needed. I mean, > why > does your MIB draft exist? You see a problem and have tried to solve > it > because a solution doesn't yet exist. >=20 > Here's a structural example to illustrate the point: >=20 > Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor types, > the data COULD be represented. For a single intelligent power supply > on > a server that monitors voltage, amperage, real power, apparent power, > power factor, and frequency, we'd have 6 entities enumerated in > ENTITY-MIB. And all of this would need to be tied together logically > into a "Power Supply" concept, so that'd be another entity -- 7 in > total. >=20 > For a single server, sure, fine, do-able. Tiny scale. >=20 > What about a 24-outlet PDU? Or a 84-circuit panelboard? >=20 > http://www.kondra.com/circuit/circuit.html >=20 > Eaton Branch Circuit Monitoring Whitepaper: > http://tinyurl.com/5rpmhrp >=20 > Managing 168 entities on a PDU or 588 entities on a panelboard is > a ridiculous burden on the user who is consuming the agent's data. >=20 > "Bonding" these entities that are a common purpose reduces the > magnitude > by a factor of 7, and simplifies the conceptual use of the framework. > Users don't need to think in terms of "voltage sensor for Outlet 1" but > instead can refer to that same data as "Outlet 1's voltage." >=20 > Juergen, it seems like you're so busy focused on a conceptual model > that > real-world usability may be getting sacrificed. Each of your examples > only reflects a single entity at a time. Why not kick up the examples > a > notch and model something like an intelligent PDU with the following > properties? >=20 > 1. 24 outlets, single phase > 2. 6 banks (4 outlets per bank), single phase > 3. 2 inputs (3 banks per input), three phase > 4. "Ganged" outlets (multiple outlets that are managed as one > construct) > 5. High current alerts, low current alerts, circuit breaker alerts, > high voltage alerts (spikes), low voltage alerts (sags) -- all of > which can be applied to a physical entity or a logical entity > (like an outlet "gang") > 6. Internal network card and metering logic > 7. Outlets "owned" by different users (think co-location facility, > "context") > 8. Manage power via 5 different interface modalities/mechanisms > 9. Except for the existence of the outlets/banks/inputs/"gangs", all > other properties are potentially optional >=20 > I challenge you -- everyone participating in the EMAN list -- to model > this level of complexity. If your MIB can withstand this, it's a good > MIB (IMO, of course). >=20 > Thanks, > Chris > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Tue Mar 1 02:50:42 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081FB3A67A3 for ; Tue, 1 Mar 2011 02:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scHAGSZgH-Ky for ; Tue, 1 Mar 2011 02:50:41 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id C40D73A6452 for ; Tue, 1 Mar 2011 02:50:40 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MbrOw-1Pc9Ix39oU-00JWv8; Tue, 01 Mar 2011 11:51:41 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> In-Reply-To: <20110301102225.GB9233@elstar.local> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Tue, 1 Mar 2011 11:50:23 +0100 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:EAwgb6be1iU8vhHWX/q6cbCEqwL2OtdoXy2Gw+5TZQH x71z8ayz/XySeCRRf3KiQ13O3cSXKUpQN6sW7OHR7UV9oio1zX IUemUdSYDROXoQZ7x92LRnz8BuM3znol1E7A7SofdYiRTKeG9+ NCUGpOve2ijVRtkO7azeVbWytpKzwCWIgJzUwRUV0NAIjYKkGp UlUFyL8n3yd8sLed+Q7sw== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 10:50:42 -0000 Hi Juergen, I assume you refer to the SNMP context engineID. Yes, this can be used as long as the remote device has one. If not, something else is needed. Juergen Am 01.03.2011 um 11:22 schrieb Juergen Schoenwaelder: > On Tue, Mar 01, 2011 at 11:08:42AM +0100, Juergen Quittek wrote: > >> The problem with the Entity MIB is that we cannot use it for reporting >> on remote devices, for example, a PoE switch reporting on PoE >> powered devices connected to it. > > Would contexts not work? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Mar 1 03:14:52 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9CC13A679F for ; Tue, 1 Mar 2011 03:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ72i7rRXEzO for ; Tue, 1 Mar 2011 03:14:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C73A83A6359 for ; Tue, 1 Mar 2011 03:14:51 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43DE5C000D; Tue, 1 Mar 2011 12:15:54 +0100 (CET) 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 uS1qo6K2vtlp; Tue, 1 Mar 2011 12:15:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71483C000E; Tue, 1 Mar 2011 12:15:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4271C16D3EE5; Tue, 1 Mar 2011 12:15:48 +0100 (CET) Date: Tue, 1 Mar 2011 12:15:48 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20110301111548.GA9369@elstar.local> Mail-Followup-To: Juergen Quittek , "Romascanu, Dan (Dan)" , eman mailing list References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 11:14:52 -0000 On Tue, Mar 01, 2011 at 11:50:23AM +0100, Juergen Quittek wrote: > Hi Juergen, > > I assume you refer to the SNMP context engineID. > > Yes, this can be used as long as the remote device has one. > If not, something else is needed. I am talking about an SNMP context as defined in RFC 3411 section 3.3.1 and in particular the usage of contextName as a mechanism to select different MIB trees. This is what the ENTITY-MIB calls a logical entity. The default contextName ("") is the zero-length string, so on a power over ethernet switch, we have objects reporting the energy consumption of the components of the device itself (physical entities). If you plug a phone into the switch and the switch is able to determine power consumption of the remote phone device, you can instantiate another MIB tree that reports the components of the phone as physical entities under a different contextName (e.g., "port-N"). The ENTITY-MIB allows you to discover which contexts are available. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Thomas.Dietz@neclab.eu Tue Mar 1 03:16:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0703A679F for ; Tue, 1 Mar 2011 03:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCBZyeM0GiY6 for ; Tue, 1 Mar 2011 03:16:29 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A54233A6359 for ; Tue, 1 Mar 2011 03:16:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 346692C000204; Tue, 1 Mar 2011 12:18:37 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymd0fehaClvP; Tue, 1 Mar 2011 12:18:37 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 13BDE2C0001D8; Tue, 1 Mar 2011 12:18:27 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Tue, 1 Mar 2011 12:17:21 +0100 From: Thomas Dietz To: Rolf Winter , Juergen Schoenwaelder , eman mailing list Thread-Topic: [eman] modeling power states Thread-Index: AQHL10AQEO6KgxJClUmx3jb0i6rbx5QXI7jwgAA0RACAAC59gIAAVvqAgAA8oYCAABU2AIAABgkAgAARY8CAAA1s8A== Date: Tue, 1 Mar 2011 11:17:20 +0000 Message-ID: <75581E268A48F849916117B977D76D37162D3B22@DAPHNIS.office.hd> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <791AD3077F94194BB2BDD13565B6295D05DE0962@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DE0962@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.10] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0049_01CBD80A.9CA235E0" MIME-Version: 1.0 Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 11:16:30 -0000 ------=_NextPart_000_0049_01CBD80A.9CA235E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Rolf that such an explanation would nicely fit into the requirements draft. I understand that it is not so easy to model the reporting for values that come from another device that does not support SNMP itself. But since I have not a concise knowledge of all those MIBs = out there it would be nice to get an overview what we have there and why it might not fit. Best Regards, Thomas --=20 Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Rolf Winter > Sent: Tuesday, March 01, 2011 11:24 AM > To: Juergen Schoenwaelder; eman mailing list > Subject: Re: [eman] modeling power states >=20 > Sounds like a reasonable request. Could also go into the requirements > draft, either section 3 or section 7? >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London > W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > > Juergen Schoenwaelder > > Sent: Dienstag, 1. M=E4rz 2011 11:21 > > To: eman mailing list > > Subject: Re: [eman] modeling power states > > > > On Tue, Mar 01, 2011 at 10:58:56AM +0100, Romascanu, Dan (Dan) = wrote: > > > > > I am still to be convinced that an ENTITY-MIB extension is not > > possible. > > > What I understood from previous discussions is that the current > > > indexation scheme and mapping tables are not sufficient, but this > > does > > > not mean that an extension cannot be built. It looks like we are > > trying > > > to solve here to solve a modeling problem that is not specific = only > > for > > > power entities. > > > > I guess like Dan, I would appreciate a clear and yet concise > > explanation why the ENTITY-MIB does not work and why it is not > > possible or awkward to extend the ENTITY-MIB to make it work. If > > someone can write this up as a 2-page I-D (plus N page boilerplate = of > > the day ;-), I think we will have a much easier time to put this > > discussion to an end. > > > > Perhaps this text can be based on the text currently in section 3 of > > with some more details > > added. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman ------=_NextPart_000_0049_01CBD80A.9CA235E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQ4MIIENAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICczAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAzMDExMTE3MTlaMCMGCSqGSIb3 DQEJBDEWBBSFF0YbJQZl4WJ9RUCOGFy4b03IaDCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzCBtwYJKoZIhvcNAQkPMYGpMIGmMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG 9w0BAQEFAASCAQB6g8T0KUGWnWM7Fa/AwBH0/EyEgp740FfOerRtGjwnT9uqo/+kxhuu/Sa7AIho PtNDAJt0zBA0WZ+Xut4OD4lmTr/uN+HT4s0A0Au8Wj+qgW6lyFioTCvH2RDyUq+/NQ0aU0NZJ9TL +/z669zkACdLrs5h+8UNj1UZVv1eWCoxrdm59rlvVuoQ4Koc33qPMXntEREDQGzeX1io1xI1PEd/ O9wCk74Ix/R6KjpiliVRg/V0n1QagnoBr06TvV7UNdjbnLpPieuebTRN0ptiHreyfts7Lq/Jfazm +z12UflNKgvXoVeHXDgdDkF0N19WA87tKeHuFUcyLVLo/CoqcTq8AAAAAAAA ------=_NextPart_000_0049_01CBD80A.9CA235E0-- From ietf@quittek.at Tue Mar 1 06:06:09 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7AD3A67E1 for ; Tue, 1 Mar 2011 06:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+IziSJNH37P for ; Tue, 1 Mar 2011 06:06:08 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 47F893A686C for ; Tue, 1 Mar 2011 06:06:08 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MF9xL-1PoaY943Lv-00Fh5Y; Tue, 01 Mar 2011 15:07:11 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> In-Reply-To: <20110301111548.GA9369@elstar.local> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Tue, 1 Mar 2011 15:07:11 +0100 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:1E+Up1a0uoQLfPZYPLsuCauaw1VFeV52f/mduEUZVrn Er2gKeUwE6OIPXAMPhcYZJF5pk2AC/EZjJpFCtKiie4n6I8yhV SSEOXEiRId1KDwQWm0oa+0kU/VLoO98F3RernMtVMHarRddf38 k6kNCDBbczzMmvaYf4P/Y/s+MeHMTlRbxm7I236kw63xm+a9bM eDjmg6KD7GjRkC8knxxcA== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:06:09 -0000 Hi Juergen, Thank you for this hint. Let's investigate how far we can get with SNMP contexts. Juergen Am 01.03.2011 um 12:15 schrieb Juergen Schoenwaelder: > On Tue, Mar 01, 2011 at 11:50:23AM +0100, Juergen Quittek wrote: >> Hi Juergen, >> >> I assume you refer to the SNMP context engineID. >> >> Yes, this can be used as long as the remote device has one. >> If not, something else is needed. > > I am talking about an SNMP context as defined in RFC 3411 section > 3.3.1 and in particular the usage of contextName as a mechanism to > select different MIB trees. This is what the ENTITY-MIB calls a > logical entity. > > The default contextName ("") is the zero-length string, so on a power > over ethernet switch, we have objects reporting the energy consumption > of the components of the device itself (physical entities). If you > plug a phone into the switch and the switch is able to determine power > consumption of the remote phone device, you can instantiate another > MIB tree that reports the components of the phone as physical entities > under a different contextName (e.g., "port-N"). The ENTITY-MIB allows > you to discover which contexts are available. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From chrisv@cyberswitching.com Tue Mar 1 07:59:33 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAF03A69A1 for ; Tue, 1 Mar 2011 07:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8866eaSX6SD for ; Tue, 1 Mar 2011 07:59:32 -0800 (PST) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) by core3.amsl.com (Postfix) with ESMTP id EFD833A699E for ; Tue, 1 Mar 2011 07:59:31 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o147.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 0281d6d4.0.21000.00-306.50748.p01c11o147.mxlogic.net (envelope-from ); Tue, 01 Mar 2011 09:00:35 -0700 (MST) X-MXL-Hash: 4d6d18236ae48575-e736777c05df18cb3525ad14a0b964b6606ed75a Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 07:59:40 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 054992F6001; Tue, 1 Mar 2011 08:00:32 -0800 (PST) Date: Tue, 1 Mar 2011 08:00:32 -0800 From: chrisv@cyberswitching.com To: eman mailing list , "Romascanu, Dan (Dan)" , Juergen Quittek , Juergen Schoenwaelder Message-ID: <20110301160031.GA1150@cslinux-build01.cyberswitching.local> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110301102032.GA9233@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 01 Mar 2011 15:59:40.0587 (UTC) FILETIME=[AC484FB0:01CBD829] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=mrxgWj59b9sA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=rQgPzlyxCjmHzGzQjbgA] X-AnalysisOut: [:9 a=IGSPRBjiQAT4R5wkahSECNDVXiMA:4 a=CjuIK1q_8ugA:10] Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:59:33 -0000 On Tue, Mar 01, 2011 at 11:20:32AM +0100, Juergen Schoenwaelder wrote: > On Tue, Mar 01, 2011 at 10:58:56AM +0100, Romascanu, Dan (Dan) wrote: > > I am still to be convinced that an ENTITY-MIB extension is not possible. > > What I understood from previous discussions is that the current > > indexation scheme and mapping tables are not sufficient, but this does > > not mean that an extension cannot be built. It looks like we are trying > > to solve here to solve a modeling problem that is not specific only for > > power entities. > > I guess like Dan, I would appreciate a clear and yet concise > explanation why the ENTITY-MIB does not work and why it is not > possible or awkward to extend the ENTITY-MIB to make it work. If > someone can write this up as a 2-page I-D (plus N page boilerplate of > the day ;-), I think we will have a much easier time to put this > discussion to an end. Hi Juergen (S) and Dan, How would the model for a virtual entity like an outlet gang and physical outlets work? Entities: 1. Outlet #1 2. Outlet #2 3. Outlet #3 4. Outlet #4 5. Outlet Gang #1 (combo of Outlets #1 and #2) 6. Outlet Gang #2 (combo of Outlets #2 and #4) This scenario does occur with certain vendors iPDUs. Entities 5 and 6 in the list above are "virtual," in that they do not reflect a physically concrete object in the real world but instead are logical containers that simplify management of the associated real outlets. As far as I understand, entPhysicalTable would contain Outlets #1 thru #4 and entLogicalTable would contain the Outlet Gangs #1 and #2. Is this your understanding, too? In an EMAN schema based on ENTITY-MIB, how would this work? How would dual-indexing to both entPhysicalTable and entLogicalTable be done? Thanks, Chris From dromasca@avaya.com Tue Mar 1 08:22:34 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA11B3A6952 for ; Tue, 1 Mar 2011 08:22:33 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0-OtARmg5+o for ; Tue, 1 Mar 2011 08:22:32 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 6E51C3A6943 for ; Tue, 1 Mar 2011 08:22:31 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAADSsbE3GmAcF/2dsb2JhbACXd45VdKJ8Apl3hWEEj3k X-IronPort-AV: E=Sophos;i="4.62,248,1297054800"; d="scan'208";a="234674245" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Mar 2011 11:23:32 -0500 X-IronPort-AV: E=Sophos;i="4.62,248,1297054800"; d="scan'208";a="588366532" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Mar 2011 11:23:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 17:23:11 +0100 Message-ID: In-Reply-To: <20110301160031.GA1150@cslinux-build01.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvYKdMxKGxuTm0WSWyaO9Wtw5nC6AAAiaHg References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> From: "Romascanu, Dan (Dan)" To: , "eman mailing list" , "Juergen Quittek" , "Juergen Schoenwaelder" Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 16:22:34 -0000 =20 > -----Original Message----- > From: chrisv@cyberswitching.com [mailto:chrisv@cyberswitching.com]=20 > Sent: Tuesday, March 01, 2011 6:01 PM > To: eman mailing list; Romascanu, Dan (Dan); Juergen Quittek;=20 > Juergen Schoenwaelder > Subject: Re: [eman] modeling power states >=20 > On Tue, Mar 01, 2011 at 11:20:32AM +0100, Juergen Schoenwaelder wrote: > > On Tue, Mar 01, 2011 at 10:58:56AM +0100, Romascanu, Dan=20 > (Dan) wrote: > > > I am still to be convinced that an ENTITY-MIB extension=20 > is not possible. > > > What I understood from previous discussions is that the current=20 > > > indexation scheme and mapping tables are not sufficient, but this=20 > > > does not mean that an extension cannot be built. It looks like we=20 > > > are trying to solve here to solve a modeling problem that is not=20 > > > specific only for power entities. > > > > I guess like Dan, I would appreciate a clear and yet concise=20 > > explanation why the ENTITY-MIB does not work and why it is not=20 > > possible or awkward to extend the ENTITY-MIB to make it work. If=20 > > someone can write this up as a 2-page I-D (plus N page=20 > boilerplate of=20 > > the day ;-), I think we will have a much easier time to put this=20 > > discussion to an end. >=20 > Hi Juergen (S) and Dan, >=20 > How would the model for a virtual entity like an outlet gang=20 > and physical outlets work? >=20 > Entities: > 1. Outlet #1 > 2. Outlet #2 > 3. Outlet #3 > 4. Outlet #4 > 5. Outlet Gang #1 (combo of Outlets #1 and #2) > 6. Outlet Gang #2 (combo of Outlets #2 and #4) >=20 > This scenario does occur with certain vendors iPDUs. >=20 > Entities 5 and 6 in the list above are "virtual," in that=20 > they do not reflect a physically concrete object in the real=20 > world but instead are logical containers that simplify=20 > management of the associated real outlets. >=20 > As far as I understand, entPhysicalTable would contain Outlets #1 thru > #4 and entLogicalTable would contain the Outlet Gangs #1 and=20 > #2. Is this your understanding, too? >=20 > In an EMAN schema based on ENTITY-MIB, how would this work? =20 > How would dual-indexing to both entPhysicalTable and=20 > entLogicalTable be done? >=20 > Thanks, > Chris >=20 How is this problem different from the one of managing a stack or cluster of physical devices? Ethernet switch vendors have done this for a decade and more. You just define entries for the Outlet Gangs #1 and #2 also in the entPhysical table, use the entPhysicalContainsTable to define the containment relations with Outlet #1-4 and map them one-to-one to the entries in the entLogicalTable. =20 Dan From j.schoenwaelder@jacobs-university.de Tue Mar 1 13:22:53 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547913A6ABF for ; Tue, 1 Mar 2011 13:22:53 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3c3Z5jEzboA for ; Tue, 1 Mar 2011 13:22:50 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BA7823A6A16 for ; Tue, 1 Mar 2011 13:22:48 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30729C0013; Tue, 1 Mar 2011 22:23:52 +0100 (CET) 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 V2t5fmpW7YOC; Tue, 1 Mar 2011 22:23:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFA89C0012; Tue, 1 Mar 2011 22:23:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BB17816D5A79; Tue, 1 Mar 2011 22:23:45 +0100 (CET) Date: Tue, 1 Mar 2011 22:23:45 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110301212345.GB12679@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, eman mailing list , "Romascanu, Dan (Dan)" , Juergen Quittek References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110301160031.GA1150@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 21:22:53 -0000 On Tue, Mar 01, 2011 at 08:00:32AM -0800, chrisv@cyberswitching.com wrote: > > Hi Juergen (S) and Dan, > > How would the model for a virtual entity like an outlet gang and > physical outlets work? > > Entities: > 1. Outlet #1 > 2. Outlet #2 > 3. Outlet #3 > 4. Outlet #4 > 5. Outlet Gang #1 (combo of Outlets #1 and #2) > 6. Outlet Gang #2 (combo of Outlets #2 and #4) > > This scenario does occur with certain vendors iPDUs. What exactly is an outlet gang? My knowledge of English is somewhat limited when it comes to such terms and it is important that I understand what it is to answer your question. > Entities 5 and 6 in the list above are "virtual," in that they do not > reflect a physically concrete object in the real world but instead are > logical containers that simplify management of the associated real > outlets. Is #2 really part of both Outlet Gangs? What can I do with such an outlet gang? > As far as I understand, entPhysicalTable would contain Outlets #1 thru > #4 and entLogicalTable would contain the Outlet Gangs #1 and #2. Is > this your understanding, too? Most likely not (most likely since I am not sure what an outlet gang is ;-). A logical entity is defined in RFC 4133 as follows: A managed system contains one or more logical entities, each represented by at most one instantiation of each of a particular set of MIB objects. A set of management functions is associated with each logical entity. Examples of logical entities include routers, bridges, print-servers, etc. The 'logical entity' term might have been a confusing choice. But anyway, a 'logical entity' means "an SNMP context hosting a MIB object tree". In other words, an SNMP agent can host multiple independent MIB object trees and contexts select which MIB object tree you access. A logical entity is pretty much the same as an SNMP context (at least for the discussion we have here, an SNMP purist likely would say that a logical entity is one way of using SNMP contexts). > In an EMAN schema based on ENTITY-MIB, how would this work? How would > dual-indexing to both entPhysicalTable and entLogicalTable be done? The SNMP engine representing your outlets has a default SNMP context (contextName ""), which is a 'logical entity'. In this default context (logical entity), you find the entPhysicalTable entries representing the physical components and sensors of the device. If some power consuming device A is plugged into one of your outlets and device A provides additional power sensors and your devices can access them remotely (via some implementation specific mechanism), you can represent the power consumer A in a seperate SNMP context (aka logical entity, e.g. contextName="A"). The MIB tree of this logical entity will provide the entPhysicalTable entries representing the physical components and sensors of power consumer A. The entLogicalTable in the default context lists the logical contexts that are available. In other words, an application can access the default context and read information about the physical components. To discover any addition logical contexts, your application reads the entLogicalTable. Once you learned which logical contexts exist, you access the agent with the appropriate contextName etc. and you can read information from remote devices, such as device A. If you have a collection of outlets somehow bundled together, you can model this by putting the physical components into different 'modules' (see PhysicalClass of the ENTITY-MIB). The ENTITY-MIB provides some support for expressing this kind of relationships since routers and switches often have a modular structure and power supplies might be similar (but I am obviously no an expert in that domain). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From chrisv@cyberswitching.com Tue Mar 1 14:24:08 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7A53A694E for ; Tue, 1 Mar 2011 14:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpmvjxZlMddV for ; Tue, 1 Mar 2011 14:24:06 -0800 (PST) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) by core3.amsl.com (Postfix) with ESMTP id 824DD3A6AB7 for ; Tue, 1 Mar 2011 14:24:06 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o143.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 6427d6d4.0.12937.00-399.28695.p01c11o143.mxlogic.net (envelope-from ); Tue, 01 Mar 2011 15:25:10 -0700 (MST) X-MXL-Hash: 4d6d7246173045e5-b70826a5f42f574aae2ac45b7b6c07f121ff69b0 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 14:24:16 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 13AC62F6001; Tue, 1 Mar 2011 14:25:10 -0800 (PST) Date: Tue, 1 Mar 2011 14:25:10 -0800 From: chrisv@cyberswitching.com To: eman mailing list , "Romascanu, Dan (Dan)" , Juergen Quittek Message-ID: <20110301222510.GA21719@cslinux-build01.cyberswitching.local> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301212345.GB12679@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110301212345.GB12679@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 01 Mar 2011 22:24:16.0232 (UTC) FILETIME=[66704E80:01CBD85F] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=mrxgWj59b9sA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=4UanM_MMZkp2Q40x4B8A] X-AnalysisOut: [:9 a=N9i6jWg0JipSuDa5u_sA:7 a=U3nJCqz81E97yUISkgD9BNSMP9MA] X-AnalysisOut: [:4 a=CjuIK1q_8ugA:10 a=P2OoPkYXJJPdhRVI:21 a=Tr8NHBuU4LSj6] X-AnalysisOut: [jmK:21] Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:24:08 -0000 On Tue, Mar 01, 2011 at 10:23:45PM +0100, Juergen Schoenwaelder wrote: > > Entities: > > 1. Outlet #1 > > 2. Outlet #2 > > 3. Outlet #3 > > 4. Outlet #4 > > 5. Outlet Gang #1 (combo of Outlets #1 and #2) > > 6. Outlet Gang #2 (combo of Outlets #2 and #4) > > > > This scenario does occur with certain vendors iPDUs. > > What exactly is an outlet gang? My knowledge of English is somewhat > limited when it comes to such terms and it is important that I > understand what it is to answer your question. An outlet gang is a collection of outlets that appear as a single entity. The corresponding class diagram might be: +------------------+ +--------------+ | OutletGangObject |<>---------| OutletObject | +------------------+ +--------------+ Where the "<>---" operator is the UML "composite" operator. For example, let's say a server has redundant power supplies connected to the same PDU (Outlets 1 and 7). You can create an outlet gang called "Server Outlets" that are a collection of Outlets 1 and 7. Then the "Server Outlets" entity can be queried for power data, control, etc. > > Entities 5 and 6 in the list above are "virtual," in that they do not > > reflect a physically concrete object in the real world but instead are > > logical containers that simplify management of the associated real > > outlets. > > Is #2 really part of both Outlet Gangs? What can I do with such an > outlet gang? I think I answered this question above in the explanation, but let me know if it was unclear. > > As far as I understand, entPhysicalTable would contain Outlets #1 thru > > #4 and entLogicalTable would contain the Outlet Gangs #1 and #2. Is > > this your understanding, too? > > Most likely not (most likely since I am not sure what an outlet gang > is ;-). A logical entity is defined in RFC 4133 as follows: > > A managed system contains one or more logical entities, each > represented by at most one instantiation of each of a particular > set of MIB objects. A set of management functions is associated > with each logical entity. Examples of logical entities include > routers, bridges, print-servers, etc. > > The 'logical entity' term might have been a confusing choice. But > anyway, a 'logical entity' means "an SNMP context hosting a MIB object > tree". In other words, an SNMP agent can host multiple independent MIB > object trees and contexts select which MIB object tree you access. A > logical entity is pretty much the same as an SNMP context (at least > for the discussion we have here, an SNMP purist likely would say that > a logical entity is one way of using SNMP contexts). > > > In an EMAN schema based on ENTITY-MIB, how would this work? How would > > dual-indexing to both entPhysicalTable and entLogicalTable be done? > > The SNMP engine representing your outlets has a default SNMP context > (contextName ""), which is a 'logical entity'. In this default context > (logical entity), you find the entPhysicalTable entries representing > the physical components and sensors of the device. > > If some power consuming device A is plugged into one of your outlets > and device A provides additional power sensors and your devices can > access them remotely (via some implementation specific mechanism), you > can represent the power consumer A in a seperate SNMP context (aka > logical entity, e.g. contextName="A"). The MIB tree of this logical > entity will provide the entPhysicalTable entries representing the > physical components and sensors of power consumer A. The > entLogicalTable in the default context lists the logical contexts that > are available. In other words, an application can access the default > context and read information about the physical components. To > discover any addition logical contexts, your application reads the > entLogicalTable. Once you learned which logical contexts exist, you > access the agent with the appropriate contextName etc. and you can > read information from remote devices, such as device A. > > If you have a collection of outlets somehow bundled together, you can > model this by putting the physical components into different 'modules' > (see PhysicalClass of the ENTITY-MIB). The ENTITY-MIB provides some > support for expressing this kind of relationships since routers and > switches often have a modular structure and power supplies might be > similar (but I am obviously no an expert in that domain). Now it's my turn to be confused. I'm definitely not understanding ENTITY-MIB, it seems. I interpreted "Physical" to mean "real-world instantiations of an object" and "Logical" to mean "objects that have no physical substance (like software)". Given that the notion of an outlet gang is virtual -- it's just a more user-friendly interface -- wouldn't that go into entLogicalTable while the outlets themselves go into entPhysicalTable? More fully, I'd appreciate a diagram of how you'd suggest representing the 24-outlet PDU scenario described earlier using ENTITY-MIB. Perhaps that would help in understanding ENTITY-MIB's structure. Thanks, Chris From chrisv@cyberswitching.com Tue Mar 1 14:29:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521BD3A6AB7 for ; Tue, 1 Mar 2011 14:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3znlTrnTgLLw for ; Tue, 1 Mar 2011 14:29:09 -0800 (PST) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) by core3.amsl.com (Postfix) with ESMTP id EA9FA3A6A47 for ; Tue, 1 Mar 2011 14:29:08 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o147.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 4737d6d4.0.20898.00-329.47617.p01c11o147.mxlogic.net (envelope-from ); Tue, 01 Mar 2011 15:30:13 -0700 (MST) X-MXL-Hash: 4d6d737520cd941c-2f74b4028c129360f1e7734ba5eab19aea7f15fd Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 14:29:18 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id A47A72F6001; Tue, 1 Mar 2011 14:30:12 -0800 (PST) Date: Tue, 1 Mar 2011 14:30:12 -0800 From: chrisv@cyberswitching.com To: "Romascanu, Dan (Dan)" Message-ID: <20110301223012.GB21719@cslinux-build01.cyberswitching.local> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 01 Mar 2011 22:29:18.0770 (UTC) FILETIME=[1AC3F120:01CBD860] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=mrxgWj59b9sA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=PVL_FtcflfICmI9a1v0A] X-AnalysisOut: [:9 a=oc5VOe3r-vhDY4JcUVQFzVEiY3UA:4 a=CjuIK1q_8ugA:10] Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:29:11 -0000 On Tue, Mar 01, 2011 at 05:23:11PM +0100, Romascanu, Dan (Dan) wrote: > How is this problem different from the one of managing a stack or > cluster of physical devices? Ethernet switch vendors have done this for > a decade and more. You just define entries for the Outlet Gangs #1 and > #2 also in the entPhysical table, use the entPhysicalContainsTable to > define the containment relations with Outlet #1-4 and map them > one-to-one to the entries in the entLogicalTable. Hi Dan, I'm going to assume that my follow up to this was covered in the previous reply. While the scenario that I've described talks about this in terms of Outlet Gangs (because that's what I know), you could apply the same question to that of a VMware ESXi server running multiple Windows and Linux VMs. If an agent wanted to expose the VMware ESXi server's power consumption and allocate power to each VM, how would that structure work in relation to ENTITY-MIB? +--------------------+ | VMware server | | | | +--------------+ | | | Windows VM 1 | | | +--------------+ | | | | +--------------+ | | | Windows VM 2 | | | +--------------+ | | | | +--------------+ | | | Linux VM | | | +--------------+ | | | | +--------------+ | | | Solaris VM | | | +--------------+ | | | +--------------------+ Would there be 5 entities listed in entPhysicalTable, one for each of the above items? (It's kinda trippy since the VM's aren't "physical.") Thanks, Chris From j.schoenwaelder@jacobs-university.de Tue Mar 1 14:50:55 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16FEE3A6B02 for ; Tue, 1 Mar 2011 14:50:55 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMiqPg0Hbs0T for ; Tue, 1 Mar 2011 14:50:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3A4B63A6908 for ; Tue, 1 Mar 2011 14:50:53 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2221C0011; Tue, 1 Mar 2011 23:51:56 +0100 (CET) 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 o9tqzp2aMTrb; Tue, 1 Mar 2011 23:51:56 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAC1EC000D; Tue, 1 Mar 2011 23:51:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E751916D5D2F; Tue, 1 Mar 2011 23:51:50 +0100 (CET) Date: Tue, 1 Mar 2011 23:51:50 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110301225150.GA12906@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, eman mailing list , "Romascanu, Dan (Dan)" , Juergen Quittek References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301212345.GB12679@elstar.local> <20110301222510.GA21719@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110301222510.GA21719@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:50:55 -0000 On Tue, Mar 01, 2011 at 02:25:10PM -0800, chrisv@cyberswitching.com wrote: > On Tue, Mar 01, 2011 at 10:23:45PM +0100, Juergen Schoenwaelder wrote: > > > Entities: > > > 1. Outlet #1 > > > 2. Outlet #2 > > > 3. Outlet #3 > > > 4. Outlet #4 > > > 5. Outlet Gang #1 (combo of Outlets #1 and #2) > > > 6. Outlet Gang #2 (combo of Outlets #2 and #4) > > > > > > This scenario does occur with certain vendors iPDUs. > > > > What exactly is an outlet gang? My knowledge of English is somewhat > > limited when it comes to such terms and it is important that I > > understand what it is to answer your question. > > An outlet gang is a collection of outlets that appear as a single > entity. The corresponding class diagram might be: > > +------------------+ +--------------+ > | OutletGangObject |<>---------| OutletObject | > +------------------+ +--------------+ > > Where the "<>---" operator is the UML "composite" operator. > > For example, let's say a server has redundant power supplies connected > to the same PDU (Outlets 1 and 7). You can create an outlet gang called > "Server Outlets" that are a collection of Outlets 1 and 7. Then the > "Server Outlets" entity can be queried for power data, control, etc. OK, I think I got it. > > > Entities 5 and 6 in the list above are "virtual," in that they do not > > > reflect a physically concrete object in the real world but instead are > > > logical containers that simplify management of the associated real > > > outlets. > > > > Is #2 really part of both Outlet Gangs? What can I do with such an > > outlet gang? > > I think I answered this question above in the explanation, but let me > know if it was unclear. So you confirm that an outlet can be part of two different outlet gangs at the same time? I think this is an important detail to know. > > > As far as I understand, entPhysicalTable would contain Outlets #1 thru > > > #4 and entLogicalTable would contain the Outlet Gangs #1 and #2. Is > > > this your understanding, too? > > > > Most likely not (most likely since I am not sure what an outlet gang > > is ;-). A logical entity is defined in RFC 4133 as follows: > > > > A managed system contains one or more logical entities, each > > represented by at most one instantiation of each of a particular > > set of MIB objects. A set of management functions is associated > > with each logical entity. Examples of logical entities include > > routers, bridges, print-servers, etc. > > > > The 'logical entity' term might have been a confusing choice. But > > anyway, a 'logical entity' means "an SNMP context hosting a MIB object > > tree". In other words, an SNMP agent can host multiple independent MIB > > object trees and contexts select which MIB object tree you access. A > > logical entity is pretty much the same as an SNMP context (at least > > for the discussion we have here, an SNMP purist likely would say that > > a logical entity is one way of using SNMP contexts). > > > > > In an EMAN schema based on ENTITY-MIB, how would this work? How would > > > dual-indexing to both entPhysicalTable and entLogicalTable be done? > > > > The SNMP engine representing your outlets has a default SNMP context > > (contextName ""), which is a 'logical entity'. In this default context > > (logical entity), you find the entPhysicalTable entries representing > > the physical components and sensors of the device. > > > > If some power consuming device A is plugged into one of your outlets > > and device A provides additional power sensors and your devices can > > access them remotely (via some implementation specific mechanism), you > > can represent the power consumer A in a seperate SNMP context (aka > > logical entity, e.g. contextName="A"). The MIB tree of this logical > > entity will provide the entPhysicalTable entries representing the > > physical components and sensors of power consumer A. The > > entLogicalTable in the default context lists the logical contexts that > > are available. In other words, an application can access the default > > context and read information about the physical components. To > > discover any addition logical contexts, your application reads the > > entLogicalTable. Once you learned which logical contexts exist, you > > access the agent with the appropriate contextName etc. and you can > > read information from remote devices, such as device A. > > > > If you have a collection of outlets somehow bundled together, you can > > model this by putting the physical components into different 'modules' > > (see PhysicalClass of the ENTITY-MIB). The ENTITY-MIB provides some > > support for expressing this kind of relationships since routers and > > switches often have a modular structure and power supplies might be > > similar (but I am obviously no an expert in that domain). > > Now it's my turn to be confused. I'm definitely not understanding > ENTITY-MIB, it seems. I interpreted "Physical" to mean "real-world > instantiations of an object" and "Logical" to mean "objects that have no > physical substance (like software)". Yes, I assume you misinterpret the terms by giving "logical" an interpretation that is not defined in RFC 4133. Please check again the text in RFC 4133. > Given that the notion of an outlet gang is virtual -- it's just a more > user-friendly interface -- wouldn't that go into entLogicalTable while > the outlets themselves go into entPhysicalTable? No. > More fully, I'd appreciate a diagram of how you'd suggest representing > the 24-outlet PDU scenario described earlier using ENTITY-MIB. Perhaps > that would help in understanding ENTITY-MIB's structure. You mean this: > 1. 24 outlets, single phase > 2. 6 banks (4 outlets per bank), single phase > 3. 2 inputs (3 banks per input), three phase > 4. "Ganged" outlets (multiple outlets that are managed as one > construct) > 5. High current alerts, low current alerts, circuit breaker alerts, > high voltage alerts (spikes), low voltage alerts (sags) -- all of > which can be applied to a physical entity or a logical entity > (like an outlet "gang") > 6. Internal network card and metering logic > 7. Outlets "owned" by different users (think co-location facility, > "context") > 8. Manage power via 5 different interface modalities/mechanisms > 9. Except for the existence of the outlets/banks/inputs/"gangs", all > other properties are potentially optional I can't do this without your help because I do not understand the example. As mentioned before, I am pretty much clueless about power supplies and their terminology. I do not know what it means for an outlet to be "owned" by a user. I do not know what 5 different interface modalities/mechanisms are. What are banks? Where exactly are the voltage / current measurements taken? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bnordman@lbl.gov Tue Mar 1 16:53:13 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470803A6A30 for ; Tue, 1 Mar 2011 16:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERmPy4oExPSF for ; Tue, 1 Mar 2011 16:53:11 -0800 (PST) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by core3.amsl.com (Postfix) with ESMTP id 4C47F3A6A21 for ; Tue, 1 Mar 2011 16:53:10 -0800 (PST) X-Ironport-SBRS: 5.3 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQBAPgjbU3RVdy0mWdsb2JhbACCTpVtAYYGAYc0VQgVAQEBAQEICwoHESWjQppWgxiCSQSFEocNiFE6 X-IronPort-AV: E=Sophos;i="4.62,250,1297065600"; d="scan'208";a="35957709" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport3.lbl.gov with ESMTP; 01 Mar 2011 16:54:14 -0800 Received: by mail-vx0-f180.google.com with SMTP id 38so6339150vxc.39 for ; Tue, 01 Mar 2011 16:54:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.180.227 with SMTP id dr3mr6864446vdc.154.1299027252976; Tue, 01 Mar 2011 16:54:12 -0800 (PST) Received: by 10.52.155.40 with HTTP; Tue, 1 Mar 2011 16:54:12 -0800 (PST) Date: Tue, 1 Mar 2011 16:54:12 -0800 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=bcaec5196747f79da9049d7559b9 Subject: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:53:13 -0000 --bcaec5196747f79da9049d7559b9 Content-Type: text/plain; charset=ISO-8859-1 I am reposting Juergen's email about power states. While the subsequent discussion has been important and useful, it is on a different topic. So, please let's also make progress on this topic. --Bruce On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: > Dear all, > > We have two proposals for a Power/Energy MIB module: > > - draft-claise-energy-monitoring-mib-06 > - draft-quittek-power-mib-02 > > Among the authors of both documents we are currently trying to merge them. > But there are some open issues that should be discussed on the mailing > list. Here is the probably biggest of them: modeling power states. > > For simplifying energy management we want to introduce the concept of > power states (aka power levels). A power state will indicate roughly how > much power a device consumes. Examples for simple power states are off, > sleep, and operational states. > > In the envisioned EMAN MIB modules, a power state is characterized by a > descriptive name and the device's expected power input in this state > (max/min/average). > > Power states are not a new concept. The DMTF has already defined a set of > power states and there is the Other standards bodies as the DMTF > (Distributed Management Task Force) and there is the ACPI (Advanced > Configuration and Power Interface) for PC motherboards. And there may be > more than these out there. I listed some DMTF and ACPI states at the end > of this message. > > An easy solution for EMAN would be just adopting one of these sets. > However, there are issues with the ones we looked at. ACPI was developed > for PC motherboards and is quite PC-centric. Also it defines states that > seem to be superfluous, because so far, almost no one has implemented > them. Also the DMTF model seems to have a narrower scope than envisioned > by the EMAN WG. > > At some point in time, the EMAN WG hast to make a decision, which power > state model to adopt. Here is a set of alternatives. The first four have > fixed sets of power states. > > Option 1: fixed minimum > Just support three power states (off, sleep (stand-by), operational) > This has clear semantics, but there are several people claiming it's too > restrictive. > > Option 2: fixed DMTF > Just use the states defined by DMTF. > Might be too much focussed n PCs. > > Option 3: fixed ACPI > Just use the states defined by ACPI. > Might be too much focussed n PCs. > > > > Option 4: fixed EMAN > Define a new fixed set of power levels within the EMAN WG. > > Option 5: IANA-registered power states > Have power states be registered at IANA. > We would start with registering (off, sleep, operational, the DMTF set, > and the ACPI set. > Manufacturers can then register further ones. > > > There has been discussions pointing out that these fixed sets may not be > sufficient, particularly if non-IT equipment should also be covered. > > For being more open, the idea to support user-defined or > manufacturer-defined power states of devices has been developed. In such > a state, for example, certain components of a device may be switched off > or put to sleep. Which ones are switched off in which state is to be > defined by the user/operator/manufacturer and may be chosen such that > operational needs are met. > > Again, there are several proposals how to do this. All of them favor a > two-level approach that distinguishes between rather flexible functional > power states and rather fixed basic power states. Functional power states > would be defined by the manufacturer, operator, or user. These would be > the power states that would be reported by a device. However, in order to > better define the semantics of functional power states, Each of these > would be mapped to exactly one basic power states. This means that a > property of any functional state would be the basic state it maps to. > Basic power states would be fixed, such as the ones used in options 1-5. > An easy example would be functional power states defined by > user/operator/manufacturer with each state indicating whether it is an off > state, a sleep state or an operational state. > > Here are the corresponding options: > > Option 6: flexible functional states mapped to a fixed set of basic states > States could be defined flexibly. But each state would indicate a basic > state to which it corresponds. Basic states could be either basic > (off/sleep/operational) or the DMTF set or the ACPI set > > Option 7: flexible functional states mapped to a IANA registered set of > basic states > This is like Option 6, but basic states would be registered at IANA and > can be extended. We would register all DMTF and ACPI states and probably > some more at IANA. Manufacturers could add more. > > Option 8: IANA-registered sets of functional states, only three basic > states > The main reasoning behind this option is that is should always be clear > whether a power state is an off state, a sleep state, or an operational > state. Therefore, only these three basic states are supported. This > would be in line with an instance of Option 6. However, this option has > an extension for the functional states. It suggests that for customizing > devices in order to be compliant with given management systems, for > example a DMTF-based system, it should be possible to restrict functional > power states to a given set that is registered at IANA. An example would > be the DMTF states. We would register a flag at IANA that indicates we > are using DMTF states only. This would signal the management application > that all power state IDs are in line with power state numbering as defined > by IANA. Analogously, ACPI and further sets could be registered at IANA. > A fallback to Option 6 could be realized by registering a set number of 0 > at IANA that does not impose any limit for functional states. > > Obviously, there are more possible options. If you think there is a > better one, please send it to this list. > > I know this discussion is not easy, but we have to have it in order to > make the right decision in the EMAN WG. Please take some time and think > about what you consider to be the best way to go. And of course send > questions on the issue. > > Thanks. > > Juergen > > > DMTF (Distributed Management Task Force) power states: > - 2 (Power On) > - 3 (Sleep - Light) > - 4 (Sleep - Deep) > - 5 (Power Cycle (Off Soft)) > - 6 (Power Off - Hard) > - 7 (Hibernate) > - 8 (Power Off - Soft) > - 9 (Power Cycle (Off Hard)) > - 10 (Master Bus Reset) > - 11 (Diagnostic Interrupt (NMI)) > - 12 (Power Off - Soft Graceful) > - 13 (Power Off - Hard Graceful) > - 14 (Master Bus Reset Graceful) > - 15 (Power Cycle (Off - Soft Graceful)) > - 16 (Power Cycle (Off - Hard Graceful)) > > ACPI (Advanced Configuration and Power Interface Specification) power > states for PC motherboards: > - G3-S5 (Off-Hard) > - G2-S5 (Off-Soft) > - G1-S4 (Hibernate) > - G1-S3 (Sleep-Deep) > - G1-S2 (Sleep-Light) > - G1-S1 (Sleep-Light) > - G0-S0-P5 > - G0-S0-P4 > - G0-S0-P3 > - G0-S0-P2 > - G0-S0-P2 > - G0-S0-P2 > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec5196747f79da9049d7559b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am reposting Juergen's email about power states.
While the subsequ= ent discussion has been important
and useful, it is on a different topic= .=A0 So, please let's
also make progress on this topic.
--Bruce
On Mon, Feb 28, 2011 at 4:07 AM, Juergen Qui= ttek <Quittek@nec= lab.eu> wrote:
Dear all,

We have two proposals for a Power/Energy MIB module:

=A0- draft-claise-energy-monitoring-mib-06
=A0- draft-quittek-power-mib-02

Among the authors of both documents we are currently trying to merge them.<= br> But there are some open issues that should be discussed on the mailing
list. =A0Here is the probably biggest of them: modeling power states.

For simplifying energy management we want to introduce the concept of
power states (aka power levels). =A0A power state will indicate roughly how=
much power a device consumes. =A0Examples for simple power states are off,<= br> sleep, and operational states.

In the envisioned EMAN MIB modules, a power state is characterized by a
descriptive name and the device's expected power input in this state (max/min/average).

Power states are not a new concept. =A0The DMTF has already defined a set o= f
power states and there is the Other standards bodies as the DMTF
(Distributed Management Task Force) and there =A0is the ACPI (Advanced
Configuration and Power Interface) for PC motherboards. =A0And there may be=
more than these out there. =A0I listed some DMTF and ACPI states at the end=
of this message.

An easy solution for EMAN would be just adopting one of these sets.
However, there are issues with the ones we looked at. =A0ACPI was developed=
for PC motherboards and is quite PC-centric. =A0Also it defines states that=
seem to be superfluous, because so far, almost no one has implemented
them. =A0Also the DMTF model seems to have a narrower scope than envisioned=
by the EMAN WG.

At some point in time, the EMAN WG hast to make a decision, which power
state model to adopt. =A0Here is a set of alternatives. The first four have=
fixed sets of power states.

Option 1: fixed minimum
Just support three power states (off, sleep (stand-by), operational)
This has clear semantics, but there are several people claiming it's to= o
restrictive.

Option 2: fixed DMTF
Just use the states defined by DMTF.
Might be too much focussed n PCs.

Option 3: fixed ACPI
Just use the states defined by ACPI.
Might be too much focussed n PCs.



Option 4: fixed EMAN
Define a new fixed set of power levels within the EMAN WG.

Option 5: IANA-registered power states
Have power states be registered at IANA.
We would start with registering (off, sleep, operational, the DMTF set,
and the ACPI set.
Manufacturers can then register further ones.


There has been discussions pointing out that these fixed sets may not be sufficient, particularly if non-IT equipment should also be covered.

For being more open, the idea to support user-defined or
manufacturer-defined power states of devices has been developed. =A0In such=
a state, for example, certain components of a device may be switched off or put to sleep. =A0Which ones are switched off in which state is to be
defined by the user/operator/manufacturer and may be chosen such that
operational needs are met.

Again, there are several proposals how to do this. =A0All of them favor a two-level approach that distinguishes between rather flexible functional power states and rather fixed basic power states. =A0Functional power state= s
would be defined by the manufacturer, operator, or user. =A0These would be<= br> the power states that would be reported by a device. =A0However, in order t= o
better define the semantics of functional power states, Each of these
would be mapped to exactly one basic power states. =A0This means that a
property of any functional state would be the basic state it maps to.
Basic power states would be fixed, such as the ones used in options 1-5. An easy example would be functional power states defined by
user/operator/manufacturer with each state indicating whether it is an off<= br> state, a sleep state or an operational state.

Here are the corresponding options:

Option 6: flexible functional states mapped to a fixed set of basic states<= br> States could be defined flexibly. =A0But each state would indicate a basic<= br> state to which it corresponds. Basic states could be either basic
(off/sleep/operational) or the DMTF set or the ACPI set

Option 7: flexible functional states mapped to a IANA registered set of
basic states
This is like Option 6, but basic states would be registered at IANA and
can be extended. =A0We would register all DMTF and ACPI states and probably=
some more at IANA. Manufacturers could add more.

Option 8: IANA-registered sets of functional states, only three basic
states
The main reasoning behind this option is that is should always be clear
whether a power state is an off state, a sleep state, or an operational
state. =A0Therefore, only these three basic states are supported. =A0This would be in line with an instance of Option 6. =A0However, this option has<= br> an extension for the functional states. =A0It suggests that for customizing=
devices in order to be compliant with given management systems, for
example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. =A0An example would=
be the DMTF states. =A0We would register a flag at IANA that indicates we are using DMTF states only. =A0This would signal the management application=
that all power state IDs are in line with power state numbering as defined<= br> by IANA. =A0Analogously, ACPI and further sets could be registered at IANA.=
A fallback to Option 6 could be realized by registering a set number of 0 at IANA that does not impose any limit for functional states.

Obviously, there are more possible options. =A0If you think there is a
better one, please send it to this list.

I know this discussion is not easy, but we have to have it in order to
make the right decision in the EMAN WG. =A0Please take some time and think<= br> about what you consider to be the best way to go. =A0And of course send
questions on the issue.

Thanks.

=A0 =A0Juergen


DMTF (Distributed Management Task Force) power states:
=A0- 2 (Power On)
=A0- 3 (Sleep - Light)
=A0- 4 (Sleep - Deep)
=A0- 5 (Power Cycle (Off Soft))
=A0- 6 (Power Off - Hard)
=A0- 7 (Hibernate)
=A0- 8 (Power Off - Soft)
=A0- 9 (Power Cycle (Off Hard))
=A0- 10 (Master Bus Reset)
=A0- 11 (Diagnostic Interrupt (NMI))
=A0- 12 (Power Off - Soft Graceful)
=A0- 13 (Power Off - Hard Graceful)
=A0- 14 (Master Bus Reset Graceful)
=A0- 15 (Power Cycle (Off - Soft Graceful))
=A0- 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced Configuration and Power Interface Specification) power
states for PC motherboards:
=A0- G3-S5 (Off-Hard)
=A0- G2-S5 (Off-Soft)
=A0- G1-S4 (Hibernate)
=A0- G1-S3 (Sleep-Deep)
=A0- G1-S2 (Sleep-Light)
=A0- G1-S1 (Sleep-Light)
=A0- G0-S0-P5
=A0- G0-S0-P4
=A0- G0-S0-P3
=A0- G0-S0-P2
=A0- G0-S0-P2
=A0- G0-S0-P2




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



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

--bcaec5196747f79da9049d7559b9-- From chrisv@cyberswitching.com Tue Mar 1 17:53:35 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE8F3A6A21 for ; Tue, 1 Mar 2011 17:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2QzCrHKMaia for ; Tue, 1 Mar 2011 17:53:33 -0800 (PST) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by core3.amsl.com (Postfix) with ESMTP id 068FB3A6A24 for ; Tue, 1 Mar 2011 17:53:11 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o144.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 843ad6d4.0.39298.00-316.83068.p01c11o144.mxlogic.net (envelope-from ); Tue, 01 Mar 2011 18:54:16 -0700 (MST) X-MXL-Hash: 4d6da34864682720-302bcbcc197b25c56a989f3b9b031fd3e2630363 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD87C.9B6F1DA8" Date: Tue, 1 Mar 2011 17:53:20 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CECD966@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power States - really Thread-Index: AcvYdELXFNvLH+ZHSyS3Xa0zzpZ4LwACEETw References: From: "Chris Verges" To: "Bruce Nordman" , "eman mailing list" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XnxjYOJpEeMA:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=wzgqfsuUAAAA:8 a=48vgC7mUAAAA:8 a=5VBs] X-AnalysisOut: [0FMkFKEn-GQfF9IA:9 a=Sq4uYppYSD4QSrP_N9AA:7 a=pmrokS2M-pQ2] X-AnalysisOut: [SQTfxEsTyLl2SAMA:4 a=CjuIK1q_8ugA:10 a=Y8rda4wpm8gA:10 a=F] X-AnalysisOut: [nBvD0j_UmcA:10 a=lr71C7C2fScA:10 a=lZB815dzVvQA:10 a=VAlTv] X-AnalysisOut: [2IFO62PzxcS:21 a=FY3h5c4CMI1CK0wN:21 a=yMhMjlubAAAA:8 a=SS] X-AnalysisOut: [mOFEACAAAA:8 a=J35dNKfbAAAA:8 a=dReXSmL-qT81MMOUpBwA:9 a=L] X-AnalysisOut: [pN-38mm4S14mmLVb5MA:7 a=mXzNVCRs_4PKaUj0fJ6WxG0wx9wA:4 a=h] X-AnalysisOut: [RyMOdY_OVx2nwau:21 a=MliuOUl5g2eP1Wyw:21] Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:53:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD87C.9B6F1DA8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Option 6: Support all of them. =20 Chris =20 --=20 Chris Verges 408-500-2377 http://www.cyberswitching.com =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman Sent: Tuesday, March 01, 2011 4:54 PM To: eman mailing list Subject: [eman] Power States - really =20 I am reposting Juergen's email about power states. While the subsequent discussion has been important and useful, it is on a different topic. So, please let's also make progress on this topic. --Bruce On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: Dear all, We have two proposals for a Power/Energy MIB module: - draft-claise-energy-monitoring-mib-06 - draft-quittek-power-mib-02 Among the authors of both documents we are currently trying to merge them. But there are some open issues that should be discussed on the mailing list. Here is the probably biggest of them: modeling power states. For simplifying energy management we want to introduce the concept of power states (aka power levels). A power state will indicate roughly how much power a device consumes. Examples for simple power states are off, sleep, and operational states. In the envisioned EMAN MIB modules, a power state is characterized by a descriptive name and the device's expected power input in this state (max/min/average). Power states are not a new concept. The DMTF has already defined a set of power states and there is the Other standards bodies as the DMTF (Distributed Management Task Force) and there is the ACPI (Advanced Configuration and Power Interface) for PC motherboards. And there may be more than these out there. I listed some DMTF and ACPI states at the end of this message. An easy solution for EMAN would be just adopting one of these sets. However, there are issues with the ones we looked at. ACPI was developed for PC motherboards and is quite PC-centric. Also it defines states that seem to be superfluous, because so far, almost no one has implemented them. Also the DMTF model seems to have a narrower scope than envisioned by the EMAN WG. At some point in time, the EMAN WG hast to make a decision, which power state model to adopt. Here is a set of alternatives. The first four have fixed sets of power states. Option 1: fixed minimum Just support three power states (off, sleep (stand-by), operational) This has clear semantics, but there are several people claiming it's too restrictive. Option 2: fixed DMTF Just use the states defined by DMTF. Might be too much focussed n PCs. Option 3: fixed ACPI Just use the states defined by ACPI. Might be too much focussed n PCs. Option 4: fixed EMAN Define a new fixed set of power levels within the EMAN WG. Option 5: IANA-registered power states Have power states be registered at IANA. We would start with registering (off, sleep, operational, the DMTF set, and the ACPI set. Manufacturers can then register further ones. There has been discussions pointing out that these fixed sets may not be sufficient, particularly if non-IT equipment should also be covered. For being more open, the idea to support user-defined or manufacturer-defined power states of devices has been developed. In such a state, for example, certain components of a device may be switched off or put to sleep. Which ones are switched off in which state is to be defined by the user/operator/manufacturer and may be chosen such that operational needs are met. Again, there are several proposals how to do this. All of them favor a two-level approach that distinguishes between rather flexible functional power states and rather fixed basic power states. Functional power states would be defined by the manufacturer, operator, or user. These would be the power states that would be reported by a device. However, in order to better define the semantics of functional power states, Each of these would be mapped to exactly one basic power states. This means that a property of any functional state would be the basic state it maps to. Basic power states would be fixed, such as the ones used in options 1-5. An easy example would be functional power states defined by user/operator/manufacturer with each state indicating whether it is an off state, a sleep state or an operational state. Here are the corresponding options: Option 6: flexible functional states mapped to a fixed set of basic states States could be defined flexibly. But each state would indicate a basic state to which it corresponds. Basic states could be either basic (off/sleep/operational) or the DMTF set or the ACPI set Option 7: flexible functional states mapped to a IANA registered set of basic states This is like Option 6, but basic states would be registered at IANA and can be extended. We would register all DMTF and ACPI states and probably some more at IANA. Manufacturers could add more. Option 8: IANA-registered sets of functional states, only three basic states The main reasoning behind this option is that is should always be clear whether a power state is an off state, a sleep state, or an operational state. Therefore, only these three basic states are supported. This would be in line with an instance of Option 6. However, this option has an extension for the functional states. It suggests that for customizing devices in order to be compliant with given management systems, for example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. An example would be the DMTF states. We would register a flag at IANA that indicates we are using DMTF states only. This would signal the management application that all power state IDs are in line with power state numbering as defined by IANA. Analogously, ACPI and further sets could be registered at IANA. A fallback to Option 6 could be realized by registering a set number of 0 at IANA that does not impose any limit for functional states. Obviously, there are more possible options. If you think there is a better one, please send it to this list. I know this discussion is not easy, but we have to have it in order to make the right decision in the EMAN WG. Please take some time and think about what you consider to be the best way to go. And of course send questions on the issue. Thanks. Juergen DMTF (Distributed Management Task Force) power states: - 2 (Power On) - 3 (Sleep - Light) - 4 (Sleep - Deep) - 5 (Power Cycle (Off Soft)) - 6 (Power Off - Hard) - 7 (Hibernate) - 8 (Power Off - Soft) - 9 (Power Cycle (Off Hard)) - 10 (Master Bus Reset) - 11 (Diagnostic Interrupt (NMI)) - 12 (Power Off - Soft Graceful) - 13 (Power Off - Hard Graceful) - 14 (Master Bus Reset Graceful) - 15 (Power Cycle (Off - Soft Graceful)) - 16 (Power Cycle (Off - Hard Graceful)) ACPI (Advanced Configuration and Power Interface Specification) power states for PC motherboards: - G3-S5 (Off-Hard) - G2-S5 (Off-Soft) - G1-S4 (Hibernate) - G1-S3 (Sleep-Deep) - G1-S2 (Sleep-Light) - G1-S1 (Sleep-Light) - G0-S0-P5 - G0-S0-P4 - G0-S0-P3 - G0-S0-P2 - G0-S0-P2 - G0-S0-P2 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 ------_=_NextPart_001_01CBD87C.9B6F1DA8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Option 6: Support all of them.

 

Chris

 

--

Chris Verges

408-500-2377

http://www.cyberswitching.com<= /span>

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Bruce Nordman
Sent: Tuesday, March 01, 2011 4:54 = PM
To: eman mailing list
Subject: [eman] Power = States - really

 

I am reposting Juergen's email about = power states.
While the subsequent discussion has been = important
and useful, it is on a different topic.  So, please = let's
also make progress on this = topic.
--Bruce

On Mon, Feb = 28, 2011 at 4:07 AM, Juergen Quittek <Quittek@neclab.eu> = wrote:

Dear all,

We have two = proposals for a Power/Energy MIB module:

 - = draft-claise-energy-monitoring-mib-06
 - = draft-quittek-power-mib-02

Among the authors of both documents we = are currently trying to merge them.
But there are some open issues = that should be discussed on the mailing
list.  Here is the = probably biggest of them: modeling power states.

For simplifying = energy management we want to introduce the concept of
power states = (aka power levels).  A power state will indicate roughly = how
much power a device consumes.  Examples for simple power = states are off,
sleep, and operational states.

In the = envisioned EMAN MIB modules, a power state is characterized by = a
descriptive name and the device's expected power input in this = state
(max/min/average).

Power states are not a new concept. =  The DMTF has already defined a set of
power states and there is = the Other standards bodies as the DMTF
(Distributed Management Task = Force) and there  is the ACPI (Advanced
Configuration and Power = Interface) for PC motherboards.  And there may be
more than = these out there.  I listed some DMTF and ACPI states at the = end
of this message.

An easy solution for EMAN would be just = adopting one of these sets.
However, there are issues with the ones = we looked at.  ACPI was developed
for PC motherboards and is = quite PC-centric.  Also it defines states that
seem to be = superfluous, because so far, almost no one has implemented
them. =  Also the DMTF model seems to have a narrower scope than = envisioned
by the EMAN WG.

At some point in time, the EMAN WG = hast to make a decision, which power
state model to adopt.  Here = is a set of alternatives. The first four have
fixed sets of power = states.

Option 1: fixed minimum
Just support three power = states (off, sleep (stand-by), operational)
This has clear semantics, = but there are several people claiming it's = too
restrictive.

Option 2: fixed DMTF
Just use the states = defined by DMTF.
Might be too much focussed n PCs.

Option 3: = fixed ACPI
Just use the states defined by ACPI.
Might be too much = focussed n PCs.



Option 4: fixed EMAN
Define a new = fixed set of power levels within the EMAN WG.

Option 5: = IANA-registered power states
Have power states be registered at = IANA.
We would start with registering (off, sleep, operational, the = DMTF set,
and the ACPI set.
Manufacturers can then register = further ones.


There has been discussions pointing out that = these fixed sets may not be
sufficient, particularly if non-IT = equipment should also be covered.

For being more open, the idea = to support user-defined or
manufacturer-defined power states of = devices has been developed.  In such
a state, for example, = certain components of a device may be switched off
or put to sleep. =  Which ones are switched off in which state is to be
defined by = the user/operator/manufacturer and may be chosen such = that
operational needs are met.

Again, there are several = proposals how to do this.  All of them favor a
two-level = approach that distinguishes between rather flexible functional
power = states and rather fixed basic power states.  Functional power = states
would be defined by the manufacturer, operator, or user. =  These would be
the power states that would be reported by a = device.  However, in order to
better define the semantics of = functional power states, Each of these
would be mapped to exactly one = basic power states.  This means that a
property of any = functional state would be the basic state it maps to.
Basic power = states would be fixed, such as the ones used in options 1-5.
An easy = example would be functional power states defined = by
user/operator/manufacturer with each state indicating whether it = is an off
state, a sleep state or an operational state.

Here = are the corresponding options:

Option 6: flexible functional = states mapped to a fixed set of basic states
States could be defined = flexibly.  But each state would indicate a basic
state to which = it corresponds. Basic states could be either = basic
(off/sleep/operational) or the DMTF set or the ACPI = set

Option 7: flexible functional states mapped to a IANA = registered set of
basic states
This is like Option 6, but basic = states would be registered at IANA and
can be extended.  We = would register all DMTF and ACPI states and probably
some more at = IANA. Manufacturers could add more.

Option 8: IANA-registered = sets of functional states, only three basic
states
The main = reasoning behind this option is that is should always be = clear
whether a power state is an off state, a sleep state, or an = operational
state.  Therefore, only these three basic states are = supported.  This
would be in line with an instance of Option 6. =  However, this option has
an extension for the functional = states.  It suggests that for customizing
devices in order to be = compliant with given management systems, for
example a DMTF-based = system, it should be possible to restrict functional
power states to = a given set that is registered at IANA.  An example would
be the = DMTF states.  We would register a flag at IANA that indicates = we
are using DMTF states only.  This would signal the management = application
that all power state IDs are in line with power state = numbering as defined
by IANA.  Analogously, ACPI and further = sets could be registered at IANA.
A fallback to Option 6 could be = realized by registering a set number of 0
at IANA that does not = impose any limit for functional states.

Obviously, there are more = possible options.  If you think there is a
better one, please = send it to this list.

I know this discussion is not easy, but we = have to have it in order to
make the right decision in the EMAN WG. =  Please take some time and think
about what you consider to be = the best way to go.  And of course send
questions on the = issue.

Thanks.

   Juergen


DMTF = (Distributed Management Task Force) power states:
 - 2 (Power = On)
 - 3 (Sleep - Light)
 - 4 (Sleep - Deep)
 - = 5 (Power Cycle (Off Soft))
 - 6 (Power Off - Hard)
 - 7 = (Hibernate)
 - 8 (Power Off - Soft)
 - 9 (Power Cycle = (Off Hard))
 - 10 (Master Bus Reset)
 - 11 (Diagnostic = Interrupt (NMI))
 - 12 (Power Off - Soft Graceful)
 - 13 = (Power Off - Hard Graceful)
 - 14 (Master Bus Reset = Graceful)
 - 15 (Power Cycle (Off - Soft Graceful))
 - = 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced = Configuration and Power Interface Specification) power
states for PC = motherboards:
 - G3-S5 (Off-Hard)
 - G2-S5 = (Off-Soft)
 - G1-S4 (Hibernate)
 - G1-S3 = (Sleep-Deep)
 - G1-S2 (Sleep-Light)
 - G1-S1 = (Sleep-Light)
 - G0-S0-P5
 - G0-S0-P4
 - = G0-S0-P3
 - G0-S0-P2
 - G0-S0-P2
 - = G0-S0-P2




_____________________________________________= __
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman




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

------_=_NextPart_001_01CBD87C.9B6F1DA8-- From chrisv@cyberswitching.com Tue Mar 1 17:55:41 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D53B3A6A24 for ; Tue, 1 Mar 2011 17:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dICNjqgjHv2P for ; Tue, 1 Mar 2011 17:55:30 -0800 (PST) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by core3.amsl.com (Postfix) with ESMTP id 2D76D3A6A21 for ; Tue, 1 Mar 2011 17:55:30 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o142.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 2d3ad6d4.0.5096.00-362.9910.p01c11o142.mxlogic.net (envelope-from ); Tue, 01 Mar 2011 18:56:35 -0700 (MST) X-MXL-Hash: 4d6da3d30958f600-9b19f51bc3ec5b05f9f9ab46a2e1064aa2c5ba35 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD87C.DBF5C3C5" Date: Tue, 1 Mar 2011 17:55:08 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CECD967@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power States - really Thread-Index: AcvYdELXFNvLH+ZHSyS3Xa0zzpZ4LwACEETwAAAQ/FA= References: <68FBE0F3CE97264395875AC1C468F22CECD966@mail03.cyberswitching.local> From: "Chris Verges" To: "Bruce Nordman" , "eman mailing list" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XnxjYOJpEeMA:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=48vgC7mUAAAA:8 a=wzgqfsuUAAAA:8 a=zZCk] X-AnalysisOut: [ITaF5-aVQqrVWT4A:9 a=pNOpqhuLXgPa_ZYQFcYA:7 a=7Ankd9kKy801] X-AnalysisOut: [Z2Xp8qFe_0glCSYA:4 a=CjuIK1q_8ugA:10 a=Y8rda4wpm8gA:10 a=F] X-AnalysisOut: [nBvD0j_UmcA:10 a=lr71C7C2fScA:10 a=lZB815dzVvQA:10 a=75sNq] X-AnalysisOut: [SupFDGn-Tv_:21 a=fWDA0VAiR0GE40yS:21 a=yMhMjlubAAAA:8 a=SS] X-AnalysisOut: [mOFEACAAAA:8 a=J35dNKfbAAAA:8 a=Fmj4eFYgJMGCglVVqDQA:9 a=l] X-AnalysisOut: [anOZbdCjbz3iGU0_HsA:7 a=TrD4YvuS9njgHg1CxjbMvms8_qYA:4 a=8] X-AnalysisOut: [1Tsx9r1139xcxSj:21 a=xm-HMqFK3XmQ1QD_:21] Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:55:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD87C.DBF5C3C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, the "9" key apparently got put upside down on my keyboard. =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Chris Verges Sent: Tuesday, March 01, 2011 5:53 PM To: Bruce Nordman; eman mailing list Subject: Re: [eman] Power States - really =20 Option 6: Support all of them. =20 Chris =20 --=20 Chris Verges 408-500-2377 http://www.cyberswitching.com =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman Sent: Tuesday, March 01, 2011 4:54 PM To: eman mailing list Subject: [eman] Power States - really =20 I am reposting Juergen's email about power states. While the subsequent discussion has been important and useful, it is on a different topic. So, please let's also make progress on this topic. --Bruce On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: Dear all, We have two proposals for a Power/Energy MIB module: - draft-claise-energy-monitoring-mib-06 - draft-quittek-power-mib-02 Among the authors of both documents we are currently trying to merge them. But there are some open issues that should be discussed on the mailing list. Here is the probably biggest of them: modeling power states. For simplifying energy management we want to introduce the concept of power states (aka power levels). A power state will indicate roughly how much power a device consumes. Examples for simple power states are off, sleep, and operational states. In the envisioned EMAN MIB modules, a power state is characterized by a descriptive name and the device's expected power input in this state (max/min/average). Power states are not a new concept. The DMTF has already defined a set of power states and there is the Other standards bodies as the DMTF (Distributed Management Task Force) and there is the ACPI (Advanced Configuration and Power Interface) for PC motherboards. And there may be more than these out there. I listed some DMTF and ACPI states at the end of this message. An easy solution for EMAN would be just adopting one of these sets. However, there are issues with the ones we looked at. ACPI was developed for PC motherboards and is quite PC-centric. Also it defines states that seem to be superfluous, because so far, almost no one has implemented them. Also the DMTF model seems to have a narrower scope than envisioned by the EMAN WG. At some point in time, the EMAN WG hast to make a decision, which power state model to adopt. Here is a set of alternatives. The first four have fixed sets of power states. Option 1: fixed minimum Just support three power states (off, sleep (stand-by), operational) This has clear semantics, but there are several people claiming it's too restrictive. Option 2: fixed DMTF Just use the states defined by DMTF. Might be too much focussed n PCs. Option 3: fixed ACPI Just use the states defined by ACPI. Might be too much focussed n PCs. Option 4: fixed EMAN Define a new fixed set of power levels within the EMAN WG. Option 5: IANA-registered power states Have power states be registered at IANA. We would start with registering (off, sleep, operational, the DMTF set, and the ACPI set. Manufacturers can then register further ones. There has been discussions pointing out that these fixed sets may not be sufficient, particularly if non-IT equipment should also be covered. For being more open, the idea to support user-defined or manufacturer-defined power states of devices has been developed. In such a state, for example, certain components of a device may be switched off or put to sleep. Which ones are switched off in which state is to be defined by the user/operator/manufacturer and may be chosen such that operational needs are met. Again, there are several proposals how to do this. All of them favor a two-level approach that distinguishes between rather flexible functional power states and rather fixed basic power states. Functional power states would be defined by the manufacturer, operator, or user. These would be the power states that would be reported by a device. However, in order to better define the semantics of functional power states, Each of these would be mapped to exactly one basic power states. This means that a property of any functional state would be the basic state it maps to. Basic power states would be fixed, such as the ones used in options 1-5. An easy example would be functional power states defined by user/operator/manufacturer with each state indicating whether it is an off state, a sleep state or an operational state. Here are the corresponding options: Option 6: flexible functional states mapped to a fixed set of basic states States could be defined flexibly. But each state would indicate a basic state to which it corresponds. Basic states could be either basic (off/sleep/operational) or the DMTF set or the ACPI set Option 7: flexible functional states mapped to a IANA registered set of basic states This is like Option 6, but basic states would be registered at IANA and can be extended. We would register all DMTF and ACPI states and probably some more at IANA. Manufacturers could add more. Option 8: IANA-registered sets of functional states, only three basic states The main reasoning behind this option is that is should always be clear whether a power state is an off state, a sleep state, or an operational state. Therefore, only these three basic states are supported. This would be in line with an instance of Option 6. However, this option has an extension for the functional states. It suggests that for customizing devices in order to be compliant with given management systems, for example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. An example would be the DMTF states. We would register a flag at IANA that indicates we are using DMTF states only. This would signal the management application that all power state IDs are in line with power state numbering as defined by IANA. Analogously, ACPI and further sets could be registered at IANA. A fallback to Option 6 could be realized by registering a set number of 0 at IANA that does not impose any limit for functional states. Obviously, there are more possible options. If you think there is a better one, please send it to this list. I know this discussion is not easy, but we have to have it in order to make the right decision in the EMAN WG. Please take some time and think about what you consider to be the best way to go. And of course send questions on the issue. Thanks. Juergen DMTF (Distributed Management Task Force) power states: - 2 (Power On) - 3 (Sleep - Light) - 4 (Sleep - Deep) - 5 (Power Cycle (Off Soft)) - 6 (Power Off - Hard) - 7 (Hibernate) - 8 (Power Off - Soft) - 9 (Power Cycle (Off Hard)) - 10 (Master Bus Reset) - 11 (Diagnostic Interrupt (NMI)) - 12 (Power Off - Soft Graceful) - 13 (Power Off - Hard Graceful) - 14 (Master Bus Reset Graceful) - 15 (Power Cycle (Off - Soft Graceful)) - 16 (Power Cycle (Off - Hard Graceful)) ACPI (Advanced Configuration and Power Interface Specification) power states for PC motherboards: - G3-S5 (Off-Hard) - G2-S5 (Off-Soft) - G1-S4 (Hibernate) - G1-S3 (Sleep-Deep) - G1-S2 (Sleep-Light) - G1-S1 (Sleep-Light) - G0-S0-P5 - G0-S0-P4 - G0-S0-P3 - G0-S0-P2 - G0-S0-P2 - G0-S0-P2 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 ------_=_NextPart_001_01CBD87C.DBF5C3C5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, the “9” key apparently got put upside down on my = keyboard.

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Chris Verges
Sent: Tuesday, March 01, 2011 5:53 = PM
To: Bruce Nordman; eman mailing list
Subject: Re: = [eman] Power States - really

 

Option 6: = Support all of them.

 

Chris

 

-- =

Chris Verges

408-500-2377

http://www.cyberswitching.com=

 

From: eman-bounces@ietf.org = [mailto:eman-bounces@ietf.org] On Behalf Of Bruce = Nordman
Sent: Tuesday, March 01, 2011 4:54 PM
To: = eman mailing list
Subject: [eman] Power States - = really

 

I am reposting = Juergen's email about power states.
While the subsequent discussion = has been important
and useful, it is on a different topic.  So, = please let's
also make progress on this = topic.
--Bruce

On Mon, Feb = 28, 2011 at 4:07 AM, Juergen Quittek <Quittek@neclab.eu> = wrote:

Dear all,

We have two = proposals for a Power/Energy MIB module:

 - = draft-claise-energy-monitoring-mib-06
 - = draft-quittek-power-mib-02

Among the authors of both documents we = are currently trying to merge them.
But there are some open issues = that should be discussed on the mailing
list.  Here is the = probably biggest of them: modeling power states.

For simplifying = energy management we want to introduce the concept of
power states = (aka power levels).  A power state will indicate roughly = how
much power a device consumes.  Examples for simple power = states are off,
sleep, and operational states.

In the = envisioned EMAN MIB modules, a power state is characterized by = a
descriptive name and the device's expected power input in this = state
(max/min/average).

Power states are not a new concept. =  The DMTF has already defined a set of
power states and there is = the Other standards bodies as the DMTF
(Distributed Management Task = Force) and there  is the ACPI (Advanced
Configuration and Power = Interface) for PC motherboards.  And there may be
more than = these out there.  I listed some DMTF and ACPI states at the = end
of this message.

An easy solution for EMAN would be just = adopting one of these sets.
However, there are issues with the ones = we looked at.  ACPI was developed
for PC motherboards and is = quite PC-centric.  Also it defines states that
seem to be = superfluous, because so far, almost no one has implemented
them. =  Also the DMTF model seems to have a narrower scope than = envisioned
by the EMAN WG.

At some point in time, the EMAN WG = hast to make a decision, which power
state model to adopt.  Here = is a set of alternatives. The first four have
fixed sets of power = states.

Option 1: fixed minimum
Just support three power = states (off, sleep (stand-by), operational)
This has clear semantics, = but there are several people claiming it's = too
restrictive.

Option 2: fixed DMTF
Just use the states = defined by DMTF.
Might be too much focussed n PCs.

Option 3: = fixed ACPI
Just use the states defined by ACPI.
Might be too much = focussed n PCs.



Option 4: fixed EMAN
Define a new = fixed set of power levels within the EMAN WG.

Option 5: = IANA-registered power states
Have power states be registered at = IANA.
We would start with registering (off, sleep, operational, the = DMTF set,
and the ACPI set.
Manufacturers can then register = further ones.


There has been discussions pointing out that = these fixed sets may not be
sufficient, particularly if non-IT = equipment should also be covered.

For being more open, the idea = to support user-defined or
manufacturer-defined power states of = devices has been developed.  In such
a state, for example, = certain components of a device may be switched off
or put to sleep. =  Which ones are switched off in which state is to be
defined by = the user/operator/manufacturer and may be chosen such = that
operational needs are met.

Again, there are several = proposals how to do this.  All of them favor a
two-level = approach that distinguishes between rather flexible functional
power = states and rather fixed basic power states.  Functional power = states
would be defined by the manufacturer, operator, or user. =  These would be
the power states that would be reported by a = device.  However, in order to
better define the semantics of = functional power states, Each of these
would be mapped to exactly one = basic power states.  This means that a
property of any = functional state would be the basic state it maps to.
Basic power = states would be fixed, such as the ones used in options 1-5.
An easy = example would be functional power states defined = by
user/operator/manufacturer with each state indicating whether it = is an off
state, a sleep state or an operational state.

Here = are the corresponding options:

Option 6: flexible functional = states mapped to a fixed set of basic states
States could be defined = flexibly.  But each state would indicate a basic
state to which = it corresponds. Basic states could be either = basic
(off/sleep/operational) or the DMTF set or the ACPI = set

Option 7: flexible functional states mapped to a IANA = registered set of
basic states
This is like Option 6, but basic = states would be registered at IANA and
can be extended.  We = would register all DMTF and ACPI states and probably
some more at = IANA. Manufacturers could add more.

Option 8: IANA-registered = sets of functional states, only three basic
states
The main = reasoning behind this option is that is should always be = clear
whether a power state is an off state, a sleep state, or an = operational
state.  Therefore, only these three basic states are = supported.  This
would be in line with an instance of Option 6. =  However, this option has
an extension for the functional = states.  It suggests that for customizing
devices in order to be = compliant with given management systems, for
example a DMTF-based = system, it should be possible to restrict functional
power states to = a given set that is registered at IANA.  An example would
be the = DMTF states.  We would register a flag at IANA that indicates = we
are using DMTF states only.  This would signal the management = application
that all power state IDs are in line with power state = numbering as defined
by IANA.  Analogously, ACPI and further = sets could be registered at IANA.
A fallback to Option 6 could be = realized by registering a set number of 0
at IANA that does not = impose any limit for functional states.

Obviously, there are more = possible options.  If you think there is a
better one, please = send it to this list.

I know this discussion is not easy, but we = have to have it in order to
make the right decision in the EMAN WG. =  Please take some time and think
about what you consider to be = the best way to go.  And of course send
questions on the = issue.

Thanks.

   Juergen


DMTF = (Distributed Management Task Force) power states:
 - 2 (Power = On)
 - 3 (Sleep - Light)
 - 4 (Sleep - Deep)
 - = 5 (Power Cycle (Off Soft))
 - 6 (Power Off - Hard)
 - 7 = (Hibernate)
 - 8 (Power Off - Soft)
 - 9 (Power Cycle = (Off Hard))
 - 10 (Master Bus Reset)
 - 11 (Diagnostic = Interrupt (NMI))
 - 12 (Power Off - Soft Graceful)
 - 13 = (Power Off - Hard Graceful)
 - 14 (Master Bus Reset = Graceful)
 - 15 (Power Cycle (Off - Soft Graceful))
 - = 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced = Configuration and Power Interface Specification) power
states for PC = motherboards:
 - G3-S5 (Off-Hard)
 - G2-S5 = (Off-Soft)
 - G1-S4 (Hibernate)
 - G1-S3 = (Sleep-Deep)
 - G1-S2 (Sleep-Light)
 - G1-S1 = (Sleep-Light)
 - G0-S0-P5
 - G0-S0-P4
 - = G0-S0-P3
 - G0-S0-P2
 - G0-S0-P2
 - = G0-S0-P2




_____________________________________________= __
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman




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

------_=_NextPart_001_01CBD87C.DBF5C3C5-- From tirth.ghose@gmail.com Tue Mar 1 17:56:21 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA883A6A21 for ; Tue, 1 Mar 2011 17:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rjir8bPlFzUv for ; Tue, 1 Mar 2011 17:56:19 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0C85B3A6C01 for ; Tue, 1 Mar 2011 17:56:18 -0800 (PST) Received: by iwl42 with SMTP id 42so5282976iwl.31 for ; Tue, 01 Mar 2011 17:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GjM9bqoiLOVRncmGclK3cOHpBG43sGJG6gtzrpm2xTA=; b=FKL76KQUrZlyvg7tHl6/LyjMmHQbx+7Ewxs2vjMY+6e8pGV1aJ0/rEr2My4OaMWIpx kGDKahLZtkXpp3rLJ637Mx+S34S7i3XOuZtPDtw+rvRcQbI7mMKetYMWXnvfZYX97wRN +2OdmplKQAv9gjj0tJaUkCpRaRt5tJB3J5vWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=n3b/G55WnFlRmwWC7inOVHr4f7aagPuIhuvVf0bASqStTyt+8e+MIxoBeqzDZ1IgOx 6UjBeKW2w8o7BhxFl4MnrLV6HexJfW16LFnridmDLcmXXQkFHVQKjn1f3+OnHdfXQJbc PObVuYJ8gIjeSWGPHASr+1dVyFPVCfX+P2Mjs= MIME-Version: 1.0 Received: by 10.231.36.77 with SMTP id s13mr7033384ibd.68.1299031043207; Tue, 01 Mar 2011 17:57:23 -0800 (PST) Sender: tirth.ghose@gmail.com Received: by 10.231.156.141 with HTTP; Tue, 1 Mar 2011 17:57:23 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Mar 2011 17:57:23 -0800 X-Google-Sender-Auth: CpUNhWeAIjlzsmMaG1RY2_tpgJ4 Message-ID: From: Ted Ghose To: eman mailing list Content-Type: multipart/alternative; boundary=0022152d5d65e1f2db049d763b97 Cc: Bruce Nordman Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:56:21 -0000 --0022152d5d65e1f2db049d763b97 Content-Type: text/plain; charset=ISO-8859-1 To summarize: there are two existing power states ACPI & DMTF As an administrator who wants to save energy, I'd like to know one set of states, regardless of any device I manage. I do no not care if there is 5 or 100 states, so long I have a clear understanding what each state does for me. Also it will be nice if the devices tells me what is the max power it will consume at any given state, and if some functionality it may loose. Better yet, how long will it expected to take for a state transition (may not be a matrix, a linear delta t from state xi to xi+1) Since we have two implementation specific power states, which does not give enough information to plan ahead, I'd like to see this standard body comes up with an unified states, that normalizes states across every devices. I understand it is a tall order. Hope the requirement will steer the discussion in the right path thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Tue, Mar 1, 2011 at 4:54 PM, Bruce Nordman wrote: > I am reposting Juergen's email about power states. > While the subsequent discussion has been important > and useful, it is on a different topic. So, please let's > also make progress on this topic. > --Bruce > > On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: > >> Dear all, >> >> We have two proposals for a Power/Energy MIB module: >> >> - draft-claise-energy-monitoring-mib-06 >> - draft-quittek-power-mib-02 >> >> Among the authors of both documents we are currently trying to merge them. >> But there are some open issues that should be discussed on the mailing >> list. Here is the probably biggest of them: modeling power states. >> >> For simplifying energy management we want to introduce the concept of >> power states (aka power levels). A power state will indicate roughly how >> much power a device consumes. Examples for simple power states are off, >> sleep, and operational states. >> >> In the envisioned EMAN MIB modules, a power state is characterized by a >> descriptive name and the device's expected power input in this state >> (max/min/average). >> >> Power states are not a new concept. The DMTF has already defined a set of >> power states and there is the Other standards bodies as the DMTF >> (Distributed Management Task Force) and there is the ACPI (Advanced >> Configuration and Power Interface) for PC motherboards. And there may be >> more than these out there. I listed some DMTF and ACPI states at the end >> of this message. >> >> An easy solution for EMAN would be just adopting one of these sets. >> However, there are issues with the ones we looked at. ACPI was developed >> for PC motherboards and is quite PC-centric. Also it defines states that >> seem to be superfluous, because so far, almost no one has implemented >> them. Also the DMTF model seems to have a narrower scope than envisioned >> by the EMAN WG. >> >> At some point in time, the EMAN WG hast to make a decision, which power >> state model to adopt. Here is a set of alternatives. The first four have >> fixed sets of power states. >> >> Option 1: fixed minimum >> Just support three power states (off, sleep (stand-by), operational) >> This has clear semantics, but there are several people claiming it's too >> restrictive. >> >> Option 2: fixed DMTF >> Just use the states defined by DMTF. >> Might be too much focussed n PCs. >> >> Option 3: fixed ACPI >> Just use the states defined by ACPI. >> Might be too much focussed n PCs. >> >> >> >> Option 4: fixed EMAN >> Define a new fixed set of power levels within the EMAN WG. >> >> Option 5: IANA-registered power states >> Have power states be registered at IANA. >> We would start with registering (off, sleep, operational, the DMTF set, >> and the ACPI set. >> Manufacturers can then register further ones. >> >> >> There has been discussions pointing out that these fixed sets may not be >> sufficient, particularly if non-IT equipment should also be covered. >> >> For being more open, the idea to support user-defined or >> manufacturer-defined power states of devices has been developed. In such >> a state, for example, certain components of a device may be switched off >> or put to sleep. Which ones are switched off in which state is to be >> defined by the user/operator/manufacturer and may be chosen such that >> operational needs are met. >> >> Again, there are several proposals how to do this. All of them favor a >> two-level approach that distinguishes between rather flexible functional >> power states and rather fixed basic power states. Functional power states >> would be defined by the manufacturer, operator, or user. These would be >> the power states that would be reported by a device. However, in order to >> better define the semantics of functional power states, Each of these >> would be mapped to exactly one basic power states. This means that a >> property of any functional state would be the basic state it maps to. >> Basic power states would be fixed, such as the ones used in options 1-5. >> An easy example would be functional power states defined by >> user/operator/manufacturer with each state indicating whether it is an off >> state, a sleep state or an operational state. >> >> Here are the corresponding options: >> >> Option 6: flexible functional states mapped to a fixed set of basic states >> States could be defined flexibly. But each state would indicate a basic >> state to which it corresponds. Basic states could be either basic >> (off/sleep/operational) or the DMTF set or the ACPI set >> >> Option 7: flexible functional states mapped to a IANA registered set of >> basic states >> This is like Option 6, but basic states would be registered at IANA and >> can be extended. We would register all DMTF and ACPI states and probably >> some more at IANA. Manufacturers could add more. >> >> Option 8: IANA-registered sets of functional states, only three basic >> states >> The main reasoning behind this option is that is should always be clear >> whether a power state is an off state, a sleep state, or an operational >> state. Therefore, only these three basic states are supported. This >> would be in line with an instance of Option 6. However, this option has >> an extension for the functional states. It suggests that for customizing >> devices in order to be compliant with given management systems, for >> example a DMTF-based system, it should be possible to restrict functional >> power states to a given set that is registered at IANA. An example would >> be the DMTF states. We would register a flag at IANA that indicates we >> are using DMTF states only. This would signal the management application >> that all power state IDs are in line with power state numbering as defined >> by IANA. Analogously, ACPI and further sets could be registered at IANA. >> A fallback to Option 6 could be realized by registering a set number of 0 >> at IANA that does not impose any limit for functional states. >> >> Obviously, there are more possible options. If you think there is a >> better one, please send it to this list. >> >> I know this discussion is not easy, but we have to have it in order to >> make the right decision in the EMAN WG. Please take some time and think >> about what you consider to be the best way to go. And of course send >> questions on the issue. >> >> Thanks. >> >> Juergen >> >> >> DMTF (Distributed Management Task Force) power states: >> - 2 (Power On) >> - 3 (Sleep - Light) >> - 4 (Sleep - Deep) >> - 5 (Power Cycle (Off Soft)) >> - 6 (Power Off - Hard) >> - 7 (Hibernate) >> - 8 (Power Off - Soft) >> - 9 (Power Cycle (Off Hard)) >> - 10 (Master Bus Reset) >> - 11 (Diagnostic Interrupt (NMI)) >> - 12 (Power Off - Soft Graceful) >> - 13 (Power Off - Hard Graceful) >> - 14 (Master Bus Reset Graceful) >> - 15 (Power Cycle (Off - Soft Graceful)) >> - 16 (Power Cycle (Off - Hard Graceful)) >> >> ACPI (Advanced Configuration and Power Interface Specification) power >> states for PC motherboards: >> - G3-S5 (Off-Hard) >> - G2-S5 (Off-Soft) >> - G1-S4 (Hibernate) >> - G1-S3 (Sleep-Deep) >> - G1-S2 (Sleep-Light) >> - G1-S1 (Sleep-Light) >> - G0-S0-P5 >> - G0-S0-P4 >> - G0-S0-P3 >> - G0-S0-P2 >> - G0-S0-P2 >> - G0-S0-P2 >> >> >> >> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --0022152d5d65e1f2db049d763b97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To=A0summarize: there are two existing power states ACPI & DMTF
As an administrator who wants to save energy, I'd like to k= now one set of states, regardless of any device I manage. I do no not care = if there is 5 or 100 states, so long I have a clear understanding what each= state does for me. Also it will be nice if the devices tells me what is th= e max power it will consume at any given state, and if some=A0functionality= =A0it may loose. Better yet, how long will it expected to take for a state = transition (may not be a matrix, a linear delta t from state xi to xi+1)

Since we have two=A0implementation specific power state= s, which does not give enough information to plan ahead, I'd like to se= e this standard body comes up with an unified states, that normalizes state= s across every devices. I understand it is a tall order.=A0

Hope the requirement will steer the discussion in the r= ight path

thanks

-tg-
=A0
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.= -:*'``'*:-.,_:-.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time... see it my way
*:= -.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-= .,_,.-:**:-.,_,.


On Tue, Mar 1, 2011 at 4:54 PM, Bruce No= rdman <bnordman@lb= l.gov> wrote:
I am reposting Juergen's email about power states.
While the subsequ= ent discussion has been important
and useful, it is on a different topic= .=A0 So, please let's
also make progress on this topic.
--Bruce
On Mon, Feb 28, 2011 at 4:07 AM, Juergen Qui= ttek <Quittek@neclab.eu> wrote:
Dear all,

We have two proposals for a Power/Energy MIB module:

=A0- draft-claise-energy-monitoring-mib-06
=A0- draft-quittek-power-mib-02

Among the authors of both documents we are currently trying to merge them.<= br> But there are some open issues that should be discussed on the mailing
list. =A0Here is the probably biggest of them: modeling power states.

For simplifying energy management we want to introduce the concept of
power states (aka power levels). =A0A power state will indicate roughly how=
much power a device consumes. =A0Examples for simple power states are off,<= br> sleep, and operational states.

In the envisioned EMAN MIB modules, a power state is characterized by a
descriptive name and the device's expected power input in this state (max/min/average).

Power states are not a new concept. =A0The DMTF has already defined a set o= f
power states and there is the Other standards bodies as the DMTF
(Distributed Management Task Force) and there =A0is the ACPI (Advanced
Configuration and Power Interface) for PC motherboards. =A0And there may be=
more than these out there. =A0I listed some DMTF and ACPI states at the end=
of this message.

An easy solution for EMAN would be just adopting one of these sets.
However, there are issues with the ones we looked at. =A0ACPI was developed=
for PC motherboards and is quite PC-centric. =A0Also it defines states that=
seem to be superfluous, because so far, almost no one has implemented
them. =A0Also the DMTF model seems to have a narrower scope than envisioned=
by the EMAN WG.

At some point in time, the EMAN WG hast to make a decision, which power
state model to adopt. =A0Here is a set of alternatives. The first four have=
fixed sets of power states.

Option 1: fixed minimum
Just support three power states (off, sleep (stand-by), operational)
This has clear semantics, but there are several people claiming it's to= o
restrictive.

Option 2: fixed DMTF
Just use the states defined by DMTF.
Might be too much focussed n PCs.

Option 3: fixed ACPI
Just use the states defined by ACPI.
Might be too much focussed n PCs.



Option 4: fixed EMAN
Define a new fixed set of power levels within the EMAN WG.

Option 5: IANA-registered power states
Have power states be registered at IANA.
We would start with registering (off, sleep, operational, the DMTF set,
and the ACPI set.
Manufacturers can then register further ones.


There has been discussions pointing out that these fixed sets may not be sufficient, particularly if non-IT equipment should also be covered.

For being more open, the idea to support user-defined or
manufacturer-defined power states of devices has been developed. =A0In such=
a state, for example, certain components of a device may be switched off or put to sleep. =A0Which ones are switched off in which state is to be
defined by the user/operator/manufacturer and may be chosen such that
operational needs are met.

Again, there are several proposals how to do this. =A0All of them favor a two-level approach that distinguishes between rather flexible functional power states and rather fixed basic power states. =A0Functional power state= s
would be defined by the manufacturer, operator, or user. =A0These would be<= br> the power states that would be reported by a device. =A0However, in order t= o
better define the semantics of functional power states, Each of these
would be mapped to exactly one basic power states. =A0This means that a
property of any functional state would be the basic state it maps to.
Basic power states would be fixed, such as the ones used in options 1-5. An easy example would be functional power states defined by
user/operator/manufacturer with each state indicating whether it is an off<= br> state, a sleep state or an operational state.

Here are the corresponding options:

Option 6: flexible functional states mapped to a fixed set of basic states<= br> States could be defined flexibly. =A0But each state would indicate a basic<= br> state to which it corresponds. Basic states could be either basic
(off/sleep/operational) or the DMTF set or the ACPI set

Option 7: flexible functional states mapped to a IANA registered set of
basic states
This is like Option 6, but basic states would be registered at IANA and
can be extended. =A0We would register all DMTF and ACPI states and probably=
some more at IANA. Manufacturers could add more.

Option 8: IANA-registered sets of functional states, only three basic
states
The main reasoning behind this option is that is should always be clear
whether a power state is an off state, a sleep state, or an operational
state. =A0Therefore, only these three basic states are supported. =A0This would be in line with an instance of Option 6. =A0However, this option has<= br> an extension for the functional states. =A0It suggests that for customizing=
devices in order to be compliant with given management systems, for
example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. =A0An example would=
be the DMTF states. =A0We would register a flag at IANA that indicates we are using DMTF states only. =A0This would signal the management application=
that all power state IDs are in line with power state numbering as defined<= br> by IANA. =A0Analogously, ACPI and further sets could be registered at IANA.=
A fallback to Option 6 could be realized by registering a set number of 0 at IANA that does not impose any limit for functional states.

Obviously, there are more possible options. =A0If you think there is a
better one, please send it to this list.

I know this discussion is not easy, but we have to have it in order to
make the right decision in the EMAN WG. =A0Please take some time and think<= br> about what you consider to be the best way to go. =A0And of course send
questions on the issue.

Thanks.

=A0 =A0Juergen


DMTF (Distributed Management Task Force) power states:
=A0- 2 (Power On)
=A0- 3 (Sleep - Light)
=A0- 4 (Sleep - Deep)
=A0- 5 (Power Cycle (Off Soft))
=A0- 6 (Power Off - Hard)
=A0- 7 (Hibernate)
=A0- 8 (Power Off - Soft)
=A0- 9 (Power Cycle (Off Hard))
=A0- 10 (Master Bus Reset)
=A0- 11 (Diagnostic Interrupt (NMI))
=A0- 12 (Power Off - Soft Graceful)
=A0- 13 (Power Off - Hard Graceful)
=A0- 14 (Master Bus Reset Graceful)
=A0- 15 (Power Cycle (Off - Soft Graceful))
=A0- 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced Configuration and Power Interface Specification) power
states for PC motherboards:
=A0- G3-S5 (Off-Hard)
=A0- G2-S5 (Off-Soft)
=A0- G1-S4 (Hibernate)
=A0- G1-S3 (Sleep-Deep)
=A0- G1-S2 (Sleep-Light)
=A0- G1-S1 (Sleep-Light)
=A0- G0-S0-P5
=A0- G0-S0-P4
=A0- G0-S0-P3
=A0- G0-S0-P2
=A0- G0-S0-P2
=A0- G0-S0-P2




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



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


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


--0022152d5d65e1f2db049d763b97-- From tirth.ghose@gmail.com Tue Mar 1 18:05:51 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AA73A6A24 for ; Tue, 1 Mar 2011 18:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m+TAEgGK+sX for ; Tue, 1 Mar 2011 18:05:49 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7BBB93A6A21 for ; Tue, 1 Mar 2011 18:05:49 -0800 (PST) Received: by iyj8 with SMTP id 8so5062232iyj.31 for ; Tue, 01 Mar 2011 18:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=5CYmA2S+ZhGyBMMQAYovFeWOQlp2JiNxjKrwQkRH3MY=; b=FIxUGFAf1mgZOJjg+eXh6pfoszhLGCvWi5c87J7eiN3Y9661+ocB3ZciEgrrD2R0Xj POKY1C2p1WBzSV2y2YVtnlCTmx38bBc0KsfRsBfjNnZ62HEGyZB/8k86Lz0hB55veRu8 e2QKxAWFnoV1RwMeVw3yOhaECEFW++JTQJI/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=GZ5STeLi+2ISYVblN56QAOuxzsksIcAY1m5Ts/L1Zk6jevdr23AwWc+X/XDX9NDfCn m9v7eAudb7Q8B7b5erxH7Q7gk/QyDijuB7CpzB69bi0PQWR9+bWFGa9eDEahRANXWY56 FdsqGeI/113lLGDL8td1eEzNQZvNgPnFxvKoM= MIME-Version: 1.0 Received: by 10.231.145.209 with SMTP id e17mr7056768ibv.43.1299031613620; Tue, 01 Mar 2011 18:06:53 -0800 (PST) Sender: tirth.ghose@gmail.com Received: by 10.231.156.141 with HTTP; Tue, 1 Mar 2011 18:06:53 -0800 (PST) In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CECD967@mail03.cyberswitching.local> References: <68FBE0F3CE97264395875AC1C468F22CECD966@mail03.cyberswitching.local> <68FBE0F3CE97264395875AC1C468F22CECD967@mail03.cyberswitching.local> Date: Tue, 1 Mar 2011 18:06:53 -0800 X-Google-Sender-Auth: mL6lQJgjt5PakjNMDakz904dF_0 Message-ID: From: Ted Ghose To: Chris Verges , eman mailing list Content-Type: multipart/alternative; boundary=0016e64754a2e1c1f5049d765df9 Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 02:05:51 -0000 --0016e64754a2e1c1f5049d765df9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Chris, I agree with you from implementation point of view, a flexible interface is better, but from user experience managing 100s of heterogeneous devices, it will be a nightmare. Instead if we have one set of states, and a mapping what devices natively support will be best. I'll let everyone decide who will be allowed to make the mapping, is it user read-write or read-only. Is it manufacturer read-write/user read-only? thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Tue, Mar 1, 2011 at 5:55 PM, Chris Verges wro= te: > Sorry, the =939=94 key apparently got put upside down on my keyboard. > > > > *From:* eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] *On Behalf O= f > *Chris Verges > *Sent:* Tuesday, March 01, 2011 5:53 PM > *To:* Bruce Nordman; eman mailing list > *Subject:* Re: [eman] Power States - really > > > > Option 6: Support all of them. > > > > Chris > > > > -- > > Chris Verges > > 408-500-2377 > > http://www.cyberswitching.com > > > > *From:* eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] *On Behalf O= f > *Bruce Nordman > *Sent:* Tuesday, March 01, 2011 4:54 PM > *To:* eman mailing list > *Subject:* [eman] Power States - really > > > > I am reposting Juergen's email about power states. > While the subsequent discussion has been important > and useful, it is on a different topic. So, please let's > also make progress on this topic. > --Bruce > > On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek > wrote: > > Dear all, > > We have two proposals for a Power/Energy MIB module: > > - draft-claise-energy-monitoring-mib-06 > - draft-quittek-power-mib-02 > > Among the authors of both documents we are currently trying to merge them= . > But there are some open issues that should be discussed on the mailing > list. Here is the probably biggest of them: modeling power states. > > For simplifying energy management we want to introduce the concept of > power states (aka power levels). A power state will indicate roughly how > much power a device consumes. Examples for simple power states are off, > sleep, and operational states. > > In the envisioned EMAN MIB modules, a power state is characterized by a > descriptive name and the device's expected power input in this state > (max/min/average). > > Power states are not a new concept. The DMTF has already defined a set o= f > power states and there is the Other standards bodies as the DMTF > (Distributed Management Task Force) and there is the ACPI (Advanced > Configuration and Power Interface) for PC motherboards. And there may be > more than these out there. I listed some DMTF and ACPI states at the end > of this message. > > An easy solution for EMAN would be just adopting one of these sets. > However, there are issues with the ones we looked at. ACPI was developed > for PC motherboards and is quite PC-centric. Also it defines states that > seem to be superfluous, because so far, almost no one has implemented > them. Also the DMTF model seems to have a narrower scope than envisioned > by the EMAN WG. > > At some point in time, the EMAN WG hast to make a decision, which power > state model to adopt. Here is a set of alternatives. The first four have > fixed sets of power states. > > Option 1: fixed minimum > Just support three power states (off, sleep (stand-by), operational) > This has clear semantics, but there are several people claiming it's too > restrictive. > > Option 2: fixed DMTF > Just use the states defined by DMTF. > Might be too much focussed n PCs. > > Option 3: fixed ACPI > Just use the states defined by ACPI. > Might be too much focussed n PCs. > > > > Option 4: fixed EMAN > Define a new fixed set of power levels within the EMAN WG. > > Option 5: IANA-registered power states > Have power states be registered at IANA. > We would start with registering (off, sleep, operational, the DMTF set, > and the ACPI set. > Manufacturers can then register further ones. > > > There has been discussions pointing out that these fixed sets may not be > sufficient, particularly if non-IT equipment should also be covered. > > For being more open, the idea to support user-defined or > manufacturer-defined power states of devices has been developed. In such > a state, for example, certain components of a device may be switched off > or put to sleep. Which ones are switched off in which state is to be > defined by the user/operator/manufacturer and may be chosen such that > operational needs are met. > > Again, there are several proposals how to do this. All of them favor a > two-level approach that distinguishes between rather flexible functional > power states and rather fixed basic power states. Functional power state= s > would be defined by the manufacturer, operator, or user. These would be > the power states that would be reported by a device. However, in order t= o > better define the semantics of functional power states, Each of these > would be mapped to exactly one basic power states. This means that a > property of any functional state would be the basic state it maps to. > Basic power states would be fixed, such as the ones used in options 1-5. > An easy example would be functional power states defined by > user/operator/manufacturer with each state indicating whether it is an of= f > state, a sleep state or an operational state. > > Here are the corresponding options: > > Option 6: flexible functional states mapped to a fixed set of basic state= s > States could be defined flexibly. But each state would indicate a basic > state to which it corresponds. Basic states could be either basic > (off/sleep/operational) or the DMTF set or the ACPI set > > Option 7: flexible functional states mapped to a IANA registered set of > basic states > This is like Option 6, but basic states would be registered at IANA and > can be extended. We would register all DMTF and ACPI states and probably > some more at IANA. Manufacturers could add more. > > Option 8: IANA-registered sets of functional states, only three basic > states > The main reasoning behind this option is that is should always be clear > whether a power state is an off state, a sleep state, or an operational > state. Therefore, only these three basic states are supported. This > would be in line with an instance of Option 6. However, this option has > an extension for the functional states. It suggests that for customizing > devices in order to be compliant with given management systems, for > example a DMTF-based system, it should be possible to restrict functional > power states to a given set that is registered at IANA. An example would > be the DMTF states. We would register a flag at IANA that indicates we > are using DMTF states only. This would signal the management application > that all power state IDs are in line with power state numbering as define= d > by IANA. Analogously, ACPI and further sets could be registered at IANA. > A fallback to Option 6 could be realized by registering a set number of 0 > at IANA that does not impose any limit for functional states. > > Obviously, there are more possible options. If you think there is a > better one, please send it to this list. > > I know this discussion is not easy, but we have to have it in order to > make the right decision in the EMAN WG. Please take some time and think > about what you consider to be the best way to go. And of course send > questions on the issue. > > Thanks. > > Juergen > > > DMTF (Distributed Management Task Force) power states: > - 2 (Power On) > - 3 (Sleep - Light) > - 4 (Sleep - Deep) > - 5 (Power Cycle (Off Soft)) > - 6 (Power Off - Hard) > - 7 (Hibernate) > - 8 (Power Off - Soft) > - 9 (Power Cycle (Off Hard)) > - 10 (Master Bus Reset) > - 11 (Diagnostic Interrupt (NMI)) > - 12 (Power Off - Soft Graceful) > - 13 (Power Off - Hard Graceful) > - 14 (Master Bus Reset Graceful) > - 15 (Power Cycle (Off - Soft Graceful)) > - 16 (Power Cycle (Off - Hard Graceful)) > > ACPI (Advanced Configuration and Power Interface Specification) power > states for PC motherboards: > - G3-S5 (Off-Hard) > - G2-S5 (Off-Soft) > - G1-S4 (Hibernate) > - G1-S3 (Sleep-Deep) > - G1-S2 (Sleep-Light) > - G1-S1 (Sleep-Light) > - G0-S0-P5 > - G0-S0-P4 > - G0-S0-P3 > - G0-S0-P2 > - G0-S0-P2 > - G0-S0-P2 > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --0016e64754a2e1c1f5049d765df9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Chris,

I agree with you from=A0implementation=A0point of= view, a flexible interface is better, but from user experience managing 10= 0s of=A0heterogeneous=A0devices, it will be a=A0nightmare. Instead if we ha= ve one set of states, and a mapping what devices=A0natively support will be= best. I'll let everyone decide who will be allowed to make the mapping= , is it user read-write or read-only. Is it=A0manufacturer=A0=A0read-write/= user read-only?

thanks

-tg-
*= :-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:= -.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time..= . see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:= *'``'*:-.,_:-.,_,.-:**:-.,_,.


On Tue, Mar 1, 2011 at 5:55 PM, Chris Ve= rges <chr= isv@cyberswitching.com> wrote:

Sorry, the =939=94 key a= pparently got put upside down on my keyboard.

=A0

= =A0

Option 6: Support all of them.

=A0

Chris

=A0

<= p class=3D"MsoNormal">--

Chris Verges

408-500-2377

http://www.cyberswitching.com

=A0

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.or= g] On Behalf Of Bruce Nordman
Sent: Tuesday, March 01, 2011 4:54 PM
To: eman mailing lis= t
Subject: [eman] Power States - really

=A0

I am repostin= g Juergen's email about power states.
While the subsequent discussion has been important
and useful, it is on = a different topic.=A0 So, please let's
also make progress on this to= pic.
--Bruce

On Mon, Feb 28, 2011 at 4:07= AM, Juergen Quittek <Quittek@neclab.eu> wrote:

Dear all,

We have two proposals for a Power/E= nergy MIB module:

=A0- draft-claise-energy-monitoring-mib-06
=A0-= draft-quittek-power-mib-02

Among the authors of both documents we a= re currently trying to merge them.
But there are some open issues that should be discussed on the mailing
l= ist. =A0Here is the probably biggest of them: modeling power states.
For simplifying energy management we want to introduce the concept of
power states (aka power levels). =A0A power state will indicate roughly how=
much power a device consumes. =A0Examples for simple power states are o= ff,
sleep, and operational states.

In the envisioned EMAN MIB mod= ules, a power state is characterized by a
descriptive name and the device's expected power input in this state(max/min/average).

Power states are not a new concept. =A0The DMTF = has already defined a set of
power states and there is the Other standar= ds bodies as the DMTF
(Distributed Management Task Force) and there =A0is the ACPI (Advanced
C= onfiguration and Power Interface) for PC motherboards. =A0And there may be<= br>more than these out there. =A0I listed some DMTF and ACPI states at the = end
of this message.

An easy solution for EMAN would be just adopting on= e of these sets.
However, there are issues with the ones we looked at. = =A0ACPI was developed
for PC motherboards and is quite PC-centric. =A0Al= so it defines states that
seem to be superfluous, because so far, almost no one has implemented
th= em. =A0Also the DMTF model seems to have a narrower scope than envisionedby the EMAN WG.

At some point in time, the EMAN WG hast to make a = decision, which power
state model to adopt. =A0Here is a set of alternatives. The first four have=
fixed sets of power states.

Option 1: fixed minimum
Just supp= ort three power states (off, sleep (stand-by), operational)
This has cle= ar semantics, but there are several people claiming it's too
restrictive.

Option 2: fixed DMTF
Just use the states defined by = DMTF.
Might be too much focussed n PCs.

Option 3: fixed ACPI
J= ust use the states defined by ACPI.
Might be too much focussed n PCs.


Option 4: fixed EMAN
Define a new fixed set of power levels = within the EMAN WG.

Option 5: IANA-registered power states
Have p= ower states be registered at IANA.
We would start with registering (off,= sleep, operational, the DMTF set,
and the ACPI set.
Manufacturers can then register further ones.

<= br>There has been discussions pointing out that these fixed sets may not be=
sufficient, particularly if non-IT equipment should also be covered.
For being more open, the idea to support user-defined or
manufacture= r-defined power states of devices has been developed. =A0In such
a state= , for example, certain components of a device may be switched off
or put= to sleep. =A0Which ones are switched off in which state is to be
defined by the user/operator/manufacturer and may be chosen such that
op= erational needs are met.

Again, there are several proposals how to d= o this. =A0All of them favor a
two-level approach that distinguishes bet= ween rather flexible functional
power states and rather fixed basic power states. =A0Functional power state= s
would be defined by the manufacturer, operator, or user. =A0These woul= d be
the power states that would be reported by a device. =A0However, in= order to
better define the semantics of functional power states, Each of these
wo= uld be mapped to exactly one basic power states. =A0This means that a
pr= operty of any functional state would be the basic state it maps to.
Basi= c power states would be fixed, such as the ones used in options 1-5.
An easy example would be functional power states defined by
user/operato= r/manufacturer with each state indicating whether it is an off
state, a = sleep state or an operational state.

Here are the corresponding opti= ons:

Option 6: flexible functional states mapped to a fixed set of basic sta= tes
States could be defined flexibly. =A0But each state would indicate a= basic
state to which it corresponds. Basic states could be either basic=
(off/sleep/operational) or the DMTF set or the ACPI set

Option 7: fl= exible functional states mapped to a IANA registered set of
basic states=
This is like Option 6, but basic states would be registered at IANA and=
can be extended. =A0We would register all DMTF and ACPI states and probably=
some more at IANA. Manufacturers could add more.

Option 8: IANA-= registered sets of functional states, only three basic
states
The mai= n reasoning behind this option is that is should always be clear
whether a power state is an off state, a sleep state, or an operational
= state. =A0Therefore, only these three basic states are supported. =A0Thiswould be in line with an instance of Option 6. =A0However, this option ha= s
an extension for the functional states. =A0It suggests that for customizing=
devices in order to be compliant with given management systems, for
= example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. =A0An example would=
be the DMTF states. =A0We would register a flag at IANA that indicates = we
are using DMTF states only. =A0This would signal the management appli= cation
that all power state IDs are in line with power state numbering as defined<= br>by IANA. =A0Analogously, ACPI and further sets could be registered at IA= NA.
A fallback to Option 6 could be realized by registering a set number= of 0
at IANA that does not impose any limit for functional states.

Obviou= sly, there are more possible options. =A0If you think there is a
better = one, please send it to this list.

I know this discussion is not easy= , but we have to have it in order to
make the right decision in the EMAN WG. =A0Please take some time and think<= br>about what you consider to be the best way to go. =A0And of course send<= br>questions on the issue.

Thanks.

=A0 =A0Juergen


= DMTF (Distributed Management Task Force) power states:
=A0- 2 (Power On)
=A0- 3 (Sleep - Light)
=A0- 4 (Sleep - Deep)
=A0= - 5 (Power Cycle (Off Soft))
=A0- 6 (Power Off - Hard)
=A0- 7 (Hibern= ate)
=A0- 8 (Power Off - Soft)
=A0- 9 (Power Cycle (Off Hard))
=A0= - 10 (Master Bus Reset)
=A0- 11 (Diagnostic Interrupt (NMI))
=A0- 12 (Power Off - Soft Graceful)=
=A0- 13 (Power Off - Hard Graceful)
=A0- 14 (Master Bus Reset Gracef= ul)
=A0- 15 (Power Cycle (Off - Soft Graceful))
=A0- 16 (Power Cycle = (Off - Hard Graceful))

ACPI (Advanced Configuration and Power Interface Specification) powerstates for PC motherboards:
=A0- G3-S5 (Off-Hard)
=A0- G2-S5 (Off-S= oft)
=A0- G1-S4 (Hibernate)
=A0- G1-S3 (Sleep-Deep)
=A0- G1-S2 (Sl= eep-Light)
=A0- G1-S1 (Sleep-Light)
=A0- G0-S0-P5
=A0- G0-S0-P4
=A0- G0-S0-P3=
=A0- G0-S0-P2
=A0- G0-S0-P2
=A0- G0-S0-P2




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




--
Bruce Nordman
Lawrence Berkeley National Laboratory<= br>eetd.lbl.go= v/ea/nordman
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


--0016e64754a2e1c1f5049d765df9-- From chrisv@cyberswitching.com Tue Mar 1 18:22:18 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A803A6C0E for ; Tue, 1 Mar 2011 18:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp8aiULSVlA6 for ; Tue, 1 Mar 2011 18:22:05 -0800 (PST) Received: from p01c11o141.mxlogic.net (p01c11o141.mxlogic.net [208.65.144.64]) by core3.amsl.com (Postfix) with ESMTP id 7F8AB3A6A16 for ; Tue, 1 Mar 2011 18:22:04 -0800 (PST) Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c11o141.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id c0aad6d4.0.6911.00-375.13285.p01c11o141.mxlogic.net (envelope-from ); Tue, 01 Mar 2011 19:23:09 -0700 (MST) X-MXL-Hash: 4d6daa0d4c12b5a1-9652610571125a966f13b7cd8fec30f87664b91e X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD880.A41C3FE4" Date: Tue, 1 Mar 2011 18:22:12 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CECD969@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power States - really Thread-Index: AcvYfmA2ec1G25NMT3yDvfMJCEQY4AAAe6XA References: <68FBE0F3CE97264395875AC1C468F22CECD966@mail03.cyberswitching.local><68FBE0F3CE97264395875AC1C468F22CECD967@mail03.cyberswitching.local> From: "Chris Verges" To: "Ted Ghose" , "eman mailing list" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [64.81.28.110] X-AnalysisOut: [v=1.0 c=1 a=XnxjYOJpEeMA:10 a=BLceEmwcHowA:10 a=4zsJQXJisS] X-AnalysisOut: [Y22NXBO5KRuA==:17 a=pGLkceISAAAA:8 a=wzgqfsuUAAAA:8 a=48vg] X-AnalysisOut: [C7mUAAAA:8 a=DrKipDvROCyKFcetSqMA:9 a=f-pM1ksqN1z1dAJ6gXoA] X-AnalysisOut: [:7 a=bPy-lvR2wBrK43tx3serpV-kvCQA:4 a=CjuIK1q_8ugA:10 a=Y8] X-AnalysisOut: [rda4wpm8gA:10 a=FnBvD0j_UmcA:10 a=lr71C7C2fScA:10 a=MSl-tD] X-AnalysisOut: [qOz04A:10 a=yvfu_RGVus0A:10 a=lZB815dzVvQA:10 a=p4V_nncvOL] X-AnalysisOut: [5N3Fjz:21 a=tVvDSHSMpFPnhzke:21 a=yMhMjlubAAAA:8 a=SSmOFEA] X-AnalysisOut: [CAAAA:8 a=J35dNKfbAAAA:8 a=ifuEVSzAZZxku4NFHYYA:9 a=GQKgSy] X-AnalysisOut: [OdfJ57Q2rL48EA:7 a=6UuyYDibIXfNx9x6DmgwXkStteMA:4 a=rB23ib] X-AnalysisOut: [D6aN8I7PTk:21 a=u1KecKrKGwwwCAgB:21] Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 02:22:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD880.A41C3FE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, =20 I'm not understanding the drawback to having multiple, coordinated interfaces. You're saying that standards like ACPI and DMTF will have to be mapped to this arbitrary state set created by EMAN, right? So why not just expose the ACPI and DMTF states natively and map them internally in the agent/MIB? It would provide for a better interface for the users, and the state-to-behavior mapping is done by the manufacturer anyway. (Read-only to the user.) =20 Thanks, Chris =20 From: tirth.ghose@gmail.com [mailto:tirth.ghose@gmail.com] On Behalf Of Ted Ghose Sent: Tuesday, March 01, 2011 6:07 PM To: Chris Verges; eman mailing list Subject: Re: [eman] Power States - really =20 Chris, =20 I agree with you from implementation point of view, a flexible interface is better, but from user experience managing 100s of heterogeneous devices, it will be a nightmare. Instead if we have one set of states, and a mapping what devices natively support will be best. I'll let everyone decide who will be allowed to make the mapping, is it user read-write or read-only. Is it manufacturer read-write/user read-only? =20 thanks =20 -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Tue, Mar 1, 2011 at 5:55 PM, Chris Verges wrote: Sorry, the "9" key apparently got put upside down on my keyboard. =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Chris Verges Sent: Tuesday, March 01, 2011 5:53 PM To: Bruce Nordman; eman mailing list Subject: Re: [eman] Power States - really =20 Option 6: Support all of them. =20 Chris =20 --=20 Chris Verges 408-500-2377 http://www.cyberswitching.com =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman Sent: Tuesday, March 01, 2011 4:54 PM To: eman mailing list Subject: [eman] Power States - really =20 I am reposting Juergen's email about power states. While the subsequent discussion has been important and useful, it is on a different topic. So, please let's also make progress on this topic. --Bruce On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: Dear all, We have two proposals for a Power/Energy MIB module: - draft-claise-energy-monitoring-mib-06 - draft-quittek-power-mib-02 Among the authors of both documents we are currently trying to merge them. But there are some open issues that should be discussed on the mailing list. Here is the probably biggest of them: modeling power states. For simplifying energy management we want to introduce the concept of power states (aka power levels). A power state will indicate roughly how much power a device consumes. Examples for simple power states are off, sleep, and operational states. In the envisioned EMAN MIB modules, a power state is characterized by a descriptive name and the device's expected power input in this state (max/min/average). Power states are not a new concept. The DMTF has already defined a set of power states and there is the Other standards bodies as the DMTF (Distributed Management Task Force) and there is the ACPI (Advanced Configuration and Power Interface) for PC motherboards. And there may be more than these out there. I listed some DMTF and ACPI states at the end of this message. An easy solution for EMAN would be just adopting one of these sets. However, there are issues with the ones we looked at. ACPI was developed for PC motherboards and is quite PC-centric. Also it defines states that seem to be superfluous, because so far, almost no one has implemented them. Also the DMTF model seems to have a narrower scope than envisioned by the EMAN WG. At some point in time, the EMAN WG hast to make a decision, which power state model to adopt. Here is a set of alternatives. The first four have fixed sets of power states. Option 1: fixed minimum Just support three power states (off, sleep (stand-by), operational) This has clear semantics, but there are several people claiming it's too restrictive. Option 2: fixed DMTF Just use the states defined by DMTF. Might be too much focussed n PCs. Option 3: fixed ACPI Just use the states defined by ACPI. Might be too much focussed n PCs. Option 4: fixed EMAN Define a new fixed set of power levels within the EMAN WG. Option 5: IANA-registered power states Have power states be registered at IANA. We would start with registering (off, sleep, operational, the DMTF set, and the ACPI set. Manufacturers can then register further ones. There has been discussions pointing out that these fixed sets may not be sufficient, particularly if non-IT equipment should also be covered. For being more open, the idea to support user-defined or manufacturer-defined power states of devices has been developed. In such a state, for example, certain components of a device may be switched off or put to sleep. Which ones are switched off in which state is to be defined by the user/operator/manufacturer and may be chosen such that operational needs are met. Again, there are several proposals how to do this. All of them favor a two-level approach that distinguishes between rather flexible functional power states and rather fixed basic power states. Functional power states would be defined by the manufacturer, operator, or user. These would be the power states that would be reported by a device. However, in order to better define the semantics of functional power states, Each of these would be mapped to exactly one basic power states. This means that a property of any functional state would be the basic state it maps to. Basic power states would be fixed, such as the ones used in options 1-5. An easy example would be functional power states defined by user/operator/manufacturer with each state indicating whether it is an off state, a sleep state or an operational state. Here are the corresponding options: Option 6: flexible functional states mapped to a fixed set of basic states States could be defined flexibly. But each state would indicate a basic state to which it corresponds. Basic states could be either basic (off/sleep/operational) or the DMTF set or the ACPI set Option 7: flexible functional states mapped to a IANA registered set of basic states This is like Option 6, but basic states would be registered at IANA and can be extended. We would register all DMTF and ACPI states and probably some more at IANA. Manufacturers could add more. Option 8: IANA-registered sets of functional states, only three basic states The main reasoning behind this option is that is should always be clear whether a power state is an off state, a sleep state, or an operational state. Therefore, only these three basic states are supported. This would be in line with an instance of Option 6. However, this option has an extension for the functional states. It suggests that for customizing devices in order to be compliant with given management systems, for example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. An example would be the DMTF states. We would register a flag at IANA that indicates we are using DMTF states only. This would signal the management application that all power state IDs are in line with power state numbering as defined by IANA. Analogously, ACPI and further sets could be registered at IANA. A fallback to Option 6 could be realized by registering a set number of 0 at IANA that does not impose any limit for functional states. Obviously, there are more possible options. If you think there is a better one, please send it to this list. I know this discussion is not easy, but we have to have it in order to make the right decision in the EMAN WG. Please take some time and think about what you consider to be the best way to go. And of course send questions on the issue. Thanks. Juergen DMTF (Distributed Management Task Force) power states: - 2 (Power On) - 3 (Sleep - Light) - 4 (Sleep - Deep) - 5 (Power Cycle (Off Soft)) - 6 (Power Off - Hard) - 7 (Hibernate) - 8 (Power Off - Soft) - 9 (Power Cycle (Off Hard)) - 10 (Master Bus Reset) - 11 (Diagnostic Interrupt (NMI)) - 12 (Power Off - Soft Graceful) - 13 (Power Off - Hard Graceful) - 14 (Master Bus Reset Graceful) - 15 (Power Cycle (Off - Soft Graceful)) - 16 (Power Cycle (Off - Hard Graceful)) ACPI (Advanced Configuration and Power Interface Specification) power states for PC motherboards: - G3-S5 (Off-Hard) - G2-S5 (Off-Soft) - G1-S4 (Hibernate) - G1-S3 (Sleep-Deep) - G1-S2 (Sleep-Light) - G1-S1 (Sleep-Light) - G0-S0-P5 - G0-S0-P4 - G0-S0-P3 - G0-S0-P2 - G0-S0-P2 - G0-S0-P2 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman =20 ------_=_NextPart_001_01CBD880.A41C3FE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ted,

 

I’m not understanding the drawback to having multiple, = coordinated interfaces.  You’re saying that standards like = ACPI and DMTF will have to be mapped to this arbitrary state set created = by EMAN, right?  So why not just expose the ACPI and DMTF states = natively and map them internally in the agent/MIB?  It would = provide for a better interface for the users, and the state-to-behavior = mapping is done by the manufacturer anyway.  (Read-only to the = user.)

 

Thanks,

Chris

 

From:= = tirth.ghose@gmail.com [mailto:tirth.ghose@gmail.com] On Behalf Of = Ted Ghose
Sent: Tuesday, March 01, 2011 6:07 = PM
To: Chris Verges; eman mailing list
Subject: Re: = [eman] Power States - really

 

Chris,

 

I = agree with you from implementation point of view, a flexible = interface is better, but from user experience managing 100s = of heterogeneous devices, it will be a nightmare. Instead = if we have one set of states, and a mapping what devices natively = support will be best. I'll let everyone decide who will be allowed to = make the mapping, is it user read-write or read-only. Is = it manufacturer  read-write/user = read-only?

 

thanks

 

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:*= *:-.,_,.
                =      Save time... see it my = way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,= _,.

On Tue, Mar 1, 2011 = at 5:55 PM, Chris Verges <chrisv@cyberswitching.com&g= t; wrote:

Sorry, the “9” key = apparently got put upside down on my keyboard.

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Chris = Verges
Sent: Tuesday, March 01, 2011 5:53 PM
To: = Bruce Nordman; eman mailing list
Subject: Re: [eman] Power = States - really

 <= /o:p>

Option 6: = Support all of them.

 <= /o:p>

Chris

 <= /o:p>

-- =

Chris = Verges

408-500-2377=

http://www.cyberswitching.com

 <= /o:p>

From:= eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce = Nordman
Sent: Tuesday, March 01, 2011 4:54 PM
To: = eman mailing list
Subject: [eman] Power States - = really

 <= /o:p>

I am reposting = Juergen's email about power states.
While the subsequent discussion = has been important
and useful, it is on a different topic.  So, = please let's
also make progress on this = topic.
--Bruce

On Mon, Feb = 28, 2011 at 4:07 AM, Juergen Quittek <Quittek@neclab.eu> wrote:

Dear = all,

We have two proposals for a Power/Energy MIB = module:

 - draft-claise-energy-monitoring-mib-06
 - = draft-quittek-power-mib-02

Among the authors of both documents we = are currently trying to merge them.
But there are some open issues = that should be discussed on the mailing
list.  Here is the = probably biggest of them: modeling power states.

For simplifying = energy management we want to introduce the concept of
power states = (aka power levels).  A power state will indicate roughly = how
much power a device consumes.  Examples for simple power = states are off,
sleep, and operational states.

In the = envisioned EMAN MIB modules, a power state is characterized by = a
descriptive name and the device's expected power input in this = state
(max/min/average).

Power states are not a new concept. =  The DMTF has already defined a set of
power states and there is = the Other standards bodies as the DMTF
(Distributed Management Task = Force) and there  is the ACPI (Advanced
Configuration and Power = Interface) for PC motherboards.  And there may be
more than = these out there.  I listed some DMTF and ACPI states at the = end
of this message.

An easy solution for EMAN would be just = adopting one of these sets.
However, there are issues with the ones = we looked at.  ACPI was developed
for PC motherboards and is = quite PC-centric.  Also it defines states that
seem to be = superfluous, because so far, almost no one has implemented
them. =  Also the DMTF model seems to have a narrower scope than = envisioned
by the EMAN WG.

At some point in time, the EMAN WG = hast to make a decision, which power
state model to adopt.  Here = is a set of alternatives. The first four have
fixed sets of power = states.

Option 1: fixed minimum
Just support three power = states (off, sleep (stand-by), operational)
This has clear semantics, = but there are several people claiming it's = too
restrictive.

Option 2: fixed DMTF
Just use the states = defined by DMTF.
Might be too much focussed n PCs.

Option 3: = fixed ACPI
Just use the states defined by ACPI.
Might be too much = focussed n PCs.



Option 4: fixed EMAN
Define a new = fixed set of power levels within the EMAN WG.

Option 5: = IANA-registered power states
Have power states be registered at = IANA.
We would start with registering (off, sleep, operational, the = DMTF set,
and the ACPI set.
Manufacturers can then register = further ones.


There has been discussions pointing out that = these fixed sets may not be
sufficient, particularly if non-IT = equipment should also be covered.

For being more open, the idea = to support user-defined or
manufacturer-defined power states of = devices has been developed.  In such
a state, for example, = certain components of a device may be switched off
or put to sleep. =  Which ones are switched off in which state is to be
defined by = the user/operator/manufacturer and may be chosen such = that
operational needs are met.

Again, there are several = proposals how to do this.  All of them favor a
two-level = approach that distinguishes between rather flexible functional
power = states and rather fixed basic power states.  Functional power = states
would be defined by the manufacturer, operator, or user. =  These would be
the power states that would be reported by a = device.  However, in order to
better define the semantics of = functional power states, Each of these
would be mapped to exactly one = basic power states.  This means that a
property of any = functional state would be the basic state it maps to.
Basic power = states would be fixed, such as the ones used in options 1-5.
An easy = example would be functional power states defined = by
user/operator/manufacturer with each state indicating whether it = is an off
state, a sleep state or an operational state.

Here = are the corresponding options:

Option 6: flexible functional = states mapped to a fixed set of basic states
States could be defined = flexibly.  But each state would indicate a basic
state to which = it corresponds. Basic states could be either = basic
(off/sleep/operational) or the DMTF set or the ACPI = set

Option 7: flexible functional states mapped to a IANA = registered set of
basic states
This is like Option 6, but basic = states would be registered at IANA and
can be extended.  We = would register all DMTF and ACPI states and probably
some more at = IANA. Manufacturers could add more.

Option 8: IANA-registered = sets of functional states, only three basic
states
The main = reasoning behind this option is that is should always be = clear
whether a power state is an off state, a sleep state, or an = operational
state.  Therefore, only these three basic states are = supported.  This
would be in line with an instance of Option 6. =  However, this option has
an extension for the functional = states.  It suggests that for customizing
devices in order to be = compliant with given management systems, for
example a DMTF-based = system, it should be possible to restrict functional
power states to = a given set that is registered at IANA.  An example would
be the = DMTF states.  We would register a flag at IANA that indicates = we
are using DMTF states only.  This would signal the management = application
that all power state IDs are in line with power state = numbering as defined
by IANA.  Analogously, ACPI and further = sets could be registered at IANA.
A fallback to Option 6 could be = realized by registering a set number of 0
at IANA that does not = impose any limit for functional states.

Obviously, there are more = possible options.  If you think there is a
better one, please = send it to this list.

I know this discussion is not easy, but we = have to have it in order to
make the right decision in the EMAN WG. =  Please take some time and think
about what you consider to be = the best way to go.  And of course send
questions on the = issue.

Thanks.

   Juergen


DMTF = (Distributed Management Task Force) power states:
 - 2 (Power = On)
 - 3 (Sleep - Light)
 - 4 (Sleep - Deep)
 - = 5 (Power Cycle (Off Soft))
 - 6 (Power Off - Hard)
 - 7 = (Hibernate)
 - 8 (Power Off - Soft)
 - 9 (Power Cycle = (Off Hard))
 - 10 (Master Bus Reset)
 - 11 (Diagnostic = Interrupt (NMI))
 - 12 (Power Off - Soft Graceful)
 - 13 = (Power Off - Hard Graceful)
 - 14 (Master Bus Reset = Graceful)
 - 15 (Power Cycle (Off - Soft Graceful))
 - = 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced = Configuration and Power Interface Specification) power
states for PC = motherboards:
 - G3-S5 (Off-Hard)
 - G2-S5 = (Off-Soft)
 - G1-S4 (Hibernate)
 - G1-S3 = (Sleep-Deep)
 - G1-S2 (Sleep-Light)
 - G1-S1 = (Sleep-Light)
 - G0-S0-P5
 - G0-S0-P4
 - = G0-S0-P3
 - G0-S0-P2
 - G0-S0-P2
 - = G0-S0-P2




_____________________________________________= __
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman




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


______________________________________= _________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

 

------_=_NextPart_001_01CBD880.A41C3FE4-- From bnordman@lbl.gov Tue Mar 1 18:36:45 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10013A6C04 for ; Tue, 1 Mar 2011 18:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rIR-OTiX4nL for ; Tue, 1 Mar 2011 18:36:44 -0800 (PST) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by core3.amsl.com (Postfix) with ESMTP id B28DF3A6A16 for ; Tue, 1 Mar 2011 18:36:44 -0800 (PST) X-Ironport-SBRS: 5.3 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwBAJI8bU3RVdy0mWdsb2JhbACCTpt0AYgJCBUBAQEBAQgLCgcRJaM6mlSDGIJJBIUShw2IUTo X-IronPort-AV: E=Sophos;i="4.62,251,1297065600"; d="scan'208";a="35962436" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport3.lbl.gov with ESMTP; 01 Mar 2011 18:37:48 -0800 Received: by vxc38 with SMTP id 38so6421299vxc.39 for ; Tue, 01 Mar 2011 18:37:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.68.44 with SMTP id s12mr7462191vdt.74.1299033468339; Tue, 01 Mar 2011 18:37:48 -0800 (PST) Received: by 10.52.155.40 with HTTP; Tue, 1 Mar 2011 18:37:48 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Mar 2011 18:37:48 -0800 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=20cf307f326c6e86fc049d76cc78 Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 02:36:45 -0000 --20cf307f326c6e86fc049d76cc78 Content-Type: text/plain; charset=ISO-8859-1 And below is my comment from yesterday to the original thread. On Tue, Mar 1, 2011 at 4:54 PM, Bruce Nordman wrote: > I am reposting Juergen's email about power states. > While the subsequent discussion has been important > and useful, it is on a different topic. So, please let's > also make progress on this topic. > --Bruce > > ... Juergen has provided a good summary and comprehensive set of options. I think several of the points he makes bear emphasis. One is the distinction between (basic) power states, and functionality differences within such states. It is tempting to want to put all of this onto one linear scale of states, and sometimes that works. However, many functionalities are essentially not on the same dimension as the basic power state one, so do not well match to it. An example is battery charging, which can occur in on, sleep, or off. Another point is that going beyond a few basic states inevitably makes the list specific to narrow groups of products and/or to specific implementations, and so is not universal. With all this, not surprisingly I favor option 1, or 6-8, with the latter ones recognizing this distinction between power states and functional states. For DMTF, this is a mixture of power states, and transition states and/or commands, so I think not a good source when we are just talking about power states. For ACPI, my understanding is that in practice, S1 and S2 are not used, so the number of actual states is fewer than appears. I do think that there may be a fourth basic state of "Ready", which would apply more to appliances than to electronic devices. --Bruce -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --20cf307f326c6e86fc049d76cc78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And below is my comment from yesterday to the original thread.

On Tue, Mar 1, 2011 at 4:54 PM, Bruce Nordman <bnordman@lbl.gov>= wrote:
I am reposting Ju= ergen's email about power states.
While the subsequent discussion ha= s been important
and useful, it is on a different topic.=A0 So, please let's
also mak= e progress on this topic.
--Bruce

...
Juergen has provided a good summary and comprehen= sive set of options.

I think several of the points he makes bear emp= hasis.
One is the distinction between (basic) power states,
and funct= ionality differences within such states.
It is tempting to want to put all of this onto one linear
scale of state= s, and sometimes that works. =A0However,
many functionalities are essent= ially not on the same
dimension as the basic power state one, so do not<= br> well match to it. =A0An example is battery charging, which
can occur in = on, sleep, or off.

Another point is that going beyond a few basic st= ates
inevitably makes the list specific to narrow groups of
products = and/or to specific implementations, and so
is not universal.

With all this, not surprisingly I favor option 1, = or 6-8,
with the latter ones recognizing this distinction between
pow= er states and functional states.

For DMTF, this is a mixture of powe= r states, and
transition states and/or commands, so I think not a
good source when we = are just talking about power
states.

For ACPI, my understanding i= s that in practice, S1
and S2 are not used, so the number of actual
states is fewer than appears.

I do think that there may be a fourth = basic state
of "Ready", which would apply more to appliancesthan to electronic devices.

--Bruce

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

--20cf307f326c6e86fc049d76cc78-- From tirth.ghose@gmail.com Tue Mar 1 20:56:12 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0803A6B5E for ; Tue, 1 Mar 2011 20:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frcgI5UKSsd3 for ; Tue, 1 Mar 2011 20:56:11 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2908B3A6A30 for ; Tue, 1 Mar 2011 20:56:11 -0800 (PST) Received: by iyj8 with SMTP id 8so5169053iyj.31 for ; Tue, 01 Mar 2011 20:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=0pjp7yky8OP2wVtf0U7O5XT2J05l+DjB3vHjYEgfqcU=; b=TwvraD6ebqFAJcVdaslgqQuZP9xZWuPCbbGoZclQs2XXx9Zbb8WaBrfW9qt1f+suO9 HXapDbZ+yysw8HBCPdA8ONQdxaMO75hd1b545YgJravxhvwlVDuYOfRX+E3p5adqXUa3 Lq025ST2KL3ndZBq8+Aysi1j3S9Vu0J1UFims= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=oSYyC+taH189qh5thhFFfn/Je9jZowpZ2r7l8xdO5WtOvIrADKZeLQGRjbeGmA9K98 fDgcBPMsISvsCkgnfRLrfHGrz3lf8HmvelHU/tA3eOpi0EatB19jnetigb7ijfWKBdxp GB/E7IxfpEAXlxmzMwBucCo49ZXJ56PQeJhoM= MIME-Version: 1.0 Received: by 10.231.11.77 with SMTP id s13mr7173435ibs.18.1299041835653; Tue, 01 Mar 2011 20:57:15 -0800 (PST) Sender: tirth.ghose@gmail.com Received: by 10.231.156.141 with HTTP; Tue, 1 Mar 2011 20:57:15 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Mar 2011 20:57:15 -0800 X-Google-Sender-Auth: RarZfS0uBmI64NRXLpM9XmOd9Po Message-ID: From: Ted Ghose To: Bruce Nordman , eman mailing list Content-Type: multipart/alternative; boundary=00221538fcb2299910049d78bf97 Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 04:56:12 -0000 --00221538fcb2299910049d78bf97 Content-Type: text/plain; charset=ISO-8859-1 So long each state defines it behavior, and in a broad bucket of what is expected of each state, individual devices behavior (battery vs coffee machine: say state 1 for battery not charging drawing full power, while coffee machine not drawing anything) in the respect of power drawn from the utility will be good. reverse should be hold good for solar panel which pumps power in. I totally miss why we are declaring it hard and refuse to explore a solution to get a linear mapping. I'm not saying it will be easy but I'd like to find one linear mapping, which will satisfy most of the devices, laying down some ground rules. say, I define following rules: Rule 1: device at low power state takes less power from utility power source than at a higher state Rule 2: device express their capability at a given state (may be % or some measure) (hypothetical example: a solar panel at lowest state might be 100% capable producing most power, and sleeps at the highest; reverse for the coffee machine.) Now can we map PDUs, UPSs, Batteries, etc? I'd propose here to come up with a set of rules w/ our objective in view, and hence define our model! Let us agree we are defining the MIB for the user and usability, and our goal is to cover all the devices we could possible get to participate. Thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Tue, Mar 1, 2011 at 6:37 PM, Bruce Nordman wrote: > And below is my comment from yesterday to the original thread. > > On Tue, Mar 1, 2011 at 4:54 PM, Bruce Nordman wrote: > >> I am reposting Juergen's email about power states. >> While the subsequent discussion has been important >> and useful, it is on a different topic. So, please let's >> also make progress on this topic. >> --Bruce >> >> ... > > Juergen has provided a good summary and comprehensive set of options. > > I think several of the points he makes bear emphasis. > One is the distinction between (basic) power states, > and functionality differences within such states. > It is tempting to want to put all of this onto one linear > scale of states, and sometimes that works. However, > many functionalities are essentially not on the same > dimension as the basic power state one, so do not > well match to it. An example is battery charging, which > can occur in on, sleep, or off. > > Another point is that going beyond a few basic states > inevitably makes the list specific to narrow groups of > products and/or to specific implementations, and so > is not universal. > > With all this, not surprisingly I favor option 1, or 6-8, > with the latter ones recognizing this distinction between > power states and functional states. > > For DMTF, this is a mixture of power states, and > transition states and/or commands, so I think not a > good source when we are just talking about power > states. > > For ACPI, my understanding is that in practice, S1 > and S2 are not used, so the number of actual > states is fewer than appears. > > I do think that there may be a fourth basic state > of "Ready", which would apply more to appliances > than to electronic devices. > > --Bruce > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --00221538fcb2299910049d78bf97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So long each state defines it behavior, and in a broad bucket of what is ex= pected of each state, individual devices behavior (battery vs coffee machin= e: say state 1 for battery not charging drawing full power, while coffee ma= chine not drawing anything) in the respect of power drawn from the utility = will be good.

reverse should be hold good for solar=A0panel=A0which pumps = power in.

I totally miss why we are=A0declaring=A0= it hard and refuse to explore a solution to get a linear mapping.

I'm not saying it will be easy but I'd like to find one = linear mapping, which will satisfy most of the devices, laying down some gr= ound rules.

say, I define following rules:

Rule 1: device at low power state takes less power from= utility power source than at a higher state
Rule 2: device expre= ss their capability at a given state (may be % or some measure)

(hypothetical example: a solar=A0panel=A0at lowest state mig= ht be 100% capable producing most power, and sleeps at the highest; reverse= for the coffee machine.)

Now can we map PDUs, UPS= s, Batteries, etc?

I'd propose here to come up with a set of rules w/ = our objective in view, and hence define our model!

Let us agree we are defining the MIB for the user and usability, and our g= oal is to cover all the devices we could possible get to participate.

Thanks

-tg-=A0
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.= ,_:-.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save tim= e... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_= :-.,_,.-:**:-.,_,.


On Tue, Mar 1, 2011 at 6:37 PM, Bruce No= rdman <bnordman@lb= l.gov> wrote:
And below is my comment from yesterday to the original thread.

On Tue, Mar 1, 2011 at 4:54 PM, Bru= ce Nordman <bnordman@lbl.gov> wrote:
I am reposting Juergen's email about power states.
While the subseq= uent discussion has been important
and useful, it is on a different topic.=A0 So, please let's
also mak= e progress on this topic.
--Bruce

...
Juergen has provided a good summary and com= prehensive set of options.

I think several of the points he makes be= ar emphasis.
One is the distinction between (basic) power states,
and functionality differences within such states.
It is tempting to want to put all of this onto one linear
scale of state= s, and sometimes that works. =A0However,
many functionalities are essent= ially not on the same
dimension as the basic power state one, so do not<= br> well match to it. =A0An example is battery charging, which
can occur in = on, sleep, or off.

Another point is that going beyond a few basic st= ates
inevitably makes the list specific to narrow groups of
products = and/or to specific implementations, and so
is not universal.

With all this, not surprisingly I favor option 1, = or 6-8,
with the latter ones recognizing this distinction between
pow= er states and functional states.

For DMTF, this is a mixture of powe= r states, and
transition states and/or commands, so I think not a
good source when we = are just talking about power
states.

For ACPI, my understanding i= s that in practice, S1
and S2 are not used, so the number of actual
states is fewer than appears.

I do think that there may be a fourth = basic state
of "Ready", which would apply more to appliancesthan to electronic devices.

--Bruce=


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


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


--00221538fcb2299910049d78bf97-- From bill.mielke@alcatel-lucent.com Tue Mar 1 21:05:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FEB13A69E4 for ; Tue, 1 Mar 2011 21:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlDtvVF66AI9 for ; Tue, 1 Mar 2011 21:05:20 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id DE9F23A6C01 for ; Tue, 1 Mar 2011 21:05:19 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p2256NJE003414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Mar 2011 23:06:24 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2256N5i014572 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Mar 2011 23:06:23 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 1 Mar 2011 23:06:23 -0600 From: "Mielke, William F (Bill)" To: eman mailing list Date: Tue, 1 Mar 2011 23:06:20 -0600 Thread-Topic: [eman] Power States - really Thread-Index: AcvYdGKsD4IHX7nnQcqwXOPGnYlzMQAC+/UA Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E79225070F7F4A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 05:05:22 -0000 The discussion of the past few days on the topic of power states has been q= uite interesting and I am happy to see some discussion on this important to= pic. I have some thoughts to throw into the mix that I wish to share. The= se are more on the level of general insights than on the level of a cooked = proposal but I think that they may introduce some much needed outside the b= ox thinking here. The discussion thus far is focused on trying to pick a fixed set of enumera= ted states which are intended to properly and reasonably abstract all possi= ble power savings capabilities which will be found in all existing and futu= re equipment to which this standard will be applied. While this is a noble= goal I fear that it is unrealistically optimistic in its chances for succe= ss. Both the DMTF and the ACPI options are far too PC-centric to be applic= able to such a wide reaching goal. Indeed, how well have these particular = standards been adopted and implemented even within that very narrow domain?= I don't know the answer but I will be surprised if the answer is that the= y are widely adopted, implemented, and used as they were originally envisio= ned. If you have anything to suggest otherwise please share it. So this leads me to the conclusion that even if we were successful in achie= ving the goal of defining a single fixed set of enumerated states that ever= yone here is happy with that the chances for the success of such an approac= h are rather limited. Note that I am not trying to throw water on the idea= or efforts to make it happen, I am just trying to assess the reality of th= e situation based on my own understanding of the inherent complexities invo= lved with large data and voice networking equipment. As I pointed out in Beijing I think that the answer needs to be both more f= lexible and more extensible if it is going to actually be useful. Here are= some of the reasons I believe this to be true: (1) We are discussing a widely disparate set of technologies which consumer= power in widely disparate ways and therefore they will have widely dispara= te notions of how to actually provide meaningful features for implementing = the inherently technology specific trade-offs between power savings and oth= er key product characteristics in terms of things like capacity, throughput= , availability, latency and response times, etc. (2) I expect that in all but the most trivial of products these power savin= gs "knobs" will be independently tunable, and they will need to be set by e= ach product owner so as to meet their specific business requirements. (3) To think that each product vendor will be able to make a reasonable map= ping between N independently controlled features and a simple linear progre= ssion of states seems like wishful thinking to me. "MAYBE" this could be d= one from a read only reporting perspective, but it will never work from a m= anagement and control perspective. I just don't believe that the operation= al use cases for a multi-million dollar router or switch will ever boil dow= n to some operator telling their router to go to "sleep" or to enter "power= savings level 3". Now, if we are to pursue the definition of a single set of fixed enumerated= states then the level of abstraction needs to be exceedingly high to be ab= le to cover the breadth of equipment we envision. So I would agree with Br= uce that if this is the direction the number of states needs to be absolute= ly high-level and generic which will also serve to reduce the number of suc= h states. So, for example, HighPerformance/PowerSavings/Off is about the b= est that you could do. But I question the usefulness of having a large rou= ter reporting that it is in the PowerSavings state. Sure, you know that so= me feature somewhere in the router is not running an maximum performance bu= t that is about all. It would be useless from a management perspective to = tell such a router to enter it's PowerSavings state. What would that actua= lly mean? What reasonable mapping could actually be done here? And Off wo= uld not be useful from a reporting perspective because if it was off how wo= uld it respond? Setting it to Off would be useful, I guess, but only in li= mited circumstances because once it was Off how would you transition it bac= k to any of the other states? Whether we have 3 states or 5 or 50 it won't really matter because this con= cept of a linear progression of states (e.g. from Off to PowerSavings to Hi= ghPerformance) is not the abstraction we should actually be pursuing IMHO. I think that a more useful abstraction would be one of modeling independent= ly controllable Capabilities. I would seek to let each product enumerate i= ts own set of such capabilities along with the type of values that each cap= ability could take on. By allowing the product to enumerate a set of suppo= rted Capabilities each piece of equipment could provide a meaningful set of= options to the technicians or management applications. As the product evo= lves from one release to the next the list of supported Capabilities can gr= ow and evolve over time based on each vendors design choices and each produ= ct's inherent technological constraints. So, without worrying about the SNMPisms involved (yet) this might only requ= ire a couple of tables to enumerate the required meta-data. I am thinking = of something along the following lines: emanCapabilitiesDefinitionsTable -------------------------------- 1. 2. ... N. This allows each product to enumerate a list of product specific capabiliti= es which are supported. These would be expected to be different from one v= endor to another, and possible from one product release to the next. This = would allow the products to evolve over time without requiring any changes = to the management interface (as long as there is no need to introduce new m= eta level attributes). would be any of a small number of simple data= types such as String or Integer or Float, or a product defined EnumeratedT= ypeID which could be discovered via a second table like the following: emanEnumeratedTypeTable ----------------------- 1. 2. ... M. This table enables the product to defined a set of EnumerationTypeIDs which= can be used in the emanCapabilitiesDefinitionsTable above as one of the Ca= pabilityTypeSpecifications. The actual values for each enumeration could b= e discovered as follows: emanEnumeratedValuesTable ------------------------- 1. + 2. | List of Values f= or ... | EnumerationID #1 I. + I+1. + I+2. | List of Values f= or ... | EnumerationID #2 I+J. + ... This table provides a product specific set of enumerated types which in tur= ns defines the possible values that can be assigned as the current state fo= r any of the corresponding capabilities. Strings, Integers, Floats, and En= umeratedTypes would provide a fairly rich set of management data which is t= uned to the specific capabilities of each managed element. The actual values for the current settings of each of these Capabilities wo= uld have to be obtained via Get/Set on yet another table along the lines of= : emanProductCapabilities ----------------------- 1. 2. ... N. Where each capability value is constrained to be within an appropriate doma= in based on the CapabilityType associated with the corresponding ProductSpe= cificCapabilityID. Now the thing that we loose with this is a fixed and well-defined set of se= mantics to go along with these product defined capabilities. It is up to t= he operator (or the logic coded into a given management application) to und= erstand the semantics of these settings for any given release of any given = product. I would argue that this is inevitable for any reasonably complex = piece of equipment. I would also argue that it is unrealistic to expect th= at we can devise some generic set of semantics which would be applicable to= a wide range of products anyway. Using the information from such tables a management application could "easi= ly" support a user interface to display the current state of each of the N = capabilities to a human operator. Similarly, any management application wh= ich seeks to exert operational control over these capabilities is required = to understand the semantics of each release of each product for it to imple= ment meaningful controls. In other words, either the operator or the logic= coded into the management application must be responsible for understandin= g the semantics of setting the values no matter what we do at the standard = level. I think that this in inevitable. For example, putting a desktop PC= to "sleep" has a meaningful set of semantics for a desktop PC whereas putt= ing a router or a hub to "sleep" has an entirely different set of product a= nd/or technology specific semantics for that equipment. At a sufficiently abstract level, yes we can say this means that the equipm= ent is in some "low level power saving state" but this level of a statement= is useless from a management perspective. Either the operator or the mana= gement applicable are still required to understand what putting a specific = piece of equipment to "sleep" means within the context of that piece of equ= ipment and its roles and responsibilities within the overall organizational= scheme. At this point I am only throwing this out for your consideration and discus= sion. We would still have to assess what this would mean within the contex= t of SNMP and the other IETF MIBs. Let me know if this is unclear as I wrote it up off the top of my head. I = will be happy to clarify anything that is unclear. I am curious if there i= s any support for moving things in this direction or whether the group feel= s that the complexity outweighs the benefits (at least as I see them). (See below for a simple concrete example.) Thanks, William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein As a simple concrete exercise, a product that only supported the single fix= ed enumerated set of states that are discussed above might choose to expose= the following: emanCapabilitiesDefinitionsTable -------------------------------- 1. CapabilityID#1 "PowerState" EnumerationID#1 emanEnumeratedTypeTable ----------------------- 1. EnumerationID#1 "PowerStateEnumeration" emanEnumeratedValuesTable ------------------------- 1. EnumerationID#1 ValueID#1 "Off" 2. EnumerationID#1 ValueID#2 "PowerSavings" 3. EnumerationID#3 ValueID#3 "HighPerformance" emanProductCapabilities ----------------------- 1. CapabilityID#1 ValueID#2 Here we are seeing a case where the product supports a single capability, P= owerState, which can be any of three possible values (i.e. Off, PowerSaving= s, and HighPerformance). In this example the current state is PowerSavings= . ________________________________ From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behal= f Of Bruce Nordman Sent: Tuesday, March 01, 2011 7:54 PM To: eman mailing list Subject: [eman] Power States - really I am reposting Juergen's email about power states. While the subsequent discussion has been important and useful, it is on a different topic. So, please let's also make progress on this topic. --Bruce On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: Dear all, We have two proposals for a Power/Energy MIB module: - draft-claise-energy-monitoring-mib-06 - draft-quittek-power-mib-02 Among the authors of both documents we are currently trying= to merge them. But there are some open issues that should be discussed on = the mailing list. Here is the probably biggest of them: modeling power= states. For simplifying energy management we want to introduce the = concept of power states (aka power levels). A power state will indica= te roughly how much power a device consumes. Examples for simple power st= ates are off, sleep, and operational states. In the envisioned EMAN MIB modules, a power state is charac= terized by a descriptive name and the device's expected power input in t= his state (max/min/average). Power states are not a new concept. The DMTF has already d= efined a set of power states and there is the Other standards bodies as the= DMTF (Distributed Management Task Force) and there is the ACPI = (Advanced Configuration and Power Interface) for PC motherboards. An= d there may be more than these out there. I listed some DMTF and ACPI sta= tes at the end of this message. An easy solution for EMAN would be just adopting one of the= se sets. However, there are issues with the ones we looked at. ACPI= was developed for PC motherboards and is quite PC-centric. Also it defin= es states that seem to be superfluous, because so far, almost no one has i= mplemented them. Also the DMTF model seems to have a narrower scope t= han envisioned by the EMAN WG. At some point in time, the EMAN WG hast to make a decision,= which power state model to adopt. Here is a set of alternatives. The f= irst four have fixed sets of power states. Option 1: fixed minimum Just support three power states (off, sleep (stand-by), ope= rational) This has clear semantics, but there are several people clai= ming it's too restrictive. Option 2: fixed DMTF Just use the states defined by DMTF. Might be too much focussed n PCs. Option 3: fixed ACPI Just use the states defined by ACPI. Might be too much focussed n PCs. Option 4: fixed EMAN Define a new fixed set of power levels within the EMAN WG. Option 5: IANA-registered power states Have power states be registered at IANA. We would start with registering (off, sleep, operational, t= he DMTF set, and the ACPI set. Manufacturers can then register further ones. There has been discussions pointing out that these fixed se= ts may not be sufficient, particularly if non-IT equipment should also be= covered. For being more open, the idea to support user-defined or manufacturer-defined power states of devices has been devel= oped. In such a state, for example, certain components of a device may be= switched off or put to sleep. Which ones are switched off in which stat= e is to be defined by the user/operator/manufacturer and may be chosen= such that operational needs are met. Again, there are several proposals how to do this. All of = them favor a two-level approach that distinguishes between rather flexib= le functional power states and rather fixed basic power states. Function= al power states would be defined by the manufacturer, operator, or user. T= hese would be the power states that would be reported by a device. Howev= er, in order to better define the semantics of functional power states, Eac= h of these would be mapped to exactly one basic power states. This me= ans that a property of any functional state would be the basic state i= t maps to. Basic power states would be fixed, such as the ones used in= options 1-5. An easy example would be functional power states defined by user/operator/manufacturer with each state indicating wheth= er it is an off state, a sleep state or an operational state. Here are the corresponding options: Option 6: flexible functional states mapped to a fixed set = of basic states States could be defined flexibly. But each state would ind= icate a basic state to which it corresponds. Basic states could be either= basic (off/sleep/operational) or the DMTF set or the ACPI set Option 7: flexible functional states mapped to a IANA regis= tered set of basic states This is like Option 6, but basic states would be registered= at IANA and can be extended. We would register all DMTF and ACPI state= s and probably some more at IANA. Manufacturers could add more. Option 8: IANA-registered sets of functional states, only t= hree basic states The main reasoning behind this option is that is should alw= ays be clear whether a power state is an off state, a sleep state, or an= operational state. Therefore, only these three basic states are suppor= ted. This would be in line with an instance of Option 6. However, th= is option has an extension for the functional states. It suggests that f= or customizing devices in order to be compliant with given management syst= ems, for example a DMTF-based system, it should be possible to restr= ict functional power states to a given set that is registered at IANA. An= example would be the DMTF states. We would register a flag at IANA that = indicates we are using DMTF states only. This would signal the manageme= nt application that all power state IDs are in line with power state numbe= ring as defined by IANA. Analogously, ACPI and further sets could be regis= tered at IANA. A fallback to Option 6 could be realized by registering a s= et number of 0 at IANA that does not impose any limit for functional state= s. Obviously, there are more possible options. If you think t= here is a better one, please send it to this list. I know this discussion is not easy, but we have to have it = in order to make the right decision in the EMAN WG. Please take some t= ime and think about what you consider to be the best way to go. And of c= ourse send questions on the issue. Thanks. Juergen DMTF (Distributed Management Task Force) power states: - 2 (Power On) - 3 (Sleep - Light) - 4 (Sleep - Deep) - 5 (Power Cycle (Off Soft)) - 6 (Power Off - Hard) - 7 (Hibernate) - 8 (Power Off - Soft) - 9 (Power Cycle (Off Hard)) - 10 (Master Bus Reset) - 11 (Diagnostic Interrupt (NMI)) - 12 (Power Off - Soft Graceful) - 13 (Power Off - Hard Graceful) - 14 (Master Bus Reset Graceful) - 15 (Power Cycle (Off - Soft Graceful)) - 16 (Power Cycle (Off - Hard Graceful)) ACPI (Advanced Configuration and Power Interface Specificat= ion) power states for PC motherboards: - G3-S5 (Off-Hard) - G2-S5 (Off-Soft) - G1-S4 (Hibernate) - G1-S3 (Sleep-Deep) - G1-S2 (Sleep-Light) - G1-S1 (Sleep-Light) - G0-S0-P5 - G0-S0-P4 - G0-S0-P3 - G0-S0-P2 - G0-S0-P2 - G0-S0-P2 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 From jparello@cisco.com Tue Mar 1 21:37:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B587E3A6B12 for ; Tue, 1 Mar 2011 21:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeGmd2uiSYoY for ; Tue, 1 Mar 2011 21:37:21 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5BDD03A694A for ; Tue, 1 Mar 2011 21:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=64830; q=dns/txt; s=iport; t=1299044306; x=1300253906; h=mime-version:subject:date:message-id:references:from:to; bh=6uvnRjpEdd21y+ASDZ5HDIRMCL37vObj75Mr3LXX+Sk=; b=XJQUBZoq1B9K6wshVDOQK23iu8SovkcqhP0QJXgILmWnNlHJNp6M2Ii7 qMkMRIwZ8pIAWglSuzlhLNkp71Oo9y6TcEFx0lLRzFSOQ61BGeLYwvmn1 vOs9wTwYiuubNz+ySwgC8CA97lswHO0mO9D2tuig9rybNaXAGWNldJxvc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAANBmbU2rR7H+/2dsb2JhbACYAI1nb3ShVJtnAoMWgkkEhReKVQ X-IronPort-AV: E=Sophos;i="4.62,251,1297036800"; d="scan'208,217";a="267705878" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2011 05:38:25 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p225cOjo006379; Wed, 2 Mar 2011 05:38:25 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 21:37:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD89B.F29A1BC5" Date: Tue, 1 Mar 2011 21:37:41 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power States - really Thread-Index: AcvYdGKsD4IHX7nnQcqwXOPGnYlzMQAC+/UAAAY9KIE= References: <0DEE3BCEE44BFD4EBC3B7DC009C8E79225070F7F4A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: "John Parello (jparello)" To: "Mielke, William F (Bill)" , "eman mailing list" X-OriginalArrivalTime: 02 Mar 2011 05:37:41.0598 (UTC) FILETIME=[F2D83FE0:01CBD89B] Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 05:37:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD89B.F29A1BC5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I like the idea of capabilities if they provide introspection on the = object/device in question. So I'd like to see that the capabilities are = discoverable from the device itself. Whether they are capabilities or states the point is to have a = management interface on the device itself, not left as an exercise for = the NMS' manufacturers. One problem faced over the years with building NMS' (and will be the = exasperated with EMS') is that the first thing you do in a presentation = is to show the different devices (table, list topology) then provide an = interface for commands. For example if one capability is to sleep you provide that action to the = user as a common polymorphoc command to every type of device that can do = it. Then the NMS has the daunting job of translating that to the = specific vendor capability for that model cross software version running = on the device. That needs to be discoverable by the NMS or a fixed set of interfaces. So the challenge is to stop this madness and have the device understand = there is an interface for management and let it encapsulate the details = of how to do it.=20 IMO this has been punted to the NMS' for so long it makes for unusable = management. With energy and the upcoming IoT, the number of touch points = will increase dramatically. If we are going to be managing the power of = heterogeneous devices let the interface to implementation abstraction = live on the device not reinvented in every NMS system. That way we have a universal way of managing power across devices. The main objection I've heard so far is will it be enough, how will you = know you have the right interface. Well running code and try it.=20 We propose a solution for that with a fixed interface based on shipping = products in an open community of manufacturers and E/NMS vendors. We now = total 44 different companies working with such a model. So it's not that = difficult to map to a simple interface. I'm not opposed to having capabilities or other interfaces listed but = they need to be discoverable. Jp Jp -----Original Message----- From: eman-bounces@ietf.org on behalf of Mielke, William F (Bill) Sent: Tue 3/1/2011 9:06 PM To: eman mailing list Subject: Re: [eman] Power States - really =20 The discussion of the past few days on the topic of power states has = been quite interesting and I am happy to see some discussion on this = important topic. I have some thoughts to throw into the mix that I wish = to share. These are more on the level of general insights than on the = level of a cooked proposal but I think that they may introduce some much = needed outside the box thinking here. The discussion thus far is focused on trying to pick a fixed set of = enumerated states which are intended to properly and reasonably abstract = all possible power savings capabilities which will be found in all = existing and future equipment to which this standard will be applied. = While this is a noble goal I fear that it is unrealistically optimistic = in its chances for success. Both the DMTF and the ACPI options are far = too PC-centric to be applicable to such a wide reaching goal. Indeed, = how well have these particular standards been adopted and implemented = even within that very narrow domain? I don't know the answer but I will = be surprised if the answer is that they are widely adopted, implemented, = and used as they were originally envisioned. If you have anything to = suggest otherwise please share it. So this leads me to the conclusion that even if we were successful in = achieving the goal of defining a single fixed set of enumerated states = that everyone here is happy with that the chances for the success of = such an approach are rather limited. Note that I am not trying to throw = water on the idea or efforts to make it happen, I am just trying to = assess the reality of the situation based on my own understanding of the = inherent complexities involved with large data and voice networking = equipment. As I pointed out in Beijing I think that the answer needs to be both = more flexible and more extensible if it is going to actually be useful. = Here are some of the reasons I believe this to be true: (1) We are discussing a widely disparate set of technologies which = consumer power in widely disparate ways and therefore they will have = widely disparate notions of how to actually provide meaningful features = for implementing the inherently technology specific trade-offs between = power savings and other key product characteristics in terms of things = like capacity, throughput, availability, latency and response times, = etc. (2) I expect that in all but the most trivial of products these power = savings "knobs" will be independently tunable, and they will need to be = set by each product owner so as to meet their specific business = requirements. (3) To think that each product vendor will be able to make a reasonable = mapping between N independently controlled features and a simple linear = progression of states seems like wishful thinking to me. "MAYBE" this = could be done from a read only reporting perspective, but it will never = work from a management and control perspective. I just don't believe = that the operational use cases for a multi-million dollar router or = switch will ever boil down to some operator telling their router to go = to "sleep" or to enter "power savings level 3". Now, if we are to pursue the definition of a single set of fixed = enumerated states then the level of abstraction needs to be exceedingly = high to be able to cover the breadth of equipment we envision. So I = would agree with Bruce that if this is the direction the number of = states needs to be absolutely high-level and generic which will also = serve to reduce the number of such states. So, for example, = HighPerformance/PowerSavings/Off is about the best that you could do. = But I question the usefulness of having a large router reporting that it = is in the PowerSavings state. Sure, you know that some feature = somewhere in the router is not running an maximum performance but that = is about all. It would be useless from a management perspective to tell = such a router to enter it's PowerSavings state. What would that = actually mean? What reasonable mapping could actually be done here? = And Off would not be useful from a reporting perspective because if it = was off how would it respond? Setting it to Off would be useful, I guess, but only in limited = circumstances because once it was Off how would you transition it back = to any of the other states? Whether we have 3 states or 5 or 50 it won't really matter because this = concept of a linear progression of states (e.g. from Off to PowerSavings = to HighPerformance) is not the abstraction we should actually be = pursuing IMHO. I think that a more useful abstraction would be one of modeling = independently controllable Capabilities. I would seek to let each = product enumerate its own set of such capabilities along with the type = of values that each capability could take on. By allowing the product = to enumerate a set of supported Capabilities each piece of equipment = could provide a meaningful set of options to the technicians or = management applications. As the product evolves from one release to the = next the list of supported Capabilities can grow and evolve over time = based on each vendors design choices and each product's inherent = technological constraints. So, without worrying about the SNMPisms involved (yet) this might only = require a couple of tables to enumerate the required meta-data. I am = thinking of something along the following lines: emanCapabilitiesDefinitionsTable -------------------------------- 1. = 2. = ... N. = This allows each product to enumerate a list of product specific = capabilities which are supported. These would be expected to be = different from one vendor to another, and possible from one product = release to the next. This would allow the products to evolve over time = without requiring any changes to the management interface (as long as = there is no need to introduce new meta level attributes). would be any of a small number of simple = data types such as String or Integer or Float, or a product defined = EnumeratedTypeID which could be discovered via a second table like the = following: emanEnumeratedTypeTable ----------------------- 1. 2. ... M. This table enables the product to defined a set of EnumerationTypeIDs = which can be used in the emanCapabilitiesDefinitionsTable above as one = of the CapabilityTypeSpecifications. The actual values for each = enumeration could be discovered as follows: emanEnumeratedValuesTable ------------------------- 1. + 2. | List of = Values for ... | EnumerationID = #1 I. + I+1. + I+2. | List of = Values for ... | EnumerationID = #2 I+J. + ... This table provides a product specific set of enumerated types which in = turns defines the possible values that can be assigned as the current = state for any of the corresponding capabilities. Strings, Integers, = Floats, and EnumeratedTypes would provide a fairly rich set of = management data which is tuned to the specific capabilities of each = managed element. The actual values for the current settings of each of these Capabilities = would have to be obtained via Get/Set on yet another table along the = lines of: emanProductCapabilities ----------------------- 1. 2. ... N. Where each capability value is constrained to be within an appropriate = domain based on the CapabilityType associated with the corresponding = ProductSpecificCapabilityID. Now the thing that we loose with this is a fixed and well-defined set of = semantics to go along with these product defined capabilities. It is up = to the operator (or the logic coded into a given management application) = to understand the semantics of these settings for any given release of = any given product. I would argue that this is inevitable for any = reasonably complex piece of equipment. I would also argue that it is = unrealistic to expect that we can devise some generic set of semantics = which would be applicable to a wide range of products anyway. Using the information from such tables a management application could = "easily" support a user interface to display the current state of each = of the N capabilities to a human operator. Similarly, any management = application which seeks to exert operational control over these = capabilities is required to understand the semantics of each release of = each product for it to implement meaningful controls. In other words, = either the operator or the logic coded into the management application = must be responsible for understanding the semantics of setting the = values no matter what we do at the standard level. I think that this in = inevitable. For example, putting a desktop PC to "sleep" has a = meaningful set of semantics for a desktop PC whereas putting a router or = a hub to "sleep" has an entirely different set of product and/or = technology specific semantics for that equipment. At a sufficiently abstract level, yes we can say this means that the = equipment is in some "low level power saving state" but this level of a = statement is useless from a management perspective. Either the operator = or the management applicable are still required to understand what = putting a specific piece of equipment to "sleep" means within the = context of that piece of equipment and its roles and responsibilities = within the overall organizational scheme. At this point I am only throwing this out for your consideration and = discussion. We would still have to assess what this would mean within = the context of SNMP and the other IETF MIBs. Let me know if this is unclear as I wrote it up off the top of my head. = I will be happy to clarify anything that is unclear. I am curious if = there is any support for moving things in this direction or whether the = group feels that the complexity outweighs the benefits (at least as I = see them). (See below for a simple concrete example.) Thanks, William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein As a simple concrete exercise, a product that only supported the single = fixed enumerated set of states that are discussed above might choose to = expose the following: emanCapabilitiesDefinitionsTable -------------------------------- 1. CapabilityID#1 "PowerState" EnumerationID#1 emanEnumeratedTypeTable ----------------------- 1. EnumerationID#1 "PowerStateEnumeration" emanEnumeratedValuesTable ------------------------- 1. EnumerationID#1 ValueID#1 "Off" 2. EnumerationID#1 ValueID#2 "PowerSavings" 3. EnumerationID#3 ValueID#3 "HighPerformance" emanProductCapabilities ----------------------- 1. CapabilityID#1 ValueID#2 Here we are seeing a case where the product supports a single = capability, PowerState, which can be any of three possible values (i.e. = Off, PowerSavings, and HighPerformance). In this example the current = state is PowerSavings. ________________________________ From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On = Behalf Of Bruce Nordman Sent: Tuesday, March 01, 2011 7:54 PM To: eman mailing list Subject: [eman] Power States - really I am reposting Juergen's email about power states. While the subsequent discussion has been important and useful, it is on a different topic. So, please let's also make progress on this topic. --Bruce On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek = wrote: Dear all, We have two proposals for a Power/Energy MIB module: - draft-claise-energy-monitoring-mib-06 - draft-quittek-power-mib-02 Among the authors of both documents we are currently = trying to merge them. But there are some open issues that should be discussed = on the mailing list. Here is the probably biggest of them: modeling = power states. For simplifying energy management we want to introduce = the concept of power states (aka power levels). A power state will = indicate roughly how much power a device consumes. Examples for simple power = states are off, sleep, and operational states. In the envisioned EMAN MIB modules, a power state is = characterized by a descriptive name and the device's expected power input = in this state (max/min/average). Power states are not a new concept. The DMTF has = already defined a set of power states and there is the Other standards bodies as = the DMTF (Distributed Management Task Force) and there is the = ACPI (Advanced Configuration and Power Interface) for PC motherboards. = And there may be more than these out there. I listed some DMTF and ACPI = states at the end of this message. An easy solution for EMAN would be just adopting one of = these sets. However, there are issues with the ones we looked at. = ACPI was developed for PC motherboards and is quite PC-centric. Also it = defines states that seem to be superfluous, because so far, almost no one = has implemented them. Also the DMTF model seems to have a narrower = scope than envisioned by the EMAN WG. At some point in time, the EMAN WG hast to make a = decision, which power state model to adopt. Here is a set of alternatives. = The first four have fixed sets of power states. Option 1: fixed minimum Just support three power states (off, sleep (stand-by), = operational) This has clear semantics, but there are several people = claiming it's too restrictive. Option 2: fixed DMTF Just use the states defined by DMTF. Might be too much focussed n PCs. Option 3: fixed ACPI Just use the states defined by ACPI. Might be too much focussed n PCs. Option 4: fixed EMAN Define a new fixed set of power levels within the EMAN = WG. Option 5: IANA-registered power states Have power states be registered at IANA. We would start with registering (off, sleep, = operational, the DMTF set, and the ACPI set. Manufacturers can then register further ones. There has been discussions pointing out that these fixed = sets may not be sufficient, particularly if non-IT equipment should also = be covered. For being more open, the idea to support user-defined or manufacturer-defined power states of devices has been = developed. In such a state, for example, certain components of a device may = be switched off or put to sleep. Which ones are switched off in which = state is to be defined by the user/operator/manufacturer and may be = chosen such that operational needs are met. Again, there are several proposals how to do this. All = of them favor a two-level approach that distinguishes between rather = flexible functional power states and rather fixed basic power states. = Functional power states would be defined by the manufacturer, operator, or user. = These would be the power states that would be reported by a device. = However, in order to better define the semantics of functional power states, = Each of these would be mapped to exactly one basic power states. This = means that a property of any functional state would be the basic = state it maps to. Basic power states would be fixed, such as the ones used = in options 1-5. An easy example would be functional power states defined = by user/operator/manufacturer with each state indicating = whether it is an off state, a sleep state or an operational state. Here are the corresponding options: Option 6: flexible functional states mapped to a fixed = set of basic states States could be defined flexibly. But each state would = indicate a basic state to which it corresponds. Basic states could be = either basic (off/sleep/operational) or the DMTF set or the ACPI set Option 7: flexible functional states mapped to a IANA = registered set of basic states This is like Option 6, but basic states would be = registered at IANA and can be extended. We would register all DMTF and ACPI = states and probably some more at IANA. Manufacturers could add more. Option 8: IANA-registered sets of functional states, = only three basic states The main reasoning behind this option is that is should = always be clear whether a power state is an off state, a sleep state, or = an operational state. Therefore, only these three basic states are = supported. This would be in line with an instance of Option 6. However, = this option has an extension for the functional states. It suggests = that for customizing devices in order to be compliant with given management = systems, for example a DMTF-based system, it should be possible to = restrict functional power states to a given set that is registered at IANA. = An example would be the DMTF states. We would register a flag at IANA = that indicates we are using DMTF states only. This would signal the = management application that all power state IDs are in line with power state = numbering as defined by IANA. Analogously, ACPI and further sets could be = registered at IANA. A fallback to Option 6 could be realized by registering = a set number of 0 at IANA that does not impose any limit for functional = states. Obviously, there are more possible options. If you = think there is a better one, please send it to this list. I know this discussion is not easy, but we have to have = it in order to make the right decision in the EMAN WG. Please take = some time and think about what you consider to be the best way to go. And = of course send questions on the issue. Thanks. Juergen DMTF (Distributed Management Task Force) power states: - 2 (Power On) - 3 (Sleep - Light) - 4 (Sleep - Deep) - 5 (Power Cycle (Off Soft)) - 6 (Power Off - Hard) - 7 (Hibernate) - 8 (Power Off - Soft) - 9 (Power Cycle (Off Hard)) - 10 (Master Bus Reset) - 11 (Diagnostic Interrupt (NMI)) - 12 (Power Off - Soft Graceful) - 13 (Power Off - Hard Graceful) - 14 (Master Bus Reset Graceful) - 15 (Power Cycle (Off - Soft Graceful)) - 16 (Power Cycle (Off - Hard Graceful)) ACPI (Advanced Configuration and Power Interface = Specification) power states for PC motherboards: - G3-S5 (Off-Hard) - G2-S5 (Off-Soft) - G1-S4 (Hibernate) - G1-S3 (Sleep-Deep) - G1-S2 (Sleep-Light) - G1-S1 (Sleep-Light) - G0-S0-P5 - G0-S0-P4 - G0-S0-P3 - G0-S0-P2 - G0-S0-P2 - G0-S0-P2 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman -- Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman ------_=_NextPart_001_01CBD89B.F29A1BC5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] Power States - really

I like the idea of capabilities if they provide = introspection on the object/device in question. So I'd like to see that = the capabilities are discoverable from the device itself.

Whether they are capabilities or states the point is to have a = management interface on the device itself, not left as an exercise for = the NMS' manufacturers.

One problem faced over the years with building NMS' (and will be the = exasperated with EMS') is that the first thing you do in a presentation = is to show the different devices (table, list topology) then provide an = interface for commands.

For example if one capability is to sleep you provide that action to the = user as a common polymorphoc command to every type of device that can do = it. Then the NMS has the daunting job of translating that to the = specific vendor capability for that model cross software version running = on the device.

That needs to be discoverable by the NMS or a fixed set of = interfaces.

So the challenge is to stop this madness and have the device understand = there is an interface for management and let it encapsulate the details = of how to do it.

IMO this has been punted to the NMS' for so long it makes for unusable = management. With energy and the upcoming IoT, the number of touch points = will increase dramatically. If we are going to be managing the power of = heterogeneous devices let the interface to  implementation = abstraction live on the device not reinvented in every NMS system.

That way we have a universal way of managing power across devices.

The main objection I've heard so far is will it be enough, how will you = know you have the right interface. Well running code and try it.

We propose a solution for that with a fixed interface based on shipping = products in an open community of manufacturers and E/NMS vendors. We now = total 44 different companies working with such a model. So it's not that = difficult to map to a simple interface.

I'm not opposed to having capabilities or other interfaces listed but = they need to be discoverable.
Jp




Jp



-----Original Message-----
From: eman-bounces@ietf.org on behalf of Mielke, William F (Bill)
Sent: Tue 3/1/2011 9:06 PM
To: eman mailing list
Subject: Re: [eman] Power States - really

The discussion of the past few days on the topic of power states has = been quite interesting and I am happy to see some discussion on this = important topic.  I have some thoughts to throw into the mix that I = wish to share.  These are more on the level of general insights = than on the level of a cooked proposal but I think that they may = introduce some much needed outside the box thinking here.

The discussion thus far is focused on trying to pick a fixed set of = enumerated states which are intended to properly and reasonably abstract = all possible power savings capabilities which will be found in all = existing and future equipment to which this standard will be = applied.  While this is a noble goal I fear that it is = unrealistically optimistic in its chances for success.  Both the = DMTF and the ACPI options are far too PC-centric to be applicable to = such a wide reaching goal.  Indeed, how well have these particular = standards been adopted and implemented even within that very narrow = domain?  I don't know the answer but I will be surprised if the = answer is that they are widely adopted, implemented, and used as they = were originally envisioned.  If you have anything to suggest = otherwise please share it.

So this leads me to the conclusion that even if we were successful in = achieving the goal of defining a single fixed set of enumerated states = that everyone here is happy with that the chances for the success of = such an approach are rather limited.  Note that I am not trying to = throw water on the idea or efforts to make it happen, I am just trying = to assess the reality of the situation based on my own understanding of = the inherent complexities involved with large data and voice networking = equipment.

As I pointed out in Beijing I think that the answer needs to be both = more flexible and more extensible if it is going to actually be = useful.  Here are some of the reasons I believe this to be = true:

(1) We are discussing a widely disparate set of technologies which = consumer power in widely disparate ways and therefore they will have = widely disparate notions of how to actually provide meaningful features = for implementing the inherently technology specific trade-offs between = power savings and other key product characteristics in terms of things = like capacity, throughput, availability, latency and response times, = etc.

(2) I expect that in all but the most trivial of products these power = savings "knobs" will be independently tunable, and they will = need to be set by each product owner so as to meet their specific = business requirements.

(3) To think that each product vendor will be able to make a reasonable = mapping between N independently controlled features and a simple linear = progression of states seems like wishful thinking to me.  = "MAYBE" this could be done from a read only reporting = perspective, but it will never work from a management and control = perspective.  I just don't believe that the operational use cases = for a multi-million dollar router or switch will ever boil down to some = operator telling their router to go to "sleep" or to enter = "power savings level 3".

Now, if we are to pursue the definition of a single set of fixed = enumerated states then the level of abstraction needs to be exceedingly = high to be able to cover the breadth of equipment we envision.  So = I would agree with Bruce that if this is the direction the number of = states needs to be absolutely high-level and generic which will also = serve to reduce the number of such states.  So, for example, = HighPerformance/PowerSavings/Off is about the best that you could = do.  But I question the usefulness of having a large router = reporting that it is in the PowerSavings state.  Sure, you know = that some feature somewhere in the router is not running an maximum = performance but that is about all.  It would be useless from a = management perspective to tell such a router to enter it's PowerSavings = state.  What would that actually mean?  What reasonable = mapping could actually be done here?  And Off would not be useful = from a reporting perspective because if it was off how would it = respond?
   Setting it to Off would be useful, I guess, but only in = limited circumstances because once it was Off how would you transition = it back to any of the other states?

Whether we have 3 states or 5 or 50 it won't really matter because this = concept of a linear progression of states (e.g. from Off to PowerSavings = to HighPerformance) is not the abstraction we should actually be = pursuing IMHO.

I think that a more useful abstraction would be one of modeling = independently controllable Capabilities.  I would seek to let each = product enumerate its own set of such capabilities along with the type = of values that each capability could take on.  By allowing the = product to enumerate a set of supported Capabilities each piece of = equipment could provide a meaningful set of options to the technicians = or management applications.  As the product evolves from one = release to the next the list of supported Capabilities can grow and = evolve over time based on each vendors design choices and each product's = inherent technological constraints.

So, without worrying about the SNMPisms involved (yet) this might only = require a couple of tables to enumerate the required meta-data.  I = am thinking of something along the following lines:

emanCapabilitiesDefinitionsTable
--------------------------------
1. <ProductSpecificCapabilityID #1> <CapabilityName #1> = <CapabilityTypeSpecification>
2. <ProductSpecificCapabilityID #2> <CapabilityName #2> = <CapabilityTypeSpecification>
...
N. <ProductSpecificCapabilityID #N> <CapabilityName #N> = <CapabilityTypeSpecification>

This allows each product to enumerate a list of product specific = capabilities which are supported.  These would be expected to be = different from one vendor to another, and possible from one product = release to the next.  This would allow the products to evolve over = time without requiring any changes to the management interface (as long = as there is no need to introduce new meta level attributes).

<CapabilityTypeSpecification> would be any of a small number of = simple data types such as String or Integer or Float, or a product = defined EnumeratedTypeID which could be discovered via a second table = like the following:

emanEnumeratedTypeTable
-----------------------
1. <EnumerationID #1> <EnumerationName #1>
2. <EnumerationID #2> <EnumerationName #2>
...
M. <EnumerationID #M> <EnumerationName #M>

This table enables the product to defined a set of EnumerationTypeIDs = which can be used in the emanCapabilitiesDefinitionsTable above as one = of the CapabilityTypeSpecifications.  The actual values for each = enumeration could be discovered as follows:

emanEnumeratedValuesTable
-------------------------
1. <EnumerationID #1> <ValueID #1> <ValueName = #1>        +
2. <EnumerationID #1> <ValueID #2> <ValueName = #2>        | List of Values = for
...           &nbs= p;            = ;            =             &= nbsp;     | EnumerationID #1
I. <EnumerationID #1> <ValueID #I> <ValueName = #I>        +
I+1. <EnumerationID #2> <ValueID #I+1> <ValueName = #I+1>  +
I+2. <EnumerationID #2> <ValueID #I+2> <ValueName = #I+2>  | List of Values for
...           &nbs= p;            = ;            =             &= nbsp;     | EnumerationID #2
I+J. <EnumerationID #2> <ValueID #I+J> <ValueName = #I+J>  +
...

This table provides a product specific set of enumerated types which in = turns defines the possible values that can be assigned as the current = state for any of the corresponding capabilities.  Strings, = Integers, Floats, and EnumeratedTypes would provide a fairly rich set of = management data which is tuned to the specific capabilities of each = managed element.

The actual values for the current settings of each of these Capabilities = would have to be obtained via Get/Set on yet another table along the = lines of:

emanProductCapabilities
-----------------------
1. <ProductSpecificCapabilityID #1> <CapabilityValue>
2. <ProductSpecificCapabilityID #2> <CapabilityValue>
...
N. <ProductSpecificCapabilityID #N> <CapabilityValue>

Where each capability value is constrained to be within an appropriate = domain based on the CapabilityType associated with the corresponding = ProductSpecificCapabilityID.

Now the thing that we loose with this is a fixed and well-defined set of = semantics to go along with these product defined capabilities.  It = is up to the operator (or the logic coded into a given management = application) to understand the semantics of these settings for any given = release of any given product.  I would argue that this is = inevitable for any reasonably complex piece of equipment.  I would = also argue that it is unrealistic to expect that we can devise some = generic set of semantics which would be applicable to a wide range of = products anyway.

Using the information from such tables a management application could = "easily" support a user interface to display the current state = of each of the N capabilities to a human operator.  Similarly, any = management application which seeks to exert operational control over = these capabilities is required to understand the semantics of each = release of each product for it to implement meaningful controls.  = In other words, either the operator or the logic coded into the = management application must be responsible for understanding the = semantics of setting the values no matter what we do at the standard = level.  I think that this in inevitable.  For example, putting = a desktop PC to "sleep" has a meaningful set of semantics for = a desktop PC whereas putting a router or a hub to "sleep" has = an entirely different set of product and/or technology specific = semantics for that equipment.

At a sufficiently abstract level, yes we can say this means that the = equipment is in some "low level power saving state" but this = level of a statement is useless from a management perspective.  = Either the operator or the management applicable are still required to = understand what putting a specific piece of equipment to = "sleep" means within the context of that piece of equipment = and its roles and responsibilities within the overall organizational = scheme.

At this point I am only throwing this out for your consideration and = discussion.  We would still have to assess what this would mean = within the context of SNMP and the other IETF MIBs.

Let me know if this is unclear as I wrote it up off the top of my = head.  I will be happy to clarify anything that is unclear.  I = am curious if there is any support for moving things in this direction = or whether the group feels that the complexity outweighs the benefits = (at least as I see them).

(See below for a simple concrete example.)

Thanks,

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com <mailto:mielke@alcatel-lucent.co= m>
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein


As a simple concrete exercise, a product that only supported the single = fixed enumerated set of states that are discussed above might choose to = expose the following:

emanCapabilitiesDefinitionsTable
--------------------------------
1. CapabilityID#1 "PowerState" EnumerationID#1

emanEnumeratedTypeTable
-----------------------
1. EnumerationID#1 "PowerStateEnumeration"

emanEnumeratedValuesTable
-------------------------
1. EnumerationID#1 ValueID#1 "Off"
2. EnumerationID#1 ValueID#2 "PowerSavings"
3. EnumerationID#3 ValueID#3 "HighPerformance"

emanProductCapabilities
-----------------------
1. CapabilityID#1 ValueID#2

Here we are seeing a case where the product supports a single = capability, PowerState, which can be any of three possible values (i.e. = Off, PowerSavings, and HighPerformance).  In this example the = current state is PowerSavings.


________________________________

        From: eman-bounces@ietf.org = [mailto:eman-bounces@ietf.org] = On Behalf Of Bruce Nordman
        Sent: Tuesday, March 01, 2011 = 7:54 PM
        To: eman mailing list
        Subject: [eman] Power States = - really


        I am reposting Juergen's = email about power states.
        While the subsequent = discussion has been important
        and useful, it is on a = different topic.  So, please let's
        also make progress on this = topic.
        --Bruce


        On Mon, Feb 28, 2011 at 4:07 = AM, Juergen Quittek <Quittek@neclab.eu> wrote:


            &= nbsp;   Dear all,

            &= nbsp;   We have two proposals for a Power/Energy MIB = module:

            &= nbsp;    - draft-claise-energy-monitoring-mib-06
            &= nbsp;    - draft-quittek-power-mib-02

            &= nbsp;   Among the authors of both documents we are currently = trying to merge them.
            &= nbsp;   But there are some open issues that should be = discussed on the mailing
            &= nbsp;   list.  Here is the probably biggest of them: = modeling power states.

            &= nbsp;   For simplifying energy management we want to introduce = the concept of
            &= nbsp;   power states (aka power levels).  A power state = will indicate roughly how
            &= nbsp;   much power a device consumes.  Examples for = simple power states are off,
            &= nbsp;   sleep, and operational states.

            &= nbsp;   In the envisioned EMAN MIB modules, a power state is = characterized by a
            &= nbsp;   descriptive name and the device's expected power input = in this state
            &= nbsp;   (max/min/average).

            &= nbsp;   Power states are not a new concept.  The DMTF has = already defined a set of
            &= nbsp;   power states and there is the Other standards bodies = as the DMTF
            &= nbsp;   (Distributed Management Task Force) and there  is = the ACPI (Advanced
            &= nbsp;   Configuration and Power Interface) for PC = motherboards.  And there may be
            &= nbsp;   more than these out there.  I listed some DMTF = and ACPI states at the end
            &= nbsp;   of this message.

            &= nbsp;   An easy solution for EMAN would be just adopting one = of these sets.
            &= nbsp;   However, there are issues with the ones we looked = at.  ACPI was developed
            &= nbsp;   for PC motherboards and is quite PC-centric.  = Also it defines states that
            &= nbsp;   seem to be superfluous, because so far, almost no one = has implemented
            &= nbsp;   them.  Also the DMTF model seems to have a = narrower scope than envisioned
            &= nbsp;   by the EMAN WG.

            &= nbsp;   At some point in time, the EMAN WG hast to make a = decision, which power
            &= nbsp;   state model to adopt.  Here is a set of = alternatives. The first four have
            &= nbsp;   fixed sets of power states.

            &= nbsp;   Option 1: fixed minimum
            &= nbsp;   Just support three power states (off, sleep = (stand-by), operational)
            &= nbsp;   This has clear semantics, but there are several people = claiming it's too
            &= nbsp;   restrictive.

            &= nbsp;   Option 2: fixed DMTF
            &= nbsp;   Just use the states defined by DMTF.
            &= nbsp;   Might be too much focussed n PCs.

            &= nbsp;   Option 3: fixed ACPI
            &= nbsp;   Just use the states defined by ACPI.
            &= nbsp;   Might be too much focussed n PCs.



            &= nbsp;   Option 4: fixed EMAN
            &= nbsp;   Define a new fixed set of power levels within the EMAN = WG.

            &= nbsp;   Option 5: IANA-registered power states
            &= nbsp;   Have power states be registered at IANA.
            &= nbsp;   We would start with registering (off, sleep, = operational, the DMTF set,
            &= nbsp;   and the ACPI set.
            &= nbsp;   Manufacturers can then register further ones.


            &= nbsp;   There has been discussions pointing out that these = fixed sets may not be
            &= nbsp;   sufficient, particularly if non-IT equipment should = also be covered.

            &= nbsp;   For being more open, the idea to support user-defined = or
            &= nbsp;   manufacturer-defined power states of devices has been = developed.  In such
            &= nbsp;   a state, for example, certain components of a device = may be switched off
            &= nbsp;   or put to sleep.  Which ones are switched off in = which state is to be
            &= nbsp;   defined by the user/operator/manufacturer and may be = chosen such that
            &= nbsp;   operational needs are met.

            &= nbsp;   Again, there are several proposals how to do = this.  All of them favor a
            &= nbsp;   two-level approach that distinguishes between rather = flexible functional
            &= nbsp;   power states and rather fixed basic power = states.  Functional power states
            &= nbsp;   would be defined by the manufacturer, operator, or = user.  These would be
            &= nbsp;   the power states that would be reported by a = device.  However, in order to
            &= nbsp;   better define the semantics of functional power = states, Each of these
            &= nbsp;   would be mapped to exactly one basic power = states.  This means that a
            &= nbsp;   property of any functional state would be the basic = state it maps to.
            &= nbsp;   Basic power states would be fixed, such as the ones = used in options 1-5.
            &= nbsp;   An easy example would be functional power states = defined by
            &= nbsp;   user/operator/manufacturer with each state indicating = whether it is an off
            &= nbsp;   state, a sleep state or an operational state.

            &= nbsp;   Here are the corresponding options:

            &= nbsp;   Option 6: flexible functional states mapped to a fixed = set of basic states
            &= nbsp;   States could be defined flexibly.  But each state = would indicate a basic
            &= nbsp;   state to which it corresponds. Basic states could be = either basic
            &= nbsp;   (off/sleep/operational) or the DMTF set or the ACPI = set

            &= nbsp;   Option 7: flexible functional states mapped to a IANA = registered set of
            &= nbsp;   basic states
            &= nbsp;   This is like Option 6, but basic states would be = registered at IANA and
            &= nbsp;   can be extended.  We would register all DMTF and = ACPI states and probably
            &= nbsp;   some more at IANA. Manufacturers could add more.

            &= nbsp;   Option 8: IANA-registered sets of functional states, = only three basic
            &= nbsp;   states
            &= nbsp;   The main reasoning behind this option is that is = should always be clear
            &= nbsp;   whether a power state is an off state, a sleep state, = or an operational
            &= nbsp;   state.  Therefore, only these three basic states = are supported.  This
            &= nbsp;   would be in line with an instance of Option 6.  = However, this option has
            &= nbsp;   an extension for the functional states.  It = suggests that for customizing
            &= nbsp;   devices in order to be compliant with given management = systems, for
            &= nbsp;   example a DMTF-based system, it should be possible to = restrict functional
            &= nbsp;   power states to a given set that is registered at = IANA.  An example would
            &= nbsp;   be the DMTF states.  We would register a flag at = IANA that indicates we
            &= nbsp;   are using DMTF states only.  This would signal = the management application
            &= nbsp;   that all power state IDs are in line with power state = numbering as defined
            &= nbsp;   by IANA.  Analogously, ACPI and further sets = could be registered at IANA.
            &= nbsp;   A fallback to Option 6 could be realized by = registering a set number of 0
            &= nbsp;   at IANA that does not impose any limit for functional = states.

            &= nbsp;   Obviously, there are more possible options.  If = you think there is a
            &= nbsp;   better one, please send it to this list.

            &= nbsp;   I know this discussion is not easy, but we have to = have it in order to
            &= nbsp;   make the right decision in the EMAN WG.  Please = take some time and think
            &= nbsp;   about what you consider to be the best way to = go.  And of course send
            &= nbsp;   questions on the issue.

            &= nbsp;   Thanks.

            &= nbsp;      Juergen


            &= nbsp;   DMTF (Distributed Management Task Force) power = states:
            &= nbsp;    - 2 (Power On)
            &= nbsp;    - 3 (Sleep - Light)
            &= nbsp;    - 4 (Sleep - Deep)
            &= nbsp;    - 5 (Power Cycle (Off Soft))
            &= nbsp;    - 6 (Power Off - Hard)
            &= nbsp;    - 7 (Hibernate)
            &= nbsp;    - 8 (Power Off - Soft)
            &= nbsp;    - 9 (Power Cycle (Off Hard))
            &= nbsp;    - 10 (Master Bus Reset)
            &= nbsp;    - 11 (Diagnostic Interrupt (NMI))
            &= nbsp;    - 12 (Power Off - Soft Graceful)
            &= nbsp;    - 13 (Power Off - Hard Graceful)
            &= nbsp;    - 14 (Master Bus Reset Graceful)
            &= nbsp;    - 15 (Power Cycle (Off - Soft Graceful))
            &= nbsp;    - 16 (Power Cycle (Off - Hard Graceful))

            &= nbsp;   ACPI (Advanced Configuration and Power Interface = Specification) power
            &= nbsp;   states for PC motherboards:
            &= nbsp;    - G3-S5 (Off-Hard)
            &= nbsp;    - G2-S5 (Off-Soft)
            &= nbsp;    - G1-S4 (Hibernate)
            &= nbsp;    - G1-S3 (Sleep-Deep)
            &= nbsp;    - G1-S2 (Sleep-Light)
            &= nbsp;    - G1-S1 (Sleep-Light)
            &= nbsp;    - G0-S0-P5
            &= nbsp;    - G0-S0-P4
            &= nbsp;    - G0-S0-P3
            &= nbsp;    - G0-S0-P2
            &= nbsp;    - G0-S0-P2
            &= nbsp;    - G0-S0-P2




            &= nbsp;   _______________________________________________
            &= nbsp;   eman mailing list
            &= nbsp;   eman@ietf.org
            &= nbsp;   https://www.ietf.org/= mailman/listinfo/eman





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



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

------_=_NextPart_001_01CBD89B.F29A1BC5-- From bill.mielke@alcatel-lucent.com Tue Mar 1 21:50:35 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5313A6A49 for ; Tue, 1 Mar 2011 21:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JWIeIRgQjdN for ; Tue, 1 Mar 2011 21:50:34 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 02E1E3A67D2 for ; Tue, 1 Mar 2011 21:50:33 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p225pbbx001178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Mar 2011 23:51:37 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p225paPN000783 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Mar 2011 23:51:37 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 1 Mar 2011 23:51:37 -0600 From: "Mielke, William F (Bill)" To: Bruce Nordman , eman mailing list Date: Tue, 1 Mar 2011 23:51:34 -0600 Thread-Topic: [eman] Power States - really Thread-Index: AcvYgtUEd7yTnI+vQwqJwK7g0cwzrwAFhP9g Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E79225070F7F4D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 05:50:36 -0000 # Bruce Nordman wrote: # # I think several of the points he makes bear emphasis. # One is the distinction between (basic) power states, # and functionality differences within such states. # It is tempting to want to put all of this onto one linear # scale of states, and sometimes that works. However, # many functionalities are essentially not on the same # dimension as the basic power state one, so do not # well match to it. An example is battery charging, which # can occur in on, sleep, or off. =20 I think that this is an argument that mirrors my own to some level for the = need to support an approach that goes beyond a single linear list of states= . Your battery charging example is a good one, actually, as it would appear t= o be a pure read only state without any control aspects to it. Does this i= mply there are actually two general types of power states? One that is for= monitoring only and one that is used to effect controls (e.g. like setting= something to the "Sleep" state)? I think that there is an important nuanc= e here that needs to be better understood and teased out. # Another point is that going beyond a few basic states # inevitably makes the list specific to narrow groups of # products and/or to specific implementations, and so # is not universal. Agreed. To be universal the level of abstraction needs to be raised so hig= h that the result is useless from a management perspective. IMHO, of cours= e. I think you are also recognizing the point that I was making that the mappi= ng from these states to implementation semantics is both technology and ven= dor aligned. I don't think that we can define a large number of states tha= t will have some universal applicability. # For DMTF, this is a mixture of power states, and=20 # transition states and/or commands, so I think not a # good source when we are just talking about power # states. # For ACPI, my understanding is that in practice, S1 # and S2 are not used, so the number of actual # states is fewer than appears. # I do think that there may be a fourth basic state # of "Ready", which would apply more to appliances # than to electronic devices. As I said in my previous email I don't think that either the DMTF or the AC= PI sets are suitable to our purpose. So from my perspective if we go the r= oute of a single fixed linear set, then I too favor Option 1 from Juergen's= list. I am not pushing for any specific set of states just that they be d= efined at a high level of abstraction so something like a ready state would= be OK if we take this route. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com =20 Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein=20 From tirth.ghose@gmail.com Wed Mar 2 00:38:42 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEFA3A6A89 for ; Wed, 2 Mar 2011 00:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eblv4B5b4aly for ; Wed, 2 Mar 2011 00:38:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B65D83A6A32 for ; Wed, 2 Mar 2011 00:38:37 -0800 (PST) Received: by iwl42 with SMTP id 42so5542909iwl.31 for ; Wed, 02 Mar 2011 00:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NSW5wO28kgaMseKCYrGpoC9BR1zHgbMwlQ3xEOVGe/s=; b=JmKKohwx5QUtlVYdL6qdzapUM7D/Lvw/kIQsh6g9VLLhCE+dvvRuVrireMwF2X5N9b 5ppWqdS0/bFTGlcEjYLNreagjXJkZdUSHeui9z4WuIdDW27Oxy6GFie+jQZdcTrFsulS A/hQmgQ0D62+iiIXtb0NCb8zavRjgMY0bPbs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=IW755D1cuagVkn/NYDXVFE5CZRWiyn+HMdtN8bNKPV4mpz6ZqISpAEfSEHV7gVlcy1 QWU2DIqWxc5xsdrySVylyuGG0BmDY4aq9lGvtbVpLetrauvWPYBpkEgq1rfi+AOEDZdf QUPaaXYpJ4hMshacB9NkUtNUpAfGT04MH6vmA= MIME-Version: 1.0 Received: by 10.231.11.77 with SMTP id s13mr7312411ibs.18.1299055182774; Wed, 02 Mar 2011 00:39:42 -0800 (PST) Sender: tirth.ghose@gmail.com Received: by 10.231.156.141 with HTTP; Wed, 2 Mar 2011 00:39:42 -0800 (PST) In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E79225070F7F4A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <0DEE3BCEE44BFD4EBC3B7DC009C8E79225070F7F4A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Date: Wed, 2 Mar 2011 00:39:42 -0800 X-Google-Sender-Auth: XsyOr5zz8QtImhS9BsNMHQxxFdU Message-ID: From: Ted Ghose To: "Mielke, William F (Bill)" Content-Type: multipart/alternative; boundary=00221538fcb2b69d61049d7bdad9 Cc: eman mailing list Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 08:38:42 -0000 --00221538fcb2b69d61049d7bdad9 Content-Type: text/plain; charset=ISO-8859-1 I'm dismayed that you failed to define a fine set of rule, and without that you are putting your model forward. the elegant this model is, I fail to to understand what are the rule does it stick to. Coming from a pure mathematics world, I'd like to define the "set" before "set operations" If we fail to define the rule, i totally agree with you that "the chances for the success of such an approach are rather limited" Are we not putting the cart before the horse? thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Tue, Mar 1, 2011 at 9:06 PM, Mielke, William F (Bill) < bill.mielke@alcatel-lucent.com> wrote: > The discussion of the past few days on the topic of power states has been > quite interesting and I am happy to see some discussion on this important > topic. I have some thoughts to throw into the mix that I wish to share. > These are more on the level of general insights than on the level of a > cooked proposal but I think that they may introduce some much needed outside > the box thinking here. > > The discussion thus far is focused on trying to pick a fixed set of > enumerated states which are intended to properly and reasonably abstract all > possible power savings capabilities which will be found in all existing and > future equipment to which this standard will be applied. While this is a > noble goal I fear that it is unrealistically optimistic in its chances for > success. Both the DMTF and the ACPI options are far too PC-centric to be > applicable to such a wide reaching goal. Indeed, how well have these > particular standards been adopted and implemented even within that very > narrow domain? I don't know the answer but I will be surprised if the > answer is that they are widely adopted, implemented, and used as they were > originally envisioned. If you have anything to suggest otherwise please > share it. > > So this leads me to the conclusion that even if we were successful in > achieving the goal of defining a single fixed set of enumerated states that > everyone here is happy with that the chances for the success of such an > approach are rather limited. Note that I am not trying to throw water on > the idea or efforts to make it happen, I am just trying to assess the > reality of the situation based on my own understanding of the inherent > complexities involved with large data and voice networking equipment. > > As I pointed out in Beijing I think that the answer needs to be both more > flexible and more extensible if it is going to actually be useful. Here are > some of the reasons I believe this to be true: > > (1) We are discussing a widely disparate set of technologies which consumer > power in widely disparate ways and therefore they will have widely disparate > notions of how to actually provide meaningful features for implementing the > inherently technology specific trade-offs between power savings and other > key product characteristics in terms of things like capacity, throughput, > availability, latency and response times, etc. > > (2) I expect that in all but the most trivial of products these power > savings "knobs" will be independently tunable, and they will need to be set > by each product owner so as to meet their specific business requirements. > > (3) To think that each product vendor will be able to make a reasonable > mapping between N independently controlled features and a simple linear > progression of states seems like wishful thinking to me. "MAYBE" this could > be done from a read only reporting perspective, but it will never work from > a management and control perspective. I just don't believe that the > operational use cases for a multi-million dollar router or switch will ever > boil down to some operator telling their router to go to "sleep" or to enter > "power savings level 3". > > Now, if we are to pursue the definition of a single set of fixed enumerated > states then the level of abstraction needs to be exceedingly high to be able > to cover the breadth of equipment we envision. So I would agree with Bruce > that if this is the direction the number of states needs to be absolutely > high-level and generic which will also serve to reduce the number of such > states. So, for example, HighPerformance/PowerSavings/Off is about the best > that you could do. But I question the usefulness of having a large router > reporting that it is in the PowerSavings state. Sure, you know that some > feature somewhere in the router is not running an maximum performance but > that is about all. It would be useless from a management perspective to > tell such a router to enter it's PowerSavings state. What would that > actually mean? What reasonable mapping could actually be done here? And > Off would not be useful from a reporting perspective because if it was off > how would it respond? > Setting it to Off would be useful, I guess, but only in limited > circumstances because once it was Off how would you transition it back to > any of the other states? > > Whether we have 3 states or 5 or 50 it won't really matter because this > concept of a linear progression of states (e.g. from Off to PowerSavings to > HighPerformance) is not the abstraction we should actually be pursuing IMHO. > > I think that a more useful abstraction would be one of modeling > independently controllable Capabilities. I would seek to let each product > enumerate its own set of such capabilities along with the type of values > that each capability could take on. By allowing the product to enumerate a > set of supported Capabilities each piece of equipment could provide a > meaningful set of options to the technicians or management applications. As > the product evolves from one release to the next the list of supported > Capabilities can grow and evolve over time based on each vendors design > choices and each product's inherent technological constraints. > > So, without worrying about the SNMPisms involved (yet) this might only > require a couple of tables to enumerate the required meta-data. I am > thinking of something along the following lines: > > emanCapabilitiesDefinitionsTable > -------------------------------- > 1. > > 2. > > ... > N. > > > This allows each product to enumerate a list of product specific > capabilities which are supported. These would be expected to be different > from one vendor to another, and possible from one product release to the > next. This would allow the products to evolve over time without requiring > any changes to the management interface (as long as there is no need to > introduce new meta level attributes). > > would be any of a small number of simple data > types such as String or Integer or Float, or a product defined > EnumeratedTypeID which could be discovered via a second table like the > following: > > emanEnumeratedTypeTable > ----------------------- > 1. > 2. > ... > M. > > This table enables the product to defined a set of EnumerationTypeIDs which > can be used in the emanCapabilitiesDefinitionsTable above as one of the > CapabilityTypeSpecifications. The actual values for each enumeration could > be discovered as follows: > > emanEnumeratedValuesTable > ------------------------- > 1. + > 2. | List of Values > for > ... | EnumerationID #1 > I. + > I+1. + > I+2. | List of Values > for > ... | EnumerationID #2 > I+J. + > ... > > This table provides a product specific set of enumerated types which in > turns defines the possible values that can be assigned as the current state > for any of the corresponding capabilities. Strings, Integers, Floats, and > EnumeratedTypes would provide a fairly rich set of management data which is > tuned to the specific capabilities of each managed element. > > The actual values for the current settings of each of these Capabilities > would have to be obtained via Get/Set on yet another table along the lines > of: > > emanProductCapabilities > ----------------------- > 1. > 2. > ... > N. > > Where each capability value is constrained to be within an appropriate > domain based on the CapabilityType associated with the corresponding > ProductSpecificCapabilityID. > > Now the thing that we loose with this is a fixed and well-defined set of > semantics to go along with these product defined capabilities. It is up to > the operator (or the logic coded into a given management application) to > understand the semantics of these settings for any given release of any > given product. I would argue that this is inevitable for any reasonably > complex piece of equipment. I would also argue that it is unrealistic to > expect that we can devise some generic set of semantics which would be > applicable to a wide range of products anyway. > > Using the information from such tables a management application could > "easily" support a user interface to display the current state of each of > the N capabilities to a human operator. Similarly, any management > application which seeks to exert operational control over these capabilities > is required to understand the semantics of each release of each product for > it to implement meaningful controls. In other words, either the operator or > the logic coded into the management application must be responsible for > understanding the semantics of setting the values no matter what we do at > the standard level. I think that this in inevitable. For example, putting > a desktop PC to "sleep" has a meaningful set of semantics for a desktop PC > whereas putting a router or a hub to "sleep" has an entirely different set > of product and/or technology specific semantics for that equipment. > > At a sufficiently abstract level, yes we can say this means that the > equipment is in some "low level power saving state" but this level of a > statement is useless from a management perspective. Either the operator or > the management applicable are still required to understand what putting a > specific piece of equipment to "sleep" means within the context of that > piece of equipment and its roles and responsibilities within the overall > organizational scheme. > > At this point I am only throwing this out for your consideration and > discussion. We would still have to assess what this would mean within the > context of SNMP and the other IETF MIBs. > > Let me know if this is unclear as I wrote it up off the top of my head. I > will be happy to clarify anything that is unclear. I am curious if there is > any support for moving things in this direction or whether the group feels > that the complexity outweighs the benefits (at least as I see them). > > (See below for a simple concrete example.) > > Thanks, > > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 > > "Live like you're going to die tomorrow. > Learn like you're going to live forever." > > - Albert Einstein > > > As a simple concrete exercise, a product that only supported the single > fixed enumerated set of states that are discussed above might choose to > expose the following: > > emanCapabilitiesDefinitionsTable > -------------------------------- > 1. CapabilityID#1 "PowerState" EnumerationID#1 > > emanEnumeratedTypeTable > ----------------------- > 1. EnumerationID#1 "PowerStateEnumeration" > > emanEnumeratedValuesTable > ------------------------- > 1. EnumerationID#1 ValueID#1 "Off" > 2. EnumerationID#1 ValueID#2 "PowerSavings" > 3. EnumerationID#3 ValueID#3 "HighPerformance" > > emanProductCapabilities > ----------------------- > 1. CapabilityID#1 ValueID#2 > > Here we are seeing a case where the product supports a single capability, > PowerState, which can be any of three possible values (i.e. Off, > PowerSavings, and HighPerformance). In this example the current state is > PowerSavings. > > > ________________________________ > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On > Behalf Of Bruce Nordman > Sent: Tuesday, March 01, 2011 7:54 PM > To: eman mailing list > Subject: [eman] Power States - really > > > I am reposting Juergen's email about power states. > While the subsequent discussion has been important > and useful, it is on a different topic. So, please let's > also make progress on this topic. > --Bruce > > > On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek > wrote: > > > Dear all, > > We have two proposals for a Power/Energy MIB module: > > - draft-claise-energy-monitoring-mib-06 > - draft-quittek-power-mib-02 > > Among the authors of both documents we are currently trying > to merge them. > But there are some open issues that should be discussed on > the mailing > list. Here is the probably biggest of them: modeling power > states. > > For simplifying energy management we want to introduce the > concept of > power states (aka power levels). A power state will > indicate roughly how > much power a device consumes. Examples for simple power > states are off, > sleep, and operational states. > > In the envisioned EMAN MIB modules, a power state is > characterized by a > descriptive name and the device's expected power input in > this state > (max/min/average). > > Power states are not a new concept. The DMTF has already > defined a set of > power states and there is the Other standards bodies as the > DMTF > (Distributed Management Task Force) and there is the ACPI > (Advanced > Configuration and Power Interface) for PC motherboards. And > there may be > more than these out there. I listed some DMTF and ACPI > states at the end > of this message. > > An easy solution for EMAN would be just adopting one of > these sets. > However, there are issues with the ones we looked at. ACPI > was developed > for PC motherboards and is quite PC-centric. Also it > defines states that > seem to be superfluous, because so far, almost no one has > implemented > them. Also the DMTF model seems to have a narrower scope > than envisioned > by the EMAN WG. > > At some point in time, the EMAN WG hast to make a decision, > which power > state model to adopt. Here is a set of alternatives. The > first four have > fixed sets of power states. > > Option 1: fixed minimum > Just support three power states (off, sleep (stand-by), > operational) > This has clear semantics, but there are several people > claiming it's too > restrictive. > > Option 2: fixed DMTF > Just use the states defined by DMTF. > Might be too much focussed n PCs. > > Option 3: fixed ACPI > Just use the states defined by ACPI. > Might be too much focussed n PCs. > > > > Option 4: fixed EMAN > Define a new fixed set of power levels within the EMAN WG. > > Option 5: IANA-registered power states > Have power states be registered at IANA. > We would start with registering (off, sleep, operational, > the DMTF set, > and the ACPI set. > Manufacturers can then register further ones. > > > There has been discussions pointing out that these fixed > sets may not be > sufficient, particularly if non-IT equipment should also be > covered. > > For being more open, the idea to support user-defined or > manufacturer-defined power states of devices has been > developed. In such > a state, for example, certain components of a device may be > switched off > or put to sleep. Which ones are switched off in which state > is to be > defined by the user/operator/manufacturer and may be chosen > such that > operational needs are met. > > Again, there are several proposals how to do this. All of > them favor a > two-level approach that distinguishes between rather > flexible functional > power states and rather fixed basic power states. > Functional power states > would be defined by the manufacturer, operator, or user. > These would be > the power states that would be reported by a device. > However, in order to > better define the semantics of functional power states, Each > of these > would be mapped to exactly one basic power states. This > means that a > property of any functional state would be the basic state it > maps to. > Basic power states would be fixed, such as the ones used in > options 1-5. > An easy example would be functional power states defined by > user/operator/manufacturer with each state indicating > whether it is an off > state, a sleep state or an operational state. > > Here are the corresponding options: > > Option 6: flexible functional states mapped to a fixed set > of basic states > States could be defined flexibly. But each state would > indicate a basic > state to which it corresponds. Basic states could be either > basic > (off/sleep/operational) or the DMTF set or the ACPI set > > Option 7: flexible functional states mapped to a IANA > registered set of > basic states > This is like Option 6, but basic states would be registered > at IANA and > can be extended. We would register all DMTF and ACPI states > and probably > some more at IANA. Manufacturers could add more. > > Option 8: IANA-registered sets of functional states, only > three basic > states > The main reasoning behind this option is that is should > always be clear > whether a power state is an off state, a sleep state, or an > operational > state. Therefore, only these three basic states are > supported. This > would be in line with an instance of Option 6. However, > this option has > an extension for the functional states. It suggests that > for customizing > devices in order to be compliant with given management > systems, for > example a DMTF-based system, it should be possible to > restrict functional > power states to a given set that is registered at IANA. An > example would > be the DMTF states. We would register a flag at IANA that > indicates we > are using DMTF states only. This would signal the > management application > that all power state IDs are in line with power state > numbering as defined > by IANA. Analogously, ACPI and further sets could be > registered at IANA. > A fallback to Option 6 could be realized by registering a > set number of 0 > at IANA that does not impose any limit for functional > states. > > Obviously, there are more possible options. If you think > there is a > better one, please send it to this list. > > I know this discussion is not easy, but we have to have it > in order to > make the right decision in the EMAN WG. Please take some > time and think > about what you consider to be the best way to go. And of > course send > questions on the issue. > > Thanks. > > Juergen > > > DMTF (Distributed Management Task Force) power states: > - 2 (Power On) > - 3 (Sleep - Light) > - 4 (Sleep - Deep) > - 5 (Power Cycle (Off Soft)) > - 6 (Power Off - Hard) > - 7 (Hibernate) > - 8 (Power Off - Soft) > - 9 (Power Cycle (Off Hard)) > - 10 (Master Bus Reset) > - 11 (Diagnostic Interrupt (NMI)) > - 12 (Power Off - Soft Graceful) > - 13 (Power Off - Hard Graceful) > - 14 (Master Bus Reset Graceful) > - 15 (Power Cycle (Off - Soft Graceful)) > - 16 (Power Cycle (Off - Hard Graceful)) > > ACPI (Advanced Configuration and Power Interface > Specification) power > states for PC motherboards: > - G3-S5 (Off-Hard) > - G2-S5 (Off-Soft) > - G1-S4 (Hibernate) > - G1-S3 (Sleep-Deep) > - G1-S2 (Sleep-Light) > - G1-S1 (Sleep-Light) > - G0-S0-P5 > - G0-S0-P4 > - G0-S0-P3 > - G0-S0-P2 > - G0-S0-P2 > - G0-S0-P2 > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > > > > > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --00221538fcb2b69d61049d7bdad9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm dismayed that you failed to define a fine set of rule, and without = that you are=A0putting=A0your model=A0forward.

the elega= nt this model is, I fail to to understand what are the rule does it stick t= o.=A0Coming=A0from a pure mathematics world, I'd like to define the &qu= ot;set" before "set operations"

If we fail to define the rule, i totally=A0agree=A0with= you that "the chances fo= r the success of such an approach are rather limited"=A0

Are we not putting the cart before the horse?

thanks

-tg-
*:-.,_,.-:*&= #39;``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:= -.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time... see it my way
*:= -.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-= .,_,.-:**:-.,_,.


On Tue, Mar 1, 2011 at 9:06 PM, Mielke, = William F (Bill) <bill.mielke@alcatel-lucent.com> wrote:
The discussion of the past few days on the topic of power states has been q= uite interesting and I am happy to see some discussion on this important to= pic. =A0I have some thoughts to throw into the mix that I wish to share. = =A0These are more on the level of general insights than on the level of a c= ooked proposal but I think that they may introduce some much needed outside= the box thinking here.

The discussion thus far is focused on trying to pick a fixed set of enumera= ted states which are intended to properly and reasonably abstract all possi= ble power savings capabilities which will be found in all existing and futu= re equipment to which this standard will be applied. =A0While this is a nob= le goal I fear that it is unrealistically optimistic in its chances for suc= cess. =A0Both the DMTF and the ACPI options are far too PC-centric to be ap= plicable to such a wide reaching goal. =A0Indeed, how well have these parti= cular standards been adopted and implemented even within that very narrow d= omain? =A0I don't know the answer but I will be surprised if the answer= is that they are widely adopted, implemented, and used as they were origin= ally envisioned. =A0If you have anything to suggest otherwise please share = it.

So this leads me to the conclusion that even if we were successful in achie= ving the goal of defining a single fixed set of enumerated states that ever= yone here is happy with that the chances for the success of such an approac= h are rather limited. =A0Note that I am not trying to throw water on the id= ea or efforts to make it happen, I am just trying to assess the reality of = the situation based on my own understanding of the inherent complexities in= volved with large data and voice networking equipment.

As I pointed out in Beijing I think that the answer needs to be both more f= lexible and more extensible if it is going to actually be useful. =A0Here a= re some of the reasons I believe this to be true:

(1) We are discussing a widely disparate set of technologies which consumer= power in widely disparate ways and therefore they will have widely dispara= te notions of how to actually provide meaningful features for implementing = the inherently technology specific trade-offs between power savings and oth= er key product characteristics in terms of things like capacity, throughput= , availability, latency and response times, etc.

(2) I expect that in all but the most trivial of products these power savin= gs "knobs" will be independently tunable, and they will need to b= e set by each product owner so as to meet their specific business requireme= nts.

(3) To think that each product vendor will be able to make a reasonable map= ping between N independently controlled features and a simple linear progre= ssion of states seems like wishful thinking to me. =A0"MAYBE" thi= s could be done from a read only reporting perspective, but it will never w= ork from a management and control perspective. =A0I just don't believe = that the operational use cases for a multi-million dollar router or switch = will ever boil down to some operator telling their router to go to "sl= eep" or to enter "power savings level 3".

Now, if we are to pursue the definition of a single set of fixed enumerated= states then the level of abstraction needs to be exceedingly high to be ab= le to cover the breadth of equipment we envision. =A0So I would agree with = Bruce that if this is the direction the number of states needs to be absolu= tely high-level and generic which will also serve to reduce the number of s= uch states. =A0So, for example, HighPerformance/PowerSavings/Off is about t= he best that you could do. =A0But I question the usefulness of having a lar= ge router reporting that it is in the PowerSavings state. =A0Sure, you know= that some feature somewhere in the router is not running an maximum perfor= mance but that is about all. =A0It would be useless from a management persp= ective to tell such a router to enter it's PowerSavings state. =A0What = would that actually mean? =A0What reasonable mapping could actually be done= here? =A0And Off would not be useful from a reporting perspective because = if it was off how would it respond?
=A0 Setting it to Off would be useful, I guess, but only in limited circum= stances because once it was Off how would you transition it back to any of = the other states?

Whether we have 3 states or 5 or 50 it won't really matter because this= concept of a linear progression of states (e.g. from Off to PowerSavings t= o HighPerformance) is not the abstraction we should actually be pursuing IM= HO.

I think that a more useful abstraction would be one of modeling independent= ly controllable Capabilities. =A0I would seek to let each product enumerate= its own set of such capabilities along with the type of values that each c= apability could take on. =A0By allowing the product to enumerate a set of s= upported Capabilities each piece of equipment could provide a meaningful se= t of options to the technicians or management applications. =A0As the produ= ct evolves from one release to the next the list of supported Capabilities = can grow and evolve over time based on each vendors design choices and each= product's inherent technological constraints.

So, without worrying about the SNMPisms involved (yet) this might only requ= ire a couple of tables to enumerate the required meta-data. =A0I am thinkin= g of something along the following lines:

emanCapabilitiesDefinitionsTable
--------------------------------
1. <ProductSpecificCapabilityID #1> <CapabilityName #1> <Cap= abilityTypeSpecification>
2. <ProductSpecificCapabilityID #2> <CapabilityName #2> <Cap= abilityTypeSpecification>
...
N. <ProductSpecificCapabilityID #N> <CapabilityName #N> <Cap= abilityTypeSpecification>

This allows each product to enumerate a list of product specific capabiliti= es which are supported. =A0These would be expected to be different from one= vendor to another, and possible from one product release to the next. =A0T= his would allow the products to evolve over time without requiring any chan= ges to the management interface (as long as there is no need to introduce n= ew meta level attributes).

<CapabilityTypeSpecification> would be any of a small number of simpl= e data types such as String or Integer or Float, or a product defined Enume= ratedTypeID which could be discovered via a second table like the following= :

emanEnumeratedTypeTable
-----------------------
1. <EnumerationID #1> <EnumerationName #1>
2. <EnumerationID #2> <EnumerationName #2>
...
M. <EnumerationID #M> <EnumerationName #M>

This table enables the product to defined a set of EnumerationTypeIDs which= can be used in the emanCapabilitiesDefinitionsTable above as one of the Ca= pabilityTypeSpecifications. =A0The actual values for each enumeration could= be discovered as follows:

emanEnumeratedValuesTable
-------------------------
1. <EnumerationID #1> <ValueID #1> <ValueName #1> =A0 =A0= =A0 =A0+
2. <EnumerationID #1> <ValueID #2> <ValueName #2> =A0 =A0= =A0 =A0| List of Values for
... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| EnumerationID #1
I. <EnumerationID #1> <ValueID #I> <ValueName #I> =A0 =A0= =A0 =A0+
I+1. <EnumerationID #2> <ValueID #I+1> <ValueName #I+1> = =A0+
I+2. <EnumerationID #2> <ValueID #I+2> <ValueName #I+2> = =A0| List of Values for
... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| EnumerationID #2
I+J. <EnumerationID #2> <ValueID #I+J> <ValueName #I+J> = =A0+
...

This table provides a product specific set of enumerated types which in tur= ns defines the possible values that can be assigned as the current state fo= r any of the corresponding capabilities. =A0Strings, Integers, Floats, and = EnumeratedTypes would provide a fairly rich set of management data which is= tuned to the specific capabilities of each managed element.

The actual values for the current settings of each of these Capabilities wo= uld have to be obtained via Get/Set on yet another table along the lines of= :

emanProductCapabilities
-----------------------
1. <ProductSpecificCapabilityID #1> <CapabilityValue>
2. <ProductSpecificCapabilityID #2> <CapabilityValue>
...
N. <ProductSpecificCapabilityID #N> <CapabilityValue>

Where each capability value is constrained to be within an appropriate doma= in based on the CapabilityType associated with the corresponding ProductSpe= cificCapabilityID.

Now the thing that we loose with this is a fixed and well-defined set of se= mantics to go along with these product defined capabilities. =A0It is up to= the operator (or the logic coded into a given management application) to u= nderstand the semantics of these settings for any given release of any give= n product. =A0I would argue that this is inevitable for any reasonably comp= lex piece of equipment. =A0I would also argue that it is unrealistic to exp= ect that we can devise some generic set of semantics which would be applica= ble to a wide range of products anyway.

Using the information from such tables a management application could "= ;easily" support a user interface to display the current state of each= of the N capabilities to a human operator. =A0Similarly, any management ap= plication which seeks to exert operational control over these capabilities = is required to understand the semantics of each release of each product for= it to implement meaningful controls. =A0In other words, either the operato= r or the logic coded into the management application must be responsible fo= r understanding the semantics of setting the values no matter what we do at= the standard level. =A0I think that this in inevitable. =A0For example, pu= tting a desktop PC to "sleep" has a meaningful set of semantics f= or a desktop PC whereas putting a router or a hub to "sleep" has = an entirely different set of product and/or technology specific semantics f= or that equipment.

At a sufficiently abstract level, yes we can say this means that the equipm= ent is in some "low level power saving state" but this level of a= statement is useless from a management perspective. =A0Either the operator= or the management applicable are still required to understand what putting= a specific piece of equipment to "sleep" means within the contex= t of that piece of equipment and its roles and responsibilities within the = overall organizational scheme.

At this point I am only throwing this out for your consideration and discus= sion. =A0We would still have to assess what this would mean within the cont= ext of SNMP and the other IETF MIBs.

Let me know if this is unclear as I wrote it up off the top of my head. =A0= I will be happy to clarify anything that is unclear. =A0I am curious if the= re is any support for moving things in this direction or whether the group = feels that the complexity outweighs the benefits (at least as I see them).<= br>
(See below for a simple concrete example.)

Thanks,

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH =A043213-1530
Email: Bill.Mielke@alcate= l-lucent.com <mailto:mi= elke@alcatel-lucent.com>
Phone: 614 367 5628
Fax: 614 367 5965

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

=A0 =A0- Albert Einstein


As a simple concrete exercise, a product that only supported the single fix= ed enumerated set of states that are discussed above might choose to expose= the following:

emanCapabilitiesDefinitionsTable
--------------------------------
1. CapabilityID#1 "PowerState" EnumerationID#1

emanEnumeratedTypeTable
-----------------------
1. EnumerationID#1 "PowerStateEnumeration"

emanEnumeratedValuesTable
-------------------------
1. EnumerationID#1 ValueID#1 "Off"
2. EnumerationID#1 ValueID#2 "PowerSavings"
3. EnumerationID#3 ValueID#3 "HighPerformance"

emanProductCapabilities
-----------------------
1. CapabilityID#1 ValueID#2

Here we are seeing a case where the product supports a single capability, P= owerState, which can be any of three possible values (i.e. Off, PowerSaving= s, and HighPerformance). =A0In this example the current state is PowerSavin= gs.


________________________________

=A0 =A0 =A0 =A0From: eman-bounces= @ietf.org [mailto:eman-bounces= @ietf.org] On Behalf Of Bruce Nordman
=A0 =A0 =A0 =A0Sent: Tuesday, March 01, 2011 7:54 PM
=A0 =A0 =A0 =A0To: eman mailing list
=A0 =A0 =A0 =A0Subject: [eman] Power States - really


=A0 =A0 =A0 =A0I am reposting Juer= gen's email about power states.
=A0 =A0 =A0 =A0While the subsequent discussion has been important
=A0 =A0 =A0 =A0and useful, it is on a different topic. =A0So, please let&#= 39;s
=A0 =A0 =A0 =A0also make progress on this topic.
=A0 =A0 =A0 =A0--Bruce


=A0 =A0 =A0 =A0On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek <Quittek@neclab.eu> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dear all,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0We have two proposals for a Power/Energy MI= B module:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - draft-claise-energy-monitoring-mib-06 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - draft-quittek-power-mib-02

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Among the authors of both documents we are = currently trying to merge them.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0But there are some open issues that should = be discussed on the mailing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0list. =A0Here is the probably biggest of th= em: modeling power states.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0For simplifying energy management we want t= o introduce the concept of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power states (aka power levels). =A0A power= state will indicate roughly how
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0much power a device consumes. =A0Examples f= or simple power states are off,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sleep, and operational states.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In the envisioned EMAN MIB modules, a power= state is characterized by a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0descriptive name and the device's expec= ted power input in this state
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(max/min/average).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Power states are not a new concept. =A0The = DMTF has already defined a set of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power states and there is the Other standar= ds bodies as the DMTF
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Distributed Management Task Force) and the= re =A0is the ACPI (Advanced
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Configuration and Power Interface) for PC m= otherboards. =A0And there may be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0more than these out there. =A0I listed some= DMTF and ACPI states at the end
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of this message.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0An easy solution for EMAN would be just ado= pting one of these sets.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0However, there are issues with the ones we = looked at. =A0ACPI was developed
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for PC motherboards and is quite PC-centric= . =A0Also it defines states that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0seem to be superfluous, because so far, alm= ost no one has implemented
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0them. =A0Also the DMTF model seems to have = a narrower scope than envisioned
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0by the EMAN WG.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0At some point in time, the EMAN WG hast to = make a decision, which power
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state model to adopt. =A0Here is a set of a= lternatives. The first four have
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fixed sets of power states.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Option 1: fixed minimum
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Just support three power states (off, sleep= (stand-by), operational)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This has clear semantics, but there are sev= eral people claiming it's too
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0restrictive.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Option 2: fixed DMTF
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Just use the states defined by DMTF.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Might be too much focussed n PCs.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Option 3: fixed ACPI
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Just use the states defined by ACPI.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Might be too much focussed n PCs.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Option 4: fixed EMAN
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Define a new fixed set of power levels with= in the EMAN WG.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Option 5: IANA-registered power states
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Have power states be registered at IANA. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0We would start with registering (off, sleep= , operational, the DMTF set,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and the ACPI set.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Manufacturers can then register further one= s.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0There has been discussions pointing out tha= t these fixed sets may not be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sufficient, particularly if non-IT equipmen= t should also be covered.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0For being more open, the idea to support us= er-defined or
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0manufacturer-defined power states of device= s has been developed. =A0In such
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a state, for example, certain components of= a device may be switched off
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or put to sleep. =A0Which ones are switched= off in which state is to be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0defined by the user/operator/manufacturer a= nd may be chosen such that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0operational needs are met.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Again, there are several proposals how to d= o this. =A0All of them favor a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0two-level approach that distinguishes betwe= en rather flexible functional
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power states and rather fixed basic power s= tates. =A0Functional power states
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0would be defined by the manufacturer, opera= tor, or user. =A0These would be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the power states that would be reported by = a device. =A0However, in order to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0better define the semantics of functional p= ower states, Each of these
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0would be mapped to exactly one basic power = states. =A0This means that a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0property of any functional state would be t= he basic state it maps to.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Basic power states would be fixed, such as = the ones used in options 1-5.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0An easy example would be functional power s= tates defined by
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0user/operator/manufacturer with each state = indicating whether it is an off
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state, a sleep state or an operational stat= e.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Here are the corresponding options:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Option 6: flexible functional states mapped= to a fixed set of basic states
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0States could be defined flexibly. =A0But ea= ch state would indicate a basic
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state to which it corresponds. Basic states= could be either basic
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(off/sleep/operational) or the DMTF set or = the ACPI set

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Option 7: flexible functional states mapped= to a IANA registered set of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0basic states
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This is like Option 6, but basic states wou= ld be registered at IANA and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0can be extended. =A0We would register all D= MTF and ACPI states and probably
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some more at IANA. Manufacturers could add = more.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Option 8: IANA-registered sets of functiona= l states, only three basic
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0states
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The main reasoning behind this option is th= at is should always be clear
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0whether a power state is an off state, a sl= eep state, or an operational
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state. =A0Therefore, only these three basic= states are supported. =A0This
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0would be in line with an instance of Option= 6. =A0However, this option has
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0an extension for the functional states. =A0= It suggests that for customizing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0devices in order to be compliant with given= management systems, for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0example a DMTF-based system, it should be p= ossible to restrict functional
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power states to a given set that is registe= red at IANA. =A0An example would
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be the DMTF states. =A0We would register a = flag at IANA that indicates we
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are using DMTF states only. =A0This would s= ignal the management application
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that all power state IDs are in line with p= ower state numbering as defined
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0by IANA. =A0Analogously, ACPI and further s= ets could be registered at IANA.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A fallback to Option 6 could be realized by= registering a set number of 0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at IANA that does not impose any limit for = functional states.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Obviously, there are more possible options.= =A0If you think there is a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0better one, please send it to this list.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I know this discussion is not easy, but we = have to have it in order to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0make the right decision in the EMAN WG. =A0= Please take some time and think
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0about what you consider to be the best way = to go. =A0And of course send
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0questions on the issue.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Juergen


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DMTF (Distributed Management Task Force) po= wer states:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 2 (Power On)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 3 (Sleep - Light)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 4 (Sleep - Deep)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 5 (Power Cycle (Off Soft))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 6 (Power Off - Hard)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 7 (Hibernate)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 8 (Power Off - Soft)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 9 (Power Cycle (Off Hard))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 10 (Master Bus Reset)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 11 (Diagnostic Interrupt (NMI))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 12 (Power Off - Soft Graceful)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 13 (Power Off - Hard Graceful)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 14 (Master Bus Reset Graceful)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 15 (Power Cycle (Off - Soft Graceful)) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - 16 (Power Cycle (Off - Hard Graceful))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ACPI (Advanced Configuration and Power Inte= rface Specification) power
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0states for PC motherboards:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G3-S5 (Off-Hard)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G2-S5 (Off-Soft)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G1-S4 (Hibernate)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G1-S3 (Sleep-Deep)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G1-S2 (Sleep-Light)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G1-S1 (Sleep-Light)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G0-S0-P5
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G0-S0-P4
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G0-S0-P3
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G0-S0-P2
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G0-S0-P2
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - G0-S0-P2




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________________________= ____
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0eman mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0eman@ietf.= org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/eman





=A0 =A0 =A0 =A0--
=A0 =A0 =A0 =A0Bruce Nordman
=A0 =A0 =A0 =A0Lawrence Berkeley National Laboratory
=A0 =A0 =A0 =A0eetd.lbl.gov/ea/nordman
=A0 =A0 =A0 =A0BNordman@LBL.gov
=A0 =A0 =A0 =A0510-486-7089
=A0 =A0 =A0 =A0m: 510-501-7943



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

--00221538fcb2b69d61049d7bdad9-- From dromasca@avaya.com Wed Mar 2 02:41:50 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278283A679C for ; Wed, 2 Mar 2011 02:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urPAWziIY2Eh for ; Wed, 2 Mar 2011 02:41:49 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 187663A6778 for ; Wed, 2 Mar 2011 02:41:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBAAOubU3GmAcF/2dsb2JhbACYAT+OF3SjYAKZLoVhBJAA X-IronPort-AV: E=Sophos;i="4.62,252,1297054800"; d="scan'208";a="234810454" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Mar 2011 05:42:39 -0500 X-IronPort-AV: E=Sophos;i="4.62,252,1297054800"; d="scan'208";a="588790366" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Mar 2011 05:42:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 11:42:14 +0100 Message-ID: In-Reply-To: <20110301223012.GB21719@cslinux-build01.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvYYD5AbQ0WovJzRyOn1D8UUZhidgAZSrtQ References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> From: "Romascanu, Dan (Dan)" To: Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 10:41:50 -0000 =20 > -----Original Message----- > From: chrisv@cyberswitching.com [mailto:chrisv@cyberswitching.com]=20 > Sent: Wednesday, March 02, 2011 12:30 AM > To: Romascanu, Dan (Dan) > Cc: eman mailing list; Juergen Quittek; Juergen Schoenwaelder > Subject: Re: [eman] modeling power states >=20 > On Tue, Mar 01, 2011 at 05:23:11PM +0100, Romascanu, Dan (Dan) wrote: > > How is this problem different from the one of managing a stack or=20 > > cluster of physical devices? Ethernet switch vendors have done this=20 > > for a decade and more. You just define entries for the=20 > Outlet Gangs #1=20 > > and > > #2 also in the entPhysical table, use the=20 > entPhysicalContainsTable to=20 > > define the containment relations with Outlet #1-4 and map them=20 > > one-to-one to the entries in the entLogicalTable. >=20 > Hi Dan, >=20 > I'm going to assume that my follow up to this was covered in=20 > the previous reply. While the scenario that I've described=20 > talks about this in terms of Outlet Gangs (because that's=20 > what I know), you could apply the same question to that of a=20 > VMware ESXi server running multiple Windows and Linux VMs. =20 > If an agent wanted to expose the VMware ESXi server's power=20 > consumption and allocate power to each VM, how would that=20 > structure work in relation to ENTITY-MIB? >=20 > +--------------------+ > | VMware server | > | | > | +--------------+ | > | | Windows VM 1 | | > | +--------------+ | > | | > | +--------------+ | > | | Windows VM 2 | | > | +--------------+ | > | | > | +--------------+ | > | | Linux VM | | > | +--------------+ | > | | > | +--------------+ | > | | Solaris VM | | > | +--------------+ | > | | > +--------------------+ >=20 > Would there be 5 entities listed in entPhysicalTable, one for=20 This looks indeed like a different application. The VMs are logical entities, the server is a physical entity. They can be modeled easily with the entity MIB and the mapping table provides you the picture of what runs where. However I may be missing something in the discussion because I do not understand what 'allocate power to each VM' means.=20 Dan From bclaise@cisco.com Wed Mar 2 03:31:46 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCBD3A67A7 for ; Wed, 2 Mar 2011 03:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaR723G5ZI9q for ; Wed, 2 Mar 2011 03:31:44 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 67DC03A6AC4 for ; Wed, 2 Mar 2011 03:31:44 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22BT4g3013902; Wed, 2 Mar 2011 12:29:04 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22BT3HN007474; Wed, 2 Mar 2011 12:29:04 +0100 (CET) Message-ID: <4D6E29FF.9090505@cisco.com> Date: Wed, 02 Mar 2011 12:29:03 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christian Groves References: <4CD0C9EB.7080103@nteczone.com> In-Reply-To: <4CD0C9EB.7080103@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman@ietf.org Subject: Re: [eman] Introduction; past comments X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 11:31:46 -0000 Hi Christian, [reviewing old EMAN emails] How do you see an overlap between the ITU-T SG5 activities and the EMAN activities? Regards, Benoit. > Hello Bruce, > > Thanks for the introduction. > > Your comment on other SDOs and the charter actually made me have a > good read of the EMAN charter. It mentions a list of SDOs whose work > may be applicable: IEC, ANSI, DTMF etc. However it doesn't mention > ITU-T Study Group 5"electromagnetic compatibility and electromagnetic > effects" > . > This group was formed from two study groups, one looking at > electro-magnetic issues and one looking at indoor and outdoor plant. > My understanding is that operators are well represented in this group. > It may be beneficial for both SG5 and the EMAN WG to exchange > information. > > Regards, Christian > > On 2/11/2010 5:49 PM, Bruce Nordman wrote: >> Greetings-- >> >> As incoming co-chair of eman, I look forward to meeting many of you >> next week in Beijing. I bring an energy-centric background to the >> process, >> which I believe will be a useful complement to more usual IETF >> participants. >> I have been on the edge of several IETF meetings, but this will be my >> first >> actual attendance. You can learn more about my interests from my web >> page >> (below). >> For our working group, I have no interest in expanding our charter. >> I am however >> interested in follow-on activities that may make sense within the IETF >> as well as in >> other standards organizations, for how we network the physical world >> (I call this >> "building networks" for devices that use energy or that influence it). >> I look forward >> to discussions on this outside our WG meeting. >> In the interest of transparency and completeness, below are some >> comments on >> several of the Internet Drafts as they were a few weeks ago, before >> recent revisions. >> These are offered as an individual participant, not in my role as >> co-chair. I am not >> seeking to start email discussions with these comments. >> Pleasant travels, >> >> --Bruce >> > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From pgrosset@cisco.com Wed Mar 2 03:46:40 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B663A6C36 for ; Wed, 2 Mar 2011 03:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6NszgNby6CV for ; Wed, 2 Mar 2011 03:46:39 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 772C23A6AE3 for ; Wed, 2 Mar 2011 03:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgrosset@cisco.com; l=8216; q=dns/txt; s=iport; t=1299066465; x=1300276065; h=date:from:to:message-id:in-reply-to:subject:mime-version; bh=Vn64qU571+AeWaB2WJjgHay72QH1jaAuPWVENPrE5bA=; b=b1uqYFzMtq4inZBQM1tTX+Ka/J3lsogVtmXmb2LzjL1t040jOHJjHSVf KOPsueFhGQtHOUB+iM+hhfZ0yhwAcUH4y5RFImOOqAk0fmzDb9Ut+6Sdv WnT9wi+F2rO4kV5Bd6k01dH9ZoveE1sP+u7CKOrqNuQovgq46vdXhXR1m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8KAHq9bU2rRN+J/2dsb2JhbAAXgjeBWqIvdJRPjGiLCpBkhGt2BI9s X-IronPort-AV: E=Sophos;i="4.62,252,1297036800"; d="scan'208,217";a="267888735" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2011 11:47:45 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p22BljvN006134 for ; Wed, 2 Mar 2011 11:47:45 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 03:47:44 -0800 Received: from localhost ([10.89.12.222]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 03:47:44 -0800 Date: Wed, 2 Mar 2011 12:47:49 +0100 (CET) From: Patrick Grossetete To: eman@ietf.org, bclaise@cisco.com Message-ID: <2444768.36.1299066465634.JavaMail.pgrosset@pgrosset-mac.local> In-Reply-To: <4D6E2C4F.5030705@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_35_23254862.1299066465633" X-OriginalArrivalTime: 02 Mar 2011 11:47:44.0231 (UTC) FILETIME=[A4A52F70:01CBD8CF] X-Mailman-Approved-At: Wed, 02 Mar 2011 04:11:07 -0800 Subject: [eman] draft-ietf-eman-requirements-00 review X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 11:47:50 -0000 ------=_Part_35_23254862.1299066465633 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Benoit, Please, find my comments regarding draft-ietf-eman-requirements-00. I wrote them while reading the doc, so there is no priority order. Best Regards Patrick - page 4-5, it should be added that environmental conditions may also impact the potential reduction of power consumption. There is often a link between temperature/RH and power...for example, see ASHRAE specifications for DataCenter (PUE and DCIE metrics). It may also be noticed that side effects may occur. For example, I have seen people increasing the temperature in their datacenter to comply with PUE metric but in fact getting fan speed increase on their servers and leading to false conclusion of metrics since the power consumption was seen as "good" for PUE computation. Clearly, the capability to monitor energy consumption of servers would have indicated that. - page 5, monitoring energy consumption can also help to check compliancy with mandates/regulations/recommendations such as ASHRAE or NTIA - page 6, I would have split this category as "servers and hosts" already implement some power consumption metrics such as IPMI on servers, and new generation CPU offers different power state level . Section 2 is incomplete if we don't introduce in the scenario, services such as Demand/Response and Load Shedding which may apply to different 2.x sections - page 8, section 2.7 - obviously not mentioning ASHRAE recommendations (PUE/DCIE) is not acknowledging industry standards for energy monitoring in datacenters. - page 9, section 3.2 - aggregation of energy data is really what helps facility managers to understand where they could save money. in fact, there would be a need to discuss how aggregation can be done. It could be as simple as monitoring all physical distribution circuits but could also be aggregated by categories such as engineering/sales/marketing departments or heating/cooling/IT/lights,... To fully understand the consumption, you also need to define the "aggregation point" to consider what is counted downstream and upstream. For example, data retrieved on a server or router will be a portion of data retrieved on a smart plug connecting all these devices which will be a portion of data retrieved at a smart circuit breaker level, and so on. - page 11, section 3.4.2, you could also indicate: line frequency, power factor, apparent power, reactive power,... as metrics being available on certain category of devices. - page 12, section 3.4.4, you may want to compare with existing MIB such as UPS vendor's MIBs ------=_Part_35_23254862.1299066465633 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Benoit,

Please, find my comments regarding draft-ietf-eman-requirements-00. I wrote them while reading the doc, so there is no priority order.

Best Regards
Patrick
 

- page 4-5, it should be added that environmental conditions may also impact the potential reduction of power consumption. There is often a link between
temperature/RH and power...for example, see ASHRAE specifications for DataCenter (PUE and DCIE metrics). It may also be noticed that side effects may occur.
For example, I have seen people increasing the temperature in their datacenter to comply with PUE metric but in fact getting fan speed increase on their servers
and leading to false conclusion of metrics since the power consumption was seen as "good" for PUE computation. Clearly, the capability to monitor
energy consumption of servers would have indicated that.

- page 5, monitoring energy consumption can also help to check compliancy with mandates/regulations/recommendations such as ASHRAE or NTIA

- page 6, I would have split this category as "servers and hosts" already implement some power consumption metrics such as IPMI on servers,
and new generation CPU offers different power state level .
Section 2 is incomplete if we don't introduce in the scenario, services such as Demand/Response and Load Shedding which may apply to different 2.x sections

- page 8, section 2.7 - obviously not mentioning ASHRAE recommendations (PUE/DCIE) is not acknowledging industry standards for energy monitoring
in datacenters.

- page 9, section 3.2 - aggregation of energy data is really what helps facility managers to understand where they could save money.
in fact, there would be a need to discuss how aggregation can be done. It could be as simple as monitoring all physical distribution circuits
but could also be aggregated by categories such as engineering/sales/marketing departments or heating/cooling/IT/lights,...
To fully understand the consumption, you also need to define the "aggregation point" to consider what is counted downstream and upstream.
For example, data retrieved on a server or router will be a portion of data retrieved on a smart plug connecting all these devices which will be a portion
of data retrieved at a smart circuit breaker level, and so on.

- page 11, section 3.4.2, you could also indicate: line frequency, power factor, apparent power, reactive power,... as metrics being available on certain
category of devices.

- page 12, section 3.4.4, you may want to compare with existing MIB such as UPS vendor's MIBs

------=_Part_35_23254862.1299066465633-- From bclaise@cisco.com Wed Mar 2 07:36:51 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8223A6817 for ; Wed, 2 Mar 2011 07:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TozPqaxqpMHO for ; Wed, 2 Mar 2011 07:36:49 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 740723A6812 for ; Wed, 2 Mar 2011 07:36:49 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22FboSM006643; Wed, 2 Mar 2011 16:37:50 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22FbjDb027879; Wed, 2 Mar 2011 16:37:45 +0100 (CET) Message-ID: <4D6E6449.4060908@cisco.com> Date: Wed, 02 Mar 2011 16:37:45 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Juergen Quittek References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] modeling power states - Entity-MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:36:51 -0000 Dear all, > Hi Chris, > > Thank you for your thoughts. I have three comments: > > - I do not think that anyone in this WG is still proposing seriously to go for an extension of the ENTITY-MIB. It seems to be clear that this is not sufficient. Maybe the chairs can check if we have consensus on this issue. I guess we have it. The issue is more about: 1. could we solve the problems specified in draft-ietf-eman-requirements with the ENTITY-MIB? 2. if yes, do we chose to do so? So consensus only addresses this part. We discussed 1. when presenting before the WG was created, i.e. in OPSAWG, and my recollection is that we concluded that the ENTITY-MIB was not good enough. I remember one of the conclusion at IETF78: the ENTITY-MIB is good to represent something on the device itself, but not good enough to represent something outside of the box, i.e. a child. Then the notion of SNMP context was put in the picture... However, I can't find any written explanation of the reasons why the ENTITY-MIB is not suitable. http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.1 addresses ENTITY-STATE-MIB http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.2 addresses ENTITY-SENSOR-MIB As proposed in this email thread, as a WG co-chair, I would like to see some summary text of why the ENTITY-MIB is not good enough. Ideally in requirements draft (a new section 7.1.x) or potentially in the framework. Another point, which seems related. It seems that the use cases described in draft-ietf-eman-requirements don't cover the ones mentioned by Chris Verges. For example, Chris already mentioned the notion of redundant power supplies in his email in http://www.ietf.org/mail-archive/web/eman/current/msg00112.html and gave the same example in this email thread again. So, we should discuss whether we want to solve this redundant power supply issue. If yes, provide some text in draft-ietf-eman-requirements for this. And apparently, this is this use case that prevents from using the ENTITY-MIB. Finally, I agree on the data model exercise, also mentioned in this email thread, which we must work on. Regards, Benoit, co-chair hat on. > - I like your example below and yes, we should be able to support this. But this is not a problem of power states. This is about the parent/child concept which we have not discussed so far on this list. My concern about parent child is that it may be too simple to model complex cases like the one you describe and others. This is why I try to have a clean reference model. > > - Yes, you are right, the reference model currently has very few example scenarios with multiple instances of a port or a PC. But the only purpose of section 3.4 is to explain how the scenarios and figures expand to multiple instances. If think this is not sufficient, I can add more explanations to it. If you think it would be helpful in any aspect to provide a figure with the PDU with 24 ports you describe in your message, I will be glad to draw this figure for you and include it in the next revision. > > Thanks, > > Juergen > > > Am 01.03.2011 um 06:06 schrieb chrisv@cyberswitching.com: > >> Hi John and Juergen, >> >>>> Without those two additions the work in this group can easily be covered >>>> by two additions to existing SNMP objects. First would be adding energy >>>> related fields (watts units or Kwh) to the sensor mib. The seconds would >>>> be to add better the context information (see energy aware proposal) to >>>> the entity mib. A simple on/off/standby state already exists in oper >>>> status. >>>> >>>> So in short without an IETF EMAN set of power states / interfaces to >>>> unify or map to the states from other orgs as you listed, *and* the >>>> ability to monitor/aggregate non SNMP devices - the work here can easily >>>> be absorbed into the sensor and entity mibs with minor additions. >> I disagree with the argument that ENTITY-MIB can be extended to support >> power data properly. ENTITY-MIB contains an inherent flaw, in that it >> separates physical and logical entities into distinct buckets that >> cannot overlap in sparse tables. >> WHEN -- not if -- the IETF decides to provide a meter hook for logical >> entities (individual programs, virtual machines on a shared server, >> etc.), an EMAN schema based on ENTITY-MIB would have to be forked to >> support this. That duplication of effort is pointless. >> >> And I say "when" because it's a matter of time. Lots of people are >> already working on this problem because there is a huge amount of money >> involved: >> >> 30-second internet search: >> http://research.microsoft.com/apps/pubs/default.aspx?id=120435 >> >> The IETF exists to enable others' innovation and interoperability in >> those pursuits. It is not our responsibility to debate the merits of >> this undertaking. It is, however, our duty to acknowledge this pursuit >> and prepare to integrate it into schema. >> >> So while it's good to make a nod to the predecessor ENTITY-MIB, I urge >> us to make a structural break from it. >> >>>> IMO any work in EMAN must contain the addition of an IETF power >>>> interface as described in claise architecture (or some compromise as you >>>> listed with IANA interfaces). It must also contain the addition of >>>> parent/child/aggregator relationship for non SNMP energy management. >>> You say we MUST adopt the power states from the claise architecture >>> and we MUST adopt the parent/child concept. >>> >>> The reasons you give for this in the paragraphs below are >>> - Otherwise we would not need an EMAN WG. >>> - This helps manufacturers to build sophisticated energy management >>> systems. >>> >>> I would not accept the first one as a technical argument, >>> On your second argument I would reply that providing good interfaces >>> for building sophisticated applications is certainly an objective >>> of our work in EMAN, but probably not the one with top priority. >> I agree with John's first point ("otherwise EMAN wouldn't exist") in the >> light that, even though it may not yet be fully and properly >> articulated, there is a sense that EMAN is needed because the existing >> solution architecture just doesn't quite do what is needed. I mean, why >> does your MIB draft exist? You see a problem and have tried to solve it >> because a solution doesn't yet exist. >> >> Here's a structural example to illustrate the point: >> >> Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor types, >> the data COULD be represented. For a single intelligent power supply on >> a server that monitors voltage, amperage, real power, apparent power, >> power factor, and frequency, we'd have 6 entities enumerated in >> ENTITY-MIB. And all of this would need to be tied together logically >> into a "Power Supply" concept, so that'd be another entity -- 7 in >> total. >> >> For a single server, sure, fine, do-able. Tiny scale. >> >> What about a 24-outlet PDU? Or a 84-circuit panelboard? >> >> http://www.kondra.com/circuit/circuit.html >> >> Eaton Branch Circuit Monitoring Whitepaper: >> http://tinyurl.com/5rpmhrp >> >> Managing 168 entities on a PDU or 588 entities on a panelboard is >> a ridiculous burden on the user who is consuming the agent's data. >> >> "Bonding" these entities that are a common purpose reduces the magnitude >> by a factor of 7, and simplifies the conceptual use of the framework. >> Users don't need to think in terms of "voltage sensor for Outlet 1" but >> instead can refer to that same data as "Outlet 1's voltage." >> >> Juergen, it seems like you're so busy focused on a conceptual model that >> real-world usability may be getting sacrificed. Each of your examples >> only reflects a single entity at a time. Why not kick up the examples a >> notch and model something like an intelligent PDU with the following >> properties? >> >> 1. 24 outlets, single phase >> 2. 6 banks (4 outlets per bank), single phase >> 3. 2 inputs (3 banks per input), three phase >> 4. "Ganged" outlets (multiple outlets that are managed as one >> construct) >> 5. High current alerts, low current alerts, circuit breaker alerts, >> high voltage alerts (spikes), low voltage alerts (sags) -- all of >> which can be applied to a physical entity or a logical entity >> (like an outlet "gang") >> 6. Internal network card and metering logic >> 7. Outlets "owned" by different users (think co-location facility, >> "context") >> 8. Manage power via 5 different interface modalities/mechanisms >> 9. Except for the existence of the outlets/banks/inputs/"gangs", all >> other properties are potentially optional >> >> I challenge you -- everyone participating in the EMAN list -- to model >> this level of complexity. If your MIB can withstand this, it's a good >> MIB (IMO, of course). > >> Thanks, >> Chris > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From chrisv@cyberswitching.com Wed Mar 2 08:28:18 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317F33A67B6 for ; Wed, 2 Mar 2011 08:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVxf-GRIfCAH for ; Wed, 2 Mar 2011 08:28:10 -0800 (PST) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by core3.amsl.com (Postfix) with ESMTP id 6D2CA3A683E for ; Wed, 2 Mar 2011 08:28:09 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o149.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id a507e6d4.0.7116.00-364.16702.p01c11o149.mxlogic.net (envelope-from ); Wed, 02 Mar 2011 09:29:15 -0700 (MST) X-MXL-Hash: 4d6e705b0c7088e0-0ab2c49662946a0af5660f81a41cfa27f712df07 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 08:28:11 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 82A4F2F6001; Wed, 2 Mar 2011 08:29:14 -0800 (PST) Date: Wed, 2 Mar 2011 08:29:14 -0800 From: chrisv@cyberswitching.com To: "Romascanu, Dan (Dan)" Message-ID: <20110302162914.GA12358@cslinux-build01.cyberswitching.local> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 02 Mar 2011 16:28:11.0775 (UTC) FILETIME=[D2A4A0F0:01CBD8F6] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=mrxgWj59b9sA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=lE855XQP6SxjkqHR7UsA] X-AnalysisOut: [:9 a=nA8zRp4-ZYAh0yCmflPPNn4cKSMA:4 a=CjuIK1q_8ugA:10 a=Of] X-AnalysisOut: [Rpth80PlXuSu5Q:21 a=nXMhAzvBLoUHecuO:21] Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:28:19 -0000 On Wed, Mar 02, 2011 at 11:42:14AM +0100, Romascanu, Dan (Dan) wrote: > > +--------------------+ > > | VMware server | > > | | > > | +--------------+ | > > | | Windows VM 1 | | > > | +--------------+ | > > | | > > | +--------------+ | > > | | Windows VM 2 | | > > | +--------------+ | > > | | > > | +--------------+ | > > | | Linux VM | | > > | +--------------+ | > > | | > > | +--------------+ | > > | | Solaris VM | | > > | +--------------+ | > > | | > > +--------------------+ > > > > This looks indeed like a different application. The VMs are logical > entities, the server is a physical entity. They can be modeled easily > with the entity MIB and the mapping table provides you the picture of > what runs where. However I may be missing something in the discussion > because I do not understand what 'allocate power to each VM' means. Hi Dan, Let's say the VMware server is drawing 10.0A total. The SNMP agent on the VMware machine reports 10.0A for the VMware server entity. That same SNMP agent is aware that multiple VMs are running on the machine, however, and attempts to use the CPU utilization for each VM to allocate the 10.0A total to a VM. So for example: Entity CPU% Amps --------------------------------- Windows VM 1 27% 2.7A Windows VM 2 35% 3.5A Linux VM 20% 2.0A Solaris VM 18% 1.8A --------------------------------- VMware server 100% 10.0A In this case, we want to display all five of these rows to give the end user a full picture of what's going on inside the server. Companies like Power Assure in Santa Clara, CA are already doing this kind of utilization-to-consumption mapping, and are extremely accurate with it. We do need to provide a hook to get this kind of detailed data as a result. How would this work with ENTITY-MIB's structure? entLogicalTable +-------+---------------+ | Index | Name | +-------+---------------+ | | | +-------+---------------+ entPhysicalTable +-------+---------------+ | Index | Name | +-------+---------------+ | | | +-------+---------------+ entLPMappingTable (?) +--------------+---------------+ | LogicalIndex | PhysicalIndex | +--------------+---------------+ | | | +--------------+---------------+ Thanks, Chris From dromasca@avaya.com Wed Mar 2 08:35:37 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D503A682C for ; Wed, 2 Mar 2011 08:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ70ZGwwGrra for ; Wed, 2 Mar 2011 08:35:36 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 68FA93A681E for ; Wed, 2 Mar 2011 08:35:33 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8AAEYAbk2HCzI1/2dsb2JhbACYAY5XdKQ4Apk7hWEEkAA X-IronPort-AV: E=Sophos;i="4.62,253,1297054800"; d="scan'208";a="61529787" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 02 Mar 2011 11:36:35 -0500 X-IronPort-AV: E=Sophos;i="4.62,253,1297054800"; d="scan'208";a="608964107" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Mar 2011 11:36:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 17:36:13 +0100 Message-ID: In-Reply-To: <20110302162914.GA12358@cslinux-build01.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvY9vrIDhe2ftk3RJGNox8yug/JzwAAEjGQ References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> From: "Romascanu, Dan (Dan)" To: Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:35:37 -0000 =20 > -----Original Message----- > From: chrisv@cyberswitching.com [mailto:chrisv@cyberswitching.com]=20 > Sent: Wednesday, March 02, 2011 6:29 PM > To: Romascanu, Dan (Dan) > Cc: eman mailing list; Juergen Quittek; Juergen Schoenwaelder > Subject: Re: [eman] modeling power states >=20 > On Wed, Mar 02, 2011 at 11:42:14AM +0100, Romascanu, Dan (Dan) wrote: > > > +--------------------+ > > > | VMware server | > > > | | > > > | +--------------+ | > > > | | Windows VM 1 | | > > > | +--------------+ | > > > | | > > > | +--------------+ | > > > | | Windows VM 2 | | > > > | +--------------+ | > > > | | > > > | +--------------+ | > > > | | Linux VM | | > > > | +--------------+ | > > > | | > > > | +--------------+ | > > > | | Solaris VM | | > > > | +--------------+ | > > > | | > > > +--------------------+ > > > > > > > This looks indeed like a different application. The VMs are logical=20 > > entities, the server is a physical entity. They can be=20 > modeled easily=20 > > with the entity MIB and the mapping table provides you the=20 > picture of=20 > > what runs where. However I may be missing something in the=20 > discussion=20 > > because I do not understand what 'allocate power to each VM' means. >=20 > Hi Dan, >=20 > Let's say the VMware server is drawing 10.0A total. The SNMP=20 > agent on the VMware machine reports 10.0A for the VMware=20 > server entity. >=20 > That same SNMP agent is aware that multiple VMs are running=20 > on the machine, however, and attempts to use the CPU=20 > utilization for each VM to allocate the 10.0A total to a VM. =20 > So for example: >=20 > Entity CPU% Amps > --------------------------------- > Windows VM 1 27% 2.7A > Windows VM 2 35% 3.5A > Linux VM 20% 2.0A > Solaris VM 18% 1.8A > --------------------------------- > VMware server 100% 10.0A >=20 > In this case, we want to display all five of these rows to=20 > give the end user a full picture of what's going on inside the server. >=20 > Companies like Power Assure in Santa Clara, CA are already=20 > doing this kind of utilization-to-consumption mapping, and=20 > are extremely accurate with it. We do need to provide a hook=20 > to get this kind of detailed data as a result. >=20 > How would this work with ENTITY-MIB's structure? >=20 > entLogicalTable > +-------+---------------+ > | Index | Name | > +-------+---------------+ > | | | > +-------+---------------+ >=20 > entPhysicalTable > +-------+---------------+ > | Index | Name | > +-------+---------------+ > | | | > +-------+---------------+ >=20 > entLPMappingTable (?) > +--------------+---------------+ > | LogicalIndex | PhysicalIndex | > +--------------+---------------+ > | | | > +--------------+---------------+ >=20 > Thanks, > Chris >=20 >From an Entity MIB modeling this is really a simple case.=20 You have=20 - one entry in the entPhysicalTable - the server - four entries in the entLogicaltable - the VMs - four entries in the entLPMappingTable mapping the index of the VM server to the 4 indices of the VMs respectively The MIB we design would be either indexed by LogicalIndex or point to the value of the Index (we need an accessible variable for this) and will include an 'estimate power consumption' object Now I assume that you power guys know how to provide the value for power estimate of a VM per server machine - because for me this is magic (i.e. technology that I do not understand) Dan From chrisv@cyberswitching.com Wed Mar 2 09:13:26 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E863A6863 for ; Wed, 2 Mar 2011 09:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jljgFgqg4kOZ for ; Wed, 2 Mar 2011 09:13:25 -0800 (PST) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by core3.amsl.com (Postfix) with ESMTP id BFE773A6857 for ; Wed, 2 Mar 2011 09:13:21 -0800 (PST) Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c11o144.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 3fa7e6d4.0.7796.00-350.17676.p01c11o144.mxlogic.net (envelope-from ); Wed, 02 Mar 2011 10:14:28 -0700 (MST) X-MXL-Hash: 4d6e7af4125b3aaf-90cadf04e4f598391c71b08b8dfa630323ec16c5 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 09:13:15 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 5FDF52F6001; Wed, 2 Mar 2011 09:14:18 -0800 (PST) Date: Wed, 2 Mar 2011 09:14:18 -0800 From: chrisv@cyberswitching.com To: "Romascanu, Dan (Dan)" Message-ID: <20110302171418.GA12416@cslinux-build01.cyberswitching.local> References: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 02 Mar 2011 17:13:15.0299 (UTC) FILETIME=[1E11A730:01CBD8FD] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [64.81.28.110] X-AnalysisOut: [v=1.0 c=1 a=mrxgWj59b9sA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=4zsJQXJisSY22NXBO5KRuA==:17 a=xNu_eKh_jBPJc_4R5osA] X-AnalysisOut: [:9 a=Skp4DfkJoDdz5okP8c8A:7 a=yIVujI6sOL6Tz7GnFP_rgfAw8IAA] X-AnalysisOut: [:4 a=CjuIK1q_8ugA:10] Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:13:26 -0000 On Wed, Mar 02, 2011 at 05:36:13PM +0100, Romascanu, Dan (Dan) wrote: > > Entity CPU% Amps > > --------------------------------- > > Windows VM 1 27% 2.7A > > Windows VM 2 35% 3.5A > > Linux VM 20% 2.0A > > Solaris VM 18% 1.8A > > --------------------------------- > > VMware server 100% 10.0A > > > > How would this work with ENTITY-MIB's structure? > > From an Entity MIB modeling this is really a simple case. > > You have > - one entry in the entPhysicalTable - the server > - four entries in the entLogicaltable - the VMs > - four entries in the entLPMappingTable mapping the index of the VM > server to the 4 indices of the VMs respectively > > The MIB we design would be either indexed by LogicalIndex or point to > the value of the Index (we need an accessible variable for this) and > will include an 'estimate power consumption' object Hi Dan, If we use the LogicalIndex for the EMAN MIB, then we lose the ability to represent the VMware server itself in the EMAN structure unless we add another "pseudo-entry" in the LogicalTable. Is it common practice for agents that implement ENTITY-MIB to enumerate an entity in both the Physical and Logical tables as a 1:1 mapping (minimum)? If we create a new "Index" variable, we'd also need to introduce a method to "multiplex" on the proper table -- Logical or Physical. So we'd have to add an additional variable to the EMAN entity table, "LogicalOrPhysical", which then adds complexity and burden onto the consuming user. This is getting at the heart of why I believe ENTITY-MIB won't necessarily work for EMAN's needs. There's always something else that is needed to make it work, some additional layer of complexity in either understanding or actual use. Thanks, Chris From ietf@quittek.at Wed Mar 2 09:21:37 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DFC33A683E for ; Wed, 2 Mar 2011 09:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGLzD2Tx3J0a for ; Wed, 2 Mar 2011 09:21:35 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 3402A3A682C for ; Wed, 2 Mar 2011 09:21:34 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MUTQ3-1PU3oL125j-00R1dL; Wed, 02 Mar 2011 18:22:38 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <4D6E6449.4060908@cisco.com> In-Reply-To: <4D6E6449.4060908@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Wed, 2 Mar 2011 18:22:38 +0100 To: Benoit Claise X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:/uIr/lXDwfk/c9IKOD8gjzf7RVBaWohOkwyVyBitwRC G8Kj7eBv2cG5Y3EFd96eLBrx5fbBOutCKPzw2oa4amX8u9T5y8 PDQ3DYX+W/GOF10Uzll1qXCEBcyO5G0IKwCxVePjUsDhQAEIDk iWkp/DrOEHbSFsn+QXhcNSgnB4SMDGhYmvmPCEeS1Sw0wkF27a wvS3B7EX2VzNVh3Ca1wHg== Cc: eman mailing list Subject: Re: [eman] modeling power states - Entity-MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:21:37 -0000 Hi Benoit, Am 02.03.2011 um 16:37 schrieb Benoit Claise: > Dear all, >> Hi Chris, >>=20 >> Thank you for your thoughts. I have three comments: >>=20 >> - I do not think that anyone in this WG is still proposing seriously = to go for an extension of the ENTITY-MIB. It seems to be clear that = this is not sufficient. Maybe the chairs can check if we have consensus = on this issue. I guess we have it. > The issue is more about: > 1. could we solve the problems specified in = draft-ietf-eman-requirements with the ENTITY-MIB? > 2. if yes, do we chose to do so? So consensus only addresses this = part. >=20 > We discussed 1. when presenting before the WG was created, i.e. in = OPSAWG, and my recollection is that we concluded that the ENTITY-MIB was = not good enough. I remember one of the conclusion at IETF78: the = ENTITY-MIB is good to represent something on the device itself, but not = good enough to represent something outside of the box, i.e. a child. = Then the notion of SNMP context was put in the picture... > However, I can't find any written explanation of the reasons why the = ENTITY-MIB is not suitable. > = http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.1 = addresses ENTITY-STATE-MIB > = http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.2 = addresses ENTITY-SENSOR-MIB >=20 > As proposed in this email thread, as a WG co-chair, I would like to = see some summary text of why the ENTITY-MIB is not good enough. Ideally = in requirements draft (a new section 7.1.x) or potentially in the = framework. So far I thought, that the Entity MIB does not meet EMAN requirements. However, with what I learned from Juergen S. maybe it does. Anyway, we will add the conclusion of the discussion going on on this = list to the requirements draft. > Another point, which seems related. > It seems that the use cases described in draft-ietf-eman-requirements = don't cover the ones mentioned by Chris Verges. > For example, Chris already mentioned the notion of redundant power = supplies in his email in = http://www.ietf.org/mail-archive/web/eman/current/msg00112.html and gave = the same example in this email thread again. > So, we should discuss whether we want to solve this redundant power = supply issue. If yes, provide some text in draft-ietf-eman-requirements = for this. > And apparently, this is this use case that prevents from using the = ENTITY-MIB. I don't think it would be a good option to ignore it and state: Sorry, = if you have a dual power supply you can't use eman MIBs. Thanks, Juergen Q. > Finally, I agree on the data model exercise, also mentioned in this = email thread, which we must work on. >=20 > Regards, Benoit, co-chair hat on. >=20 >> - I like your example below and yes, we should be able to support = this. But this is not a problem of power states. This is about the = parent/child concept which we have not discussed so far on this list. My = concern about parent child is that it may be too simple to model complex = cases like the one you describe and others. This is why I try to have a = clean reference model. >>=20 >> - Yes, you are right, the reference model currently has very few = example scenarios with multiple instances of a port or a PC. But the = only purpose of section 3.4 is to explain how the scenarios and figures = expand to multiple instances. If think this is not sufficient, I can add = more explanations to it. If you think it would be helpful in any aspect = to provide a figure with the PDU with 24 ports you describe in your = message, I will be glad to draw this figure for you and include it in = the next revision. >>=20 >> Thanks, >>=20 >> Juergen >>=20 >>=20 >> Am 01.03.2011 um 06:06 schrieb chrisv@cyberswitching.com: >>=20 >>> Hi John and Juergen, >>>=20 >>>>> Without those two additions the work in this group can easily be = covered >>>>> by two additions to existing SNMP objects. First would be adding = energy >>>>> related fields (watts units or Kwh) to the sensor mib. The seconds = would >>>>> be to add better the context information (see energy aware = proposal) to >>>>> the entity mib. A simple on/off/standby state already exists in = oper >>>>> status. >>>>>=20 >>>>> So in short without an IETF EMAN set of power states / interfaces = to >>>>> unify or map to the states from other orgs as you listed, *and* = the >>>>> ability to monitor/aggregate non SNMP devices - the work here can = easily >>>>> be absorbed into the sensor and entity mibs with minor additions. >>> I disagree with the argument that ENTITY-MIB can be extended to = support >>> power data properly. ENTITY-MIB contains an inherent flaw, in that = it >>> separates physical and logical entities into distinct buckets that >>> cannot overlap in sparse tables. >>> WHEN -- not if -- the IETF decides to provide a meter hook for = logical >>> entities (individual programs, virtual machines on a shared server, >>> etc.), an EMAN schema based on ENTITY-MIB would have to be forked to >>> support this. That duplication of effort is pointless. >>>=20 >>> And I say "when" because it's a matter of time. Lots of people are >>> already working on this problem because there is a huge amount of = money >>> involved: >>>=20 >>> 30-second internet search: >>> http://research.microsoft.com/apps/pubs/default.aspx?id=3D120435 >>>=20 >>> The IETF exists to enable others' innovation and interoperability in >>> those pursuits. It is not our responsibility to debate the merits = of >>> this undertaking. It is, however, our duty to acknowledge this = pursuit >>> and prepare to integrate it into schema. >>>=20 >>> So while it's good to make a nod to the predecessor ENTITY-MIB, I = urge >>> us to make a structural break from it. >>>=20 >>>>> IMO any work in EMAN must contain the addition of an IETF power >>>>> interface as described in claise architecture (or some compromise = as you >>>>> listed with IANA interfaces). It must also contain the addition of >>>>> parent/child/aggregator relationship for non SNMP energy = management. >>>> You say we MUST adopt the power states from the claise architecture >>>> and we MUST adopt the parent/child concept. >>>>=20 >>>> The reasons you give for this in the paragraphs below are >>>> - Otherwise we would not need an EMAN WG. >>>> - This helps manufacturers to build sophisticated energy = management >>>> systems. >>>>=20 >>>> I would not accept the first one as a technical argument, >>>> On your second argument I would reply that providing good = interfaces >>>> for building sophisticated applications is certainly an objective >>>> of our work in EMAN, but probably not the one with top priority. >>> I agree with John's first point ("otherwise EMAN wouldn't exist") in = the >>> light that, even though it may not yet be fully and properly >>> articulated, there is a sense that EMAN is needed because the = existing >>> solution architecture just doesn't quite do what is needed. I mean, = why >>> does your MIB draft exist? You see a problem and have tried to = solve it >>> because a solution doesn't yet exist. >>>=20 >>> Here's a structural example to illustrate the point: >>>=20 >>> Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor = types, >>> the data COULD be represented. For a single intelligent power = supply on >>> a server that monitors voltage, amperage, real power, apparent = power, >>> power factor, and frequency, we'd have 6 entities enumerated in >>> ENTITY-MIB. And all of this would need to be tied together = logically >>> into a "Power Supply" concept, so that'd be another entity -- 7 in >>> total. >>>=20 >>> For a single server, sure, fine, do-able. Tiny scale. >>>=20 >>> What about a 24-outlet PDU? Or a 84-circuit panelboard? >>>=20 >>> http://www.kondra.com/circuit/circuit.html >>>=20 >>> Eaton Branch Circuit Monitoring Whitepaper: >>> http://tinyurl.com/5rpmhrp >>>=20 >>> Managing 168 entities on a PDU or 588 entities on a panelboard is >>> a ridiculous burden on the user who is consuming the agent's data. >>>=20 >>> "Bonding" these entities that are a common purpose reduces the = magnitude >>> by a factor of 7, and simplifies the conceptual use of the = framework. >>> Users don't need to think in terms of "voltage sensor for Outlet 1" = but >>> instead can refer to that same data as "Outlet 1's voltage." >>>=20 >>> Juergen, it seems like you're so busy focused on a conceptual model = that >>> real-world usability may be getting sacrificed. Each of your = examples >>> only reflects a single entity at a time. Why not kick up the = examples a >>> notch and model something like an intelligent PDU with the following >>> properties? >>>=20 >>> 1. 24 outlets, single phase >>> 2. 6 banks (4 outlets per bank), single phase >>> 3. 2 inputs (3 banks per input), three phase >>> 4. "Ganged" outlets (multiple outlets that are managed as one >>> construct) >>> 5. High current alerts, low current alerts, circuit breaker = alerts, >>> high voltage alerts (spikes), low voltage alerts (sags) -- all = of >>> which can be applied to a physical entity or a logical entity >>> (like an outlet "gang") >>> 6. Internal network card and metering logic >>> 7. Outlets "owned" by different users (think co-location facility, >>> "context") >>> 8. Manage power via 5 different interface modalities/mechanisms >>> 9. Except for the existence of the outlets/banks/inputs/"gangs", = all >>> other properties are potentially optional >>>=20 >>> I challenge you -- everyone participating in the EMAN list -- to = model >>> this level of complexity. If your MIB can withstand this, it's a = good >>> MIB (IMO, of course). >>=20 >>> Thanks, >>> Chris >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >=20 From dromasca@avaya.com Wed Mar 2 09:23:38 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B213A6838 for ; Wed, 2 Mar 2011 09:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ4BFDCBxiSQ for ; Wed, 2 Mar 2011 09:23:37 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 8581D3A682C for ; Wed, 2 Mar 2011 09:23:37 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUBAMMLbk3GmAcF/2dsb2JhbACYAT+OGXSkYQKZQ4VhBJAA X-IronPort-AV: E=Sophos;i="4.62,254,1297054800"; d="scan'208";a="267442979" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Mar 2011 12:24:43 -0500 X-IronPort-AV: E=Sophos;i="4.62,254,1297054800"; d="scan'208";a="588969016" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Mar 2011 12:24:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 18:24:21 +0100 Message-ID: In-Reply-To: <20110302171418.GA12416@cslinux-build01.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvY/U5iwiB7Pf7/QuOhqQZ+s4OPdwAAHnhA References: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302171418.GA12416@cslinux-build01.cyberswitching.local> From: "Romascanu, Dan (Dan)" To: Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:23:38 -0000 Hi Chris, See in-line.=20 Regards, Dan (speaking as contributor) > -----Original Message----- > From: chrisv@cyberswitching.com [mailto:chrisv@cyberswitching.com]=20 > Sent: Wednesday, March 02, 2011 7:14 PM > To: Romascanu, Dan (Dan) > Cc: eman mailing list; Juergen Quittek; Juergen Schoenwaelder > Subject: Re: [eman] modeling power states >=20 > On Wed, Mar 02, 2011 at 05:36:13PM +0100, Romascanu, Dan (Dan) wrote: > > > Entity CPU% Amps > > > --------------------------------- > > > Windows VM 1 27% 2.7A > > > Windows VM 2 35% 3.5A > > > Linux VM 20% 2.0A > > > Solaris VM 18% 1.8A > > > --------------------------------- > > > VMware server 100% 10.0A > > > > > > How would this work with ENTITY-MIB's structure? > > > > From an Entity MIB modeling this is really a simple case. > > > > You have > > - one entry in the entPhysicalTable - the server > > - four entries in the entLogicaltable - the VMs > > - four entries in the entLPMappingTable mapping the index of the VM=20 > > server to the 4 indices of the VMs respectively > > > > The MIB we design would be either indexed by LogicalIndex=20 > or point to=20 > > the value of the Index (we need an accessible variable for=20 > this) and=20 > > will include an 'estimate power consumption' object >=20 > Hi Dan, >=20 > If we use the LogicalIndex for the EMAN MIB, then we lose the=20 > ability to represent the VMware server itself in the EMAN=20 > structure unless we add another "pseudo-entry" in the=20 > LogicalTable. Is it common practice for agents that=20 > implement ENTITY-MIB to enumerate an entity in both the=20 > Physical and Logical tables as a 1:1 mapping (minimum)? >=20 Yes - you define a PhysicalVMWareServer and LogicalVMWareServer and a one to one mapping. This is what is down when managing stacks of switches or clusters of rounding devices.=20 > If we create a new "Index" variable, we'd also need to=20 > introduce a method to "multiplex" on the proper table --=20 > Logical or Physical. So we'd have to add an additional=20 > variable to the EMAN entity table, "LogicalOrPhysical", which=20 > then adds complexity and burden onto the consuming user. The overhead is minimal, and you can use the same indices as in the Entity MIB to avoid this. >=20 > This is getting at the heart of why I believe ENTITY-MIB=20 > won't necessarily work for EMAN's needs. There's always=20 > something else that is needed to make it work, some=20 > additional layer of complexity in either understanding or actual use. Reinventing something new is more overhead IMO. The Entity MIB is designed to provide a basic common structure to managed different entities and yes - in many cases you need to add something else, but this is simpler than writing all from scratch and making it usable only for one application (EMAN in this case).=20 >=20 > Thanks, > Chris >=20 From bclaise@cisco.com Wed Mar 2 09:27:06 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96353A67E1 for ; Wed, 2 Mar 2011 09:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsH-FHcYZu4U for ; Wed, 2 Mar 2011 09:27:06 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A54313A683A for ; Wed, 2 Mar 2011 09:27:05 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22HFafY015128; Wed, 2 Mar 2011 18:15:36 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22HFZlA017894; Wed, 2 Mar 2011 18:15:35 +0100 (CET) Message-ID: <4D6E7B37.7000301@cisco.com> Date: Wed, 02 Mar 2011 18:15:35 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] modeling power states - power monitoring for virtual machines X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:27:07 -0000 Dear all, As far as we understand the power monitoring for virtual machines is not on our charter However, if we have a flexible data model that allows us to cover this case as well, great. Regards, co-chair hats on, Bruce and Benoit, > > >> -----Original Message----- >> From: chrisv@cyberswitching.com [mailto:chrisv@cyberswitching.com] >> Sent: Wednesday, March 02, 2011 12:30 AM >> To: Romascanu, Dan (Dan) >> Cc: eman mailing list; Juergen Quittek; Juergen Schoenwaelder >> Subject: Re: [eman] modeling power states >> >> On Tue, Mar 01, 2011 at 05:23:11PM +0100, Romascanu, Dan (Dan) wrote: >>> How is this problem different from the one of managing a stack or >>> cluster of physical devices? Ethernet switch vendors have done this >>> for a decade and more. You just define entries for the >> Outlet Gangs #1 >>> and >>> #2 also in the entPhysical table, use the >> entPhysicalContainsTable to >>> define the containment relations with Outlet #1-4 and map them >>> one-to-one to the entries in the entLogicalTable. >> Hi Dan, >> >> I'm going to assume that my follow up to this was covered in >> the previous reply. While the scenario that I've described >> talks about this in terms of Outlet Gangs (because that's >> what I know), you could apply the same question to that of a >> VMware ESXi server running multiple Windows and Linux VMs. >> If an agent wanted to expose the VMware ESXi server's power >> consumption and allocate power to each VM, how would that >> structure work in relation to ENTITY-MIB? >> >> +--------------------+ >> | VMware server | >> | | >> | +--------------+ | >> | | Windows VM 1 | | >> | +--------------+ | >> | | >> | +--------------+ | >> | | Windows VM 2 | | >> | +--------------+ | >> | | >> | +--------------+ | >> | | Linux VM | | >> | +--------------+ | >> | | >> | +--------------+ | >> | | Solaris VM | | >> | +--------------+ | >> | | >> +--------------------+ >> >> Would there be 5 entities listed in entPhysicalTable, one for > This looks indeed like a different application. The VMs are logical > entities, the server is a physical entity. They can be modeled easily > with the entity MIB and the mapping table provides you the picture of > what runs where. However I may be missing something in the discussion > because I do not understand what 'allocate power to each VM' means. > > Dan > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Wed Mar 2 09:28:31 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7079A3A67E1 for ; Wed, 2 Mar 2011 09:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVLINDEB5lfM for ; Wed, 2 Mar 2011 09:28:29 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id C11213A67B6 for ; Wed, 2 Mar 2011 09:28:28 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22HPjnC015955; Wed, 2 Mar 2011 18:25:45 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22HPiuN028812; Wed, 2 Mar 2011 18:25:44 +0100 (CET) Message-ID: <4D6E7D98.5030002@cisco.com> Date: Wed, 02 Mar 2011 18:25:44 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Juergen Quittek References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <4D6E6449.4060908@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] modeling power states - Entity-MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:28:31 -0000 Hi Juergen, > Hi Benoit, > > Am 02.03.2011 um 16:37 schrieb Benoit Claise: > >> Dear all, >>> Hi Chris, >>> >>> Thank you for your thoughts. I have three comments: >>> >>> - I do not think that anyone in this WG is still proposing seriously to go for an extension of the ENTITY-MIB. It seems to be clear that this is not sufficient. Maybe the chairs can check if we have consensus on this issue. I guess we have it. >> The issue is more about: >> 1. could we solve the problems specified in draft-ietf-eman-requirements with the ENTITY-MIB? >> 2. if yes, do we chose to do so? So consensus only addresses this part. >> >> We discussed 1. when presenting before the WG was created, i.e. in OPSAWG, and my recollection is that we concluded that the ENTITY-MIB was not good enough. I remember one of the conclusion at IETF78: the ENTITY-MIB is good to represent something on the device itself, but not good enough to represent something outside of the box, i.e. a child. Then the notion of SNMP context was put in the picture... >> However, I can't find any written explanation of the reasons why the ENTITY-MIB is not suitable. >> http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.1 addresses ENTITY-STATE-MIB >> http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.2 addresses ENTITY-SENSOR-MIB >> >> As proposed in this email thread, as a WG co-chair, I would like to see some summary text of why the ENTITY-MIB is not good enough. Ideally in requirements draft (a new section 7.1.x) or potentially in the framework. > So far I thought, that the Entity MIB does not meet EMAN requirements. > However, with what I learned from Juergen S. maybe it does. > Anyway, we will add the conclusion of the discussion going on on this list to the requirements draft. thanks. >> Another point, which seems related. >> It seems that the use cases described in draft-ietf-eman-requirements don't cover the ones mentioned by Chris Verges. >> For example, Chris already mentioned the notion of redundant power supplies in his email in http://www.ietf.org/mail-archive/web/eman/current/msg00112.html and gave the same example in this email thread again. >> So, we should discuss whether we want to solve this redundant power supply issue. If yes, provide some text in draft-ietf-eman-requirements for this. >> And apparently, this is this use case that prevents from using the ENTITY-MIB. > I don't think it would be a good option to ignore it and state: Sorry, if you have a dual power supply you can't use eman MIBs. Agreed. Regards, Benoit. > Thanks, > > Juergen Q. > >> Finally, I agree on the data model exercise, also mentioned in this email thread, which we must work on. >> >> Regards, Benoit, co-chair hat on. >> >>> - I like your example below and yes, we should be able to support this. But this is not a problem of power states. This is about the parent/child concept which we have not discussed so far on this list. My concern about parent child is that it may be too simple to model complex cases like the one you describe and others. This is why I try to have a clean reference model. >>> >>> - Yes, you are right, the reference model currently has very few example scenarios with multiple instances of a port or a PC. But the only purpose of section 3.4 is to explain how the scenarios and figures expand to multiple instances. If think this is not sufficient, I can add more explanations to it. If you think it would be helpful in any aspect to provide a figure with the PDU with 24 ports you describe in your message, I will be glad to draw this figure for you and include it in the next revision. >>> >>> Thanks, >>> >>> Juergen >>> >>> >>> Am 01.03.2011 um 06:06 schrieb chrisv@cyberswitching.com: >>> >>>> Hi John and Juergen, >>>> >>>>>> Without those two additions the work in this group can easily be covered >>>>>> by two additions to existing SNMP objects. First would be adding energy >>>>>> related fields (watts units or Kwh) to the sensor mib. The seconds would >>>>>> be to add better the context information (see energy aware proposal) to >>>>>> the entity mib. A simple on/off/standby state already exists in oper >>>>>> status. >>>>>> >>>>>> So in short without an IETF EMAN set of power states / interfaces to >>>>>> unify or map to the states from other orgs as you listed, *and* the >>>>>> ability to monitor/aggregate non SNMP devices - the work here can easily >>>>>> be absorbed into the sensor and entity mibs with minor additions. >>>> I disagree with the argument that ENTITY-MIB can be extended to support >>>> power data properly. ENTITY-MIB contains an inherent flaw, in that it >>>> separates physical and logical entities into distinct buckets that >>>> cannot overlap in sparse tables. >>>> WHEN -- not if -- the IETF decides to provide a meter hook for logical >>>> entities (individual programs, virtual machines on a shared server, >>>> etc.), an EMAN schema based on ENTITY-MIB would have to be forked to >>>> support this. That duplication of effort is pointless. >>>> >>>> And I say "when" because it's a matter of time. Lots of people are >>>> already working on this problem because there is a huge amount of money >>>> involved: >>>> >>>> 30-second internet search: >>>> http://research.microsoft.com/apps/pubs/default.aspx?id=120435 >>>> >>>> The IETF exists to enable others' innovation and interoperability in >>>> those pursuits. It is not our responsibility to debate the merits of >>>> this undertaking. It is, however, our duty to acknowledge this pursuit >>>> and prepare to integrate it into schema. >>>> >>>> So while it's good to make a nod to the predecessor ENTITY-MIB, I urge >>>> us to make a structural break from it. >>>> >>>>>> IMO any work in EMAN must contain the addition of an IETF power >>>>>> interface as described in claise architecture (or some compromise as you >>>>>> listed with IANA interfaces). It must also contain the addition of >>>>>> parent/child/aggregator relationship for non SNMP energy management. >>>>> You say we MUST adopt the power states from the claise architecture >>>>> and we MUST adopt the parent/child concept. >>>>> >>>>> The reasons you give for this in the paragraphs below are >>>>> - Otherwise we would not need an EMAN WG. >>>>> - This helps manufacturers to build sophisticated energy management >>>>> systems. >>>>> >>>>> I would not accept the first one as a technical argument, >>>>> On your second argument I would reply that providing good interfaces >>>>> for building sophisticated applications is certainly an objective >>>>> of our work in EMAN, but probably not the one with top priority. >>>> I agree with John's first point ("otherwise EMAN wouldn't exist") in the >>>> light that, even though it may not yet be fully and properly >>>> articulated, there is a sense that EMAN is needed because the existing >>>> solution architecture just doesn't quite do what is needed. I mean, why >>>> does your MIB draft exist? You see a problem and have tried to solve it >>>> because a solution doesn't yet exist. >>>> >>>> Here's a structural example to illustrate the point: >>>> >>>> Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor types, >>>> the data COULD be represented. For a single intelligent power supply on >>>> a server that monitors voltage, amperage, real power, apparent power, >>>> power factor, and frequency, we'd have 6 entities enumerated in >>>> ENTITY-MIB. And all of this would need to be tied together logically >>>> into a "Power Supply" concept, so that'd be another entity -- 7 in >>>> total. >>>> >>>> For a single server, sure, fine, do-able. Tiny scale. >>>> >>>> What about a 24-outlet PDU? Or a 84-circuit panelboard? >>>> >>>> http://www.kondra.com/circuit/circuit.html >>>> >>>> Eaton Branch Circuit Monitoring Whitepaper: >>>> http://tinyurl.com/5rpmhrp >>>> >>>> Managing 168 entities on a PDU or 588 entities on a panelboard is >>>> a ridiculous burden on the user who is consuming the agent's data. >>>> >>>> "Bonding" these entities that are a common purpose reduces the magnitude >>>> by a factor of 7, and simplifies the conceptual use of the framework. >>>> Users don't need to think in terms of "voltage sensor for Outlet 1" but >>>> instead can refer to that same data as "Outlet 1's voltage." >>>> >>>> Juergen, it seems like you're so busy focused on a conceptual model that >>>> real-world usability may be getting sacrificed. Each of your examples >>>> only reflects a single entity at a time. Why not kick up the examples a >>>> notch and model something like an intelligent PDU with the following >>>> properties? >>>> >>>> 1. 24 outlets, single phase >>>> 2. 6 banks (4 outlets per bank), single phase >>>> 3. 2 inputs (3 banks per input), three phase >>>> 4. "Ganged" outlets (multiple outlets that are managed as one >>>> construct) >>>> 5. High current alerts, low current alerts, circuit breaker alerts, >>>> high voltage alerts (spikes), low voltage alerts (sags) -- all of >>>> which can be applied to a physical entity or a logical entity >>>> (like an outlet "gang") >>>> 6. Internal network card and metering logic >>>> 7. Outlets "owned" by different users (think co-location facility, >>>> "context") >>>> 8. Manage power via 5 different interface modalities/mechanisms >>>> 9. Except for the existence of the outlets/banks/inputs/"gangs", all >>>> other properties are potentially optional >>>> >>>> I challenge you -- everyone participating in the EMAN list -- to model >>>> this level of complexity. If your MIB can withstand this, it's a good >>>> MIB (IMO, of course). >>>> Thanks, >>>> Chris >>> _______________________________________________ >>> eman mailing list >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Wed Mar 2 09:38:03 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FE33A681B for ; Wed, 2 Mar 2011 09:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPj2LfU3WVpy for ; Wed, 2 Mar 2011 09:38:00 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 51D363A680F for ; Wed, 2 Mar 2011 09:38:00 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22Hd5PC017007; Wed, 2 Mar 2011 18:39:05 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p22Hd4Kf015916; Wed, 2 Mar 2011 18:39:05 +0100 (CET) Message-ID: <4D6E80B8.6060002@cisco.com> Date: Wed, 02 Mar 2011 18:39:04 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruce Nordman References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070808050300010509080201" Cc: eman mailing list Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:38:03 -0000 This is a multi-part message in MIME format. --------------070808050300010509080201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, In the industry, there are multiple series of power states: - The ACPI standard. In practice, mainly used for PCs in case of non operational power states - The DMTF Power State Management Profile defines an information model over web services. The DMTF has 6 power states, 5 of them non-operational. They merged all operational power states into a single one: "on". - Some manufacturers have their own power state series. And there is an attempt to define the EMAN states in the EMAN framework, which would be a new power states series, at least for the operational ones. In the world of PCs in case of non operational power states, ACPI seems well accepted. However, my point is the following: there is no clear winner in terms of adopted series of power state in the industry. I believe I would be dangerous to bet on power state series based on our knowledge today. The industry will decide, and maybe it will be a new power states series. What I believe the solution is in terms of EMAN: - we must be ready to support multiple power states series - we must be ready to support a new power states series. - the device must report which power states series it supports In conclusion: be flexible and support all Regards, Benoit. > I am reposting Juergen's email about power states. > While the subsequent discussion has been important > and useful, it is on a different topic. So, please let's > also make progress on this topic. > --Bruce > > On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek > wrote: > > Dear all, > > We have two proposals for a Power/Energy MIB module: > > - draft-claise-energy-monitoring-mib-06 > - draft-quittek-power-mib-02 > > Among the authors of both documents we are currently trying to > merge them. > But there are some open issues that should be discussed on the mailing > list. Here is the probably biggest of them: modeling power states. > > For simplifying energy management we want to introduce the concept of > power states (aka power levels). A power state will indicate > roughly how > much power a device consumes. Examples for simple power states > are off, > sleep, and operational states. > > In the envisioned EMAN MIB modules, a power state is characterized > by a > descriptive name and the device's expected power input in this state > (max/min/average). > > Power states are not a new concept. The DMTF has already defined > a set of > power states and there is the Other standards bodies as the DMTF > (Distributed Management Task Force) and there is the ACPI (Advanced > Configuration and Power Interface) for PC motherboards. And there > may be > more than these out there. I listed some DMTF and ACPI states at > the end > of this message. > > An easy solution for EMAN would be just adopting one of these sets. > However, there are issues with the ones we looked at. ACPI was > developed > for PC motherboards and is quite PC-centric. Also it defines > states that > seem to be superfluous, because so far, almost no one has implemented > them. Also the DMTF model seems to have a narrower scope than > envisioned > by the EMAN WG. > > At some point in time, the EMAN WG hast to make a decision, which > power > state model to adopt. Here is a set of alternatives. The first > four have > fixed sets of power states. > > Option 1: fixed minimum > Just support three power states (off, sleep (stand-by), operational) > This has clear semantics, but there are several people claiming > it's too > restrictive. > > Option 2: fixed DMTF > Just use the states defined by DMTF. > Might be too much focussed n PCs. > > Option 3: fixed ACPI > Just use the states defined by ACPI. > Might be too much focussed n PCs. > > > > Option 4: fixed EMAN > Define a new fixed set of power levels within the EMAN WG. > > Option 5: IANA-registered power states > Have power states be registered at IANA. > We would start with registering (off, sleep, operational, the DMTF > set, > and the ACPI set. > Manufacturers can then register further ones. > > > There has been discussions pointing out that these fixed sets may > not be > sufficient, particularly if non-IT equipment should also be covered. > > For being more open, the idea to support user-defined or > manufacturer-defined power states of devices has been developed. > In such > a state, for example, certain components of a device may be > switched off > or put to sleep. Which ones are switched off in which state is to be > defined by the user/operator/manufacturer and may be chosen such that > operational needs are met. > > Again, there are several proposals how to do this. All of them > favor a > two-level approach that distinguishes between rather flexible > functional > power states and rather fixed basic power states. Functional > power states > would be defined by the manufacturer, operator, or user. These > would be > the power states that would be reported by a device. However, in > order to > better define the semantics of functional power states, Each of these > would be mapped to exactly one basic power states. This means that a > property of any functional state would be the basic state it maps to. > Basic power states would be fixed, such as the ones used in > options 1-5. > An easy example would be functional power states defined by > user/operator/manufacturer with each state indicating whether it > is an off > state, a sleep state or an operational state. > > Here are the corresponding options: > > Option 6: flexible functional states mapped to a fixed set of > basic states > States could be defined flexibly. But each state would indicate a > basic > state to which it corresponds. Basic states could be either basic > (off/sleep/operational) or the DMTF set or the ACPI set > > Option 7: flexible functional states mapped to a IANA registered > set of > basic states > This is like Option 6, but basic states would be registered at > IANA and > can be extended. We would register all DMTF and ACPI states and > probably > some more at IANA. Manufacturers could add more. > > Option 8: IANA-registered sets of functional states, only three basic > states > The main reasoning behind this option is that is should always be > clear > whether a power state is an off state, a sleep state, or an > operational > state. Therefore, only these three basic states are supported. This > would be in line with an instance of Option 6. However, this > option has > an extension for the functional states. It suggests that for > customizing > devices in order to be compliant with given management systems, for > example a DMTF-based system, it should be possible to restrict > functional > power states to a given set that is registered at IANA. An > example would > be the DMTF states. We would register a flag at IANA that > indicates we > are using DMTF states only. This would signal the management > application > that all power state IDs are in line with power state numbering as > defined > by IANA. Analogously, ACPI and further sets could be registered > at IANA. > A fallback to Option 6 could be realized by registering a set > number of 0 > at IANA that does not impose any limit for functional states. > > Obviously, there are more possible options. If you think there is a > better one, please send it to this list. > > I know this discussion is not easy, but we have to have it in order to > make the right decision in the EMAN WG. Please take some time and > think > about what you consider to be the best way to go. And of course send > questions on the issue. > > Thanks. > > Juergen > > > DMTF (Distributed Management Task Force) power states: > - 2 (Power On) > - 3 (Sleep - Light) > - 4 (Sleep - Deep) > - 5 (Power Cycle (Off Soft)) > - 6 (Power Off - Hard) > - 7 (Hibernate) > - 8 (Power Off - Soft) > - 9 (Power Cycle (Off Hard)) > - 10 (Master Bus Reset) > - 11 (Diagnostic Interrupt (NMI)) > - 12 (Power Off - Soft Graceful) > - 13 (Power Off - Hard Graceful) > - 14 (Master Bus Reset Graceful) > - 15 (Power Cycle (Off - Soft Graceful)) > - 16 (Power Cycle (Off - Hard Graceful)) > > ACPI (Advanced Configuration and Power Interface Specification) power > states for PC motherboards: > - G3-S5 (Off-Hard) > - G2-S5 (Off-Soft) > - G1-S4 (Hibernate) > - G1-S3 (Sleep-Deep) > - G1-S2 (Sleep-Light) > - G1-S1 (Sleep-Light) > - G0-S0-P5 > - G0-S0-P4 > - G0-S0-P3 > - G0-S0-P2 > - G0-S0-P2 > - G0-S0-P2 > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------070808050300010509080201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

In the industry, there are multiple series of power states:
-  The ACPI standard. In practice, mainly used for PCs in case of non operational power states
-  The DMTF Power State Management Profile defines an information model over web services. The DMTF has 6 power states, 5 of them non-operational. They merged all operational power states into a single one: "on".
- Some manufacturers have their own power state series.

And there is an attempt to define the EMAN states in the EMAN framework, which would be a new power states series, at least for the operational ones.

In the world of PCs in case of non operational power states, ACPI seems well accepted.
However, my point is the following: there is no clear winner in terms of adopted series of power state in the industry.
I believe I would be dangerous to bet on power state series based on our knowledge today. The industry will decide, and maybe it will be a new power states series.

What I believe the solution is in terms of EMAN:
- we must be ready to support multiple power states series
- we must be ready to support a new power states series.
- the device must report which power states series it supports
In conclusion: be flexible and support all

Regards, Benoit.

I am reposting Juergen's email about power states.
While the subsequent discussion has been important
and useful, it is on a different topic.  So, please let's
also make progress on this topic.
--Bruce

On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek <Quittek@neclab.eu> wrote:
Dear all,

We have two proposals for a Power/Energy MIB module:

 - draft-claise-energy-monitoring-mib-06
 - draft-quittek-power-mib-02

Among the authors of both documents we are currently trying to merge them.
But there are some open issues that should be discussed on the mailing
list.  Here is the probably biggest of them: modeling power states.

For simplifying energy management we want to introduce the concept of
power states (aka power levels).  A power state will indicate roughly how
much power a device consumes.  Examples for simple power states are off,
sleep, and operational states.

In the envisioned EMAN MIB modules, a power state is characterized by a
descriptive name and the device's expected power input in this state
(max/min/average).

Power states are not a new concept.  The DMTF has already defined a set of
power states and there is the Other standards bodies as the DMTF
(Distributed Management Task Force) and there  is the ACPI (Advanced
Configuration and Power Interface) for PC motherboards.  And there may be
more than these out there.  I listed some DMTF and ACPI states at the end
of this message.

An easy solution for EMAN would be just adopting one of these sets.
However, there are issues with the ones we looked at.  ACPI was developed
for PC motherboards and is quite PC-centric.  Also it defines states that
seem to be superfluous, because so far, almost no one has implemented
them.  Also the DMTF model seems to have a narrower scope than envisioned
by the EMAN WG.

At some point in time, the EMAN WG hast to make a decision, which power
state model to adopt.  Here is a set of alternatives. The first four have
fixed sets of power states.

Option 1: fixed minimum
Just support three power states (off, sleep (stand-by), operational)
This has clear semantics, but there are several people claiming it's too
restrictive.

Option 2: fixed DMTF
Just use the states defined by DMTF.
Might be too much focussed n PCs.

Option 3: fixed ACPI
Just use the states defined by ACPI.
Might be too much focussed n PCs.



Option 4: fixed EMAN
Define a new fixed set of power levels within the EMAN WG.

Option 5: IANA-registered power states
Have power states be registered at IANA.
We would start with registering (off, sleep, operational, the DMTF set,
and the ACPI set.
Manufacturers can then register further ones.


There has been discussions pointing out that these fixed sets may not be
sufficient, particularly if non-IT equipment should also be covered.

For being more open, the idea to support user-defined or
manufacturer-defined power states of devices has been developed.  In such
a state, for example, certain components of a device may be switched off
or put to sleep.  Which ones are switched off in which state is to be
defined by the user/operator/manufacturer and may be chosen such that
operational needs are met.

Again, there are several proposals how to do this.  All of them favor a
two-level approach that distinguishes between rather flexible functional
power states and rather fixed basic power states.  Functional power states
would be defined by the manufacturer, operator, or user.  These would be
the power states that would be reported by a device.  However, in order to
better define the semantics of functional power states, Each of these
would be mapped to exactly one basic power states.  This means that a
property of any functional state would be the basic state it maps to.
Basic power states would be fixed, such as the ones used in options 1-5.
An easy example would be functional power states defined by
user/operator/manufacturer with each state indicating whether it is an off
state, a sleep state or an operational state.

Here are the corresponding options:

Option 6: flexible functional states mapped to a fixed set of basic states
States could be defined flexibly.  But each state would indicate a basic
state to which it corresponds. Basic states could be either basic
(off/sleep/operational) or the DMTF set or the ACPI set

Option 7: flexible functional states mapped to a IANA registered set of
basic states
This is like Option 6, but basic states would be registered at IANA and
can be extended.  We would register all DMTF and ACPI states and probably
some more at IANA. Manufacturers could add more.

Option 8: IANA-registered sets of functional states, only three basic
states
The main reasoning behind this option is that is should always be clear
whether a power state is an off state, a sleep state, or an operational
state.  Therefore, only these three basic states are supported.  This
would be in line with an instance of Option 6.  However, this option has
an extension for the functional states.  It suggests that for customizing
devices in order to be compliant with given management systems, for
example a DMTF-based system, it should be possible to restrict functional
power states to a given set that is registered at IANA.  An example would
be the DMTF states.  We would register a flag at IANA that indicates we
are using DMTF states only.  This would signal the management application
that all power state IDs are in line with power state numbering as defined
by IANA.  Analogously, ACPI and further sets could be registered at IANA.
A fallback to Option 6 could be realized by registering a set number of 0
at IANA that does not impose any limit for functional states.

Obviously, there are more possible options.  If you think there is a
better one, please send it to this list.

I know this discussion is not easy, but we have to have it in order to
make the right decision in the EMAN WG.  Please take some time and think
about what you consider to be the best way to go.  And of course send
questions on the issue.

Thanks.

   Juergen


DMTF (Distributed Management Task Force) power states:
 - 2 (Power On)
 - 3 (Sleep - Light)
 - 4 (Sleep - Deep)
 - 5 (Power Cycle (Off Soft))
 - 6 (Power Off - Hard)
 - 7 (Hibernate)
 - 8 (Power Off - Soft)
 - 9 (Power Cycle (Off Hard))
 - 10 (Master Bus Reset)
 - 11 (Diagnostic Interrupt (NMI))
 - 12 (Power Off - Soft Graceful)
 - 13 (Power Off - Hard Graceful)
 - 14 (Master Bus Reset Graceful)
 - 15 (Power Cycle (Off - Soft Graceful))
 - 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced Configuration and Power Interface Specification) power
states for PC motherboards:
 - G3-S5 (Off-Hard)
 - G2-S5 (Off-Soft)
 - G1-S4 (Hibernate)
 - G1-S3 (Sleep-Deep)
 - G1-S2 (Sleep-Light)
 - G1-S1 (Sleep-Light)
 - G0-S0-P5
 - G0-S0-P4
 - G0-S0-P3
 - G0-S0-P2
 - G0-S0-P2
 - G0-S0-P2




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



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


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

--------------070808050300010509080201-- From bill.mielke@alcatel-lucent.com Wed Mar 2 11:46:04 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E473A687C for ; Wed, 2 Mar 2011 11:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gysD3xTXjtEt for ; Wed, 2 Mar 2011 11:46:03 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id B81973A6863 for ; Wed, 2 Mar 2011 11:46:03 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p22Jl8AZ026165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 13:47:08 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p22Jl8Dv002267 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Mar 2011 13:47:08 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 2 Mar 2011 13:47:08 -0600 From: "Mielke, William F (Bill)" To: eman mailing list Date: Wed, 2 Mar 2011 13:47:05 -0600 Thread-Topic: Re: [eman] Power States - really Thread-Index: AcvZEpuErEOBuFm0QuufCEcqvwjphQ== Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C171@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "tirth.ghose@gmail.com" Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:46:04 -0000 # Ted Ghose wrote: # # I'm dismayed that you failed to define a fine set of rule, and without th= at # you are putting your model forward. I am not sure what "fine set of rule" you are looking for. Can you please c= larify? As I said in in my previous email, I am putting some ideas out for consider= ation and discussion. That was my sole intent. I don't consider what I wr= itten to be putting a model forward, per se. As I also said in my previous= email this is not a fully cooked proposal (i.e. it is not a finished propo= sal with all of its various dependencies identified and fleshed out. Is this not a proper use of the email discussion list? # the elegant this model is, I fail to to understand what are the rule does= it=20 # stick to. Coming from a pure mathematics world, I'd like to define the "s= et" # before "set operations" Again, what rules are you looking for? All I have done is to identify a fe= w tables that might be used to expose product specific meta data which can = then be used by the management applications to interface with a managed ele= ment. Perhaps an alternative explanation might shed further light on my meaning. The intent is that the tables I specified would allow each product to self-= identify a list a power management features or capabilities which it suppor= ts (i.e. the emanCapabilitiesDefinitionsTable table). The intent is also t= o allow the products to self-identify a simple set of parameters which are = associated with those capabilities to enable a management application to me= aningfully interact with those capabilities (i.e. the emanEnumeratedTypeTab= le and emanEnumeratedValuesTable tables). All of the above exposes meta information which simply describes a set of c= apabilities (power related by virtue of being part of the EMAN work) that a= given device supports. It is declarative in nature and is provided to all= ow the management application to "discover" the unique capabilities of a gi= ven managed element. The actual work of monitoring and controling the currently defined "state" = for each such capability is accomplished via the last table (i.e. the emanP= roductCapabilities table). This is the table where the management applicat= ion would query for the current "capability settings" and/or where it would= effect controls by setting new values within those capabilities. When setting new values for a specific capability the meta information desc= ribed above would be used to constrain the value to fall within a proper do= main (e.g. a string, or an integer, or a specific selection from an enumera= ted type that was self-identified by the managed element). Let me offer a few definitions (are these the rules you want?) that may aid= in the interpretation of my meaning. ProductSpecificCapabilityID: An unsigned integer value used to uniquely identify a specific managed elem= ent defined capability. CapabilityName: A string value representing a human readable name for the capability. CapabilityTypeSpecification: This is any of String, Integer, Float, or a managed element defined Enumera= tionID EnumerationID: An unsigned integer value used to uniquely identify a specific managed elem= ent defined list of enumerated values. The managed element can define mult= iple distinct enumerations and these IDs are used to distinguish one such e= numeration from another. EnumerationName: A string value representing a human readable name for the enumeration. ValueID: An unsigned integer value used to uniquely identify a specific enumerated v= alue within a given Enumeration. The managed element can define multiple d= istinct values that represent the domain of alowable values for any given e= numeration and these IDs are used to distinguish one such value from anothe= r within that enumeration. ValueName: A string value representing a human readable name for the value. These nam= es are expected to be unique within any given enumeration (i.e. within Enum= erationID=3D15) but not across enumerations (i.e. the human readable name "= Off" may appear in any number of enumerations, just not multiple times with= in the same enumeration). So how does this all work? In the emanCapabilitiesDefinitionsTable the managed element is simply enume= rating a set of capabilities that it supports. This is purely declarative = information. Each row in the table defines one such capability and part of= that definition assigns a unique numerical ID to that capability, such as = 103 or 27. The table also defines a human readable name for that capabilit= y, such as "PortPowerControlFeature" or "FanPowerControlFeature" or "Lighti= ngDimmerControlFeature". The exact names and the semantics of what they do= is completely encapsulated within the managed element. Lastly the table a= ssociates a specific datatype with that capability which defines the domain= of meaningful values which can be assigned to that capability from an admi= nistrative perspective. So if the operator (or management application) is expected to assign a stri= ng or an integer or a float to a specific capability then it would specify = as much. I expect, however, that in most cases these values will correspond to enume= rated types. The emanEnumeratedTypeTable and emanEnumeratedValuesTable tab= les provide a declarative mechanism whereby the managed element can expose = any number of such enumerated types which can then be specified in the eman= CapabilitiesDefinitionsTable. If this is still unclear please feel free to ask for more clarification eit= her publicly on the list or by contacting me directly. I welcome any sort = of feedback. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein From ietf@quittek.at Wed Mar 2 12:43:19 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A4F3A68B0 for ; Wed, 2 Mar 2011 12:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdXIcAf56WaX for ; Wed, 2 Mar 2011 12:43:17 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 65A3C3A68AD for ; Wed, 2 Mar 2011 12:43:12 -0800 (PST) Received: from [192.168.0.4] (HSI-KBW-109-193-019-068.hsi7.kabel-badenwuerttemberg.de [109.193.19.68]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MAilT-1PjZRP0AjT-00BtJi; Wed, 02 Mar 2011 21:44:12 +0100 References: <4D6E80B8.6060002@cisco.com> In-Reply-To: <4D6E80B8.6060002@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2-816388978 Message-Id: <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> From: Juergen Quittek Date: Wed, 2 Mar 2011 21:44:12 +0100 To: Benoit Claise X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:1EEfPpHVT66ENb+Xxx2BUYTu5mVT9rYFbHVle+coxG6 XVkg/wVnJ/Z5YNHZvXFVzrAMOBsF9QZrjqo9qTBr76Dt6br89i eYbtu1Xp2WYOpm/6CXn6tde2uBCdF5ZfiQr68G3iCXIWA4TOWX JygPAH+J27aNNf3Z/LJjjZOdqWnWQ4SZCgNTa9P3cMnKMtTF7e Yny8dL7EWPIe7uJD+BU2w== Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:43:19 -0000 --Apple-Mail-2-816388978 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, Just a short question: Which power state would apply to my notebook computer when - it is switched of, but charging its batteries.=20 This is an off-state with relatively high power consumption.=20 Is this covered by any ACPI or DMTF states or by the states in the = drafts we have? - it is switched on and fully operational, but running on built-in = battery only. This is an operational state with zero power consumption, at least = as seen from outside. Again, how can we cover this with states described so far? Thanks, Juergen Am 02.03.2011 um 18:39 schrieb Benoit Claise: > Dear all, >=20 > In the industry, there are multiple series of power states: > - The ACPI standard. In practice, mainly used for PCs in case of non = operational power states > - The DMTF Power State Management Profile defines an information = model over web services. The DMTF has 6 power states, 5 of them = non-operational. They merged all operational power states into a single = one: "on". > - Some manufacturers have their own power state series. >=20 > And there is an attempt to define the EMAN states in the EMAN = framework, which would be a new power states series, at least for the = operational ones. >=20 > In the world of PCs in case of non operational power states, ACPI = seems well accepted. > However, my point is the following: there is no clear winner in terms = of adopted series of power state in the industry. > I believe I would be dangerous to bet on power state series based on = our knowledge today. The industry will decide, and maybe it will be a = new power states series. >=20 > What I believe the solution is in terms of EMAN: > - we must be ready to support multiple power states series > - we must be ready to support a new power states series.=20 > - the device must report which power states series it supports > In conclusion: be flexible and support all >=20 > Regards, Benoit. >=20 >> I am reposting Juergen's email about power states. >> While the subsequent discussion has been important >> and useful, it is on a different topic. So, please let's >> also make progress on this topic. >> --Bruce >>=20 >> On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek = wrote: >> Dear all, >>=20 >> We have two proposals for a Power/Energy MIB module: >>=20 >> - draft-claise-energy-monitoring-mib-06 >> - draft-quittek-power-mib-02 >>=20 >> Among the authors of both documents we are currently trying to merge = them. >> But there are some open issues that should be discussed on the = mailing >> list. Here is the probably biggest of them: modeling power states. >>=20 >> For simplifying energy management we want to introduce the concept of >> power states (aka power levels). A power state will indicate roughly = how >> much power a device consumes. Examples for simple power states are = off, >> sleep, and operational states. >>=20 >> In the envisioned EMAN MIB modules, a power state is characterized by = a >> descriptive name and the device's expected power input in this state >> (max/min/average). >>=20 >> Power states are not a new concept. The DMTF has already defined a = set of >> power states and there is the Other standards bodies as the DMTF >> (Distributed Management Task Force) and there is the ACPI (Advanced >> Configuration and Power Interface) for PC motherboards. And there = may be >> more than these out there. I listed some DMTF and ACPI states at the = end >> of this message. >>=20 >> An easy solution for EMAN would be just adopting one of these sets. >> However, there are issues with the ones we looked at. ACPI was = developed >> for PC motherboards and is quite PC-centric. Also it defines states = that >> seem to be superfluous, because so far, almost no one has implemented >> them. Also the DMTF model seems to have a narrower scope than = envisioned >> by the EMAN WG. >>=20 >> At some point in time, the EMAN WG hast to make a decision, which = power >> state model to adopt. Here is a set of alternatives. The first four = have >> fixed sets of power states. >>=20 >> Option 1: fixed minimum >> Just support three power states (off, sleep (stand-by), operational) >> This has clear semantics, but there are several people claiming it's = too >> restrictive. >>=20 >> Option 2: fixed DMTF >> Just use the states defined by DMTF. >> Might be too much focussed n PCs. >>=20 >> Option 3: fixed ACPI >> Just use the states defined by ACPI. >> Might be too much focussed n PCs. >>=20 >>=20 >>=20 >> Option 4: fixed EMAN >> Define a new fixed set of power levels within the EMAN WG. >>=20 >> Option 5: IANA-registered power states >> Have power states be registered at IANA. >> We would start with registering (off, sleep, operational, the DMTF = set, >> and the ACPI set. >> Manufacturers can then register further ones. >>=20 >>=20 >> There has been discussions pointing out that these fixed sets may not = be >> sufficient, particularly if non-IT equipment should also be covered. >>=20 >> For being more open, the idea to support user-defined or >> manufacturer-defined power states of devices has been developed. In = such >> a state, for example, certain components of a device may be switched = off >> or put to sleep. Which ones are switched off in which state is to be >> defined by the user/operator/manufacturer and may be chosen such that >> operational needs are met. >>=20 >> Again, there are several proposals how to do this. All of them favor = a >> two-level approach that distinguishes between rather flexible = functional >> power states and rather fixed basic power states. Functional power = states >> would be defined by the manufacturer, operator, or user. These would = be >> the power states that would be reported by a device. However, in = order to >> better define the semantics of functional power states, Each of these >> would be mapped to exactly one basic power states. This means that a >> property of any functional state would be the basic state it maps to. >> Basic power states would be fixed, such as the ones used in options = 1-5. >> An easy example would be functional power states defined by >> user/operator/manufacturer with each state indicating whether it is = an off >> state, a sleep state or an operational state. >>=20 >> Here are the corresponding options: >>=20 >> Option 6: flexible functional states mapped to a fixed set of basic = states >> States could be defined flexibly. But each state would indicate a = basic >> state to which it corresponds. Basic states could be either basic >> (off/sleep/operational) or the DMTF set or the ACPI set >>=20 >> Option 7: flexible functional states mapped to a IANA registered set = of >> basic states >> This is like Option 6, but basic states would be registered at IANA = and >> can be extended. We would register all DMTF and ACPI states and = probably >> some more at IANA. Manufacturers could add more. >>=20 >> Option 8: IANA-registered sets of functional states, only three basic >> states >> The main reasoning behind this option is that is should always be = clear >> whether a power state is an off state, a sleep state, or an = operational >> state. Therefore, only these three basic states are supported. This >> would be in line with an instance of Option 6. However, this option = has >> an extension for the functional states. It suggests that for = customizing >> devices in order to be compliant with given management systems, for >> example a DMTF-based system, it should be possible to restrict = functional >> power states to a given set that is registered at IANA. An example = would >> be the DMTF states. We would register a flag at IANA that indicates = we >> are using DMTF states only. This would signal the management = application >> that all power state IDs are in line with power state numbering as = defined >> by IANA. Analogously, ACPI and further sets could be registered at = IANA. >> A fallback to Option 6 could be realized by registering a set number = of 0 >> at IANA that does not impose any limit for functional states. >>=20 >> Obviously, there are more possible options. If you think there is a >> better one, please send it to this list. >>=20 >> I know this discussion is not easy, but we have to have it in order = to >> make the right decision in the EMAN WG. Please take some time and = think >> about what you consider to be the best way to go. And of course send >> questions on the issue. >>=20 >> Thanks. >>=20 >> Juergen >>=20 >>=20 >> DMTF (Distributed Management Task Force) power states: >> - 2 (Power On) >> - 3 (Sleep - Light) >> - 4 (Sleep - Deep) >> - 5 (Power Cycle (Off Soft)) >> - 6 (Power Off - Hard) >> - 7 (Hibernate) >> - 8 (Power Off - Soft) >> - 9 (Power Cycle (Off Hard)) >> - 10 (Master Bus Reset) >> - 11 (Diagnostic Interrupt (NMI)) >> - 12 (Power Off - Soft Graceful) >> - 13 (Power Off - Hard Graceful) >> - 14 (Master Bus Reset Graceful) >> - 15 (Power Cycle (Off - Soft Graceful)) >> - 16 (Power Cycle (Off - Hard Graceful)) >>=20 >> ACPI (Advanced Configuration and Power Interface Specification) power >> states for PC motherboards: >> - G3-S5 (Off-Hard) >> - G2-S5 (Off-Soft) >> - G1-S4 (Hibernate) >> - G1-S3 (Sleep-Deep) >> - G1-S2 (Sleep-Light) >> - G1-S1 (Sleep-Light) >> - G0-S0-P5 >> - G0-S0-P4 >> - G0-S0-P3 >> - G0-S0-P2 >> - G0-S0-P2 >> - G0-S0-P2 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >>=20 >>=20 >>=20 >> --=20 >> Bruce Nordman >> Lawrence Berkeley National Laboratory >> eetd.lbl.gov/ea/nordman >> BNordman@LBL.gov >> 510-486-7089 >> m: 510-501-7943 >>=20 >>=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 --Apple-Mail-2-816388978 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear all,

In the industry, there are multiple series of power states:
-  The ACPI standard. In practice, mainly used for PCs in case = of non operational power states
-  The DMTF Power State Management Profile defines an = information model over web services. The DMTF has 6 power states, 5 of them non-operational. They merged all operational power states into a single one: "on".
- Some manufacturers have their own power state series.

And there is an attempt to define the EMAN states in the EMAN framework, which would be a new power states series, at least for the operational ones.

In the world of PCs in case of non operational power states, ACPI seems well accepted.
However, my point is the following: there is no clear winner in terms of adopted series of power state in the industry.
I believe I would be dangerous to bet on power state series based on our knowledge today. The industry will decide, and maybe it will be a new power states series.

What I believe the solution is in terms of EMAN:
- we must be ready to support multiple power states series
- we must be ready to support a new power states series.
- the device must report which power states series it supports
In conclusion: be flexible and support all

Regards, Benoit.

I am reposting Juergen's email about power states.
While the subsequent discussion has been important
and useful, it is on a different topic.  So, please let's
also make progress on this topic.
--Bruce

On Mon, Feb 28, 2011 at 4:07 AM, = Juergen Quittek <Quittek@neclab.eu> wrote:
Dear all,

We have two proposals for a Power/Energy MIB module:

 - draft-claise-energy-monitoring-mib-06
 - draft-quittek-power-mib-02

Among the authors of both documents we are currently trying to merge them.
But there are some open issues that should be discussed on the mailing
list.  Here is the probably biggest of them: modeling = power states.

For simplifying energy management we want to introduce the concept of
power states (aka power levels).  A power state will = indicate roughly how
much power a device consumes.  Examples for simple power states are off,
sleep, and operational states.

In the envisioned EMAN MIB modules, a power state is characterized by a
descriptive name and the device's expected power input in this state
(max/min/average).

Power states are not a new concept.  The DMTF has already defined a set of
power states and there is the Other standards bodies as the DMTF
(Distributed Management Task Force) and there  is the = ACPI (Advanced
Configuration and Power Interface) for PC motherboards. =  And there may be
more than these out there.  I listed some DMTF and ACPI = states at the end
of this message.

An easy solution for EMAN would be just adopting one of these sets.
However, there are issues with the ones we looked at. =  ACPI was developed
for PC motherboards and is quite PC-centric.  Also it = defines states that
seem to be superfluous, because so far, almost no one has implemented
them.  Also the DMTF model seems to have a narrower scope = than envisioned
by the EMAN WG.

At some point in time, the EMAN WG hast to make a decision, which power
state model to adopt.  Here is a set of alternatives. The first four have
fixed sets of power states.

Option 1: fixed minimum
Just support three power states (off, sleep (stand-by), operational)
This has clear semantics, but there are several people claiming it's too
restrictive.

Option 2: fixed DMTF
Just use the states defined by DMTF.
Might be too much focussed n PCs.

Option 3: fixed ACPI
Just use the states defined by ACPI.
Might be too much focussed n PCs.



Option 4: fixed EMAN
Define a new fixed set of power levels within the EMAN WG.

Option 5: IANA-registered power states
Have power states be registered at IANA.
We would start with registering (off, sleep, operational, the DMTF set,
and the ACPI set.
Manufacturers can then register further ones.


There has been discussions pointing out that these fixed sets may not be
sufficient, particularly if non-IT equipment should also be covered.

For being more open, the idea to support user-defined or
manufacturer-defined power states of devices has been developed.  In such
a state, for example, certain components of a device may be switched off
or put to sleep.  Which ones are switched off in which = state is to be
defined by the user/operator/manufacturer and may be chosen such that
operational needs are met.

Again, there are several proposals how to do this.  All = of them favor a
two-level approach that distinguishes between rather flexible functional
power states and rather fixed basic power states. =  Functional power states
would be defined by the manufacturer, operator, or user.  These would be
the power states that would be reported by a device. =  However, in order to
better define the semantics of functional power states, Each of these
would be mapped to exactly one basic power states.  This = means that a
property of any functional state would be the basic state it maps to.
Basic power states would be fixed, such as the ones used in options 1-5.
An easy example would be functional power states defined = by
user/operator/manufacturer with each state indicating whether it is an off
state, a sleep state or an operational state.

Here are the corresponding options:

Option 6: flexible functional states mapped to a fixed set of basic states
States could be defined flexibly.  But each state would indicate a basic
state to which it corresponds. Basic states could be either basic
(off/sleep/operational) or the DMTF set or the ACPI set

Option 7: flexible functional states mapped to a IANA registered set of
basic states
This is like Option 6, but basic states would be registered at IANA and
can be extended.  We would register all DMTF and ACPI = states and probably
some more at IANA. Manufacturers could add more.

Option 8: IANA-registered sets of functional states, only three basic
states
The main reasoning behind this option is that is should always be clear
whether a power state is an off state, a sleep state, or an operational
state.  Therefore, only these three basic states are supported.  This
would be in line with an instance of Option 6.  However, = this option has
an extension for the functional states.  It suggests that = for customizing
devices in order to be compliant with given management systems, for
example a DMTF-based system, it should be possible to restrict functional
power states to a given set that is registered at IANA. =  An example would
be the DMTF states.  We would register a flag at IANA = that indicates we
are using DMTF states only.  This would signal the = management application
that all power state IDs are in line with power state numbering as defined
by IANA.  Analogously, ACPI and further sets could be registered at IANA.
A fallback to Option 6 could be realized by registering a set number of 0
at IANA that does not impose any limit for functional = states.

Obviously, there are more possible options.  If you think there is a
better one, please send it to this list.

I know this discussion is not easy, but we have to have it in order to
make the right decision in the EMAN WG.  Please take some = time and think
about what you consider to be the best way to go.  And of course send
questions on the issue.

Thanks.

   Juergen


DMTF (Distributed Management Task Force) power states:
 - 2 (Power On)
 - 3 (Sleep - Light)
 - 4 (Sleep - Deep)
 - 5 (Power Cycle (Off Soft))
 - 6 (Power Off - Hard)
 - 7 (Hibernate)
 - 8 (Power Off - Soft)
 - 9 (Power Cycle (Off Hard))
 - 10 (Master Bus Reset)
 - 11 (Diagnostic Interrupt (NMI))
 - 12 (Power Off - Soft Graceful)
 - 13 (Power Off - Hard Graceful)
 - 14 (Master Bus Reset Graceful)
 - 15 (Power Cycle (Off - Soft Graceful))
 - 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced Configuration and Power Interface Specification) power
states for PC motherboards:
 - G3-S5 (Off-Hard)
 - G2-S5 (Off-Soft)
 - G1-S4 (Hibernate)
 - G1-S3 (Sleep-Deep)
 - G1-S2 (Sleep-Light)
 - G1-S1 (Sleep-Light)
 - G0-S0-P5
 - G0-S0-P4
 - G0-S0-P3
 - G0-S0-P2
 - G0-S0-P2
 - G0-S0-P2




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



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


_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/m=
ailman/listinfo/eman

_______________________________________________
eman mailing = list
eman@ietf.org
https://www.ietf.org/ma= ilman/listinfo/eman

= --Apple-Mail-2-816388978-- From msuchoff@gmail.com Wed Mar 2 11:33:55 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4541D3A6872 for ; Wed, 2 Mar 2011 11:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4HsU9lX5cDR for ; Wed, 2 Mar 2011 11:33:52 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6DB243A685A for ; Wed, 2 Mar 2011 11:33:51 -0800 (PST) Received: by fxm15 with SMTP id 15so360808fxm.31 for ; Wed, 02 Mar 2011 11:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=b3DDuPy3Jj7OfFGXxZjPNOTELPKQ0VjkQobuQSMeRhc=; b=aIE0EMBVmkj2P5xv3YCULGc9MRTf5+F99gnAG/SaJYNaaEEiT3FDWWK4HtzAHIJGmK Xv27M9bjwjHxymKTl1m9qkX5fjC1lrrPQU5xEa8rz+ySl58BCUCMDDo/6CQYFaUU3zNW jVhM/TO32FvS6zs0Nb+kEJxvtoY10zmNK0R8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=naBS9LIfDBZETydPfyc17jUdKJMCYi6amVNNVe/PJOtK0vI1OQ1CqSrWZVfRc5tGlx CxiX62+Kq4jOxnJkK5N/EkRzlrHlXTNp7OTmMLD3z7zB9UXiIQKfcrnZyCpVlUL69EVi bqNpZjolBmwuZXBXPmBnX77mZP6gswtHPF8bw= MIME-Version: 1.0 Received: by 10.223.97.2 with SMTP id j2mr356833fan.23.1299094496695; Wed, 02 Mar 2011 11:34:56 -0800 (PST) Sender: msuchoff@gmail.com Received: by 10.223.112.72 with HTTP; Wed, 2 Mar 2011 11:34:56 -0800 (PST) In-Reply-To: <4D6E80B8.6060002@cisco.com> References: <4D6E80B8.6060002@cisco.com> Date: Wed, 2 Mar 2011 14:34:56 -0500 X-Google-Sender-Auth: R8xPzDGoXsf5CLmuMahd-Aw1TkM Message-ID: From: Michael Suchoff To: Benoit Claise Content-Type: multipart/alternative; boundary=20cf3054ac79015745049d850277 Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:48:52 -0000 --20cf3054ac79015745049d850277 Content-Type: text/plain; charset=ISO-8859-1 The ACPI & DMTF power states are not sufficient for real world applications. For example, take Cisco data labs that employ Raritan PDUs and Raritan's Power IQ (Power IQ is a power management service program). Each night the following actions take place at Cisco 1. Power IQ scheduler determines which outlets must be turned off. 2. If outlet is associated with an server, a graceful shutdown takes place (ssh script sent to server to run /etc/shutdown, etc.) 3. AC power to the outlet is turned off. Now assume that the server has a BMC (baseboard management controller) that can report ACPI power states. These power states refer to the main processor board and do not include the BMC itself. In other words, ACPI power state OFF means no power is being supplied to the motherboard, but AC power is still being supplied to the server so that the BMC can continue to function. When above step 3 occurs to turn off all power to the server, the BMC ceases to function. This power state is outside the scope of ACPI. Now let's assume that Raritan Power IQ adds the capability of interrogating the ACPI power states of the server and wants to map them into the EMAN standard. Clearly at least one additional power state is required (AC power turned off). in actual practice, a user would also like to know such things available from a PDU like "AC power lost due to circuit breaker trip", etc. On Wed, Mar 2, 2011 at 12:39 PM, Benoit Claise wrote: > Dear all, > > In the industry, there are multiple series of power states: > - The ACPI standard. In practice, mainly used for PCs in case of non > operational power states > - The DMTF Power State Management Profile defines an information model > over web services. The DMTF has 6 power states, 5 of them non-operational. > They merged all operational power states into a single one: "on". > - Some manufacturers have their own power state series. > > And there is an attempt to define the EMAN states in the EMAN framework, > which would be a new power states series, at least for the operational ones. > > In the world of PCs in case of non operational power states, ACPI seems > well accepted. > However, my point is the following: there is no clear winner in terms of > adopted series of power state in the industry. > I believe I would be dangerous to bet on power state series based on our > knowledge today. The industry will decide, and maybe it will be a new power > states series. > > What I believe the solution is in terms of EMAN: > - we must be ready to support multiple power states series > - we must be ready to support a new power states series. > - the device must report which power states series it supports > In conclusion: be flexible and support all > > Regards, Benoit. > > > I am reposting Juergen's email about power states. > While the subsequent discussion has been important > and useful, it is on a different topic. So, please let's > also make progress on this topic. > --Bruce > > On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: > >> Dear all, >> >> We have two proposals for a Power/Energy MIB module: >> >> - draft-claise-energy-monitoring-mib-06 >> - draft-quittek-power-mib-02 >> >> Among the authors of both documents we are currently trying to merge them. >> But there are some open issues that should be discussed on the mailing >> list. Here is the probably biggest of them: modeling power states. >> >> For simplifying energy management we want to introduce the concept of >> power states (aka power levels). A power state will indicate roughly how >> much power a device consumes. Examples for simple power states are off, >> sleep, and operational states. >> >> In the envisioned EMAN MIB modules, a power state is characterized by a >> descriptive name and the device's expected power input in this state >> (max/min/average). >> >> Power states are not a new concept. The DMTF has already defined a set of >> power states and there is the Other standards bodies as the DMTF >> (Distributed Management Task Force) and there is the ACPI (Advanced >> Configuration and Power Interface) for PC motherboards. And there may be >> more than these out there. I listed some DMTF and ACPI states at the end >> of this message. >> >> An easy solution for EMAN would be just adopting one of these sets. >> However, there are issues with the ones we looked at. ACPI was developed >> for PC motherboards and is quite PC-centric. Also it defines states that >> seem to be superfluous, because so far, almost no one has implemented >> them. Also the DMTF model seems to have a narrower scope than envisioned >> by the EMAN WG. >> >> At some point in time, the EMAN WG hast to make a decision, which power >> state model to adopt. Here is a set of alternatives. The first four have >> fixed sets of power states. >> >> Option 1: fixed minimum >> Just support three power states (off, sleep (stand-by), operational) >> This has clear semantics, but there are several people claiming it's too >> restrictive. >> >> Option 2: fixed DMTF >> Just use the states defined by DMTF. >> Might be too much focussed n PCs. >> >> Option 3: fixed ACPI >> Just use the states defined by ACPI. >> Might be too much focussed n PCs. >> >> >> >> Option 4: fixed EMAN >> Define a new fixed set of power levels within the EMAN WG. >> >> Option 5: IANA-registered power states >> Have power states be registered at IANA. >> We would start with registering (off, sleep, operational, the DMTF set, >> and the ACPI set. >> Manufacturers can then register further ones. >> >> >> There has been discussions pointing out that these fixed sets may not be >> sufficient, particularly if non-IT equipment should also be covered. >> >> For being more open, the idea to support user-defined or >> manufacturer-defined power states of devices has been developed. In such >> a state, for example, certain components of a device may be switched off >> or put to sleep. Which ones are switched off in which state is to be >> defined by the user/operator/manufacturer and may be chosen such that >> operational needs are met. >> >> Again, there are several proposals how to do this. All of them favor a >> two-level approach that distinguishes between rather flexible functional >> power states and rather fixed basic power states. Functional power states >> would be defined by the manufacturer, operator, or user. These would be >> the power states that would be reported by a device. However, in order to >> better define the semantics of functional power states, Each of these >> would be mapped to exactly one basic power states. This means that a >> property of any functional state would be the basic state it maps to. >> Basic power states would be fixed, such as the ones used in options 1-5. >> An easy example would be functional power states defined by >> user/operator/manufacturer with each state indicating whether it is an off >> state, a sleep state or an operational state. >> >> Here are the corresponding options: >> >> Option 6: flexible functional states mapped to a fixed set of basic states >> States could be defined flexibly. But each state would indicate a basic >> state to which it corresponds. Basic states could be either basic >> (off/sleep/operational) or the DMTF set or the ACPI set >> >> Option 7: flexible functional states mapped to a IANA registered set of >> basic states >> This is like Option 6, but basic states would be registered at IANA and >> can be extended. We would register all DMTF and ACPI states and probably >> some more at IANA. Manufacturers could add more. >> >> Option 8: IANA-registered sets of functional states, only three basic >> states >> The main reasoning behind this option is that is should always be clear >> whether a power state is an off state, a sleep state, or an operational >> state. Therefore, only these three basic states are supported. This >> would be in line with an instance of Option 6. However, this option has >> an extension for the functional states. It suggests that for customizing >> devices in order to be compliant with given management systems, for >> example a DMTF-based system, it should be possible to restrict functional >> power states to a given set that is registered at IANA. An example would >> be the DMTF states. We would register a flag at IANA that indicates we >> are using DMTF states only. This would signal the management application >> that all power state IDs are in line with power state numbering as defined >> by IANA. Analogously, ACPI and further sets could be registered at IANA. >> A fallback to Option 6 could be realized by registering a set number of 0 >> at IANA that does not impose any limit for functional states. >> >> Obviously, there are more possible options. If you think there is a >> better one, please send it to this list. >> >> I know this discussion is not easy, but we have to have it in order to >> make the right decision in the EMAN WG. Please take some time and think >> about what you consider to be the best way to go. And of course send >> questions on the issue. >> >> Thanks. >> >> Juergen >> >> >> DMTF (Distributed Management Task Force) power states: >> - 2 (Power On) >> - 3 (Sleep - Light) >> - 4 (Sleep - Deep) >> - 5 (Power Cycle (Off Soft)) >> - 6 (Power Off - Hard) >> - 7 (Hibernate) >> - 8 (Power Off - Soft) >> - 9 (Power Cycle (Off Hard)) >> - 10 (Master Bus Reset) >> - 11 (Diagnostic Interrupt (NMI)) >> - 12 (Power Off - Soft Graceful) >> - 13 (Power Off - Hard Graceful) >> - 14 (Master Bus Reset Graceful) >> - 15 (Power Cycle (Off - Soft Graceful)) >> - 16 (Power Cycle (Off - Hard Graceful)) >> >> ACPI (Advanced Configuration and Power Interface Specification) power >> states for PC motherboards: >> - G3-S5 (Off-Hard) >> - G2-S5 (Off-Soft) >> - G1-S4 (Hibernate) >> - G1-S3 (Sleep-Deep) >> - G1-S2 (Sleep-Light) >> - G1-S1 (Sleep-Light) >> - G0-S0-P5 >> - G0-S0-P4 >> - G0-S0-P3 >> - G0-S0-P2 >> - G0-S0-P2 >> - G0-S0-P2 >> >> >> >> >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> > > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > _______________________________________________ > eman mailing listeman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --20cf3054ac79015745049d850277 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The ACPI & DMTF power states are not sufficient for real world applicat= ions.

For example, take Cisco data labs that employ Raritan PDUs and Raritan'= s Power IQ (Power IQ is a power management service program).

Each night the following actions take place at Cisco
1.=A0 Power IQ scheduler determines which outlets must be turned off.
2.=A0 If outlet is associated with an server, a graceful shutdown takes=20 place (ssh script sent to server to run /etc/shutdown, etc.)
3. AC power to the outlet is turned off.

Now assume that the server has a BMC (baseboard management controller)=20 that can report ACPI power states.=A0 These power states refer to the main processor board and do not include the BMC itself.=A0 In other words, ACPI= power state OFF means no power is being supplied to the motherboard, but AC power is=20 still being supplied to the server so that the BMC can continue to=20 function.

When above step 3 occurs to turn off all power to the server, the BMC=20 ceases to function.=A0 This power state is outside the scope of ACPI.

Now let's assume that Raritan Power IQ adds the capability of interroga= ting the=20 ACPI power states of the server and wants to map them into the EMAN=20 standard.=A0 Clearly at least one additional power state is required (AC po= wer=20 turned off).=A0 in actual practice, a user would also like to know such=20 things available from a PDU like "AC power lost due to circuit breaker= =20 trip", etc.


On Wed, Mar 2, 2011 at 12:39 PM, Benoit = Claise <bclaise@c= isco.com> wrote:
=20 =20 =20
Dear all,

In the industry, there are multiple series of power states:
-=A0 The ACPI standard. In practice, mainly used for PCs in case of non operational power states
-=A0 The DMTF Power State Management Profile defines an information model over web services. The DMTF has 6 power states, 5 of them non-operational. They merged all operational power states into a single one: "on".
- Some manufacturers have their own power state series.

And there is an attempt to define the EMAN states in the EMAN framework, which would be a new power states series, at least for the operational ones.

In the world of PCs in case of non operational power states, ACPI seems well accepted.
However, my point is the following: there is no clear winner in terms of adopted series of power state in the industry.
I believe I would be dangerous to bet on power state series based on our knowledge today. The industry will decide, and maybe it will be a new power states series.

What I believe the solution is in terms of EMAN:
- we must be ready to support multiple power states series
- we must be ready to support a new power states series.
- the device must report which power states series it supports
In conclusion: be flexible and support all

Regards, Benoit.


I am reposting Juergen's email about powe= r states.
While the subsequent discussion has been important
and useful, it is on a different topic.=A0 So, please let's
also make progress on this topic.
--Bruce

On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek <Quittek@neclab.eu> wrote:
Dear all,

We have two proposals for a Power/Energy MIB module:

=A0- draft-claise-energy-monitoring-mib-06
=A0- draft-quittek-power-mib-02

Among the authors of both documents we are currently trying to merge them.
But there are some open issues that should be discussed on the mailing
list. =A0Here is the probably biggest of them: modeling power states.

For simplifying energy management we want to introduce the concept of
power states (aka power levels). =A0A power state will indicate roughly how
much power a device consumes. =A0Examples for simple power states are off,
sleep, and operational states.

In the envisioned EMAN MIB modules, a power state is characterized by a
descriptive name and the device's expected power input in thi= s state
(max/min/average).

Power states are not a new concept. =A0The DMTF has already defined a set of
power states and there is the Other standards bodies as the DMTF
(Distributed Management Task Force) and there =A0is the ACPI (Advanced
Configuration and Power Interface) for PC motherboards. =A0And there may be
more than these out there. =A0I listed some DMTF and ACPI states at the end
of this message.

An easy solution for EMAN would be just adopting one of these sets.
However, there are issues with the ones we looked at. =A0ACPI was developed
for PC motherboards and is quite PC-centric. =A0Also it defines states that
seem to be superfluous, because so far, almost no one has implemented
them. =A0Also the DMTF model seems to have a narrower scope than envisioned
by the EMAN WG.

At some point in time, the EMAN WG hast to make a decision, which power
state model to adopt. =A0Here is a set of alternatives. The first four have
fixed sets of power states.

Option 1: fixed minimum
Just support three power states (off, sleep (stand-by), operational)
This has clear semantics, but there are several people claiming it's too
restrictive.

Option 2: fixed DMTF
Just use the states defined by DMTF.
Might be too much focussed n PCs.

Option 3: fixed ACPI
Just use the states defined by ACPI.
Might be too much focussed n PCs.



Option 4: fixed EMAN
Define a new fixed set of power levels within the EMAN WG.

Option 5: IANA-registered power states
Have power states be registered at IANA.
We would start with registering (off, sleep, operational, the DMTF set,
and the ACPI set.
Manufacturers can then register further ones.


There has been discussions pointing out that these fixed sets may not be
sufficient, particularly if non-IT equipment should also be covered.

For being more open, the idea to support user-defined or
manufacturer-defined power states of devices has been developed. =A0In such
a state, for example, certain components of a device may be switched off
or put to sleep. =A0Which ones are switched off in which state is to be
defined by the user/operator/manufacturer and may be chosen such that
operational needs are met.

Again, there are several proposals how to do this. =A0All of them favor a
two-level approach that distinguishes between rather flexible functional
power states and rather fixed basic power states. =A0Functional power states
would be defined by the manufacturer, operator, or user. =A0These would be
the power states that would be reported by a device. =A0However, in order to
better define the semantics of functional power states, Each of these
would be mapped to exactly one basic power states. =A0This means that a
property of any functional state would be the basic state it maps to.
Basic power states would be fixed, such as the ones used in options 1-5.
An easy example would be functional power states defined by
user/operator/manufacturer with each state indicating whether it is an off
state, a sleep state or an operational state.

Here are the corresponding options:

Option 6: flexible functional states mapped to a fixed set of basic states
States could be defined flexibly. =A0But each state would indicate a basic
state to which it corresponds. Basic states could be either basic
(off/sleep/operational) or the DMTF set or the ACPI set

Option 7: flexible functional states mapped to a IANA registered set of
basic states
This is like Option 6, but basic states would be registered at IANA and
can be extended. =A0We would register all DMTF and ACPI states and probably
some more at IANA. Manufacturers could add more.

Option 8: IANA-registered sets of functional states, only three basic
states
The main reasoning behind this option is that is should always be clear
whether a power state is an off state, a sleep state, or an operational
state. =A0Therefore, only these three basic states are supported. =A0This
would be in line with an instance of Option 6. =A0However, this option has
an extension for the functional states. =A0It suggests that for customizing
devices in order to be compliant with given management systems, for
example a DMTF-based system, it should be possible to restrict functional
power states to a given set that is registered at IANA. =A0An example would
be the DMTF states. =A0We would register a flag at IANA that indicates we
are using DMTF states only. =A0This would signal the management application
that all power state IDs are in line with power state numbering as defined
by IANA. =A0Analogously, ACPI and further sets could be registered at IANA.
A fallback to Option 6 could be realized by registering a set number of 0
at IANA that does not impose any limit for functional states.

Obviously, there are more possible options. =A0If you think there is a
better one, please send it to this list.

I know this discussion is not easy, but we have to have it in order to
make the right decision in the EMAN WG. =A0Please take some time and think
about what you consider to be the best way to go. =A0And of course send
questions on the issue.

Thanks.

=A0 =A0Juergen


DMTF (Distributed Management Task Force) power states:
=A0- 2 (Power On)
=A0- 3 (Sleep - Light)
=A0- 4 (Sleep - Deep)
=A0- 5 (Power Cycle (Off Soft))
=A0- 6 (Power Off - Hard)
=A0- 7 (Hibernate)
=A0- 8 (Power Off - Soft)
=A0- 9 (Power Cycle (Off Hard))
=A0- 10 (Master Bus Reset)
=A0- 11 (Diagnostic Interrupt (NMI))
=A0- 12 (Power Off - Soft Graceful)
=A0- 13 (Power Off - Hard Graceful)
=A0- 14 (Master Bus Reset Graceful)
=A0- 15 (Power Cycle (Off - Soft Graceful))
=A0- 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced Configuration and Power Interface Specification) power
states for PC motherboards:
=A0- G3-S5 (Off-Hard)
=A0- G2-S5 (Off-Soft)
=A0- G1-S4 (Hibernate)
=A0- G1-S3 (Sleep-Deep)
=A0- G1-S2 (Sleep-Light)
=A0- G1-S1 (Sleep-Light)
=A0- G0-S0-P5
=A0- G0-S0-P4
=A0- G0-S0-P3
=A0- G0-S0-P2
=A0- G0-S0-P2
=A0- G0-S0-P2




_______________________________________________
eman mailing list
eman@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/eman



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


_______________________________________________
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


--20cf3054ac79015745049d850277-- From tirth.ghose@gmail.com Wed Mar 2 13:17:44 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA1A3A6816 for ; Wed, 2 Mar 2011 13:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU0aCel4350I for ; Wed, 2 Mar 2011 13:17:44 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 16A443A6850 for ; Wed, 2 Mar 2011 13:17:44 -0800 (PST) Received: by iwl42 with SMTP id 42so379330iwl.31 for ; Wed, 02 Mar 2011 13:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=giKJkmuhwLE0jCe7neRc++3E1jGToqJbNQmL0KSGluI=; b=dkkovR6uib46d9j5bbErHi9D/CAAwZBdUnHk+7YILtewSytk2j/WCjewhVQapslUA8 4vJpjrYk5+N9Mx/9/uPJltxcxTx/KoNrTjvJwn2Xhm+dojZuRUhXC+Tfl8JTlUQ+0dT3 JLoV/uTaEVhH6JmCTY7VD0lJru2tmqWtoO/c4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=RgghzPy6waydWookF3QLTGatV6Gxvrxydj331sfeuuV4Eu5L/eW0ywQSw/6Jh90NzV HuQBjVlPFfpqOi5i8T8D/phywGS6qH9pxZQ1O5pbhwQoC9UohqsXtPVVtk/yyZS1WHSF hb2fmBjPKspUJXY6mzuQ2lfX4iGUZPTByT+1M= MIME-Version: 1.0 Received: by 10.231.145.209 with SMTP id e17mr343540ibv.43.1299100730595; Wed, 02 Mar 2011 13:18:50 -0800 (PST) Sender: tirth.ghose@gmail.com Received: by 10.231.156.141 with HTTP; Wed, 2 Mar 2011 13:18:50 -0800 (PST) In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C171@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C171@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Date: Wed, 2 Mar 2011 13:18:50 -0800 X-Google-Sender-Auth: u_9DoGk9WE7cfscBUiWmEt0ib_o Message-ID: From: Ted Ghose To: "Mielke, William F (Bill)" Content-Type: multipart/alternative; boundary=0016e64754a293192f049d8675dc Cc: eman mailing list Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:17:45 -0000 --0016e64754a293192f049d8675dc Content-Type: text/plain; charset=ISO-8859-1 Mielke, William F (Bill) wrote: > > I am not sure what "fine set of rule" you are looking for. Can you please > clarify? > > here the example of the rule I stated earlier: Rule 1: device at low power state takes less power from utility power source than at a higher state Rule 2: device express their capability at a given state (may be % or some measure) What you have described is not much different from what I'm asking for. If we have the states mapped the way you have stated, we will get the same functionality. thanks -tg- --0016e64754a293192f049d8675dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mielke, William F (Bill) <bill.mielke@alcatel-lucent.com> wrote:<= br>

I am not sure what "fine set of rule" you are looking for. Ca= n you please clarify?

here the example of the rule I stated earlier:

Rule 1: device at low power state takes less power from= utility power source than at a higher state
Rule 2: device expre= ss their capability at a given state (may be % or some measure)
=A0 What you have described is not much different from what I'm asking for.= If we have the states mapped the way you have stated, we will get the same= functionality.

thanks

-tg-
--0016e64754a293192f049d8675dc-- From bnordman@lbl.gov Wed Mar 2 13:48:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12F13A68BD for ; Wed, 2 Mar 2011 13:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.79 X-Spam-Level: X-Spam-Status: No, score=-5.79 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laXh6Fhx08Gq for ; Wed, 2 Mar 2011 13:48:20 -0800 (PST) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by core3.amsl.com (Postfix) with ESMTP id B79DC3A6816 for ; Wed, 2 Mar 2011 13:48:20 -0800 (PST) X-Ironport-SBRS: 4.4 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgACAJJKbk3RVdQ0kGdsb2JhbACCTpwOAYgLCBUBAQEBCQkMBxEEIaQkmmODGIJJBIUXhw+IUjo X-IronPort-AV: E=Sophos;i="4.62,255,1297065600"; d="scan'208";a="35494737" Received: from mail-vw0-f52.google.com ([209.85.212.52]) by ironport4.lbl.gov with ESMTP; 02 Mar 2011 13:49:26 -0800 Received: by vws20 with SMTP id 20so508706vws.39 for ; Wed, 02 Mar 2011 13:49:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.157.74 with SMTP id wk10mr572687vdb.114.1299102564911; Wed, 02 Mar 2011 13:49:24 -0800 (PST) Received: by 10.52.155.40 with HTTP; Wed, 2 Mar 2011 13:49:24 -0800 (PST) In-Reply-To: <4D6E7B37.7000301@cisco.com> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <4D6E7B37.7000301@cisco.com> Date: Wed, 2 Mar 2011 13:49:24 -0800 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=bcaec53f8f63e889b3049d86e286 Subject: Re: [eman] modeling power states - power monitoring for virtual machines X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:48:22 -0000 --bcaec53f8f63e889b3049d86e286 Content-Type: text/plain; charset=ISO-8859-1 I would also add that allocating power and energy among virtual machines could be done many different ways so is unlike other topics we have discussed where there is a specific flow of electrons that is being measured or estimated. To me the key is that I would not want the email reflector or meeting time to be burdened by the topic. --Hat still on, Bruce On Wed, Mar 2, 2011 at 9:15 AM, Benoit Claise wrote: > Dear all, > > As far as we understand the power monitoring for virtual machines is not on > our charter > However, if we have a flexible data model that allows us to cover this case > as well, great. > > Regards, co-chair hats on, Bruce and Benoit, > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec53f8f63e889b3049d86e286 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would also add that allocating power and energy among virtual machinescould be done many different ways so is unlike other topics we have discus= sed
where there is a specific flow of electrons that is being measured o= r estimated.
To me the key is that I would not want the email reflector or meeting time = to
be burdened by the topic.
--Hat still on, Bruce

On Wed, Mar 2, 2011 at 9:15 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

As far as we understand the power monitoring for virtual machines is not on= our charter
However, if we have a flexible data model that allows us to cover this case= as well, great.

Regards, co-chair hats on, Bruce and Benoit,


--
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/e= a/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
--bcaec53f8f63e889b3049d86e286-- From j.schoenwaelder@jacobs-university.de Wed Mar 2 14:43:35 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33993A68E2 for ; Wed, 2 Mar 2011 14:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6MQ7iTuH2-s for ; Wed, 2 Mar 2011 14:43:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C0F823A68B5 for ; Wed, 2 Mar 2011 14:43:34 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBB67C0019; Wed, 2 Mar 2011 23:44:40 +0100 (CET) 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 YMtO74jI6FKe; Wed, 2 Mar 2011 23:44:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A164AC000D; Wed, 2 Mar 2011 23:44:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 572D916D8339; Wed, 2 Mar 2011 23:44:33 +0100 (CET) Date: Wed, 2 Mar 2011 23:44:33 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20110302224433.GA17070@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , chrisv@cyberswitching.com, eman mailing list , Juergen Quittek References: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.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 mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:43:35 -0000 On Wed, Mar 02, 2011 at 05:36:13PM +0100, Romascanu, Dan (Dan) wrote: > From an Entity MIB modeling this is really a simple case. > > You have > - one entry in the entPhysicalTable - the server > - four entries in the entLogicaltable - the VMs > - four entries in the entLPMappingTable mapping the index of the VM > server to the 4 indices of the VMs respectively > > The MIB we design would be either indexed by LogicalIndex or point to > the value of the Index (we need an accessible variable for this) and > will include an 'estimate power consumption' object Dan, I am not sure I can follow you. Where is the values be reported? For virtualization, I think the most logical approach would be that the VMs run their own SNMP agents (as ours do) and that the VMs would have virtual power resources that they report in their ENTITY-MIB tree. In other words, the hypervisor (or whatever piece of software does the virtualization) should provide a virtualized power sensor to the virtual machines and you take it from there. If it is important to discover which VMs run on a given physical server, one could use the entLogicalTable of the ENTITY-MIB on the physical server to point to the SNMP agents running on the VMs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From chrisv@cyberswitching.com Wed Mar 2 18:04:06 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA9C3A68E0 for ; Wed, 2 Mar 2011 18:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzR0LpFaP+zO for ; Wed, 2 Mar 2011 18:04:03 -0800 (PST) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by core3.amsl.com (Postfix) with ESMTP id B74B73A6359 for ; Wed, 2 Mar 2011 18:04:02 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o142.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 457fe6d4.0.3514.00-384.6079.p01c11o142.mxlogic.net (envelope-from ); Wed, 02 Mar 2011 19:05:10 -0700 (MST) X-MXL-Hash: 4d6ef7564407fd4d-a83a58f094e0aab0d3fd80004cd310193e11d54d Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 18:01:21 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id BCB842F6001; Wed, 2 Mar 2011 18:05:08 -0800 (PST) Date: Wed, 2 Mar 2011 18:05:08 -0800 From: chrisv@cyberswitching.com To: Juergen Quittek Message-ID: <20110303020507.GA19321@cslinux-build01.cyberswitching.local> References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 03 Mar 2011 02:01:21.0975 (UTC) FILETIME=[E4CCB470:01CBD946] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XnxjYOJpEeMA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=d0puL9jKTE5f45F-q84A] X-AnalysisOut: [:9 a=L6onW4ZwpNYjc_4jlkd8qFuiwtAA:4 a=CjuIK1q_8ugA:10] Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 02:04:07 -0000 On Wed, Mar 02, 2011 at 09:44:12PM +0100, Juergen Quittek wrote: > Which power state would apply to my notebook computer when > > - it is switched of, but charging its batteries. > This is an off-state with relatively high power consumption. > Is this covered by any ACPI or DMTF states or by the states in the > drafts we have? > - it is switched on and fully operational, but running on built-in > battery only. > This is an operational state with zero power consumption, at least > as seen from outside. > Again, how can we cover this with states described so far? Hi Juergen, My initial thought is that the server entity would be OFF and the battery entity would be ON/charging. Like with a tripped circuit breaker, "off" doesn't quite cut it, but I think we can find an appropriate caption. They key is to realize that the states for each entity are reflected separately. Thanks, Chris From chrisv@cyberswitching.com Wed Mar 2 18:06:59 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2AA3A6359 for ; Wed, 2 Mar 2011 18:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHULxSO9iC6N for ; Wed, 2 Mar 2011 18:06:59 -0800 (PST) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by core3.amsl.com (Postfix) with ESMTP id 569CB3A6920 for ; Wed, 2 Mar 2011 18:06:41 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o149.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 4f7fe6d4.0.40133.00-377.83493.p01c11o149.mxlogic.net (envelope-from ); Wed, 02 Mar 2011 19:07:48 -0700 (MST) X-MXL-Hash: 4d6ef7f44ed3a2cd-be91a36ad143814164739ffcb8324a5259904aec Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 18:04:01 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 063342F6001; Wed, 2 Mar 2011 18:07:48 -0800 (PST) Date: Wed, 2 Mar 2011 18:07:48 -0800 From: chrisv@cyberswitching.com To: Bruce Nordman Message-ID: <20110303020747.GB19321@cslinux-build01.cyberswitching.local> References: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <4D6E7B37.7000301@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 03 Mar 2011 02:04:01.0179 (UTC) FILETIME=[43B14EB0:01CBD947] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=1CwcpQG1Vq8A:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=s20vE82QbrTIMk_2O14A] X-AnalysisOut: [:9 a=ejp2aWGPUaU-btincLUgNl5toY8A:4 a=CjuIK1q_8ugA:10] Cc: eman mailing list Subject: Re: [eman] modeling power states - power monitoring for virtual machines X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 02:06:59 -0000 On Wed, Mar 02, 2011 at 01:49:24PM -0800, Bruce Nordman wrote: > I would also add that allocating power and energy among virtual > machines could be done many different ways so is unlike other topics > we have discussed where there is a specific flow of electrons that is > being measured or estimated. To me the key is that I would not want > the email reflector or meeting time to be burdened by the topic. Hi Bruce and Benoit, Agreed that it shouldn't be a major point, but it needs to be something that we add to the use case list. In principle, it is a problem of defining a time-share in the specific flow of electrons, which could theoretically apply to other conditions beyond virtual machines. It gets to my earier point about modeling "power/electricity" rather than a specific type of entity ("server" or "switch.") Thanks, Chris From chrisv@cyberswitching.com Wed Mar 2 18:08:34 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC193A6920 for ; Wed, 2 Mar 2011 18:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5nEUgK2cwCD for ; Wed, 2 Mar 2011 18:08:33 -0800 (PST) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by core3.amsl.com (Postfix) with ESMTP id 88F6C3A6359 for ; Wed, 2 Mar 2011 18:08:33 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o142.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 468fe6d4.0.4015.00-371.7055.p01c11o142.mxlogic.net (envelope-from ); Wed, 02 Mar 2011 19:09:40 -0700 (MST) X-MXL-Hash: 4d6ef86450a52a7a-da093addf95c147e4e37f9ad1bb7d1d66447bf61 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 18:05:29 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 152EF2F6001; Wed, 2 Mar 2011 18:09:16 -0800 (PST) Date: Wed, 2 Mar 2011 18:09:16 -0800 From: chrisv@cyberswitching.com To: Michael Suchoff Message-ID: <20110303020915.GC19321@cslinux-build01.cyberswitching.local> References: <4D6E80B8.6060002@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 03 Mar 2011 02:05:29.0218 (UTC) FILETIME=[782AFE20:01CBD947] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XnxjYOJpEeMA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=squbUm3mu1LetaRuLygA] X-AnalysisOut: [:9 a=VolVM-Q0CZU70qB8iI8UxjYIbPYA:4 a=CjuIK1q_8ugA:10] Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 02:08:34 -0000 On Wed, Mar 02, 2011 at 02:34:56PM -0500, Michael Suchoff wrote: > The ACPI & DMTF power states are not sufficient for real world applications. Agreed with regard's to Cyber Switching's operations, too. I could easily see having a "PduPowerStates" standard that augments or even replaces the ACPI and DMTF standards for certain entities. Chris From dromasca@avaya.com Wed Mar 2 23:21:00 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540953A6956 for ; Wed, 2 Mar 2011 23:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4At7dsaBElJ for ; Wed, 2 Mar 2011 23:20:57 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 87F443A694D for ; Wed, 2 Mar 2011 23:20:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAKPQbk2HCzI1/2dsb2JhbACYHY5XdKUsAplJhWEEkAg X-IronPort-AV: E=Sophos;i="4.62,257,1297054800"; d="scan'208";a="267553970" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Mar 2011 02:22:01 -0500 X-IronPort-AV: E=Sophos;i="4.62,257,1297054800"; d="scan'208";a="609509412" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Mar 2011 02:22:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2011 08:21:47 +0100 Message-ID: In-Reply-To: <20110302224433.GA17070@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvZK23xoy6nllcHToWsoNMJpD/fFwARtjSA References: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 07:21:00 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, March 03, 2011 12:45 AM > To: Romascanu, Dan (Dan) > Cc: chrisv@cyberswitching.com; eman mailing list; Juergen Quittek > Subject: Re: [eman] modeling power states >=20 > On Wed, Mar 02, 2011 at 05:36:13PM +0100, Romascanu, Dan (Dan) wrote: > =20 > > From an Entity MIB modeling this is really a simple case.=20 > >=20 > > You have > > - one entry in the entPhysicalTable - the server > > - four entries in the entLogicaltable - the VMs > > - four entries in the entLPMappingTable mapping the index of the VM=20 > > server to the 4 indices of the VMs respectively > >=20 > > The MIB we design would be either indexed by LogicalIndex=20 > or point to=20 > > the value of the Index (we need an accessible variable for=20 > this) and=20 > > will include an 'estimate power consumption' object >=20 > Dan, >=20 > I am not sure I can follow you. Where is the values be=20 > reported? For virtualization, I think the most logical=20 > approach would be that the VMs run their own SNMP agents (as=20 > ours do) and that the VMs would have virtual power resources=20 > that they report in their ENTITY-MIB tree. In other words,=20 > the hypervisor (or whatever piece of software does the > virtualization) should provide a virtualized power sensor to=20 > the virtual machines and you take it from there. >=20 > If it is important to discover which VMs run on a given=20 > physical server, one could use the entLogicalTable of the=20 > ENTITY-MIB on the physical server to point to the SNMP agents=20 > running on the VMs. >=20 > /js >=20 Hi Juergen, Indeed, the more general solution (or one of them) is the one that you point to. You still need to define a new object in a table augmenting the ENTITY-MIB logical table.=20 Still the major problem for me (and it may be my lack of knowledge on how power per VM is estimated or measured) seems to me how you estimate the power consumed by each VM. My common sense tells me that this is function not only of SW but also of the HW it runs on (i.e. the same VM may 'suck' different power on my Dell D630 than on my MacBook). Maybe I am wrong, maybe the power people know how to cope with this.=20 Dan From chrisv@cyberswitching.com Wed Mar 2 23:45:38 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169243A6937 for ; Wed, 2 Mar 2011 23:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37oojlCLRdyc for ; Wed, 2 Mar 2011 23:45:37 -0800 (PST) Received: from p01c11o148.mxlogic.net (p01c11o148.mxlogic.net [208.65.144.71]) by core3.amsl.com (Postfix) with ESMTP id A570B3A6403 for ; Wed, 2 Mar 2011 23:45:36 -0800 (PST) Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c11o148.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 3674f6d4.0.83213.00-322.166037.p01c11o148.mxlogic.net (envelope-from ); Thu, 03 Mar 2011 00:46:44 -0700 (MST) X-MXL-Hash: 4d6f476439cd8e71-1c3c6feb0ef53fdcb567a37494cea4afa596f8ee Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 23:46:34 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 5931F2F6001; Wed, 2 Mar 2011 23:46:43 -0800 (PST) Date: Wed, 2 Mar 2011 23:46:43 -0800 From: chrisv@cyberswitching.com To: "Romascanu, Dan (Dan)" Message-ID: <20110303074643.GA31664@cslinux-build01.cyberswitching.local> References: <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 03 Mar 2011 07:46:34.0753 (UTC) FILETIME=[1E93CF10:01CBD977] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [64.81.28.110] X-AnalysisOut: [v=1.0 c=1 a=mrxgWj59b9sA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=4zsJQXJisSY22NXBO5KRuA==:17 a=6UNAmSCXAAAA:8 a=lFK] X-AnalysisOut: [CS1cpLk9nUY_bblUA:9 a=3swkL1FLJeTAm9acifsA:7 a=ci4UDvuK0YH] X-AnalysisOut: [TRJ8Cws9fkdgjRfgA:4 a=CjuIK1q_8ugA:10] Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 07:45:38 -0000 On Thu, Mar 03, 2011 at 08:21:47AM +0100, Romascanu, Dan (Dan) wrote: > > I am not sure I can follow you. Where is the values be > > reported? For virtualization, I think the most logical > > approach would be that the VMs run their own SNMP agents (as > > ours do) and that the VMs would have virtual power resources > > that they report in their ENTITY-MIB tree. In other words, > > the hypervisor (or whatever piece of software does the > > virtualization) should provide a virtualized power sensor to > > the virtual machines and you take it from there. The VMs don't always know their power consumption, but the host operating system does. 1. The host OS (VMware ESXi server in the example) reads the power measuremrents from the hardware on the motherboard 2. The host OS also tracks the CPU utilization of each of the VMs 3. Therefore, the host OS can correlate power measurements with CPU utilization 4. The guest VMs are ignorant of all of this because they don't know their CPU utilization relative to other VMs nor do they have direct access to the power measurement hardware on the motherboard (they're virtual, of course) > > If it is important to discover which VMs run on a given > > physical server, one could use the entLogicalTable of the > > ENTITY-MIB on the physical server to point to the SNMP agents > > running on the VMs. > > Indeed, the more general solution (or one of them) is the one that you > point to. You still need to define a new object in a table augmenting > the ENTITY-MIB logical table. I'm still struggling with some of these ENTITY-MIB concepts. They really do seem to be convoluted and require either highly specific (esoteric?) domain knowledge about ENTITY-MIB to be useful or "hacks" to get it to do what we want. Certainly, I tend to be vocal. :-) What do others (that we haven't heard from) think? > Still the major problem for me (and it may be my lack of knowledge on > how power per VM is estimated or measured) seems to me how you estimate > the power consumed by each VM. My common sense tells me that this is > function not only of SW but also of the HW it runs on (i.e. the same VM > may 'suck' different power on my Dell D630 than on my MacBook). Maybe I > am wrong, maybe the power people know how to cope with this. CPU utilization is the metric that ties this together. You really should check out these guys: http://www.powerassure.com. Chris From j.schoenwaelder@jacobs-university.de Wed Mar 2 23:50:03 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD9F3A696F for ; Wed, 2 Mar 2011 23:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALFrZr+cIUXc for ; Wed, 2 Mar 2011 23:50:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 565423A6942 for ; Wed, 2 Mar 2011 23:50:01 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF8B6C0017; Thu, 3 Mar 2011 08:51:07 +0100 (CET) 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 AMVKxwrKG7Gi; Thu, 3 Mar 2011 08:51:07 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12E5CC0006; Thu, 3 Mar 2011 08:51:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BC4BB16D918B; Thu, 3 Mar 2011 08:51:02 +0100 (CET) Date: Thu, 3 Mar 2011 08:51:02 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20110303075102.GA19258@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , chrisv@cyberswitching.com, eman mailing list , Juergen Quittek References: <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@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 mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 07:50:03 -0000 On Thu, Mar 03, 2011 at 08:21:47AM +0100, Romascanu, Dan (Dan) wrote: > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, March 03, 2011 12:45 AM > > To: Romascanu, Dan (Dan) > > Cc: chrisv@cyberswitching.com; eman mailing list; Juergen Quittek > > Subject: Re: [eman] modeling power states > > > > On Wed, Mar 02, 2011 at 05:36:13PM +0100, Romascanu, Dan (Dan) wrote: > > > > > From an Entity MIB modeling this is really a simple case. > > > > > > You have > > > - one entry in the entPhysicalTable - the server > > > - four entries in the entLogicaltable - the VMs > > > - four entries in the entLPMappingTable mapping the index of the VM > > > server to the 4 indices of the VMs respectively > > > > > > The MIB we design would be either indexed by LogicalIndex > > or point to > > > the value of the Index (we need an accessible variable for > > this) and > > > will include an 'estimate power consumption' object > > > > Dan, > > > > I am not sure I can follow you. Where is the values be > > reported? For virtualization, I think the most logical > > approach would be that the VMs run their own SNMP agents (as > > ours do) and that the VMs would have virtual power resources > > that they report in their ENTITY-MIB tree. In other words, > > the hypervisor (or whatever piece of software does the > > virtualization) should provide a virtualized power sensor to > > the virtual machines and you take it from there. > > > > If it is important to discover which VMs run on a given > > physical server, one could use the entLogicalTable of the > > ENTITY-MIB on the physical server to point to the SNMP agents > > running on the VMs. > > > > /js > > > > Hi Juergen, > > Indeed, the more general solution (or one of them) is the one that you > point to. You still need to define a new object in a table augmenting > the ENTITY-MIB logical table. Not sure what this object would be. > Still the major problem for me (and it may be my lack of knowledge on > how power per VM is estimated or measured) seems to me how you estimate > the power consumed by each VM. My common sense tells me that this is > function not only of SW but also of the HW it runs on (i.e. the same VM > may 'suck' different power on my Dell D630 than on my MacBook). Maybe I > am wrong, maybe the power people know how to cope with this. I share your curiosity how this calculation might work but then I also understand that if customers demand numbers, they are provided with numbers, whatever the accuracy really is. I have seen enough fake SNMP counters in my life. ;-) /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 Mar 2 23:58:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3D93A6942 for ; Wed, 2 Mar 2011 23:58:22 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK2jHBnG9f5U for ; Wed, 2 Mar 2011 23:58:22 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D23013A693B for ; Wed, 2 Mar 2011 23:58:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOTYbk2HCzI1/2dsb2JhbACmdXSlKwKZSYVhBJAI X-IronPort-AV: E=Sophos;i="4.62,257,1297054800"; d="scan'208";a="234982773" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Mar 2011 02:59:27 -0500 X-IronPort-AV: E=Sophos;i="4.62,257,1297054800"; d="scan'208";a="609525798" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Mar 2011 02:59:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2011 08:59:16 +0100 Message-ID: In-Reply-To: <20110303075102.GA19258@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvZd8nz3/KRrCRSRjOh/jnvZtRVvAAAHnQA References: <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@elstar.local> <20110303075102.GA19258@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 07:58:23 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 ... > > Hi Juergen, > >=20 > > Indeed, the more general solution (or one of them) is the=20 > one that you=20 > > point to. You still need to define a new object in a table=20 > augmenting=20 > > the ENTITY-MIB logical table. >=20 > Not sure what this object would be. >=20 Something like entLogicalPowerConsume expressed in miliWatts or similar. The output of what you call 'virtualized power sensor' I guess. Dan From j.schoenwaelder@jacobs-university.de Thu Mar 3 00:06:04 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C27D3A6842 for ; Thu, 3 Mar 2011 00:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.229 X-Spam-Level: X-Spam-Status: No, score=-103.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XdppujfaZi1 for ; Thu, 3 Mar 2011 00:06:03 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 23EF33A6939 for ; Thu, 3 Mar 2011 00:05:44 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CC35C0017; Thu, 3 Mar 2011 09:06:51 +0100 (CET) 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 7DK2gwyrcKpL; Thu, 3 Mar 2011 09:06:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61FA9C0018; Thu, 3 Mar 2011 09:06:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 81B2516D9209; Thu, 3 Mar 2011 09:06:45 +0100 (CET) Date: Thu, 3 Mar 2011 09:06:45 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110303080644.GB19258@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, "Romascanu, Dan (Dan)" , eman mailing list , Juergen Quittek References: <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@elstar.local> <20110303074643.GA31664@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110303074643.GA31664@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:06:04 -0000 On Wed, Mar 02, 2011 at 11:46:43PM -0800, chrisv@cyberswitching.com wrote: > I'm still struggling with some of these ENTITY-MIB concepts. They > really do seem to be convoluted and require either highly specific > (esoteric?) domain knowledge about ENTITY-MIB to be useful or "hacks" to > get it to do what we want. > > Certainly, I tend to be vocal. :-) What do others (that we haven't > heard from) think? My understanding is that this IETF WG is chartered to produce standards-track MIB modules and thus this requires some willingness to understand how SNMP and core IETF MIB modules work. You might call this "highly specific (esoteric?) domain knowledge" but then I am wondering how you write this down in a way that it passes the IESG. I jumped into this discussion because I sensed that people have a completely wrong idea of the ENTITY-MIB, in particular what logical entities are. I do not know where this confusion is coming from, I can only offer help so that the WG understands what the ENTITY-MIB and SNMP has to offer. /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 Mar 3 00:16:54 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B9D3A695B for ; Thu, 3 Mar 2011 00:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V995Tm7DNfzb for ; Thu, 3 Mar 2011 00:16:53 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 4D6E03A6971 for ; Thu, 3 Mar 2011 00:16:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAIfdbk2HCzI1/2dsb2JhbACYHo5XdKUXAplLhWEEkAg X-IronPort-AV: E=Sophos;i="4.62,257,1297054800"; d="scan'208";a="267559236" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Mar 2011 03:18:00 -0500 X-IronPort-AV: E=Sophos;i="4.62,257,1297054800"; d="scan'208";a="609536174" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Mar 2011 03:17:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2011 09:17:37 +0100 Message-ID: In-Reply-To: <20110303080644.GB19258@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvZefamBs5BqLn0TfOY0tjHfP9DTwAAUh6A References: <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@elstar.local> <20110303074643.GA31664@cslinux-build01.cyberswitching.local> <20110303080644.GB19258@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:16:54 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, March 03, 2011 10:07 AM > To: chrisv@cyberswitching.com > Cc: Romascanu, Dan (Dan); eman mailing list; Juergen Quittek > Subject: Re: [eman] modeling power states >=20 > On Wed, Mar 02, 2011 at 11:46:43PM -0800,=20 > chrisv@cyberswitching.com wrote: > =20 > > I'm still struggling with some of these ENTITY-MIB concepts. They=20 > > really do seem to be convoluted and require either highly specific > > (esoteric?) domain knowledge about ENTITY-MIB to be useful=20 > or "hacks"=20 > > to get it to do what we want. > >=20 > > Certainly, I tend to be vocal. :-) What do others (that=20 > we haven't=20 > > heard from) think? >=20 > My understanding is that this IETF WG is chartered to produce=20 > standards-track MIB modules and thus this requires some=20 > willingness to understand how SNMP and core IETF MIB modules=20 > work. You might call this "highly specific (esoteric?) domain=20 > knowledge" but then I am wondering how you write this down in=20 > a way that it passes the IESG. >=20 > I jumped into this discussion because I sensed that people=20 > have a completely wrong idea of the ENTITY-MIB, in particular=20 > what logical entities are. I do not know where this confusion=20 > is coming from, I can only offer help so that the WG=20 > understands what the ENTITY-MIB and SNMP has to offer. >=20 > /js >=20 I agree to what Juergen says here. There needs to be a good justification to invent something new rather than re-use concepts that are shared by many MIB and SNMP management applications.=20 Dan From j.schoenwaelder@jacobs-university.de Thu Mar 3 00:19:49 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5353A6989 for ; Thu, 3 Mar 2011 00:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.23 X-Spam-Level: X-Spam-Status: No, score=-103.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkHvO5v6MR8I for ; Thu, 3 Mar 2011 00:19:47 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 43E7E3A6971 for ; Thu, 3 Mar 2011 00:19:47 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45C05C0024; Thu, 3 Mar 2011 09:20:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Svj9NWAO42vu; Thu, 3 Mar 2011 09:20:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8ACFEC001F; Thu, 3 Mar 2011 09:20:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3F31316D9263; Thu, 3 Mar 2011 09:20:49 +0100 (CET) Date: Thu, 3 Mar 2011 09:20:49 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20110303082049.GC19258@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , chrisv@cyberswitching.com, eman mailing list , Juergen Quittek References: <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@elstar.local> <20110303075102.GA19258@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 mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:19:49 -0000 On Thu, Mar 03, 2011 at 08:59:16AM +0100, Romascanu, Dan (Dan) wrote: > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > ... > > > > Hi Juergen, > > > > > > Indeed, the more general solution (or one of them) is the > > one that you > > > point to. You still need to define a new object in a table > > augmenting > > > the ENTITY-MIB logical table. > > > > Not sure what this object would be. > > > > Something like entLogicalPowerConsume expressed in miliWatts or similar. > The output of what you call 'virtualized power sensor' I guess. But why? The purpose of the entLogicalTable is to point to other SNMP contexts where you find the information and then you access the context pointed to in order to read the information you are interested in. For me, virtualization means that the VM provides a virtual notion of power sensors to the OSes running in the VMs; the SNMP context representing your Linux VM would then host a physical entity reporting power states. This is consistent with how I get network interface statistics and CPU usage statistics from VMs today - I talk to the SNMP agent on the VMs. People likely argue that this is a purly academic view since some common virtualization solutions simply do not provide the relevant information to the VMs and instead an add-on piece of software on the physical server is supposed to report the information instead of the SNMP engines on the virtual machines. But even then, you can use different contextNames to represent the virtualized power states and sensors with a single SNMP agent running on a pysical server. /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 Mar 3 00:26:48 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2E43A6981 for ; Thu, 3 Mar 2011 00:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83SgFInhv6Bt for ; Thu, 3 Mar 2011 00:26:47 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id EA7453A694D for ; Thu, 3 Mar 2011 00:26:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAN/fbk2HCzI1/2dsb2JhbACYHo5XdKUYAplNhWEEkAg X-IronPort-AV: E=Sophos;i="4.62,257,1297054800"; d="scan'208";a="267560302" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Mar 2011 03:27:54 -0500 X-IronPort-AV: E=Sophos;i="4.62,257,1297054800"; d="scan'208";a="609540563" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Mar 2011 03:27:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2011 09:27:49 +0100 Message-ID: In-Reply-To: <20110303082049.GC19258@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvZe+yCsA4yei8fSJqwnRhh6ayySQAANZHQ References: <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@elstar.local> <20110303075102.GA19258@elstar.local> <20110303082049.GC19258@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:26:48 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, March 03, 2011 10:21 AM > To: Romascanu, Dan (Dan) > Cc: chrisv@cyberswitching.com; eman mailing list; Juergen Quittek > Subject: Re: [eman] modeling power states >=20 > On Thu, Mar 03, 2011 at 08:59:16AM +0100, Romascanu, Dan (Dan) wrote: > > =20 > >=20 > > > -----Original Message----- > > > From: Juergen Schoenwaelder > >=20 > > ... > >=20 > > > > Hi Juergen, > > > >=20 > > > > Indeed, the more general solution (or one of them) is the > > > one that you > > > > point to. You still need to define a new object in a table > > > augmenting > > > > the ENTITY-MIB logical table. > > >=20 > > > Not sure what this object would be. > > >=20 > >=20 > > Something like entLogicalPowerConsume expressed in=20 > miliWatts or similar. > > The output of what you call 'virtualized power sensor' I guess. >=20 > But why? The purpose of the entLogicalTable is to point to=20 > other SNMP contexts where you find the information and then=20 > you access the context pointed to in order to read the=20 > information you are interested in. For me, virtualization=20 > means that the VM provides a virtual notion of power sensors=20 > to the OSes running in the VMs; the SNMP context representing=20 > your Linux VM would then host a physical entity reporting=20 > power states. This is consistent with how I get network=20 > interface statistics and CPU usage statistics from VMs today=20 > - I talk to the SNMP agent on the VMs. >=20 > People likely argue that this is a purly academic view since=20 > some common virtualization solutions simply do not provide=20 > the relevant information to the VMs and instead an add-on=20 > piece of software on the physical server is supposed to=20 > report the information instead of the SNMP engines on the=20 > virtual machines. But even then, you can use different=20 > contextNames to represent the virtualized power states and=20 > sensors with a single SNMP agent running on a pysical server. >=20 > /js >=20 Got it. You are right.=20 Dan From bclaise@cisco.com Thu Mar 3 05:49:37 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8883A6866 for ; Thu, 3 Mar 2011 05:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P44+LSGWa7tM for ; Thu, 3 Mar 2011 05:49:36 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 7D9EB3A6884 for ; Thu, 3 Mar 2011 05:49:35 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p23DMNAu006325 for ; Thu, 3 Mar 2011 14:22:24 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p23DMNjQ020065; Thu, 3 Mar 2011 14:22:23 +0100 (CET) Message-ID: <4D6F960E.8020300@cisco.com> Date: Thu, 03 Mar 2011 14:22:22 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Patrick Grossetete References: <2444768.36.1299066465634.JavaMail.pgrosset@pgrosset-mac.local> In-Reply-To: <2444768.36.1299066465634.JavaMail.pgrosset@pgrosset-mac.local> Content-Type: multipart/alternative; boundary="------------090703010301010304060204" Cc: eman@ietf.org Subject: Re: [eman] draft-ietf-eman-requirements-00 review X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:49:37 -0000 This is a multi-part message in MIME format. --------------090703010301010304060204 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Patrick, Thanks for a lot for your review. See inline for one particular point. > > Benoit, > > Please, find my comments regarding > draft-ietf-eman-requirements-00. I wrote them while reading the > doc, so there is no priority order. > > Best Regards > Patrick > > > - page 4-5, it should be added that environmental conditions may > also impact the potential reduction of power consumption. There is > often a link between > temperature/RH and power...for example, see ASHRAE specifications > for DataCenter (PUE and DCIE metrics). It may also be noticed that > side effects may occur. > For example, I have seen people increasing the temperature in > their datacenter to comply with PUE metric but in fact getting fan > speed increase on their servers > and leading to false conclusion of metrics since the power > consumption was seen as "good" for PUE computation. Clearly, the > capability to monitor > energy consumption of servers would have indicated that. > > - page 5, monitoring energy consumption can also help to check > compliancy with mandates/regulations/recommendations such as > ASHRAE or NTIA > > - page 6, I would have split this category as "servers and hosts" > already implement some power consumption metrics such as IPMI on > servers, > > and new generation CPU offers different power state level . > Section 2 is incomplete if we don't introduce in the scenario, > services such as Demand/Response and Load Shedding which may apply > to different 2.x sections > Right, we could add them as they will _influence _the different use cases in 2.1 . Scenario 1: Routers, switches, middleboxes, and hosts . .6 2.2. Scenario 2: PoE sourcing equipment and PoE powered devices . . . . . . . . . . . . . . . . . . . . . . . . .7 2.3 . Scenario 3: Power probes and Smart meters . . . . . . . .7 2.4 . Scenario 4: Mid-level managers . . . . . . . . . . . . . .7 2.5 . Scenario 5: Gateways to building networks . . . . . . . .7 2.6 . Scenario 6: Home energy gateways . . . . . . . . . . . . .8 2.7 . Scenario 7: Data center devices . . . . . . . . . . . . .8 2.8 . Scenario 8: Battery powered devices . . . . . . . . . . .8 By influencing, I mean that the demand/response for policies in these use cases . However, I would not list demand/response at the same level as these use cases, as the section 2 introduction explains: 2. Scenarios and target devices This section describes a selection of scenarios for the application of energy management. For each scenario a list of target devices is given in the headline, for which IETF energy management standards are needed. And the EMAN WG will not be solving the demand/response problem: it will "just" produce one piece of the puzzle Regards, Benoit. > > > - page 8, section 2.7 - obviously not mentioning ASHRAE > recommendations (PUE/DCIE) is not acknowledging industry standards > for energy monitoring > in datacenters. > > - page 9, section 3.2 - aggregation of energy data is really what > helps facility managers to understand where they could save money. > in fact, there would be a need to discuss how aggregation can be > done. It could be as simple as monitoring all physical > distribution circuits > but could also be aggregated by categories such as > engineering/sales/marketing departments or > heating/cooling/IT/lights,... > To fully understand the consumption, you also need to define the > "aggregation point" to consider what is counted downstream and > upstream. > For example, data retrieved on a server or router will be a > portion of data retrieved on a smart plug connecting all these > devices which will be a portion > of data retrieved at a smart circuit breaker level, and so on. > > - page 11, section 3.4.2, you could also indicate: line frequency, > power factor, apparent power, reactive power,... as metrics being > available on certain > category of devices. > > - page 12, section 3.4.4, you may want to compare with existing > MIB such as UPS vendor's MIBs > > --------------090703010301010304060204 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Patrick,

Thanks for a lot for your review.
See inline for one particular point.

Benoit,

Please, find my comments regarding draft-ietf-eman-requirements-00. I wrote them while reading the doc, so there is no priority order.

Best Regards
Patrick
 

- page 4-5, it should be added that environmental conditions may also impact the potential reduction of power consumption. There is often a link between
temperature/RH and power...for example, see ASHRAE specifications for DataCenter (PUE and DCIE metrics). It may also be noticed that side effects may occur.
For example, I have seen people increasing the temperature in their datacenter to comply with PUE metric but in fact getting fan speed increase on their servers
and leading to false conclusion of metrics since the power consumption was seen as "good" for PUE computation. Clearly, the capability to monitor
energy consumption of servers would have indicated that.

- page 5, monitoring energy consumption can also help to check compliancy with mandates/regulations/recommendations such as ASHRAE or NTIA

- page 6, I would have split this category as "servers and hosts" already implement some power consumption metrics such as IPMI on servers,
and new generation CPU offers different power state level .
Section 2 is incomplete if we don't introduce in the scenario, services such as Demand/Response and Load Shedding which may apply to different 2.x sections
Right, we could add them as they will influence the different use cases in 
     2.1.  Scenario 1: Routers, switches, middleboxes, and hosts  . .  6
     2.2.  Scenario 2: PoE sourcing equipment and PoE powered
           devices  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Scenario 3: Power probes and Smart meters  . . . . . . . .  7
     2.4.  Scenario 4: Mid-level managers . . . . . . . . . . . . . .  7
     2.5.  Scenario 5: Gateways to building networks  . . . . . . . .  7
     2.6.  Scenario 6: Home energy gateways . . . . . . . . . . . . .  8
     2.7.  Scenario 7: Data center devices  . . . . . . . . . . . . .  8
     2.8.  Scenario 8: Battery powered devices  . . . . . . . . . . .  8


By influencing, I mean that the demand/response for policies in these use cases .
However, I would not list demand/response at the same level as these use cases, as the section 2 introduction explains:

2.  Scenarios and target devices

   This section describes a selection of scenarios for the application
   of energy management.  For each scenario a list of target devices is
   given in the headline, for which IETF energy management standards are
   needed.

And the EMAN WG will not be solving the demand/response problem: it will "just" produce one piece of the puzzle

Regards, Benoit.

- page 8, section 2.7 - obviously not mentioning ASHRAE recommendations (PUE/DCIE) is not acknowledging industry standards for energy monitoring
in datacenters.

- page 9, section 3.2 - aggregation of energy data is really what helps facility managers to understand where they could save money.
in fact, there would be a need to discuss how aggregation can be done. It could be as simple as monitoring all physical distribution circuits
but could also be aggregated by categories such as engineering/sales/marketing departments or heating/cooling/IT/lights,...
To fully understand the consumption, you also need to define the "aggregation point" to consider what is counted downstream and upstream.
For example, data retrieved on a server or router will be a portion of data retrieved on a smart plug connecting all these devices which will be a portion
of data retrieved at a smart circuit breaker level, and so on.

- page 11, section 3.4.2, you could also indicate: line frequency, power factor, apparent power, reactive power,... as metrics being available on certain
category of devices.

- page 12, section 3.4.4, you may want to compare with existing MIB such as UPS vendor's MIBs


--------------090703010301010304060204-- From ietf@quittek.at Thu Mar 3 07:19:41 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C593A6802 for ; Thu, 3 Mar 2011 07:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdeEvHT+BW9v for ; Thu, 3 Mar 2011 07:19:40 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 8E4413A67B2 for ; Thu, 3 Mar 2011 07:19:40 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MErMM-1PnyXV1s9y-00GSYF; Thu, 03 Mar 2011 16:20:47 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> In-Reply-To: <20110301111548.GA9369@elstar.local> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Thu, 3 Mar 2011 16:20:48 +0100 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:ljkVrZGhvKyKC7mUPKs3yD1Kqpj1a0SY9y5UAi4/Myx YkSU/zjfuWbJ1fpbOKCVGH3k+mD33Ps673xumLv9FasbOwaiUP 18Nc48R0dlkxC3o04JGaTxlAWfYHaJeICmhhQoBLPv5o2i4Qut zGdWPafeHKtjxMxB3Z07pQm9M02ITlwVSUmGHAX1brStzZETiq tpnP869e1bH2oXEjkO8Cw== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 15:19:41 -0000 Hi Juergen, If we use the Entity MIB for reporting on power values for remote PCs aren't we over-stretching the Entity MIB a bit? In the introduction of RFC4133, there is stated: 'Effectively, there is some "overall" physical entity which houses the sum of the things managed by that one agent, i.e., there are multiple "logical" entities within a single physical entity.' We exceed this limitation, when we report on several entities that are not located within a single physical entity. Juergen Q. Am 01.03.2011 um 12:15 schrieb Juergen Schoenwaelder: > On Tue, Mar 01, 2011 at 11:50:23AM +0100, Juergen Quittek wrote: >> Hi Juergen, >> >> I assume you refer to the SNMP context engineID. >> >> Yes, this can be used as long as the remote device has one. >> If not, something else is needed. > > I am talking about an SNMP context as defined in RFC 3411 section > 3.3.1 and in particular the usage of contextName as a mechanism to > select different MIB trees. This is what the ENTITY-MIB calls a > logical entity. > > The default contextName ("") is the zero-length string, so on a power > over ethernet switch, we have objects reporting the energy consumption > of the components of the device itself (physical entities). If you > plug a phone into the switch and the switch is able to determine power > consumption of the remote phone device, you can instantiate another > MIB tree that reports the components of the phone as physical entities > under a different contextName (e.g., "port-N"). The ENTITY-MIB allows > you to discover which contexts are available. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 3 11:51:43 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2F53A6843 for ; Thu, 3 Mar 2011 11:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.733 X-Spam-Level: X-Spam-Status: No, score=-100.733 tagged_above=-999 required=5 tests=[AWL=-2.484, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISpE86x842V9 for ; Thu, 3 Mar 2011 11:51:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9AD603A67EF for ; Thu, 3 Mar 2011 11:51:42 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4BE6AC0017; Thu, 3 Mar 2011 20:52:50 +0100 (CET) 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 rUv-iSLqC5zw; Thu, 3 Mar 2011 20:52:49 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E584C0006; Thu, 3 Mar 2011 20:52:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4685C16DAE35; Thu, 3 Mar 2011 20:52:44 +0100 (CET) Date: Thu, 3 Mar 2011 20:52:43 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20110303195243.GC21657@elstar.local> Mail-Followup-To: Juergen Quittek , "Romascanu, Dan (Dan)" , eman mailing list References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@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 mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:51:44 -0000 On Thu, Mar 03, 2011 at 04:20:48PM +0100, Juergen Quittek wrote: > If we use the Entity MIB for reporting on power values for remote PCs > aren't we over-stretching the Entity MIB a bit? > > In the introduction of RFC4133, there is stated: > > 'Effectively, there is some "overall" physical entity which houses > the sum of the things managed by that one agent, i.e., there are > multiple "logical" entities within a single physical entity.' > > We exceed this limitation, when we report on several entities > that are not located within a single physical entity. So all we have is a philosophical concern? What do you think is the proper way in SNMP to report data about remote systems? Are contexts not the natural way of doing this? I went to the requirements document and searched for remote but could not find a decent description what this remote monitoring requirement is. The framework document mentions remote somewhere but does not provide any details either. So where can I find more details? /js PS: Out of curiosity, I actually like to know how the devices this group models actually retrieve measurement data from remote systems. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From chrisv@cyberswitching.com Thu Mar 3 12:54:48 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8C63A6A04 for ; Thu, 3 Mar 2011 12:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.069 X-Spam-Level: X-Spam-Status: No, score=-4.069 tagged_above=-999 required=5 tests=[AWL=-2.470, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l4mkr1XYCj4 for ; Thu, 3 Mar 2011 12:54:47 -0800 (PST) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) by core3.amsl.com (Postfix) with ESMTP id 874CA3A6800 for ; Thu, 3 Mar 2011 12:54:47 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o143.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id b50007d4.0.6385.00-374.14738.p01c11o143.mxlogic.net (envelope-from ); Thu, 03 Mar 2011 13:55:56 -0700 (MST) X-MXL-Hash: 4d70005c26e1cf5c-30ec5d7536264ff575720ae69eeca4a3fa4b1ff4 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 12:55:37 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 2CE292F6001; Thu, 3 Mar 2011 12:55:55 -0800 (PST) Date: Thu, 3 Mar 2011 12:55:55 -0800 From: chrisv@cyberswitching.com To: Juergen Quittek , "Romascanu, Dan (Dan)" , eman mailing list Message-ID: <20110303205555.GA8301@cslinux-build01.cyberswitching.local> References: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110303195243.GC21657@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 03 Mar 2011 20:55:37.0855 (UTC) FILETIME=[5943E0F0:01CBD9E5] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=mrxgWj59b9sA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=i09YgNfkIz8lUz5JhgMA] X-AnalysisOut: [:9 a=4Zlnso4ex-1_vmgpYUUA:7 a=qFIoF9TN4zwHKIdRmOGT4PlVS9AA] X-AnalysisOut: [:4 a=CjuIK1q_8ugA:10 a=vmzExeJjeL_14q1L:21 a=subVHQMuW_FVj] X-AnalysisOut: [da5:21] Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:54:48 -0000 On Thu, Mar 03, 2011 at 08:52:43PM +0100, Juergen Schoenwaelder wrote: > On Thu, Mar 03, 2011 at 04:20:48PM +0100, Juergen Quittek wrote: > > > If we use the Entity MIB for reporting on power values for remote PCs > > aren't we over-stretching the Entity MIB a bit? > > > > In the introduction of RFC4133, there is stated: > > > > 'Effectively, there is some "overall" physical entity which houses > > the sum of the things managed by that one agent, i.e., there are > > multiple "logical" entities within a single physical entity.' > > > > We exceed this limitation, when we report on several entities > > that are not located within a single physical entity. > > So all we have is a philosophical concern? What do you think is the > proper way in SNMP to report data about remote systems? Are contexts > not the natural way of doing this? > > I went to the requirements document and searched for remote but could > not find a decent description what this remote monitoring requirement > is. The framework document mentions remote somewhere but does not > provide any details either. So where can I find more details? I'll address the above points in a separate thread that will be started later tonight. > PS: Out of curiosity, I actually like to know how the devices this > group models actually retrieve measurement data from remote > systems. Modbus, BACnet, etc. There are lots of non-SNMP protocols that can transmit information to a collector. This is, I believe, the principle behind the Cisco Mediator product, which is gaining a lot of traction as an IP gateway/bridge for the non-SNMP products. Chris From bill.mielke@alcatel-lucent.com Thu Mar 3 20:23:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F421F3A6927 for ; Thu, 3 Mar 2011 20:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6rvRUxDwtyS for ; Thu, 3 Mar 2011 20:23:20 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id AA6EE3A6925 for ; Thu, 3 Mar 2011 20:23:20 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p244ORP1027084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Mar 2011 22:24:28 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p244OR6T025877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 3 Mar 2011 22:24:27 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 3 Mar 2011 22:24:27 -0600 From: "Mielke, William F (Bill)" To: eman mailing list Date: Thu, 3 Mar 2011 22:24:24 -0600 Thread-Topic: [eman] modeling power states Thread-Index: AcvZegQnu/bL6U6bS0+ljmwIcwj79gApue9Q Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C826@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <20110301102032.GA9233@elstar.local> <20110301160031.GA1150@cslinux-build01.cyberswitching.local> <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@elstar.local> <20110303074643.GA31664@cslinux-build01.cyberswitching.local> <20110303080644.GB19258@elstar.local> In-Reply-To: <20110303080644.GB19258@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 04:23:22 -0000 I think the issue here is that there a lot of people on this list who undou= btedly have personal experience in implementing the ENTITY-MIB and the phys= ical and logical tables which some here may lack. I certainly know that I = am no expert in the practical aspects of how these tables are implemented i= n actual practice. I would expect that there may be common or de facto sta= ndard ways of using them that aren't obvious directly from the base specifi= cations. Does anyone on this list know of any publicly available sources of informat= ion on the practical side of implementing these objects and how they are ac= tually used in real systems? Tutorials? Books? Archived discussions? Op= en source code? I for one would like to review such information if it is a= vailable. Thanks, William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein =20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Juergen Schoenwaelder > Sent: Thursday, March 03, 2011 3:07 AM > To: chrisv@cyberswitching.com > Cc: eman mailing list > Subject: Re: [eman] modeling power states >=20 > On Wed, Mar 02, 2011 at 11:46:43PM -0800,=20 > chrisv@cyberswitching.com wrote: > =20 > > I'm still struggling with some of these ENTITY-MIB concepts. They > > really do seem to be convoluted and require either highly specific > > (esoteric?) domain knowledge about ENTITY-MIB to be useful=20 > or "hacks" to > > get it to do what we want. > >=20 > > Certainly, I tend to be vocal. :-) What do others (that we haven't > > heard from) think? >=20 > My understanding is that this IETF WG is chartered to produce > standards-track MIB modules and thus this requires some willingness to > understand how SNMP and core IETF MIB modules work. You might call > this "highly specific (esoteric?) domain knowledge" but then I am > wondering how you write this down in a way that it passes the IESG. >=20 > I jumped into this discussion because I sensed that people have a > completely wrong idea of the ENTITY-MIB, in particular what logical > entities are. I do not know where this confusion is coming from, I can > only offer help so that the WG understands what the ENTITY-MIB and > SNMP has to offer. >=20 > /js >=20 > --=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 ietf@quittek.at Fri Mar 4 01:29:21 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227BD3A68B6 for ; Fri, 4 Mar 2011 01:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[AWL=-2.273, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spvu727GhOmO for ; Fri, 4 Mar 2011 01:29:20 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id E43AC3A6889 for ; Fri, 4 Mar 2011 01:29:19 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LnDWH-1QTfd00jev-00hvQC; Fri, 04 Mar 2011 10:30:27 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> In-Reply-To: <20110303195243.GC21657@elstar.local> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <0E32737B-484D-4263-9749-149E61601B03@quittek.at> Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Fri, 4 Mar 2011 10:30:27 +0100 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:0OGVHP1E28WeHfCvZ76NQxiGkZd5+0HL2i7DY74yFgR FDlriqW4JoITEHM9TIvegJMChr7iXt9ctYevAUUv2fGMysIGT+ SkJ6lId9reebBFWT5odnfQodYpxwyTYgXyhFJqYxbjFkSpC9m4 xP29HZD+RaetPGgf7ijdop2+OU0lfkp30tS2o0F0Id+REEkxrr 6RSyHl3DX4PPcS20ff/RQ== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 09:29:21 -0000 On 03.03.2011, 20:52, Juergen Schoenwaelder wrote: > On Thu, Mar 03, 2011 at 04:20:48PM +0100, Juergen Quittek wrote: > >> If we use the Entity MIB for reporting on power values for remote PCs >> aren't we over-stretching the Entity MIB a bit? >> >> In the introduction of RFC4133, there is stated: >> >> 'Effectively, there is some "overall" physical entity which houses >> the sum of the things managed by that one agent, i.e., there are >> multiple "logical" entities within a single physical entity.' >> >> We exceed this limitation, when we report on several entities >> that are not located within a single physical entity. > > So all we have is a philosophical concern? What do you think is the > proper way in SNMP to report data about remote systems? Are contexts > not the natural way of doing this? The question we need to answer is not a philosophical one, but a technical one: Is there anything in the Entity MIB module that breaks if we extend it beyond the scope that the IETF originally limited it to? The question is valid, because we can assume that when the Entity MIB was written, checked, and implemented, probably everyone had the original scope in mind and did not check if things would still work with our intended extension. I started writing a summary on the applicability of the Entity MIB to eman. For this, I don't want to ignore such a sentence from RFC 4133 as the one cited above. I rather want to be able to clearly state: "We are extending the Entity MIB beyond its original scope and there is no technical problem with this." > I went to the requirements document and searched for remote but could > not find a decent description what this remote monitoring requirement > is. The framework document mentions remote somewhere but does not > provide any details either. So where can I find more details? Good point. We should elaborate this more clearly in the requirements. There are currently two sections in draft-ietf-eman-requirements dealing with this issue: 1.2. Specific aspects of energy management 3.2. Remote and Aggregated Monitoring I will update them with more detailed example scenarios and figures. > /js > > PS: Out of curiosity, I actually like to know how the devices this > group models actually retrieve measurement data from remote > systems. I see two basic scenarios: 1. The reporting device is attached to the power supply lines of other devices Examples (also mentioned in raft-ietf-eman-requirements) are dedicated power meters, power distribution units with built-in power meters, and PoE switches. Here devices report on what they measured at power lines attached to them. If they are able to find out which devices are supplied by a power line, then they should report this as well. 2. The reporting device receives power/energy information on other devices by any means that are not based on SNMP or even not on IP. It may even just be an estimate of power consumption of other devices. An example would be a gateway to a building network, that receives power information on many devices within the building and makes it available using eman MIB modules. I think Cisco has another example with PCs reporting their power to switches and the switches report it to the management system, but this can certainly be explained better by the people from Cisco. Thanks, Juergen Q. > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 4 03:24:34 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F063A69F5 for ; Fri, 4 Mar 2011 03:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.109 X-Spam-Level: X-Spam-Status: No, score=-103.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfGmpYcPAiyQ for ; Fri, 4 Mar 2011 03:24:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 542453A69A0 for ; Fri, 4 Mar 2011 03:24:32 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2C35C0005; Fri, 4 Mar 2011 12:25:40 +0100 (CET) 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 rXM1XEJclLO8; Fri, 4 Mar 2011 12:25:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7C45C0003; Fri, 4 Mar 2011 12:25:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3E88216DDA48; Fri, 4 Mar 2011 12:25:33 +0100 (CET) Date: Fri, 4 Mar 2011 12:25:32 +0100 From: Juergen Schoenwaelder To: "Mielke, William F (Bill)" Message-ID: <20110304112532.GA23422@elstar.local> Mail-Followup-To: "Mielke, William F (Bill)" , eman mailing list References: <20110301223012.GB21719@cslinux-build01.cyberswitching.local> <20110302162914.GA12358@cslinux-build01.cyberswitching.local> <20110302224433.GA17070@elstar.local> <20110303074643.GA31664@cslinux-build01.cyberswitching.local> <20110303080644.GB19258@elstar.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C826@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C826@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 11:24:34 -0000 On Thu, Mar 03, 2011 at 10:24:24PM -0600, Mielke, William F (Bill) wrote: > I think the issue here is that there a lot of people on this list who undoubtedly have personal experience in implementing the ENTITY-MIB and the physical and logical tables which some here may lack. I certainly know that I am no expert in the practical aspects of how these tables are implemented in actual practice. I would expect that there may be common or de facto standard ways of using them that aren't obvious directly from the base specifications. > > Does anyone on this list know of any publicly available sources of information on the practical side of implementing these objects and how they are actually used in real systems? Tutorials? Books? Archived discussions? Open source code? I for one would like to review such information if it is available. > Perhaps it helps to take a quick look at an example (in this case data taken from a Cisco Catalyst 4500 L3 switch). Here is a part of the physical entity containment hierarchy: $ scli -c "show entity containment" $DEVICE ENTITY CLASS CONTAINMENT 1 chassis Cisco Systems, Inc. WS-C4506 6 slot switch 2 container |- WS-C4506 6 slot switch chassis slot 1000 module | `- Supervisor II+ with 2 1000BaseX GBIC ports 1001 container | |- Port Container 1003 port | | `- 1000BaseSX 1002 container | `- Port Container 1004 port | `- 1000BaseSX 3 container |- WS-C4506 6 slot switch chassis slot 2000 module | `- 10/100/1000BaseT (RJ45) with 48 10/100/1000 baseT ports 4 container |- WS-C4506 6 slot switch chassis slot 3000 module | `- 10/100/1000BaseT (RJ45) with 48 10/100/1000 baseT ports 5 container |- WS-C4506 6 slot switch chassis slot 4000 module | `- 10/100/1000BaseT (RJ45)V with 48 10/100/1000 baseT voice power ports (Cisco/IEE 6 container |- WS-C4506 6 slot switch chassis slot 7 container |- WS-C4506 6 slot switch chassis slot 8 backplane |- WS-C4506 6 slot switch backplane 9 sensor |- Chassis Temperature Sensor 10 container |- Container of Fan Tray 11 fan | `- FanTray 12 container `- Container of Container of Power Supply 13 container |- Container of Power Supply 14 powerSupply | `- Power Supply ( AC 1300W ) 15 sensor | `- Power Supply Fan Sensor 16 container `- Container of Power Supply 17 powerSupply `- Power Supply ( AC 1300W ) 18 sensor `- Power Supply Fan Sensor I have removed all the ports from the tree since it would get a bit long. Anyway, this should give you an idea what you get already out of today's ENTITY-MIB. Note the power supplies and the various sensors already there. Here is more detailed information I can get from one of the power supplies: $ scli -c "show entity details" $DEVICE [...] Entity: 17 Name: Power Supply 2 Vendor: Cisco Systems, Inc. HW Rev: V04 Model: PWR-C45-1300ACV FW Rev: Serial: xxxxxxxxxxxx SW Rev: Asset: Class: powerSupply (replaceable) Alias: Descr: Power Supply ( AC 1300W ) [...] These information fields are application to all physical entity types. Now from an ENTITY-MIB point of view, it seems rather logical to have lets say batteries represented as physical components and to have augmentations that can provide more detailed information for batteries. Similarily, reporting power states and power consumption of modules or ports or power supplies seems a rather straight-forward extension (in fact, a number of objects in the pmTable of the ENERGY-AWARE-MIB would not be needed at all). Back to our example device. Since our device provides briding functionality per VLAN, it supports multiple "virtual" bridge instances. To access them, we have to use different SNMP contexts (aka logical entities in ENTITY-MIB speak). So lets look which contexts exists: $ ./scli -c "show snmp contexts" $SWITCH Description: VLAN0000 Community: public@0 ContextEngineID: 800000090300020000000100 (Cisco Systems) ContextName: Transport: xxx.xxx.xxx.xxx:161 (udp) Description: vlan1 Community: public@1 ContextEngineID: 800000090300020000000100 (Cisco Systems) Context: Transport: xxx.xxx.xxx.xxx:161 (udp) [...] This data is retrieved from the logical entity table, which simply provides a directory of all known SNMP contexts plus the information needed to access them. If I use SNMPv1/SNMPv2c, I can access the SNMP agent using the community string "public@1" to see the bridge instance of vlan1. Note that the logical entity can even point to a different transport endpoint, so I could even point to a separate SNMP agent. I have no clue whether Net-SNMP supports meanwhile the ENTITY-MIB out of the box. The biggest challenge I guess will not be the implementation of the MIB objects themself but the digging of information out of the various operating systems Net-SNMP is running on. But it would actually be cool if Net-SNMP would provide a common way to list the components of the systems via the ENTITY-MIB and if it would be possible to access the various sensors most computers now have embedded. /js PS: If I manage to tweak the scli code a bit during the weekend, I might also be able to show you sensor readings from the same Cisco box. PS: We have recently implemented a tiny SNMP agent running under Contiki on AVR Raven boards (8-bit microcontroller) and to report the temperature sensor reading, we implemented just a few objects to represent this sensor using the ENTITY-SENSOR-MIB. In terms of implementation complexity, this all might be more a reading and learning hurdle for people not familiar with the ENTITY-MIB than a coding hurdle. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@quittek.at Fri Mar 4 07:16:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3474E3A69DA for ; Fri, 4 Mar 2011 07:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wmcYN4nm5A3 for ; Fri, 4 Mar 2011 07:16:26 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 14FB93A69A5 for ; Fri, 4 Mar 2011 07:16:25 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0M4Vnk-1QCGKZ3j12-00ypyD; Fri, 04 Mar 2011 16:17:28 +0100 References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> <20110303020507.GA19321@cslinux-build01.cyberswitching.local> In-Reply-To: <20110303020507.GA19321@cslinux-build01.cyberswitching.local> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at> Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Fri, 4 Mar 2011 16:17:28 +0100 To: chrisv@cyberswitching.com, eman mailing list X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:EXaEQANP7OJOh5NGrSo8+wCRympyDQECxkjJ7r4ySM3 J10nmd6PfLzf42SuMgVxi7kDpe3QflFBPaxoQg5EjIwEFaN14t E02w6WQE9AtFXFnWt7I8SZarBXbGMftymJgXLkazLtDeW1UaFL VAXBSRukKB1x0VZPr7FpVmTD8ucLCkKxXPtoXMCepzVT73iftu 2vKC6MoZG1ZBZTCbj5Xkw== Cc: Bruce Nordman Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:16:27 -0000 Hi Chris, What you say shows again that ACPI power states are not sufficient for EMAN. If we model the notebook computer with battery as one device, then we will need additional (non-ACPI) states for the notebook, such as, for example, - off, but charging batters - on, but supplied by battery - etc. If we follow your suggestion and model the notebook such that it contains a PC device and a battery device, then we can use ACPI states for the contained PC. But we need new (non-ACPI) states for modeling the battery, such as, for example, - full - charging - trickle charging - discharging (providing power) - empty. The same applies to DMTF states. All static ones are mapped to ACPI. Thus, also DMTF states are not sufficient for what we need in the EMAN WG. Thanks, Juergen Am 03.03.2011 um 03:05 schrieb chrisv@cyberswitching.com: > On Wed, Mar 02, 2011 at 09:44:12PM +0100, Juergen Quittek wrote: >> Which power state would apply to my notebook computer when >> >> - it is switched of, but charging its batteries. >> This is an off-state with relatively high power consumption. >> Is this covered by any ACPI or DMTF states or by the states in the >> drafts we have? >> - it is switched on and fully operational, but running on built-in >> battery only. >> This is an operational state with zero power consumption, at least >> as seen from outside. >> Again, how can we cover this with states described so far? > > Hi Juergen, > > My initial thought is that the server entity would be OFF and the > battery entity would be ON/charging. Like with a tripped circuit > breaker, "off" doesn't quite cut it, but I think we can find an > appropriate caption. > > They key is to realize that the states for each entity are reflected > separately. > > Thanks, > Chris From bill.mielke@alcatel-lucent.com Fri Mar 4 07:34:54 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3483A6906 for ; Fri, 4 Mar 2011 07:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BP3TmTyVcdxf for ; Fri, 4 Mar 2011 07:34:53 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 7E3AE3A6893 for ; Fri, 4 Mar 2011 07:34:53 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p24Fa2eo003999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Mar 2011 09:36:02 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p24Fa2RR024669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Mar 2011 09:36:02 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 4 Mar 2011 09:36:02 -0600 From: "Mielke, William F (Bill)" To: eman mailing list Date: Fri, 4 Mar 2011 09:35:58 -0600 Thread-Topic: [eman] modeling power states Thread-Index: AcvaTs/pmu1AAmoWRoyJ1D0rWlv25gAMZLag Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C950@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> <0E32737B-484D-4263-9749-149E61601B03@quittek.at> In-Reply-To: <0E32737B-484D-4263-9749-149E61601B03@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:34:54 -0000 > Juergen Quittek [ietf@quittek.at] wrote: > > 2. The reporting device receives power/energy information on other=20 > devices by any means that are not based on SNMP or even not on IP. > It may even just be an estimate of power consumption of other devices. > An example would be a gateway to a building network, that receives > power information on many devices within the building and makes=20 > it available using eman MIB modules. I have a question related to "by any means that are not based on SNMP or ev= en not on IP". I understand that the intent here is to emphasize that such= information may be gathered by any proprietary means available, which is f= ine. Is the intent here also to explicitly EXCLUDE the use of SNMP and the= EMAN MIBs as a means of gathering such "internal" information? Personally I don't think that we should prohibit the use of SNMP and the EM= AN MIBs in that context so I wish to understand your thinking in this case. Now once we envision a multi-layered hierachy of SNMP and EMAN driven repor= ting we are starting to dive into the discussion of Parent/Child that is wa= iting to be discussed. I am happy enough to save that discussion until lat= er but a brief response here might help people to start getting their menta= l gears working in this space as well. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein =20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Juergen Quittek > Sent: Friday, March 04, 2011 4:30 AM > To: Juergen Schoenwaelder > Cc: eman mailing list > Subject: Re: [eman] modeling power states >=20 > On 03.03.2011, 20:52, Juergen Schoenwaelder wrote: >=20 > > On Thu, Mar 03, 2011 at 04:20:48PM +0100, Juergen Quittek wrote: > >=20 > >> If we use the Entity MIB for reporting on power values for=20 > remote PCs > >> aren't we over-stretching the Entity MIB a bit? > >>=20 > >> In the introduction of RFC4133, there is stated: > >>=20 > >> 'Effectively, there is some "overall" physical entity=20 > which houses=20 > >> the sum of the things managed by that one agent, i.e., there are=20 > >> multiple "logical" entities within a single physical entity.' > >>=20 > >> We exceed this limitation, when we report on several entities=20 > >> that are not located within a single physical entity. > >=20 > > So all we have is a philosophical concern? What do you think is the > > proper way in SNMP to report data about remote systems? Are contexts > > not the natural way of doing this? >=20 > The question we need to answer is not a philosophical one, but a=20 > technical one: > Is there anything in the Entity MIB module that breaks if we extend it > beyond the scope that the IETF originally limited it to?=20 > The question is valid, because we can assume that when the Entity > MIB was written, checked, and implemented, probably everyone had=20 > the original scope in mind and did not check if things would=20 > still work > with our intended extension. >=20 > I started writing a summary on the applicability of the=20 > Entity MIB to eman. > For this, I don't want to ignore such a sentence from RFC=20 > 4133 as the one > cited above. I rather want to be able to clearly state: "We=20 > are extending=20 > the Entity MIB beyond its original scope and there is no technical=20 > problem with this." >=20 > > I went to the requirements document and searched for remote=20 > but could > > not find a decent description what this remote monitoring=20 > requirement > > is. The framework document mentions remote somewhere but does not > > provide any details either. So where can I find more details? >=20 > Good point. We should elaborate this more clearly in the requirements. > There are currently two sections in=20 > draft-ietf-eman-requirements dealing > with this issue: > 1.2. Specific aspects of energy management > 3.2. Remote and Aggregated Monitoring > I will update them with more detailed example scenarios and figures. >=20 > > /js > >=20 > > PS: Out of curiosity, I actually like to know how the devices this > > group models actually retrieve measurement data from remote > > systems. >=20 > I see two basic scenarios: > 1. The reporting device is attached to the power supply lines=20 > of other=20 > devices > Examples (also mentioned in raft-ietf-eman-requirements) are=20 > dedicated=20 > power meters, power distribution units with built-in power meters, and > PoE switches. > Here devices report on what they measured at power lines=20 > attached to them. > If they are able to find out which devices are supplied by a=20 > power line,=20 > then they should report this as well. >=20 > 2. The reporting device receives power/energy information on other=20 > devices by any means that are not based on SNMP or even not on IP. > It may even just be an estimate of power consumption of other devices. > An example would be a gateway to a building network, that receives > power information on many devices within the building and makes=20 > it available using eman MIB modules. >=20 > I think Cisco has another example with PCs reporting their power to=20 > switches and the switches report it to the management system,=20 > but this can certainly be explained better by the people from Cisco. >=20 > Thanks, >=20 > Juergen Q. >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > = From ietf@quittek.at Fri Mar 4 07:38:03 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053FB3A69E0 for ; Fri, 4 Mar 2011 07:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.636 X-Spam-Level: X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[AWL=-2.116, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYOZk2TZyHj6 for ; Fri, 4 Mar 2011 07:38:01 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id D3FA13A6893 for ; Fri, 4 Mar 2011 07:38:00 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MCMOD-1PmUYI3Fzt-0097Yt; Fri, 04 Mar 2011 16:39:05 +0100 References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> <0E32737B-484D-4263-9749-149E61601B03@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C950@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C950@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-7-970880777 Message-Id: <89113E99-B507-498C-954E-B79258B53140@quittek.at> From: Juergen Quittek Date: Fri, 4 Mar 2011 16:39:04 +0100 To: "Mielke, William F (Bill)" X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:ZN5LgNJLIx4ZSUj3qckNKklSonpgfKrPyKqhZauiB+c p+OSyqPe7RblNRwHWlZ5gE+LOia1qgQP+AWZwbEomGed2CgCD6 cE9uJNnkmJWwvi5QLxmE5RtB7cIFKEA8HX+J7xppUNwi5vfp9Q aoHmcJAS5bYK9iRO5++lvfYyFfryE+35I9qUI5QcK4ZVhyXWMz 0DjmZwCuBeUDDm86MjGrA== Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:38:03 -0000 --Apple-Mail-7-970880777 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bill, Am 04.03.2011 um 16:35 schrieb Mielke, William F (Bill): >> Juergen Quittek [ietf@quittek.at] wrote: >>=20 >> 2. The reporting device receives power/energy information on other=20 >> devices by any means that are not based on SNMP or even not on IP. >> It may even just be an estimate of power consumption of other = devices. >> An example would be a gateway to a building network, that receives >> power information on many devices within the building and makes=20 >> it available using eman MIB modules. >=20 > I have a question related to "by any means that are not based on SNMP = or even not on IP". I understand that the intent here is to emphasize = that such information may be gathered by any proprietary means = available, which is fine. Is the intent here also to explicitly EXCLUDE = the use of SNMP and the EMAN MIBs as a means of gathering such = "internal" information? Sorry for not being clear in my message. I definitely do not want to exclude gathering such information with = SNMP. Juergen > Personally I don't think that we should prohibit the use of SNMP and = the EMAN MIBs in that context so I wish to understand your thinking in = this case. >=20 > Now once we envision a multi-layered hierachy of SNMP and EMAN driven = reporting we are starting to dive into the discussion of Parent/Child = that is waiting to be discussed. I am happy enough to save that = discussion until later but a brief response here might help people to = start getting their mental gears working in this space as well. >=20 > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 >=20 > "Live like you're going to die tomorrow. > Learn like you're going to live forever." >=20 > - Albert Einstein >=20 >=20 >=20 >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 >> Behalf Of Juergen Quittek >> Sent: Friday, March 04, 2011 4:30 AM >> To: Juergen Schoenwaelder >> Cc: eman mailing list >> Subject: Re: [eman] modeling power states >>=20 >> On 03.03.2011, 20:52, Juergen Schoenwaelder wrote: >>=20 >>> On Thu, Mar 03, 2011 at 04:20:48PM +0100, Juergen Quittek wrote: >>>=20 >>>> If we use the Entity MIB for reporting on power values for=20 >> remote PCs >>>> aren't we over-stretching the Entity MIB a bit? >>>>=20 >>>> In the introduction of RFC4133, there is stated: >>>>=20 >>>> 'Effectively, there is some "overall" physical entity=20 >> which houses=20 >>>> the sum of the things managed by that one agent, i.e., there are=20= >>>> multiple "logical" entities within a single physical entity.' >>>>=20 >>>> We exceed this limitation, when we report on several entities=20 >>>> that are not located within a single physical entity. >>>=20 >>> So all we have is a philosophical concern? What do you think is the >>> proper way in SNMP to report data about remote systems? Are contexts >>> not the natural way of doing this? >>=20 >> The question we need to answer is not a philosophical one, but a=20 >> technical one: >> Is there anything in the Entity MIB module that breaks if we extend = it >> beyond the scope that the IETF originally limited it to?=20 >> The question is valid, because we can assume that when the Entity >> MIB was written, checked, and implemented, probably everyone had=20 >> the original scope in mind and did not check if things would=20 >> still work >> with our intended extension. >>=20 >> I started writing a summary on the applicability of the=20 >> Entity MIB to eman. >> For this, I don't want to ignore such a sentence from RFC=20 >> 4133 as the one >> cited above. I rather want to be able to clearly state: "We=20 >> are extending=20 >> the Entity MIB beyond its original scope and there is no technical=20 >> problem with this." >>=20 >>> I went to the requirements document and searched for remote=20 >> but could >>> not find a decent description what this remote monitoring=20 >> requirement >>> is. The framework document mentions remote somewhere but does not >>> provide any details either. So where can I find more details? >>=20 >> Good point. We should elaborate this more clearly in the = requirements. >> There are currently two sections in=20 >> draft-ietf-eman-requirements dealing >> with this issue: >> 1.2. Specific aspects of energy management >> 3.2. Remote and Aggregated Monitoring >> I will update them with more detailed example scenarios and figures. >>=20 >>> /js >>>=20 >>> PS: Out of curiosity, I actually like to know how the devices this >>> group models actually retrieve measurement data from remote >>> systems. >>=20 >> I see two basic scenarios: >> 1. The reporting device is attached to the power supply lines=20 >> of other=20 >> devices >> Examples (also mentioned in raft-ietf-eman-requirements) are=20 >> dedicated=20 >> power meters, power distribution units with built-in power meters, = and >> PoE switches. >> Here devices report on what they measured at power lines=20 >> attached to them. >> If they are able to find out which devices are supplied by a=20 >> power line,=20 >> then they should report this as well. >>=20 >> 2. The reporting device receives power/energy information on other=20 >> devices by any means that are not based on SNMP or even not on IP. >> It may even just be an estimate of power consumption of other = devices. >> An example would be a gateway to a building network, that receives >> power information on many devices within the building and makes=20 >> it available using eman MIB modules. >>=20 >> I think Cisco has another example with PCs reporting their power to=20= >> switches and the switches report it to the management system,=20 >> but this can certainly be explained better by the people from Cisco. >>=20 >> Thanks, >>=20 >> Juergen Q. >>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>=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 --Apple-Mail-7-970880777 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Bill,

Am 04.03.2011 um 16:35 schrieb Mielke, William F = (Bill):

Juergen Quittek = [ietf@quittek.at] wrote:

2. The = reporting device receives power/energy information on other =
devices by any means that are = not based on SNMP or even not on IP.
It may even just be an estimate of power consumption of = other devices.
An example = would be a gateway to a building network, that = receives
power information on = many devices within the building and makes
it available using eman MIB modules.

I = have a question related to "by any means that are not based on SNMP or = even not on IP".  I understand that the intent here is to emphasize = that such information may be gathered by any proprietary means = available, which is fine.  Is the intent here also to explicitly = EXCLUDE the use of SNMP and the EMAN MIBs as a means of gathering such = "internal" information?

Sorr= y for not being clear in my message.
I definitely do not want = to exclude gathering such information with = SNMP.

   =  Juergen

Personally I = don't think that we should prohibit the use of SNMP and the EMAN MIBs in = that context so I wish to understand your thinking in this = case.

Now once we envision a multi-layered hierachy of SNMP and = EMAN driven reporting we are starting to dive into the discussion of = Parent/Child that is waiting to be discussed.  I am happy enough to = save that discussion until later but a brief response here might help = people to start getting their mental gears working in this space as = well.

William F. Mielke
Alcatel-Lucent
Distinguished Member = of Technical Staff
6200 East Broad Street
Room: = 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.= com
Phone: 614 367 5628
Fax: 614 367 5965

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

   - Albert = Einstein



-----Original = Message-----
From: eman-bounces@ietf.org = [mailto:eman-bounces@ietf.org] On
Behalf Of Juergen Quittek
Sent: Friday, March 04, 2011 4:30 = AM
To: Juergen = Schoenwaelder
Cc: eman mailing = list
Subject: Re: [eman] = modeling power states

On 03.03.2011, = 20:52, Juergen Schoenwaelder wrote:

On Thu, Mar 03, 2011 at 04:20:48PM +0100, Juergen Quittek = wrote:

If we = use the Entity MIB for reporting on power values for =
remote PCs
aren't = we over-stretching the Entity MIB a = bit?

In the = introduction of RFC4133, there is = stated:

= 'Effectively, there is some "overall" physical entity =
which= houses
 the sum of the things = managed by that one agent, i.e., there are =
=  multiple "logical" entities within a single physical = entity.'

We = exceed this limitation, when we report on several entities =
that = are not located within a single physical = entity.

So all we have is a = philosophical concern? What do you think is = the
proper way in SNMP to report data about remote systems? = Are contexts
not the natural way of doing = this?

The question we = need to answer is not a philosophical one, but a =
technical = one:
Is there anything in the = Entity MIB module that breaks if we extend = it
beyond the scope that the = IETF originally limited it to?
The question is valid, because we can assume that when the = Entity
MIB was written, = checked, and implemented, probably everyone had =
the original scope in mind = and did not check if things would
still work
with = our intended extension.

I started = writing a summary on the applicability of the =
Entity MIB to = eman.
For this, I don't want = to ignore such a sentence from RFC
4133 as the one
cited above. I rather want to be able to clearly state: = "We
are extending =
the Entity MIB beyond its = original scope and there is no technical
problem with this."

I went to the requirements document and searched for = remote
but = could
not find a decent description what this remote monitoring =
requirement
is. The framework document = mentions remote somewhere but does = not
provide any details either. So where can I find more = details?

Good point. We = should elaborate this more clearly in the = requirements.
There are = currently two sections in
draft-ietf-eman-requirements = dealing
with this = issue:
1.2.  Specific = aspects of energy management
3.2.  Remote and Aggregated = Monitoring
I will update them = with more detailed example scenarios and = figures.

/js

PS: Out of curiosity, I actually = like to know how the devices = this
  group models actually retrieve measurement = data from remote
=   systems.

I see two basic = scenarios:
1. The reporting = device is attached to the power supply lines =
of other =
devices
Examples = (also mentioned in raft-ietf-eman-requirements) are =
dedicated =
power meters, power = distribution units with built-in power meters, = and
PoE = switches.
Here devices report = on what they measured at power lines
attached to them.
If they are able to find out which devices are supplied by = a
power line, =
then they should report this = as well.

2. The = reporting device receives power/energy information on other =
devices by any means that are = not based on SNMP or even not on IP.
It may even just be an estimate of power consumption of = other devices.
An example = would be a gateway to a building network, that = receives
power information on = many devices within the building and makes
it available using eman MIB = modules.

I think Cisco = has another example with PCs reporting their power to =
switches and the switches = report it to the management system,
but this can certainly be explained better by the people = from Cisco.

Thanks,

=    Juergen Q.

--
Juergen Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1, 28759 = Bremen, Germany
Fax:   +49 421 200 = 3103         <http://www.jacobs-university.de/= >

_______________________________________________
eman mailing = list
eman@ietf.org
https://www.ietf.org/m= ailman/listinfo/eman

___________________________________________= ____
eman mailing list
eman@ietf.org
https://www.ietf.org/ma= ilman/listinfo/eman

= --Apple-Mail-7-970880777-- From bill.mielke@alcatel-lucent.com Fri Mar 4 07:39:19 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7E53A6946 for ; Fri, 4 Mar 2011 07:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=-2.084, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTdzfuw0YXcQ for ; Fri, 4 Mar 2011 07:39:17 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 5FA833A6893 for ; Fri, 4 Mar 2011 07:39:17 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p24FePmm007281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2011 09:40:26 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p24FePoS020848 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Mar 2011 09:40:25 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 4 Mar 2011 09:40:25 -0600 From: "Mielke, William F (Bill)" To: Juergen Quittek Date: Fri, 4 Mar 2011 09:40:24 -0600 Thread-Topic: [eman] modeling power states Thread-Index: Acvagk45pd+RyJdhRi+h5mLGa66k3QAABfXg Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C95A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> <0E32737B-484D-4263-9749-149E61601B03@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C950@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <89113E99-B507-498C-954E-B79258B53140@quittek.at> In-Reply-To: <89113E99-B507-498C-954E-B79258B53140@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C95AUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:39:19 -0000 --_000_0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C95AUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, that is what I would have expected/assumed but I wanted to make certain= we were on the same page. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein ________________________________ From: Juergen Quittek [mailto:ietf@quittek.at] Sent: Friday, March 04, 2011 10:39 AM To: Mielke, William F (Bill) Cc: eman mailing list Subject: Re: [eman] modeling power states Hi Bill, Am 04.03.2011 um 16:35 schrieb Mielke, William F (Bill): Juergen Quittek [ietf@quittek.at] wrote: 2. The reporting device receives power/energy information on other devices by any means that are not based on SNMP or even not on IP. It may even just be an estimate of power consumption of other devices. An example would be a gateway to a building network, that receives power information on many devices within the building and makes it available using eman MIB modules. I have a question related to "by any means that are not based on SNMP or ev= en not on IP". I understand that the intent here is to emphasize that such= information may be gathered by any proprietary means available, which is f= ine. Is the intent here also to explicitly EXCLUDE the use of SNMP and the= EMAN MIBs as a means of gathering such "internal" information? Sorry for not being clear in my message. I definitely do not want to exclude gathering such information with SNMP. Juergen Personally I don't think that we should prohibit the use of SNMP and the EM= AN MIBs in that context so I wish to understand your thinking in this case. Now once we envision a multi-layered hierachy of SNMP and EMAN driven repor= ting we are starting to dive into the discussion of Parent/Child that is wa= iting to be discussed. I am happy enough to save that discussion until lat= er but a brief response here might help people to start getting their menta= l gears working in this space as well. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-boun= ces@ietf.org] On Behalf Of Juergen Quittek Sent: Friday, March 04, 2011 4:30 AM To: Juergen Schoenwaelder Cc: eman mailing list Subject: Re: [eman] modeling power states On 03.03.2011, 20:52, Juergen Schoenwaelder wrote: On Thu, Mar 03, 2011 at 04:20:48PM +0100, Juergen Quittek wrote: If we use the Entity MIB for reporting on power values for remote PCs aren't we over-stretching the Entity MIB a bit? In the introduction of RFC4133, there is stated: 'Effectively, there is some "overall" physical entity which houses the sum of the things managed by that one agent, i.e., there are multiple "logical" entities within a single physical entity.' We exceed this limitation, when we report on several entities that are not located within a single physical entity. So all we have is a philosophical concern? What do you think is the proper way in SNMP to report data about remote systems? Are contexts not the natural way of doing this? The question we need to answer is not a philosophical one, but a technical one: Is there anything in the Entity MIB module that breaks if we extend it beyond the scope that the IETF originally limited it to? The question is valid, because we can assume that when the Entity MIB was written, checked, and implemented, probably everyone had the original scope in mind and did not check if things would still work with our intended extension. I started writing a summary on the applicability of the Entity MIB to eman. For this, I don't want to ignore such a sentence from RFC 4133 as the one cited above. I rather want to be able to clearly state: "We are extending the Entity MIB beyond its original scope and there is no technical problem with this." I went to the requirements document and searched for remote but could not find a decent description what this remote monitoring requirement is. The framework document mentions remote somewhere but does not provide any details either. So where can I find more details? Good point. We should elaborate this more clearly in the requirements. There are currently two sections in draft-ietf-eman-requirements dealing with this issue: 1.2. Specific aspects of energy management 3.2. Remote and Aggregated Monitoring I will update them with more detailed example scenarios and figures. /js PS: Out of curiosity, I actually like to know how the devices this group models actually retrieve measurement data from remote systems. I see two basic scenarios: 1. The reporting device is attached to the power supply lines of other devices Examples (also mentioned in raft-ietf-eman-requirements) are dedicated power meters, power distribution units with built-in power meters, and PoE switches. Here devices report on what they measured at power lines attached to them. If they are able to find out which devices are supplied by a power line, then they should report this as well. 2. The reporting device receives power/energy information on other devices by any means that are not based on SNMP or even not on IP. It may even just be an estimate of power consumption of other devices. An example would be a gateway to a building network, that receives power information on many devices within the building and makes it available using eman MIB modules. I think Cisco has another example with PCs reporting their power to switches and the switches report it to the management system, but this can certainly be explained better by the people from Cisco. Thanks, Juergen Q. -- 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 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --_000_0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C95AUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
OK, that is what I would have expected/assumed but I = wanted to=20 make certain we were on the same page.

William F.=20 Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200= East=20 Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email:=20 Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628Fax: 614=20 367 5965

"Live like you're going to die tomorrow.
 Learn lik= e=20 you're going to live forever."

    - Albert=20 Einstein

 

From: Juergen Quittek [mailto:ietf@qu= ittek.at]=20
Sent: Friday, March 04, 2011 10:39 AM
To: Mielke, Wi= lliam=20 F (Bill)
Cc: eman mailing list
Subject: Re: [eman]=20 modeling power states

Hi Bill,

Am 04.03.2011 um 16:35 schrieb Mielke, William F (Bill):
Juergen Quittek [ietf@quittek.at]=20 wrote:

2. The reporting device receives power/energy= =20 information on other
devices by any means that are not based on SN= MP or=20 even not on IP.
It may even just be an estimate of power=20 consumption of other devices.
An example would be a gateway to a building=20 network, that receives
power information on many devices within the= =20 building and makes
it available using eman MIB=20 modules.

I have a question related to "by any means= that=20 are not based on SNMP or even not on IP".  I understand that the i= ntent=20 here is to emphasize that such information may be gathered by any=20 proprietary means available, which is fine.  Is the intent here al= so to=20 explicitly EXCLUDE the use of SNMP and the EMAN MIBs as a means of gath= ering=20 such "internal" information?

Sorry for not being clear in my message.
I definitely do not want to exclude gathering such information with= =20 SNMP.

    Juergen

Personally I don't think that we should prohibit the use of SNMP a= nd=20 the EMAN MIBs in that context so I wish to understand your thinking in = this=20 case.

Now once we envision a multi-layered hierachy of SNMP and = EMAN=20 driven reporting we are starting to dive into the discussion of Parent/= Child=20 that is waiting to be discussed.  I am happy enough to save that=20 discussion until later but a brief response here might help people to s= tart=20 getting their mental gears working in this space as well.

Willia= m F.=20 Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
= 6200=20 East Broad Street
Room: 4B01-1V
Columbus, OH=20  43213-1530
Email: Bill.Mielke@alcatel-luce= nt.com
Phone:=20 614 367 5628
Fax: 614 367 5965

"Live like you're going to die= =20 tomorrow.
Learn like you're going to live=20 forever."

   - Albert Einstein



-----Original Message-----
From: eman-bounces@ietf.org=20 [mailto:eman-bounces@ietf.org] On
Behalf Of Juergen Quittek
Sent: Friday, March 04, 2011 4:30=20 AM
To: Juergen Schoenwaelder
Cc: eman mailing list
Subject: Re: [eman] modeling power=20 states

On 03.03.2011, 20:52, Juergen Schoenwaelder=20 wrote:

On Thu, Mar 03, 2011 at 04:20:48PM +0100,=20 Juergen Quittek wrote:

If we use the Entity MIB for reporting on= =20 power values for
remote PCs
aren't we over-stretching the Entity MIB = a=20 bit?

In the introduction of RFC4133, there is= =20 stated:

'Effectively, there is some "overall" phy= sical=20 entity
which houses
 the sum of the things managed by th= at=20 one agent, i.e., there are
 multiple "logical" entities within = a=20 single physical entity.'

We exceed this limitation, when we report= on=20 several entities
that are not located within a single phys= ical=20 entity.

So all we have is a philosophical concern? = What=20 do you think is the
proper way in SNMP to report data about rem= ote=20 systems? Are contexts
not the natural way of doing=20 this?

The question we need to answer is not a=20 philosophical one, but a
technical one:
Is there anything in the Entity MIB module th= at=20 breaks if we extend it
beyond the scope that the IETF originally lim= ited=20 it to?
The question is valid, because we can assume = that=20 when the Entity
MIB was written, checked, and implemented,=20 probably everyone had
the original scope in mind and did not check = if=20 things would
still work
with our intended extension.

I started writing a summary on the applicabil= ity=20 of the
Entity MIB to eman.
For this, I don't want to ignore such a sente= nce=20 from RFC
4133 as the one
cited above. I rather want to be able to clea= rly=20 state: "We
are extending
the Entity MIB beyond its original scope and = there=20 is no technical
problem with this."

I went to the requirements document and sea= rched=20 for remote
but could
not find a decent description what this rem= ote=20 monitoring
requirement
is. The framework document mentions remote= =20 somewhere but does not
provide any details either. So where can I = find=20 more details?

Good point. We should elaborate this more cle= arly=20 in the requirements.
There are currently two sections in=20
draft-ietf-eman-requirements=20 dealing
with this issue:
1.2.  Specific aspects of energy=20 management
3.2.  Remote and Aggregated=20 Monitoring
I will update them with more detailed example= =20 scenarios and figures.

/js

PS: Out of curiosity, I actually like to kn= ow=20 how the devices this
  group models actually retrieve= =20 measurement data from remote
  systems.

I see two basic scenarios:
1. The reporting device is attached to the po= wer=20 supply lines
of other
devices
Examples (also mentioned in=20 raft-ietf-eman-requirements) are
dedicated
power meters, power distribution units with=20 built-in power meters, and
PoE switches.
Here devices report on what they measured at = power=20 lines
attached to them.
If they are able to find out which devices ar= e=20 supplied by a
power line,
then they should report this as=20 well.

2. The reporting device receives power/energy= =20 information on other
devices by any means that are not based on SN= MP or=20 even not on IP.
It may even just be an estimate of power=20 consumption of other devices.
An example would be a gateway to a building=20 network, that receives
power information on many devices within the= =20 building and makes
it available using eman MIB=20 modules.

I think Cisco has another example with PCs=20 reporting their power to
switches and the switches report it to the=20 management system,
but this can certainly be explained better by= the=20 people from Cisco.

Thanks,

   Juergen Q.

--
Juergen Schoenwaelder=20           Jacobs= =20 University Bremen gGmbH
Phone: +49 421 200 3587=20         Campus Ring 1, 2875= 9=20 Bremen, Germany
Fax:   +49 421 200 3103=20         <http://www.jacobs-univers= ity.de/>

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

________________________________________= _______
eman=20 mailing list
eman@ietf.org
https://www.ietf.org= /mailman/listinfo/eman

<= /BODY> --_000_0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C95AUSNAVSXCHMBSA_-- From j.schoenwaelder@jacobs-university.de Fri Mar 4 07:41:47 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285903A6893 for ; Fri, 4 Mar 2011 07:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA+JC2hiKIqx for ; Fri, 4 Mar 2011 07:41:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B35523A696C for ; Fri, 4 Mar 2011 07:41:45 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F008C0053; Fri, 4 Mar 2011 16:42:54 +0100 (CET) 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 f08R9xsScnns; Fri, 4 Mar 2011 16:42:54 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1189C004F; Fri, 4 Mar 2011 16:42:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7AE7C16DDFFB; Fri, 4 Mar 2011 16:42:48 +0100 (CET) Date: Fri, 4 Mar 2011 16:42:48 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20110304154248.GB24292@elstar.local> Mail-Followup-To: Juergen Quittek , "Romascanu, Dan (Dan)" , eman mailing list References: <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> <0E32737B-484D-4263-9749-149E61601B03@quittek.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E32737B-484D-4263-9749-149E61601B03@quittek.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:41:47 -0000 On Fri, Mar 04, 2011 at 10:30:27AM +0100, Juergen Quittek wrote: > I see two basic scenarios: > 1. The reporting device is attached to the power supply lines of other > devices > Examples (also mentioned in raft-ietf-eman-requirements) are dedicated > power meters, power distribution units with built-in power meters, and > PoE switches. > Here devices report on what they measured at power lines attached to them. But this is straight forward as far as the reporting of the power going over the power lines go. A PoE switch should have no problem to report the power going over the different ports by using physical entities. I do not see anything report here. > If they are able to find out which devices are supplied by a power > line, then they should report this as well. What are we talking about? A simple string? A few objects? A complete MIB tree? > 2. The reporting device receives power/energy information on other > devices by any means that are not based on SNMP or even not on IP. > It may even just be an estimate of power consumption of other devices. > An example would be a gateway to a building network, that receives > power information on many devices within the building and makes > it available using eman MIB modules. > > I think Cisco has another example with PCs reporting their power to > switches and the switches report it to the management system, > but this can certainly be explained better by the people from Cisco. One mechanism that can be used in such cases are contexts. Using contexts allows to reuse existing MIB definitions as much as you want since you have a separate OID namespace for the different devices. The alternative is to create new object definitions (partially overlapping existing ones) and to have everything indexed by some additional ID. With contexts, I also gain some flexibility because I can either provide a local context for stuff learned via some other mechanism or I can provide a pointer to a remote context if I happen to know that the other devices provides SNMP access. The question likely boils down to how much information (standardized and proprietary) "other means" provide about remote devices in the foreseeable future. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bill.mielke@alcatel-lucent.com Fri Mar 4 07:53:41 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CA53A69E0 for ; Fri, 4 Mar 2011 07:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwwTvRXIz3jF for ; Fri, 4 Mar 2011 07:53:40 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 201CD3A69BC for ; Fri, 4 Mar 2011 07:53:39 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p24FslwU015193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Mar 2011 09:54:48 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p24FskCn024998 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Mar 2011 09:54:47 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 4 Mar 2011 09:54:46 -0600 From: "Mielke, William F (Bill)" To: eman mailing list Date: Fri, 4 Mar 2011 09:54:45 -0600 Thread-Topic: [eman] Power States - really Thread-Index: Acvaf1EFudJXra85SEODow4zS6Ek9gAAtH+Q Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> <20110303020507.GA19321@cslinux-build01.cyberswitching.local> <2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at> In-Reply-To: <2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 15:53:41 -0000 This is a good illustration of why I think a single standardized linear set= of states will be insufficient and therefore ultimately unsuccessful in pa= ctice. In this case you are highlighting what I mean when I say that the s= tates have a technological dependency. The states which make sense for one= technology are not necessarily going to make sense for another as we see w= ith your example of the PC vs. the battery. I may have obscured my earlier point by trying to provide too much detail o= n a potential solution to this issue. So let me take this opportunity to b= ack up and pose the following questions to the group: 1. Are we aiming for a single standardized linear set of states in the EMAN= standard, or will our approach have to take into account the inherent vari= abilities between technologies and different vender implementations in some= way? 2. What degree of flexibility must we incorporate into our solution such th= at we adequately account for these variabilities without opening the doors = to pure chaos? Personally I think that the specific answers to these questions will have a= significant impact on our chances for success (which I am defining here as= having written a useful standard that is widely accepted and utilized effe= ctively). Thoughts on this issue from others? William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein =20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Juergen Quittek > Sent: Friday, March 04, 2011 10:17 AM > To: chrisv@cyberswitching.com; eman mailing list > Cc: Bruce Nordman > Subject: Re: [eman] Power States - really >=20 > Hi Chris, >=20 > What you say shows again that ACPI power states=20 > are not sufficient for EMAN. >=20 > If we model the notebook computer with battery as one device,=20 > then we will need additional (non-ACPI) states for the notebook,=20 > such as, for example, > - off, but charging batters > - on, but supplied by battery > - etc. >=20 > If we follow your suggestion and model the notebook such that > it contains a PC device and a battery device, then we can use > ACPI states for the contained PC. But we need new (non-ACPI)=20 > states for modeling the battery, such as, for example, > - full > - charging > - trickle charging > - discharging (providing power) > - empty. >=20 > The same applies to DMTF states. All static ones are mapped to ACPI. > Thus, also DMTF states are not sufficient for what we need in=20 > the EMAN WG. >=20 > Thanks, >=20 > Juergen From Rolf.Winter@neclab.eu Fri Mar 4 08:13:18 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6D13A67B1 for ; Fri, 4 Mar 2011 08:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANQuL33fOS+c for ; Fri, 4 Mar 2011 08:13:17 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 099B43A67AF for ; Fri, 4 Mar 2011 08:13:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 600AD2C00020A; Fri, 4 Mar 2011 17:15:42 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwSxWHXPqkZp; Fri, 4 Mar 2011 17:15:42 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 3ED822C0001DE; Fri, 4 Mar 2011 17:15:32 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 4 Mar 2011 17:14:15 +0100 From: Rolf Winter To: "Mielke, William F (Bill)" , eman mailing list Thread-Topic: [eman] Power States - really Thread-Index: AQHL2HR2DCBEsmr3E0GzYlsUz6Y3JpQaP8UAgAAzugCAAFmrAIACb7UAgAAKa4CAABL2oA== Date: Fri, 4 Mar 2011 16:14:14 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DE3E82@DAPHNIS.office.hd> References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> <20110303020507.GA19321@cslinux-build01.cyberswitching.local> <2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:13:18 -0000 Bill, I think I agree with most parts of your statement. Devices are too diverse = to fit them into one universal power state model. The technological depende= ncy is what Bruce I think is calling functional states. Ultimately, these f= unctional states have important implications regarding a device's function = (speed, rate etc. ...) which in turn has an impact on the energy they consu= me (likely many functional states only exist to safe energy). However, I am not sure there is not a rather universal power state categori= zation in which many functional states exist such as On/Off/Sleep. We have = tried to describe that model in draft-norwin-energy-consider. But then, if = you really want to model a battery as a single device with its own power st= ates as being discussed (maybe I misunderstood this point) then maybe even = that won't work. Basically, I think batteries are a different beast and wil= l complicate things if we attempt to treat them like a switch, server etc. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Mielke, William F (Bill) > Sent: Freitag, 4. M=E4rz 2011 16:55 > To: eman mailing list > Subject: Re: [eman] Power States - really >=20 > This is a good illustration of why I think a single standardized linear > set of states will be insufficient and therefore ultimately > unsuccessful in pactice. In this case you are highlighting what I mean > when I say that the states have a technological dependency. The states > which make sense for one technology are not necessarily going to make > sense for another as we see with your example of the PC vs. the battery. >=20 > I may have obscured my earlier point by trying to provide too much > detail on a potential solution to this issue. So let me take this > opportunity to back up and pose the following questions to the group: >=20 > 1. Are we aiming for a single standardized linear set of states in the > EMAN standard, or will our approach have to take into account the > inherent variabilities between technologies and different vender > implementations in some way? >=20 > 2. What degree of flexibility must we incorporate into our solution > such that we adequately account for these variabilities without opening > the doors to pure chaos? >=20 > Personally I think that the specific answers to these questions will > have a significant impact on our chances for success (which I am > defining here as having written a useful standard that is widely > accepted and utilized effectively). >=20 > Thoughts on this issue from others? >=20 > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 >=20 > "Live like you're going to die tomorrow. > Learn like you're going to live forever." >=20 > - Albert Einstein >=20 >=20 >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On > > Behalf Of Juergen Quittek > > Sent: Friday, March 04, 2011 10:17 AM > > To: chrisv@cyberswitching.com; eman mailing list > > Cc: Bruce Nordman > > Subject: Re: [eman] Power States - really > > > > Hi Chris, > > > > What you say shows again that ACPI power states > > are not sufficient for EMAN. > > > > If we model the notebook computer with battery as one device, > > then we will need additional (non-ACPI) states for the notebook, > > such as, for example, > > - off, but charging batters > > - on, but supplied by battery > > - etc. > > > > If we follow your suggestion and model the notebook such that > > it contains a PC device and a battery device, then we can use > > ACPI states for the contained PC. But we need new (non-ACPI) > > states for modeling the battery, such as, for example, > > - full > > - charging > > - trickle charging > > - discharging (providing power) > > - empty. > > > > The same applies to DMTF states. All static ones are mapped to ACPI. > > Thus, also DMTF states are not sufficient for what we need in > > the EMAN WG. > > > > Thanks, > > > > Juergen > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Fri Mar 4 08:39:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9100B3A69C7 for ; Fri, 4 Mar 2011 08:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVaQFdp35KIu for ; Fri, 4 Mar 2011 08:39:21 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 3FACC3A67AF for ; Fri, 4 Mar 2011 08:39:21 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lx3Ub-1Q26Qs1zT7-0172rv; Fri, 04 Mar 2011 17:40:21 +0100 References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> <20110303020507.GA19321@cslinux-build01.cyberswitching.local> <2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <791AD3077F94194BB2BDD13565B6295D05DE3E82@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DE3E82@DAPHNIS.office.hd> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <12792E1A-AC1C-477A-8037-4E9C820DC9E9@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Fri, 4 Mar 2011 17:40:19 +0100 To: Rolf Winter X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:7vb4sTfBB2NPQVcpVhjeEbPTcFIRYDZEluCr0BI2ax6 vG+o15i2B4R75YHo+xvTf0XP4+iWADBBlFkBgu+BTb6KpldOZY R1187K1fhqRXaGjRitnifHRCjDzZmyANpa0Ro1eBrGmAvu0M94 SZrWZPOcNlIe3LGlaSlsgyFdXW+nnHu7rr0FJIQ9nEE1JjItW+ X9cMPSM+SNXq3AQxI6tMg== Cc: eman mailing list Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:39:22 -0000 Hi Rolf, It looks like we need to add managing storage devices (batteries, etc.) = to the requirements. As you say, they are different beasts and are not covered by what we = have for switches, PCs, etc. Juergen Am 04.03.2011 um 17:14 schrieb Rolf Winter: > Bill, >=20 > I think I agree with most parts of your statement. Devices are too = diverse to fit them into one universal power state model. The = technological dependency is what Bruce I think is calling functional = states. Ultimately, these functional states have important implications = regarding a device's function (speed, rate etc. ...) which in turn has = an impact on the energy they consume (likely many functional states only = exist to safe energy). >=20 > However, I am not sure there is not a rather universal power state = categorization in which many functional states exist such as = On/Off/Sleep. We have tried to describe that model in = draft-norwin-energy-consider. But then, if you really want to model a = battery as a single device with its own power states as being discussed = (maybe I misunderstood this point) then maybe even that won't work. = Basically, I think batteries are a different beast and will complicate = things if we attempt to treat them like a switch, server etc. >=20 >=20 > Best, >=20 >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 >=20 >=20 >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of >> Mielke, William F (Bill) >> Sent: Freitag, 4. M=E4rz 2011 16:55 >> To: eman mailing list >> Subject: Re: [eman] Power States - really >>=20 >> This is a good illustration of why I think a single standardized = linear >> set of states will be insufficient and therefore ultimately >> unsuccessful in pactice. In this case you are highlighting what I = mean >> when I say that the states have a technological dependency. The = states >> which make sense for one technology are not necessarily going to make >> sense for another as we see with your example of the PC vs. the = battery. >>=20 >> I may have obscured my earlier point by trying to provide too much >> detail on a potential solution to this issue. So let me take this >> opportunity to back up and pose the following questions to the group: >>=20 >> 1. Are we aiming for a single standardized linear set of states in = the >> EMAN standard, or will our approach have to take into account the >> inherent variabilities between technologies and different vender >> implementations in some way? >>=20 >> 2. What degree of flexibility must we incorporate into our solution >> such that we adequately account for these variabilities without = opening >> the doors to pure chaos? >>=20 >> Personally I think that the specific answers to these questions will >> have a significant impact on our chances for success (which I am >> defining here as having written a useful standard that is widely >> accepted and utilized effectively). >>=20 >> Thoughts on this issue from others? >>=20 >> William F. Mielke >> Alcatel-Lucent >> Distinguished Member of Technical Staff >> 6200 East Broad Street >> Room: 4B01-1V >> Columbus, OH 43213-1530 >> Email: Bill.Mielke@alcatel-lucent.com >> Phone: 614 367 5628 >> Fax: 614 367 5965 >>=20 >> "Live like you're going to die tomorrow. >> Learn like you're going to live forever." >>=20 >> - Albert Einstein >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On >>> Behalf Of Juergen Quittek >>> Sent: Friday, March 04, 2011 10:17 AM >>> To: chrisv@cyberswitching.com; eman mailing list >>> Cc: Bruce Nordman >>> Subject: Re: [eman] Power States - really >>>=20 >>> Hi Chris, >>>=20 >>> What you say shows again that ACPI power states >>> are not sufficient for EMAN. >>>=20 >>> If we model the notebook computer with battery as one device, >>> then we will need additional (non-ACPI) states for the notebook, >>> such as, for example, >>> - off, but charging batters >>> - on, but supplied by battery >>> - etc. >>>=20 >>> If we follow your suggestion and model the notebook such that >>> it contains a PC device and a battery device, then we can use >>> ACPI states for the contained PC. But we need new (non-ACPI) >>> states for modeling the battery, such as, for example, >>> - full >>> - charging >>> - trickle charging >>> - discharging (providing power) >>> - empty. >>>=20 >>> The same applies to DMTF states. All static ones are mapped to ACPI. >>> Thus, also DMTF states are not sufficient for what we need in >>> the EMAN WG. >>>=20 >>> Thanks, >>>=20 >>> 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 chrisv@cyberswitching.com Fri Mar 4 08:40:51 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F643A69E0 for ; Fri, 4 Mar 2011 08:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.405 X-Spam-Level: X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWwyD-sjbIRc for ; Fri, 4 Mar 2011 08:40:50 -0800 (PST) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by core3.amsl.com (Postfix) with ESMTP id 306683A67AF for ; Fri, 4 Mar 2011 08:40:50 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o144.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 756117d4.0.141739.00-259.289617.p01c11o144.mxlogic.net (envelope-from ); Fri, 04 Mar 2011 09:41:59 -0700 (MST) X-MXL-Hash: 4d71165729745047-5372064b7e5104c3746ecdaa1e10bbc642757f51 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 08:41:48 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CECDA9E@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power States - really Thread-Index: AcvaitOqQKOM70tWSPykuTGpoQBe0wAACgOw References: <4D6E80B8.6060002@cisco.com><919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at><20110303020507.GA19321@cslinux-build01.cyberswitching.local><2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at><0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><791AD3077F94194BB2BDD13565B6295D05DE3E82@DAPHNIS.office.hd> <12792E1A-AC1C-477A-8037-4E9C820DC9E9@quittek.at> From: "Chris Verges" To: "Juergen Quittek" , "Rolf Winter" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XnxjYOJpEeMA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-] X-AnalysisOut: [IA:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=48vgC7mUAAAA:8 a=gxZ] X-AnalysisOut: [vrgisAAAA:8 a=wzgqfsuUAAAA:8 a=GPrgo85GoPISWdrh2YkA:9 a=3-] X-AnalysisOut: [1ZpFywP2mzXTD7vjsA:7 a=OzVZ7yZEAPHn-cH3xcVW4ZyYbOAA:4 a=wP] X-AnalysisOut: [NLvfGTeEIA:10 a=uedtHNu2mX0A:10 a=4LErlHHHw5cA:10 a=yjbb7G] X-AnalysisOut: [A0i1wA:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a=yvfu_RGVus] X-AnalysisOut: [0A:10 a=ZLkZmmfqm6k2i1-l:21 a=TtkJwhaJhEHakrpI:21] Cc: eman mailing list Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:40:51 -0000 What are the states that a battery can have? 1. Draining 2. Charging 3. Off Chris -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek Sent: Friday, March 04, 2011 8:40 AM To: Rolf Winter Cc: eman mailing list Subject: Re: [eman] Power States - really Hi Rolf, It looks like we need to add managing storage devices (batteries, etc.) = to the requirements. As you say, they are different beasts and are not covered by what we = have for switches, PCs, etc. Juergen Am 04.03.2011 um 17:14 schrieb Rolf Winter: > Bill, >=20 > I think I agree with most parts of your statement. Devices are too = diverse to fit them into one universal power state model. The = technological dependency is what Bruce I think is calling functional = states. Ultimately, these functional states have important implications = regarding a device's function (speed, rate etc. ...) which in turn has = an impact on the energy they consume (likely many functional states only = exist to safe energy). >=20 > However, I am not sure there is not a rather universal power state = categorization in which many functional states exist such as = On/Off/Sleep. We have tried to describe that model in = draft-norwin-energy-consider. But then, if you really want to model a = battery as a single device with its own power states as being discussed = (maybe I misunderstood this point) then maybe even that won't work. = Basically, I think batteries are a different beast and will complicate = things if we attempt to treat them like a switch, server etc. >=20 >=20 > Best, >=20 >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,=20 > London W3 6BL | Registered in England 2832014 >=20 >=20 >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf=20 >> Of Mielke, William F (Bill) >> Sent: Freitag, 4. M=E4rz 2011 16:55 >> To: eman mailing list >> Subject: Re: [eman] Power States - really >>=20 >> This is a good illustration of why I think a single standardized=20 >> linear set of states will be insufficient and therefore ultimately=20 >> unsuccessful in pactice. In this case you are highlighting what I=20 >> mean when I say that the states have a technological dependency. The = >> states which make sense for one technology are not necessarily going=20 >> to make sense for another as we see with your example of the PC vs. = the battery. >>=20 >> I may have obscured my earlier point by trying to provide too much=20 >> detail on a potential solution to this issue. So let me take this=20 >> opportunity to back up and pose the following questions to the group: >>=20 >> 1. Are we aiming for a single standardized linear set of states in=20 >> the EMAN standard, or will our approach have to take into account the = >> inherent variabilities between technologies and different vender=20 >> implementations in some way? >>=20 >> 2. What degree of flexibility must we incorporate into our solution=20 >> such that we adequately account for these variabilities without=20 >> opening the doors to pure chaos? >>=20 >> Personally I think that the specific answers to these questions will=20 >> have a significant impact on our chances for success (which I am=20 >> defining here as having written a useful standard that is widely=20 >> accepted and utilized effectively). >>=20 >> Thoughts on this issue from others? >>=20 >> William F. Mielke >> Alcatel-Lucent >> Distinguished Member of Technical Staff >> 6200 East Broad Street >> Room: 4B01-1V >> Columbus, OH 43213-1530 >> Email: Bill.Mielke@alcatel-lucent.com >> Phone: 614 367 5628 >> Fax: 614 367 5965 >>=20 >> "Live like you're going to die tomorrow. >> Learn like you're going to live forever." >>=20 >> - Albert Einstein >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = >>> Of Juergen Quittek >>> Sent: Friday, March 04, 2011 10:17 AM >>> To: chrisv@cyberswitching.com; eman mailing list >>> Cc: Bruce Nordman >>> Subject: Re: [eman] Power States - really >>>=20 >>> Hi Chris, >>>=20 >>> What you say shows again that ACPI power states are not sufficient=20 >>> for EMAN. >>>=20 >>> If we model the notebook computer with battery as one device, then=20 >>> we will need additional (non-ACPI) states for the notebook, such as, = >>> for example, >>> - off, but charging batters >>> - on, but supplied by battery >>> - etc. >>>=20 >>> If we follow your suggestion and model the notebook such that it=20 >>> contains a PC device and a battery device, then we can use ACPI=20 >>> states for the contained PC. But we need new (non-ACPI) states for=20 >>> modeling the battery, such as, for example, >>> - full >>> - charging >>> - trickle charging >>> - discharging (providing power) >>> - empty. >>>=20 >>> The same applies to DMTF states. All static ones are mapped to ACPI. >>> Thus, also DMTF states are not sufficient for what we need in the=20 >>> EMAN WG. >>>=20 >>> Thanks, >>>=20 >>> 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 From ietf@quittek.at Fri Mar 4 09:05:50 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686683A6866 for ; Fri, 4 Mar 2011 09:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCyFw6O4YJV5 for ; Fri, 4 Mar 2011 09:05:49 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 17D2E3A683C for ; Fri, 4 Mar 2011 09:05:49 -0800 (PST) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M7Wnz-1QAJlR0cLf-00wbss; Fri, 04 Mar 2011 18:06:54 +0100 References: <4D6E80B8.6060002@cisco.com><919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at><20110303020507.GA19321@cslinux-build01.cyberswitching.local><2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at><0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><791AD3077F94194BB2BDD13565B6295D05DE3E82@DAPHNIS.office.hd> <12792E1A-AC1C-477A-8037-4E9C820DC9E9@quittek.at> <68FBE0F3CE97264395875AC1C468F22CECDA9E@mail03.cyberswitching.local> In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CECDA9E@mail03.cyberswitching.local> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <24858675-22AE-4EDA-8383-9B74C1E7EFCC@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Fri, 4 Mar 2011 18:06:54 +0100 To: "Chris Verges" X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:txjt6VRLZgO77G0rjkMzvBJTnXZGQEt12HUw1HsXcc3 xCJRUYwuqonpnS6OFXfaeHEHdmzWAJxt45BEcyxZyHfYJfoIdd m2VQj/gldte4e2FW4Ubb2yFTYlnOa/wQ5LPrnvDSJJ9h2VFjCW KgZ5IRgl6Cvdkj7Rdj11Lzwc4GhXdSfYDa6nmP8nEJG2DP+v21 amyHcH1ISl+vIl6qmMyPg== Cc: eman mailing list , Rolf Winter Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17:05:50 -0000 Hi Chris,. There are two charging modes for batteries: - regular charging=20 used to get the battery from empty to full. - trickle charging or float charging used if the battery is full already The issue here is that a full battery (depending on the technology = tends to discharge itself. For compensating this effect trickle charging (open loop)=20 or float charging (with voltage control) is used to keep the battery = full In addition you may want to add power states empty (needs charging)=20 and full (does not need charging), because this may be relevant=20 for power demand planning. Juergen Am 04.03.2011 um 17:41 schrieb Chris Verges: > What are the states that a battery can have? >=20 > 1. Draining > 2. Charging > 3. Off >=20 > Chris >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of Juergen Quittek > Sent: Friday, March 04, 2011 8:40 AM > To: Rolf Winter > Cc: eman mailing list > Subject: Re: [eman] Power States - really >=20 > Hi Rolf, >=20 > It looks like we need to add managing storage devices (batteries, = etc.) to the requirements. > As you say, they are different beasts and are not covered by what we = have for switches, PCs, etc. >=20 > Juergen >=20 >=20 > Am 04.03.2011 um 17:14 schrieb Rolf Winter: >=20 >> Bill, >>=20 >> I think I agree with most parts of your statement. Devices are too = diverse to fit them into one universal power state model. The = technological dependency is what Bruce I think is calling functional = states. Ultimately, these functional states have important implications = regarding a device's function (speed, rate etc. ...) which in turn has = an impact on the energy they consume (likely many functional states only = exist to safe energy). >>=20 >> However, I am not sure there is not a rather universal power state = categorization in which many functional states exist such as = On/Off/Sleep. We have tried to describe that model in = draft-norwin-energy-consider. But then, if you really want to model a = battery as a single device with its own power states as being discussed = (maybe I misunderstood this point) then maybe even that won't work. = Basically, I think batteries are a different beast and will complicate = things if we attempt to treat them like a switch, server etc. >>=20 >>=20 >> Best, >>=20 >>=20 >> Rolf >>=20 >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,=20= >> London W3 6BL | Registered in England 2832014 >>=20 >>=20 >>> -----Original Message----- >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf=20= >>> Of Mielke, William F (Bill) >>> Sent: Freitag, 4. M=E4rz 2011 16:55 >>> To: eman mailing list >>> Subject: Re: [eman] Power States - really >>>=20 >>> This is a good illustration of why I think a single standardized=20 >>> linear set of states will be insufficient and therefore ultimately=20= >>> unsuccessful in pactice. In this case you are highlighting what I=20= >>> mean when I say that the states have a technological dependency. = The=20 >>> states which make sense for one technology are not necessarily going=20= >>> to make sense for another as we see with your example of the PC vs. = the battery. >>>=20 >>> I may have obscured my earlier point by trying to provide too much=20= >>> detail on a potential solution to this issue. So let me take this=20= >>> opportunity to back up and pose the following questions to the = group: >>>=20 >>> 1. Are we aiming for a single standardized linear set of states in=20= >>> the EMAN standard, or will our approach have to take into account = the=20 >>> inherent variabilities between technologies and different vender=20 >>> implementations in some way? >>>=20 >>> 2. What degree of flexibility must we incorporate into our solution=20= >>> such that we adequately account for these variabilities without=20 >>> opening the doors to pure chaos? >>>=20 >>> Personally I think that the specific answers to these questions will=20= >>> have a significant impact on our chances for success (which I am=20 >>> defining here as having written a useful standard that is widely=20 >>> accepted and utilized effectively). >>>=20 >>> Thoughts on this issue from others? >>>=20 >>> William F. Mielke >>> Alcatel-Lucent >>> Distinguished Member of Technical Staff >>> 6200 East Broad Street >>> Room: 4B01-1V >>> Columbus, OH 43213-1530 >>> Email: Bill.Mielke@alcatel-lucent.com >>> Phone: 614 367 5628 >>> Fax: 614 367 5965 >>>=20 >>> "Live like you're going to die tomorrow. >>> Learn like you're going to live forever." >>>=20 >>> - Albert Einstein >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On = Behalf=20 >>>> Of Juergen Quittek >>>> Sent: Friday, March 04, 2011 10:17 AM >>>> To: chrisv@cyberswitching.com; eman mailing list >>>> Cc: Bruce Nordman >>>> Subject: Re: [eman] Power States - really >>>>=20 >>>> Hi Chris, >>>>=20 >>>> What you say shows again that ACPI power states are not sufficient=20= >>>> for EMAN. >>>>=20 >>>> If we model the notebook computer with battery as one device, then=20= >>>> we will need additional (non-ACPI) states for the notebook, such = as,=20 >>>> for example, >>>> - off, but charging batters >>>> - on, but supplied by battery >>>> - etc. >>>>=20 >>>> If we follow your suggestion and model the notebook such that it=20 >>>> contains a PC device and a battery device, then we can use ACPI=20 >>>> states for the contained PC. But we need new (non-ACPI) states for=20= >>>> modeling the battery, such as, for example, >>>> - full >>>> - charging >>>> - trickle charging >>>> - discharging (providing power) >>>> - empty. >>>>=20 >>>> The same applies to DMTF states. All static ones are mapped to = ACPI. >>>> Thus, also DMTF states are not sufficient for what we need in the=20= >>>> EMAN WG. >>>>=20 >>>> Thanks, >>>>=20 >>>> 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 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bill.mielke@alcatel-lucent.com Fri Mar 4 09:50:35 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6EF3A69E7 for ; Fri, 4 Mar 2011 09:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUM6mDIUckNV for ; Fri, 4 Mar 2011 09:50:34 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D93213A6856 for ; Fri, 4 Mar 2011 09:50:33 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p24Hpgu0010001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Mar 2011 11:51:42 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p24Hpggm018639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Mar 2011 11:51:42 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 4 Mar 2011 11:51:42 -0600 From: "Mielke, William F (Bill)" To: eman mailing list Date: Fri, 4 Mar 2011 11:51:39 -0600 Thread-Topic: [eman] Power States - really Thread-Index: AcvajpVgvm/CYOXTRiqsMwY5MWXXuAAARqAQ Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715CA42@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4D6E80B8.6060002@cisco.com><919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at><20110303020507.GA19321@cslinux-build01.cyberswitching.local><2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at><0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><791AD3077F94194BB2BDD13565B6295D05DE3E82@DAPHNIS.office.hd> <12792E1A-AC1C-477A-8037-4E9C820DC9E9@quittek.at> <68FBE0F3CE97264395875AC1C468F22CECDA9E@mail03.cyberswitching.local> <24858675-22AE-4EDA-8383-9B74C1E7EFCC@quittek.at> In-Reply-To: <24858675-22AE-4EDA-8383-9B74C1E7EFCC@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17:50:35 -0000 When you add in the concept of "level of charge" which you are summarizing = as "Empty" or "Full", is this not a totally orthogonal dimension of informa= tion from the "PowerState" as articulated by Chris? This seems to be the s= ame point that Bruce (and others?) have made about the limits of a single l= inear set of states. I would argue that what we have here is an example to two independent attri= butes: PowerState and LevelOfCharge. I would think that LevelOfCharge woul= d be best modeled as a percentage rather than a fixed set of states, howeve= r a "reasonable" approach might be to let it take on the range of values "E= mpty", "Partial", and "Full". This leads to something like the following: BatteryPowerState :=3D { Off, Draining, Charging } BatteryLevelOfCharge :=3D { Empty, Partial, Full } If we try to combine these into a single set of states, then logically that= set of states will correspond to the cross product of these two sets and s= hould yield a total of 3 x 3 =3D 9 unique combined states as follows: CombinedState BatteryPowerState BatteryLevelOfCharge ------------- ----------------- -------------------- CS1 Off Empty CS2 Off Partial CS3 Off Full CS4 Draining Empty CS5 Draining Partial CS6 Draining Full CS7 Charging Empty CS8 Charging Partial CS9 Charging Full Note that not all such combined states are necessarily meaningful. For exa= mple CS4 appears logically inconsistent as does CS9. This seems to beg the question, what do we actually mean by the term "Power= State"? Section 5.6 of the updated framework document discusses this conce= pt but I don't see a simple concise definition of the term anywhere. Have = I missed it? William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein =20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Juergen Quittek > Sent: Friday, March 04, 2011 12:07 PM > To: Chris Verges > Cc: eman mailing list; Rolf Winter > Subject: Re: [eman] Power States - really >=20 > Hi Chris,. >=20 > There are two charging modes for batteries: >=20 > - regular charging=20 > used to get the battery from empty to full. > - trickle charging or float charging > used if the battery is full already > The issue here is that a full battery (depending on the=20 > technology tends to discharge itself. > For compensating this effect trickle charging (open loop)=20 > or float charging (with voltage control) is used to keep=20 > the battery full >=20 > In addition you may want to add power states empty (needs charging)=20 > and full (does not need charging), because this may be relevant=20 > for power demand planning. >=20 > Juergen >=20 > Am 04.03.2011 um 17:41 schrieb Chris Verges: >=20 > > What are the states that a battery can have? > >=20 > > 1. Draining > > 2. Charging > > 3. Off > >=20 > > Chris > >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]=20 > On Behalf Of Juergen Quittek > > Sent: Friday, March 04, 2011 8:40 AM > > To: Rolf Winter > > Cc: eman mailing list > > Subject: Re: [eman] Power States - really > >=20 > > Hi Rolf, > >=20 > > It looks like we need to add managing storage devices=20 > (batteries, etc.) to the requirements. > > As you say, they are different beasts and are not covered=20 > by what we have for switches, PCs, etc. > >=20 > > Juergen > >=20 > >=20 > > Am 04.03.2011 um 17:14 schrieb Rolf Winter: > >=20 > >> Bill, > >>=20 > >> I think I agree with most parts of your statement. Devices=20 > are too diverse to fit them into one universal power state=20 > model. The technological dependency is what Bruce I think is=20 > calling functional states. Ultimately, these functional=20 > states have important implications regarding a device's=20 > function (speed, rate etc. ...) which in turn has an impact=20 > on the energy they consume (likely many functional states=20 > only exist to safe energy). > >>=20 > >> However, I am not sure there is not a rather universal=20 > power state categorization in which many functional states=20 > exist such as On/Off/Sleep. We have tried to describe that=20 > model in draft-norwin-energy-consider. But then, if you=20 > really want to model a battery as a single device with its=20 > own power states as being discussed (maybe I misunderstood=20 > this point) then maybe even that won't work. Basically, I=20 > think batteries are a different beast and will complicate=20 > things if we attempt to treat them like a switch, server etc. > >>=20 > >>=20 > >> Best, > >>=20 > >>=20 > >> Rolf > >>=20 > >> NEC Europe Limited | Registered Office: NEC House, 1=20 > Victoria Road,=20 > >> London W3 6BL | Registered in England 2832014 > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: eman-bounces@ietf.org=20 > [mailto:eman-bounces@ietf.org] On Behalf=20 > >>> Of Mielke, William F (Bill) > >>> Sent: Freitag, 4. M=E4rz 2011 16:55 > >>> To: eman mailing list > >>> Subject: Re: [eman] Power States - really > >>>=20 > >>> This is a good illustration of why I think a single standardized=20 > >>> linear set of states will be insufficient and therefore=20 > ultimately=20 > >>> unsuccessful in pactice. In this case you are=20 > highlighting what I=20 > >>> mean when I say that the states have a technological=20 > dependency. The=20 > >>> states which make sense for one technology are not=20 > necessarily going=20 > >>> to make sense for another as we see with your example of=20 > the PC vs. the battery. > >>>=20 > >>> I may have obscured my earlier point by trying to provide=20 > too much=20 > >>> detail on a potential solution to this issue. So let me=20 > take this=20 > >>> opportunity to back up and pose the following questions=20 > to the group: > >>>=20 > >>> 1. Are we aiming for a single standardized linear set of=20 > states in=20 > >>> the EMAN standard, or will our approach have to take into=20 > account the=20 > >>> inherent variabilities between technologies and different vender=20 > >>> implementations in some way? > >>>=20 > >>> 2. What degree of flexibility must we incorporate into=20 > our solution=20 > >>> such that we adequately account for these variabilities without=20 > >>> opening the doors to pure chaos? > >>>=20 > >>> Personally I think that the specific answers to these=20 > questions will=20 > >>> have a significant impact on our chances for success (which I am=20 > >>> defining here as having written a useful standard that is widely=20 > >>> accepted and utilized effectively). > >>>=20 > >>> Thoughts on this issue from others? > >>>=20 > >>> William F. Mielke > >>> Alcatel-Lucent > >>> Distinguished Member of Technical Staff > >>> 6200 East Broad Street > >>> Room: 4B01-1V > >>> Columbus, OH 43213-1530 > >>> Email: Bill.Mielke@alcatel-lucent.com > >>> Phone: 614 367 5628 > >>> Fax: 614 367 5965 > >>>=20 > >>> "Live like you're going to die tomorrow. > >>> Learn like you're going to live forever." > >>>=20 > >>> - Albert Einstein > >>>=20 > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: eman-bounces@ietf.org=20 > [mailto:eman-bounces@ietf.org] On Behalf=20 > >>>> Of Juergen Quittek > >>>> Sent: Friday, March 04, 2011 10:17 AM > >>>> To: chrisv@cyberswitching.com; eman mailing list > >>>> Cc: Bruce Nordman > >>>> Subject: Re: [eman] Power States - really > >>>>=20 > >>>> Hi Chris, > >>>>=20 > >>>> What you say shows again that ACPI power states are not=20 > sufficient=20 > >>>> for EMAN. > >>>>=20 > >>>> If we model the notebook computer with battery as one=20 > device, then=20 > >>>> we will need additional (non-ACPI) states for the=20 > notebook, such as,=20 > >>>> for example, > >>>> - off, but charging batters > >>>> - on, but supplied by battery > >>>> - etc. > >>>>=20 > >>>> If we follow your suggestion and model the notebook such that it=20 > >>>> contains a PC device and a battery device, then we can use ACPI=20 > >>>> states for the contained PC. But we need new (non-ACPI)=20 > states for=20 > >>>> modeling the battery, such as, for example, > >>>> - full > >>>> - charging > >>>> - trickle charging > >>>> - discharging (providing power) > >>>> - empty. > >>>>=20 > >>>> The same applies to DMTF states. All static ones are=20 > mapped to ACPI. > >>>> Thus, also DMTF states are not sufficient for what we=20 > need in the=20 > >>>> EMAN WG. > >>>>=20 > >>>> Thanks, > >>>>=20 > >>>> 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 > >=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 > = From tirth.ghose@gmail.com Fri Mar 4 09:53:52 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3A73A6856 for ; Fri, 4 Mar 2011 09:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kMD90kxr2Ck for ; Fri, 4 Mar 2011 09:53:50 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id ABB783A684A for ; Fri, 4 Mar 2011 09:53:50 -0800 (PST) Received: by iwl42 with SMTP id 42so2485632iwl.31 for ; Fri, 04 Mar 2011 09:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fd864bQVYBnr76G1XlUuuIUjfPvfcVJN6clykYqEt0g=; b=Qx74yirDDlU2n0UhEfQB3Px40o8JyGSWzh959QniwR1E7GWtTNg3axf+zfYm7UOjEe zevcRFY0L+IzD4tM1nI2l2Yhdfge7yHTV+SlbA/2maiOws5enDtlD/A0NQg4bR8uKego a0oLsH558dBwUpSW01ofTQ5AfIrp9M6pQP6ng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=pAA/b5iu+6Pnw2uBfgiqUwSL6PAsmyHroHsopg0TGkyjHrTQtFj97yfbaQwFCj6qIv TLV7+Z+bBYEpD8kpDrzZNn92LTa6/xL6IPQQahVzRMaFgppTEHdYO+tJJxEI5q/fS18I lQY+CivoDXymAe8+lQ5QfP58n2maUGaXEpS1A= MIME-Version: 1.0 Received: by 10.43.51.73 with SMTP id vh9mr932750icb.262.1299261299836; Fri, 04 Mar 2011 09:54:59 -0800 (PST) Sender: tirth.ghose@gmail.com Received: by 10.231.156.141 with HTTP; Fri, 4 Mar 2011 09:54:59 -0800 (PST) In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> <20110303020507.GA19321@cslinux-build01.cyberswitching.local> <2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Date: Fri, 4 Mar 2011 09:54:59 -0800 X-Google-Sender-Auth: G7qzWAqtBUSyOx2pGNggXQXryyY Message-ID: From: Ted Ghose To: "Mielke, William F (Bill)" Content-Type: multipart/alternative; boundary=bcaec5299ef33f465b049dabd88f Cc: eman mailing list Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17:53:52 -0000 --bcaec5299ef33f465b049dabd88f Content-Type: text/plain; charset=ISO-8859-1 Bill, I totally disagree with you. It is diverse from device perspective, but if I look at energy saving perspective, I want it unified. We lay down some guideline for manufactures, but for managing power, I need a fixed set of states, which to me means lower state, I save more, higher state I pay more!! Is it too much to ask? -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Fri, Mar 4, 2011 at 7:54 AM, Mielke, William F (Bill) < bill.mielke@alcatel-lucent.com> wrote: > This is a good illustration of why I think a single standardized linear set > of states will be insufficient and therefore ultimately unsuccessful in > pactice. In this case you are highlighting what I mean when I say that the > states have a technological dependency. The states which make sense for one > technology are not necessarily going to make sense for another as we see > with your example of the PC vs. the battery. > > I may have obscured my earlier point by trying to provide too much detail > on a potential solution to this issue. So let me take this opportunity to > back up and pose the following questions to the group: > > 1. Are we aiming for a single standardized linear set of states in the EMAN > standard, or will our approach have to take into account the inherent > variabilities between technologies and different vender implementations in > some way? > > 2. What degree of flexibility must we incorporate into our solution such > that we adequately account for these variabilities without opening the doors > to pure chaos? > > Personally I think that the specific answers to these questions will have a > significant impact on our chances for success (which I am defining here as > having written a useful standard that is widely accepted and utilized > effectively). > > Thoughts on this issue from others? > > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 > > "Live like you're going to die tomorrow. > Learn like you're going to live forever." > > - Albert Einstein > > > > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On > > Behalf Of Juergen Quittek > > Sent: Friday, March 04, 2011 10:17 AM > > To: chrisv@cyberswitching.com; eman mailing list > > Cc: Bruce Nordman > > Subject: Re: [eman] Power States - really > > > > Hi Chris, > > > > What you say shows again that ACPI power states > > are not sufficient for EMAN. > > > > If we model the notebook computer with battery as one device, > > then we will need additional (non-ACPI) states for the notebook, > > such as, for example, > > - off, but charging batters > > - on, but supplied by battery > > - etc. > > > > If we follow your suggestion and model the notebook such that > > it contains a PC device and a battery device, then we can use > > ACPI states for the contained PC. But we need new (non-ACPI) > > states for modeling the battery, such as, for example, > > - full > > - charging > > - trickle charging > > - discharging (providing power) > > - empty. > > > > The same applies to DMTF states. All static ones are mapped to ACPI. > > Thus, also DMTF states are not sufficient for what we need in > > the EMAN WG. > > > > Thanks, > > > > Juergen > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --bcaec5299ef33f465b049dabd88f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bill,

I totally disagree with you. It is diverse from de= vice perspective, but if I look at energy saving perspective, I want it uni= fied. We lay down some guideline for manufactures, but for managing power, = I need a fixed set of states, which to me means lower state, I save more, h= igher state I pay more!!

Is it too much to ask?

-tg-*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*= 9;``'*:-.,_:-.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=A0 Save time... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_= :-.,_,.-:**:-.,_,.


On Fri, Mar 4, 2011 at 7:54 AM, Mielke, = William F (Bill) <bill.mielke@alcatel-lucent.com> wrote:
This is a good illustration of why I think a single standardized linear set= of states will be insufficient and therefore ultimately unsuccessful in pa= ctice. =A0In this case you are highlighting what I mean when I say that the= states have a technological dependency. =A0The states which make sense for= one technology are not necessarily going to make sense for another as we s= ee with your example of the PC vs. the battery.

I may have obscured my earlier point by trying to provide too much detail o= n a potential solution to this issue. =A0So let me take this opportunity to= back up and pose the following questions to the group:

1. Are we aiming for a single standardized linear set of states in the EMAN= standard, or will our approach have to take into account the inherent vari= abilities between technologies and different vender implementations in some= way?

2. What degree of flexibility must we incorporate into our solution such th= at we adequately account for these variabilities without opening the doors = to pure chaos?

Personally I think that the specific answers to these questions will have a= significant impact on our chances for success (which I am defining here as= having written a useful standard that is widely accepted and utilized effe= ctively).

Thoughts on this issue from others?

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH =A043213-1530
Email: Bill.Mielke@alcate= l-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

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

=A0 =A0- Albert Einstein



> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
> Behalf Of Juergen Quittek
> Sent: Friday, March 04, 2011 10:17 AM
> To: chrisv@cyberswitching= .com; eman mailing list
> Cc: Bruce Nordman
> Subject: Re: [eman] Power States - really
>
> Hi Chris,
>
> What you say shows again that ACPI power states
> are not sufficient for EMAN.
>
> If we model the notebook computer with battery as one device,
> then we will need additional (non-ACPI) states for the notebook,
> such as, for example,
> =A0 - off, but charging batters
> =A0 - on, but supplied by battery
> =A0 - etc.
>
> If we follow your suggestion and model the notebook such that
> it contains a PC device and a battery device, then we can use
> ACPI states for the contained PC. But we need new (non-ACPI)
> states for modeling the battery, such as, for example,
> =A0 - full
> =A0 - charging
> =A0 - trickle charging
> =A0 - discharging (providing power)
> =A0 - empty.
>
> The same applies to DMTF states. All static ones are mapped to ACPI. > Thus, also DMTF states are not sufficient for what we need in
> the EMAN WG.
>
> Thanks,
>
> =A0 =A0 Juergen
_____________________________= __________________
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman

--bcaec5299ef33f465b049dabd88f-- From blueroofmusic@gmail.com Fri Mar 4 10:39:29 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC763A69C7 for ; Fri, 4 Mar 2011 10:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.175 X-Spam-Level: X-Spam-Status: No, score=-3.175 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-gcMPOP+PMM for ; Fri, 4 Mar 2011 10:39:28 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D12533A6802 for ; Fri, 4 Mar 2011 10:39:27 -0800 (PST) Received: by fxm15 with SMTP id 15so2600851fxm.31 for ; Fri, 04 Mar 2011 10:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uqbYEuuzwQ2KY09YJqTYGmCDW2zFDAq00yZyIZq7J9k=; b=uXFjW+9dVoaBB0Ye+zRtnVbKOHXLTeiT05KnNGBL1rIPUInN1nfVKVJxnIyopUs8Py SG+/jWJZGOxifLni2QpAqbiOvPgdtQSBMWYU0hLApz3a1CZjwAHoQUZQ+PU1yY40oJSi Phx9teEtrF+tA4ZFben54aau0COzBKst84yus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cBzWhfjjwGd4/ll+NYWxLAHZNYlWgTxEdnjX0QiCdXbOQUrV/Kl2BlUwKAUmhFBHV9 B7gi/irW+m97s9SAnsNxaK5Wv/Zn2wMqWQYNvmIJ7YsO+i2ZP88VDCMZ/hUsYR8T5PYF zf4qg+ECoQ7PmgabczkFy/4VQtsdZCwgI/hnw= MIME-Version: 1.0 Received: by 10.223.151.8 with SMTP id a8mr1226534faw.69.1299263705298; Fri, 04 Mar 2011 10:35:05 -0800 (PST) Received: by 10.223.78.132 with HTTP; Fri, 4 Mar 2011 10:35:05 -0800 (PST) In-Reply-To: References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> <20110303020507.GA19321@cslinux-build01.cyberswitching.local> <2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Date: Fri, 4 Mar 2011 13:35:05 -0500 Message-ID: From: Ira McDonald To: Ted Ghose , Ira McDonald Content-Type: multipart/alternative; boundary=00235429bda49fc366049dac67ee Cc: eman mailing list Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 18:39:29 -0000 --00235429bda49fc366049dac67ee Content-Type: text/plain; charset=ISO-8859-1 Hi, I suggest that this discussion is confusing the notions of power state and operational state. The IEEE-ISTO Printer Working Group approved in February our abstract Imaging System Power Management Model [1] and corresponding concrete Imaging System Power MIB [2] for printers and multifunction devices (print/scan/fax/etc.). We used exactly the DMTF power states (static and resets) and their corresponding ACPI power states. But we *also* used separate operational states (e.g., down, testing, idle, processing, etc.) for each managed component. I suggest that a battery, just like any other component, has a few simple power states (i.e., input/output of power itself) and a separate set operational states. Attempting to fold these two related (but independent) states into a single linear power state will fail - there are just too many different components with unusual operational states - and the behavior of a reset will become too ambiguous. Cheers, - Ira (editor of PWG Power Model/Power MIB) [1] PWG Imaging System Power Management Model ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspower10-20110302.pdf [2] PWG Imaging System Power MIB ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspowermib10-20110302.pdf ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspowermib10-20110302.mib Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Christmas through April: 579 Park Place Saline, MI 48176 734-944-0094 May to Christmas: PO Box 221 Grand Marais, MI 49839 906-494-2434 --00235429bda49fc366049dac67ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I suggest that this discussion is confusing the notions of
po= wer state and operational state.

The IEEE-ISTO Printer Working Group= approved in February
our abstract Imaging System Power Management Model= [1]
and corresponding concrete Imaging=A0System Power MIB [2]
for printers = and multifunction devices (print/scan/fax/etc.).

We used exactly the= DMTF power states (static and resets)
and their corresponding ACPI pow= er states.=A0

But we *also* used separate operational states (e.g., down,
testing= , idle, processing, etc.) for each managed component.

I suggest that= a battery, just like any other component, has
a few simple power state= s (i.e., input/output of power itself)
and a separate set operational states.

Attempting to fold these two = related (but independent) states
into a single linear power state will = fail - there are just too
many different components with unusual operat= ional states
- and the behavior of a reset will become too ambiguous.

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

[1] PWG Imaging System P= ower Management Model
f= tp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspower10-20110302.pdf

[2] PWG Imaging System Power MIB
ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspowermib10-20110302.pdf
ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspowermib10-20110302.mib
<= br clear=3D"all">Ira McDonald (Musician / Software Architect)
Chair - Li= nux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Desig= nated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
<= a href=3D"http://sites.google.com/site/blueroofmusic" target=3D"_blank">htt= p://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:b= lueroofmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 Saline, MI=A0 48176
= =A0 734-944-0094
May to Christmas:
=A0 PO Box 221=A0 Grand Marais, MI= 49839
=A0 906-494-2434



--00235429bda49fc366049dac67ee-- From chrisv@cyberswitching.com Fri Mar 4 11:01:29 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718A03A69FF for ; Fri, 4 Mar 2011 11:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6L3koAsRFh2 for ; Fri, 4 Mar 2011 11:01:28 -0800 (PST) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) by core3.amsl.com (Postfix) with ESMTP id 38C8B3A69F0 for ; Fri, 4 Mar 2011 11:01:28 -0800 (PST) Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c12o141.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id d47317d4.0.15539.00-260.35620.p01c12o141.mxlogic.net (envelope-from ); Fri, 04 Mar 2011 12:02:38 -0700 (MST) X-MXL-Hash: 4d71374e2852210d-15354aeb11e50b838e616b5cb500d146fb3ee51c Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 11:01:50 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 186892F6001; Fri, 4 Mar 2011 11:02:16 -0800 (PST) Date: Fri, 4 Mar 2011 11:02:16 -0800 From: chrisv@cyberswitching.com To: eman@ietf.org Message-ID: <20110304190215.GA5072@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 04 Mar 2011 19:01:50.0229 (UTC) FILETIME=[9E189450:01CBDA9E] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [64.81.28.110] X-AnalysisOut: [v=1.0 c=1 a=5jKxznCknX8A:10 a=BLceEmwcHowA:10 a=4zsJQXJisS] X-AnalysisOut: [Y22NXBO5KRuA==:17 a=s3QH7Jy6ygyhgl8gl6sA:9 a=vCUvbuB2h8S5a] X-AnalysisOut: [PGlkpfN4Sw-hy8A:4 a=CjuIK1q_8ugA:10 a=YaSVt_x22M8wy4UUNlIA] X-AnalysisOut: [:9 a=Et71_OI7--yOYVwbnaMAzoOQ0D0A:4] Subject: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 19:01:29 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Juergen, I wrote an additon to the various scenarios described in draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario found on Smart PDUs. Please let me know if you have any questions while integrating it. $ diff draft-ietf-eman-requirements-00.txt draft-ietf-eman-requirements-01.txt 416a417,449 > 2.9. Scenario 9: Ganged outlets on a Smart Power Strip > > Some PDUs allow physical entities like outlets to be "ganged" together as a > logical entity for simplified management purposes. This is particularly > useful for servers with multiple power supplies, where each power supply is > connected to a different physical outlet. Other implementations allow > "gangs" to be created based on common ownership of outlets, such as > business units or load shed priority or other non-physical relationships. > > Current implementations allow for an "M-to-N" mapping between outlet > "gangs" and physical outlets. An example of this mapping includes the > following: > > Outlet 1 (physical entity) > Outlet 2 (physical entity) > Outlet 3 (physical entity) > Outlet 4 (physical entity) > Outlet Gang A (virtual entity) > Outlet Gang B (virtual entity) > > Gang A -> Outlets 1, 2 and 3 > Gang B -> Outlets 3 and 4 > > Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both > "gangs." > > Each "Outlet Gang" entity reports the aggregated data from the individual > outlet entities that comprise it and enables a single point of control for > all the individual outlet entities. For example, turning "Outlet Gang A" > to the "off" state would turn outlets 1, 2, and 3 "off" in some > implementations. (The impact of this action on "Outlet Gang B" is to be > defined by the equipment manufacturer.) > Thanks, Chris --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="outlet_gang.patch" 416a417,449 > 2.9. Scenario 9: Ganged outlets on a Smart Power Strip > > Some PDUs allow physical entities like outlets to be "ganged" together as a > logical entity for simplified management purposes. This is particularly > useful for servers with multiple power supplies, where each power supply is > connected to a different physical outlet. Other implementations allow > "gangs" to be created based on common ownership of outlets, such as > business units or load shed priority or other non-physical relationships. > > Current implementations allow for an "M-to-N" mapping between outlet > "gangs" and physical outlets. An example of this mapping includes the > following: > > Outlet 1 (physical entity) > Outlet 2 (physical entity) > Outlet 3 (physical entity) > Outlet 4 (physical entity) > Outlet Gang A (virtual entity) > Outlet Gang B (virtual entity) > > Gang A -> Outlets 1, 2 and 3 > Gang B -> Outlets 3 and 4 > > Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both > "gangs." > > Each "Outlet Gang" entity reports the aggregated data from the individual > outlet entities that comprise it and enables a single point of control for > all the individual outlet entities. For example, turning "Outlet Gang A" > to the "off" state would turn outlets 1, 2, and 3 "off" in some > implementations. (The impact of this action on "Outlet Gang B" is to be > defined by the equipment manufacturer.) > --X1bOJ3K7DJ5YkBrT-- From bill.mielke@alcatel-lucent.com Fri Mar 4 13:38:25 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0D83A6A2D for ; Fri, 4 Mar 2011 13:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.043 X-Spam-Level: X-Spam-Status: No, score=-6.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dkYhrCGzxfw for ; Fri, 4 Mar 2011 13:38:24 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id B2D1B3A6A3A for ; Fri, 4 Mar 2011 13:38:24 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p24LdUOs012218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Mar 2011 15:39:31 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p24LdUYD001938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Mar 2011 15:39:30 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 4 Mar 2011 15:39:30 -0600 From: "Mielke, William F (Bill)" To: eman mailing list Date: Fri, 4 Mar 2011 15:39:27 -0600 Thread-Topic: [eman] Power States - really Thread-Index: AcvalUjJU1tRxNKJSR2FtW/n8TqJkAAFyIMA Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715CB95@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> <20110303020507.GA19321@cslinux-build01.cyberswitching.local> <2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:38:26 -0000 > Ted Ghose wrote: > > I totally disagree with you. It is good that we disagree. Doing so fosters the discussion necessary to = better understand the topic du jour and to drive meaningful progress. :) =20 > It is diverse from device perspective, but if I look at energy saving per= spective,=20 > I want it unified. OK, let me challenge you to articulate WHY you want it unified. I am not s= aying that "unification" so is either good or bad, I would just like to kno= w the reasons for making that choice. I have tried to articulate a number of reasons why I think unification is n= ot a good goal in this case. What are your reasons for asserting that it i= s a good goal so that we might weigh the benefits against the costs? > We lay down some guideline for manufactures, but for managing power, I ne= ed a=20 > fixed set of states, which to me means lower state, I save more, higher s= tate=20 > I pay more!! This is an esthetically pleasing goal based on a nice sounding abstraction.= Even if I accept that such an approach is "doable" in the sense that the = constraint that you articulate (i.e. lower state implies lower cost) is sat= isfied by conforming implementations, I question the utility of such an app= roach in any practical sense from an effect management strategy. Any piece of equipment which is going to be managed via these interfaces pr= esumably is part of a larger system of cooperating entities who are expecte= d to jointly satisfy some specific business or operational requirements. T= he problem with trying to manage equipment at this level of abstraction is = that it is completely divorced from the implications it will have on those = business and operational requirements. If we consider the management of a specific entity the assumption people ar= e making here seems to be that some of the available power levels will be s= ufficient to meet those business requirements while others will not. How i= s an operator to know which levels are business requirements conforming and= which are not without understanding the vendor specific implications of se= tting one level or another? I argue that they cannot and so raising things to this level of abstraction= has not helped anything from a management perspective. The operators stil= l need to understand the idiosyncracies of each vendor's equipment and so t= he abstraction has not proven to be useful. If we instead assume that ALL power levels will somehow be business require= ments conforming (a very tall order without knowing any of the business con= text) then all operators will presumably set the power levels on all equipm= ent to their lowest values since this will obviously save the most money. = Why would you ever use a higher power level if do so costs money for no goo= d business benefit (i.e. in terms of meeting the business requirements)? If everyone is going to always set the lowest values then why bother to hav= e a parameter at all? Again, this abstraction, IMHO obviously, has not pro= ven useful from a management perspective. Do you disagree with the above analysis? If so please explain why. Thanks, William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com =20 Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein=20 From tirth.ghose@gmail.com Fri Mar 4 16:52:55 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D8E3A68CF for ; Fri, 4 Mar 2011 16:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3u9K-Z7s9iv for ; Fri, 4 Mar 2011 16:52:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 711203A6875 for ; Fri, 4 Mar 2011 16:52:53 -0800 (PST) Received: by iyj8 with SMTP id 8so2760214iyj.31 for ; Fri, 04 Mar 2011 16:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7T6Tv5FHTLD4XQeEiS12RD/3EMC46BJoH8PsVG7KiGg=; b=HpajNIbxpJUigxcmfMIt4TQ16wuilVL7ngLJTdxSoJfvUc2cPb6hCFT6Wpz8BthA1n dUZSoNl4fFm0OGVEmr30gduiZNdNSpmGX+8cj/L9G+DIn8aL2fntqB/TB29ufomXWYbi CFoc59uAR+kIKAjJQ2pabx3F0Cl7Jg9Mi4UPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Z3QKgtSC67PUpcCYhG+8N3SfA7dXyJY5byKfgzKPTiYBnZpbGTz2C0N43Vq0x47L7e lSXBO37YUqT24H+0aQthHHv9BURPiM146MtTA6NOc/D2I4CWLWqdIPq2uTcw4vc37vf4 UwCZ2138e9G8N8SD1tReE87drTJyAICXNdw8Q= MIME-Version: 1.0 Received: by 10.231.203.68 with SMTP id fh4mr473138ibb.68.1299286442214; Fri, 04 Mar 2011 16:54:02 -0800 (PST) Sender: tirth.ghose@gmail.com Received: by 10.231.156.141 with HTTP; Fri, 4 Mar 2011 16:54:02 -0800 (PST) In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715CB95@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> <20110303020507.GA19321@cslinux-build01.cyberswitching.local> <2181BF7B-8A07-44EA-A3F6-BE1A860B7456@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715C975@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250715CB95@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Date: Fri, 4 Mar 2011 16:54:02 -0800 X-Google-Sender-Auth: L66Q0yx6Fk08Lt8ZY3iAqIqDX_Y Message-ID: From: Ted Ghose To: "Mielke, William F (Bill)" Content-Type: multipart/alternative; boundary=0016369f9c2fd983de049db1b2bc Cc: eman mailing list Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 00:52:55 -0000 --0016369f9c2fd983de049db1b2bc Content-Type: text/plain; charset=ISO-8859-1 Hi Bill: ## Do you disagree with the above analysis? If so please explain why. I actually do agree with you that capability of a device along with the business context is the extra dimension that will be needed to factor in. These 2 parameters are crucial to drive the complete solution. How are we going to represent these two parameter with respect to a devices power state, and how can we have a granular control from cost benefit analysis is the next thing on my agenda. But, unless we have a agreed set of power states, we are not having a forum to work. In my mind all along, I'm modelling around the power states to drive the enterprise of home power policies. My objective is not just to blindly set to a lower state, but have the ability to have policies around the power states, and this abstraction is going to give us the tool to do so. without the fixed number of states though, please show me how could we make policies or rule engines to automate across a business domain or even for your home. If we can achieve that without power states, I'm in one mind with you, that we do not need them. Do I the make my reasons clear why I'm for making that choice? Thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Fri, Mar 4, 2011 at 1:39 PM, Mielke, William F (Bill) < bill.mielke@alcatel-lucent.com> wrote: > > Ted Ghose wrote: > > > > I totally disagree with you. > > It is good that we disagree. Doing so fosters the discussion necessary to > better understand the topic du jour and to drive meaningful progress. :) > > > It is diverse from device perspective, but if I look at energy saving > perspective, > > I want it unified. > > OK, let me challenge you to articulate WHY you want it unified. I am not > saying that "unification" so is either good or bad, I would just like to > know the reasons for making that choice. > > I have tried to articulate a number of reasons why I think unification is > not a good goal in this case. What are your reasons for asserting that it > is a good goal so that we might weigh the benefits against the costs? > > > We lay down some guideline for manufactures, but for managing power, I > need a > > fixed set of states, which to me means lower state, I save more, higher > state > > I pay more!! > > This is an esthetically pleasing goal based on a nice sounding abstraction. > Even if I accept that such an approach is "doable" in the sense that the > constraint that you articulate (i.e. lower state implies lower cost) is > satisfied by conforming implementations, I question the utility of such an > approach in any practical sense from an effect management strategy. > > Any piece of equipment which is going to be managed via these interfaces > presumably is part of a larger system of cooperating entities who are > expected to jointly satisfy some specific business or operational > requirements. The problem with trying to manage equipment at this level of > abstraction is that it is completely divorced from the implications it will > have on those business and operational requirements. > > If we consider the management of a specific entity the assumption people > are making here seems to be that some of the available power levels will be > sufficient to meet those business requirements while others will not. How > is an operator to know which levels are business requirements conforming and > which are not without understanding the vendor specific implications of > setting one level or another? > > I argue that they cannot and so raising things to this level of abstraction > has not helped anything from a management perspective. The operators still > need to understand the idiosyncracies of each vendor's equipment and so the > abstraction has not proven to be useful. > > If we instead assume that ALL power levels will somehow be business > requirements conforming (a very tall order without knowing any of the > business context) then all operators will presumably set the power levels on > all equipment to their lowest values since this will obviously save the most > money. Why would you ever use a higher power level if do so costs money for > no good business benefit (i.e. in terms of meeting the business > requirements)? > > If everyone is going to always set the lowest values then why bother to > have a parameter at all? Again, this abstraction, IMHO obviously, has not > proven useful from a management perspective. > > Do you disagree with the above analysis? If so please explain why. > > Thanks, > > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 > > "Live like you're going to die tomorrow. > Learn like you're going to live forever." > > - Albert Einstein > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --0016369f9c2fd983de049db1b2bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bill:

## Do you disagree with the above analysis? =A0If so pleas= e explain why.

I actually do agree with you that capabil= ity of a device along with the=A0business=A0context is the extra dimension = that will be needed to factor in. These 2 parameters are crucial to drive t= he complete solution. How are we going to represent these two parameter wit= h respect to a devices power state, and how can we have a granular control = from cost benefit analysis is the next thing on my agenda. But, unless we h= ave a agreed set of power states, we are not having a forum to work. In my = mind all along, I'm modelling around the power states to drive the ente= rprise of home power policies.

My objective is not just to blindly set to a lower stat= e, but have the ability to have policies around the power states, and this = abstraction is going to give us the tool to do so.

without the fixed number of states though, please show me how could we= make policies or rule engines to automate across a=A0business=A0domain or = even for your home.

If we can achieve that without= power states, I'm in one mind with you, that we do not need them.

Do I=A0the make my reasons clear why I'm for making= that choice?

Thanks

-tg-=
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*= '``'*:-.,_:-.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time... see it my way
*:= -.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-= .,_,.-:**:-.,_,.


On Fri, Mar 4, 2011 at 1:39 PM, Mielke, = William F (Bill) <bill.mielke@alcatel-lucent.com> wrote:
> Ted Ghose wrote:
>
> I totally disagree with you.

It is good that we disagree. =A0Doing so fosters the discussion neces= sary to better understand the topic du jour and to drive meaningful progres= s. =A0:)

> It is diverse from device perspective, but if I look at energy saving = perspective,
> I want it unified.

OK, let me challenge you to articulate WHY you want it unified. =A0I = am not saying that "unification" so is either good or bad, I woul= d just like to know the reasons for making that choice.

I have tried to articulate a number of reasons why I think unification is n= ot a good goal in this case. =A0What are your reasons for asserting that it= is a good goal so that we might weigh the benefits against the costs?

> We lay down some guideline for manufactures, but for managing power, I= need a
> fixed set of states, which to me means lower state, I save more, highe= r state
> I pay more!!

This is an esthetically pleasing goal based on a nice sounding abstra= ction. =A0Even if I accept that such an approach is "doable" in t= he sense that the constraint that you articulate (i.e. lower state implies = lower cost) is satisfied by conforming implementations, I question the util= ity of such an approach in any practical sense from an effect management st= rategy.

Any piece of equipment which is going to be managed via these interfaces pr= esumably is part of a larger system of cooperating entities who are expecte= d to jointly satisfy some specific business or operational requirements. = =A0The problem with trying to manage equipment at this level of abstraction= is that it is completely divorced from the implications it will have on th= ose business and operational requirements.

If we consider the management of a specific entity the assumption people ar= e making here seems to be that some of the available power levels will be s= ufficient to meet those business requirements while others will not. =A0How= is an operator to know which levels are business requirements conforming a= nd which are not without understanding the vendor specific implications of = setting one level or another?

I argue that they cannot and so raising things to this level of abstraction= has not helped anything from a management perspective. =A0The operators st= ill need to understand the idiosyncracies of each vendor's equipment an= d so the abstraction has not proven to be useful.

If we instead assume that ALL power levels will somehow be business require= ments conforming (a very tall order without knowing any of the business con= text) then all operators will presumably set the power levels on all equipm= ent to their lowest values since this will obviously save the most money. = =A0Why would you ever use a higher power level if do so costs money for no = good business benefit (i.e. in terms of meeting the business requirements)?=

If everyone is going to always set the lowest values then why bother to hav= e a parameter at all? =A0Again, this abstraction, IMHO obviously, has not p= roven useful from a management perspective.

Do you disagree with the above analysis? =A0If so please explain why.

Thanks,

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH =A043213-1530
Email: Bill.Mielke@= alcatel-lucent.com <mailto:mielke@alcatel-lucent.com>
Phone: 614 367 5628
Fax: 614 367 5965

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

=A0 =A0- Albert Einstein

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

--0016369f9c2fd983de049db1b2bc-- From chrisv@cyberswitching.com Sat Mar 5 16:26:26 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8713A6A32 for ; Sat, 5 Mar 2011 16:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, FRT_LITTLE=1.555, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE16wNG1UiHL for ; Sat, 5 Mar 2011 16:26:23 -0800 (PST) Received: from p01c12o143.mxlogic.net (p01c12o143.mxlogic.net [208.65.145.66]) by core3.amsl.com (Postfix) with ESMTP id 96F903A6A16 for ; Sat, 5 Mar 2011 16:26:22 -0800 (PST) Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c12o143.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 5f4d27d4.0.212260.00-340.328418.p01c12o143.mxlogic.net (envelope-from ); Sat, 05 Mar 2011 17:27:34 -0700 (MST) X-MXL-Hash: 4d72d4f63d78422f-f701241cbecef22cdf1078a405e13d87cb5f85a5 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Sat, 5 Mar 2011 16:26:59 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 2F9032F6001; Sat, 5 Mar 2011 16:27:33 -0800 (PST) Date: Sat, 5 Mar 2011 16:27:33 -0800 From: chrisv@cyberswitching.com To: eman@ietf.org Message-ID: <20110306002733.GA14483@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 06 Mar 2011 00:26:59.0906 (UTC) FILETIME=[352ECA20:01CBDB95] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [64.81.28.110] X-AnalysisOut: [v=1.0 c=1 a=BLceEmwcHowA:10 a=4zsJQXJisSY22NXBO5KRuA==:17 ] X-AnalysisOut: [a=ySRphs8YPu7QZ6P9YZsA:9 a=Kk9CbAEqsd_hzkxRj4OU5NmYONAA:4 ] X-AnalysisOut: [a=CjuIK1q_8ugA:10 a=Uqgdx_rjxWmhtboANSAA:9 a=kgvrfKmD2Shhj] X-AnalysisOut: [4wshvMA:7 a=v9JzOacOeZXBitGqpNbIACB5hRIA:4 a=WURTZkp3fTHl8] X-AnalysisOut: [UPe:21 a=JIOlW9ZQ50tYo0L3:21] Subject: [eman] Use of ENTITY-MIB in EMAN X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 00:26:26 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, The large number of discussions related to the use of ENTITY-MIB prompted me to look further at its use related to EMAN. I'd like to thank Dan and Juergen for helping to explain certain concepts during the development of this analysis. I've finished putting together the first draft of the analysis and invite your feedback. (Especially from those of you who understand ENTITY-MIB better than I do!) Please take a look and make sure that such a structural breakdown makes sense and works for the various needs related to EMAN. Thanks, Chris --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="eman-relationship-to-entity-mib-00.txt" On the EMAN working group mailing list recently, there has a been a huge surge of activity surrounding the use of ENTITY-MIB (RFC4133) to define the list of core entities. I thought a detailed look at ENTITY-MIB's structures and philosophical underpinnings would be in order to see if it will work for EMAN's needs. >From RFC4133, ENTITY-MIB's description of itself and its purpose: "There is a need for a standardized way of representing a single agent, which supports multiple intstances of one MIB. This is presently true for at least 3 standard MIBs, and is likely to become true for more and more MIBs as time passes...." "What is needed is a way to determine exactly which logical entities are managed by the agent (with some version of SNMP) in order to communicate with the agent about a particular logical entity. When different logical entities are associated with different physical entities within the overall physical entity, it is also useful to be able to use this information to distinguish between logical entities." Also from RFC4311, some nomenclature: "Logical Entity: a managed system contains one or more logical entities, each represented by at most one instantiation of each of a particular set of MIB objects. A set of management functions is associated with each logical entity. Examples of logical entities include routers, bridges, print-servers, etc." "Physical Entity: a 'physical entity' or 'physical component' represents an identifiable physical resource within a managed system. Zero or more logical entities may utilize a physical resource at any given time. Determining which physical components are represented by an agent in the EntPhysicalTable is an implementation-specific matter. Typically, physical resources (e.g., communications ports, backplanes, sensors, daughter-cards, power supplies, the overall chassis), which can be managed via functions associated with one or more logical entities, are included in the MIB." There exist two key tables in ENTITY-MIB: entPhysicalTable, which identifies physical system components; and entLogicalTable, which identifies logical entities. Each contain one row per entity, where each row is indexed by an arbitrary integer. The target system that I am attempting to model is an ePower series intelligent PDU (iPDU) from Cyber Switching. One representation of this device's physical construction might be: ePower PDU |-- Network Interface Card | |-- LCD screen | |-- Processor | `-- Real-time clock battery/super-cap |-- Input #1 (3 Phase AC cord) | |-- Bank #1 (1Ph branch circuit - L1/L2) | | |-- Outlet #1 | | |-- Outlet #2 | | |-- Outlet #3 | | `-- Outlet #4 | |-- Bank #2 (1Ph branch circuit - L2/L3) | | |-- Outlet #5 | | |-- Outlet #6 | | |-- Outlet #7 | | `-- Outlet #8 | `-- Bank #3 (1Ph branch circuit - L3/L1) | |-- Outlet #9 | |-- Outlet #10 | |-- Outlet #11 | `-- Outlet #12 `-- Input #2 (3 Phase AC cord) |-- Bank #4 (1Ph branch circuit - L1/L2) | |-- Outlet #13 | |-- Outlet #14 | |-- Outlet #15 | `-- Outlet #16 |-- Bank #5 (1Ph branch circuit - L2/L3) | |-- Outlet #17 | |-- Outlet #18 | |-- Outlet #19 | `-- Outlet #20 `-- Bank #6 (1Ph branch circuit - L3/L1) |-- Outlet #21 |-- Outlet #22 |-- Outlet #23 `-- Outlet #24 Note that for each 3 Phase AC cord, between three and four separate sub-entities can exist: 3 Phase AC cord |-- Line L1 / X / A |-- Line L2 / Y / B |-- Line L3 / Z / C `-- Line Neutral / N In addition to this physical component breakdown, logical groupings of physical entities may be created. For example, outlet entities may be logically associated with one another into an "outlet gang." An outlet may belong to more than one "outlet gang." One representation of this may be: ePower PDU |-- Outlet Gang #1 | |-- Outlet #5 | |-- Outlet #6 | `-- Outlet #7 `-- Outlet Gang #2 |-- Outlet #6 `-- Outlet #13 As this applies to the EMAN goals, our objective is to instantiate the objects necessary to represent all of these various entities in such a way that power data and operational state control can be linked to them. I will investigate several possible scenarios of using ENTITY-MIB's existing structures to achieve this instantiation. In this exercise, we will start by placing all physical entities in entPhysicalTable. The table below shows key columns from that table along with sample values. entPhysicalTable +-----+---------------+-------------------+-------------+--------------+ | Idx | Name | Alias | ContainedIn | ParentRelPos | +-----+---------------+-------------------+-------------+--------------+ | 1 | ePower PDU | epower-pdu | 0 | 0 | | 2 | NIC | Control Logic | 1 | 1 | | 3 | LCD | Touchscreen Disp. | 2 | 0 | | 4 | Processor | CPU | 2 | 0 | | 5 | RTC Battery | Clock battery | 2 | 0 | | 6 | Input #1 | XFMR #1 feed | 1 | 2 | | 7 | Input #1 - L1 | Line L1 / X / A | 6 | 0 | | 8 | Input #1 - L2 | Line L2 / Y / B | 6 | 0 | | 9 | Input #1 - L3 | Line L3 / Z / C | 6 | 0 | | 10 | Input #1 - N | Line Neutral / N | 6 | 0 | | 11 | Bank #1 | Branch Cir. L1/L2 | 6 | 1 | | 12 | Outlet #1 | filer01-sjc-pwr1 | 11 | 1 | | 13 | Outlet #2 | filer17-sjc | 11 | 2 | | 14 | Outlet #3 | filer23-sjc | 11 | 3 | | 15 | Outlet #4 | san-array05-sjc | 11 | 4 | | 16 | Bank #2 | Branch Cir. L2/L3 | 6 | 2 | | 17 | Outlet #5 | rtr-u3-fre | 16 | 1 | | 18 | Outlet #6 | wap-flr01 | 16 | 2 | | 19 | Outlet #7 | wap-flr02 | 16 | 3 | | 20 | Outlet #8 | wap-flr03 | 16 | 4 | | 21 | Bank #3 | Branch Cir. L3/L1 | 6 | 3 | | 22 | Outlet #9 | rtr-m6-he | 21 | 1 | | 23 | Outlet #10 | rtr-m6-att | 21 | 2 | | 24 | Outlet #11 | switch-p989 | 21 | 3 | | 25 | Outlet #12 | switch-t332 | 21 | 4 | | 26 | Input #2 | XFMR #1 feed | 1 | 3 | | 27 | Input #2 - L1 | Line L1 / X / A | 26 | 0 | | 28 | Input #2 - L2 | Line L2 / Y / B | 26 | 0 | | 29 | Input #2 - L3 | Line L3 / Z / C | 26 | 0 | | 30 | Input #2 - N | Line Neutral / N | 26 | 0 | | 31 | Bank #4 | Branch Cir. L1/L2 | 26 | 1 | | 32 | Outlet #13 | filer01-sjc-pwr2 | 31 | 1 | | 33 | Outlet #14 | ... | 31 | 2 | | 34 | Outlet #15 | ... | 31 | 3 | | 35 | Outlet #16 | ... | 31 | 4 | | 36 | Bank #5 | Branch Cir. L2/L3 | 26 | 2 | | 37 | Outlet #17 | ... | 36 | 1 | | 38 | Outlet #18 | ... | 36 | 2 | | 39 | Outlet #19 | ... | 36 | 3 | | 40 | Outlet #20 | ... | 36 | 4 | | 41 | Bank #6 | Branch Cir. L3/L1 | 26 | 3 | | 42 | Outlet #21 | ... | 41 | 1 | | 43 | Outlet #22 | ... | 41 | 2 | | 44 | Outlet #23 | ... | 41 | 3 | | 44 | Outlet #24 | ... | 41 | 4 | +-----+---------------+-------------------+-------------+--------------+ In the spirit of ENTITY-MIB, the "outlet gang" entities do not belong in entPhysicalTable, as they are virtual representations of a collection of outlets. Therefore, we will place them in entLogicalTable. entLogicalTable +-----+----------------+ | Idx | Descr | +-----+----------------+ | 1 | Outlet Gang #1 | | 2 | Outlet Gang #2 | +-----+----------------+ The logical entities can be mapped onto the physical entities by using entLPMappingTable. entLPMappingTable +------------+-------------+ | LogicalIdx | PhysicalIdx | +------------+-------------+ | 1 | 17 | Outlet Gang #1 -> Outlet #5 | 1 | 18 | -> Outlet #6 | 1 | 19 | -> Outlet #7 | 2 | 16 | Outlet Gang #2 -> Outlet #6 | 2 | 32 | -> Outlet #13 +------------+-------------+ The entire model is now implemented using ENTITY-MIB. However, there are some ramifications to this: 1. There is no single "index" that can be referenced for sparse tables in an EMAN MIB. The use of both entPhysicalTable and entLogicalTable means that separate indicies must be used, which results in separate EMAN tables for power data, control, etc. (one for physical entities, one for logical entities). 2. The structure of entPhysicalTable allows an entity to maintain a constant name (e.g., "Outlet #1") while changing an alias (e.g., "filer01-sjc-pwr1"). The structure of entLogicalTable does not allow the same behavior, so logical entities are naturally less feature capable. 3. None of the objects in ENTITY-MIB allow for 'read-create', so creating new "outlet gangs" would have to be supported by a third-party mechanism. While not critical to EMAN's needs, it is a major inconvenience for the various manufacturers who would benefit from such standard operation. One proposed solution on the mailing list for #1 is to duplicate all entries from entPhysicalTable in entLogicalTable. The resulting structure would allow a single index to be used (entLogicalIndex), but would not address item #2. One possible solution for #2 would be to list the virtual "outlet gangs" in entPhysicalTable as well as in entLogicalTable, but this violates the spirit behind entPhysicalTable as described in RFC4133. So both compromise solutions would need to be made in order to handle "virtual" entities like "outlet gangs" using ENTITY-MIB. However, even if both solutions are used, establishing a relationship graph between an "outlet gang" and its parent PDU and between an "outlet gang" and its associated physical outlets is not handled in a simple manner. The entPhysicalContainedIn object can be used to relate physical outlets to their corresponding banks and the "outlet gangs" with the physical PDU. The entLPMappingTable can establish a mapping between the "outlet gang" and the physical outlets. However, as you can see, determining the parent/child relationship between entities is a complex process involving both entPhysicalContainedIn and entLPMappingTable. Another goal for EMAN is to report data on behalf of remote entities. In such a scenario, the agent must reference multiple physical entities that are external to the agent's system. Ethernet Switch |-- Port 1 |-- Port 2 --------------------> VoIP Phone |-- Port 3 --------------------> ePower PDU `-- Port 4 --------------------> Windows PC In this scenario, the VoIP phone, ePower PDU, and Windows PC report their power data to the Ethernet Switch, which acts as a collection proxy for the data. The structure underneath "ePower PDU" follows that described above. Modeling the switch itself is straight-forward. Following the logic used to describe an ePower PDU above, we can model all of the entities known/managed by the switch. entPhysicalTable +-----+---------------+-------------------+-------------+--------------+ | Idx | Name | Alias | ContainedIn | ParentRelPos | +-----+---------------+-------------------+-------------+--------------+ | 1 | Eth. Switch | switch-4-sjc | 0 | 0 | | 2 | Port 1 | Switchport 1 | 1 | 1 | | 3 | Port 2 | Switchport 2 | 1 | 2 | | 4 | Port 3 | Switchport 3 | 1 | 3 | | 5 | Port 4 | Switchport 4 | 1 | 4 | | 6 | ePower PDU | epower-pdu | 4 | 0 | | 7 | NIC | Control Logic | 6 | 1 | | 8 | LCD | Touchscreen Disp. | 7 | 0 | | 9 | Processor | CPU | 7 | 0 | | 10 | RTC Battery | Clock battery | 7 | 0 | | 11 | Input #1 | XFMR #1 feed | 6 | 2 | | 12 | Input #1 - L1 | Line L1 / X / A | 11 | 0 | | 13 | Input #1 - L2 | Line L2 / Y / B | 11 | 0 | | 14 | Input #1 - L3 | Line L3 / Z / C | 11 | 0 | | 15 | Input #1 - N | Line Neutral / N | 11 | 0 | | 16 | Bank #1 | Branch Cir. L1/L2 | 11 | 1 | | 17 | Outlet #1 | filer01-sjc-pwr1 | 16 | 1 | | 18 | Outlet #2 | filer17-sjc | 16 | 2 | | 19 | Outlet #3 | filer23-sjc | 16 | 3 | | 20 | Outlet #4 | san-array05-sjc | 16 | 4 | | 21 | Bank #2 | Branch Cir. L2/L3 | 11 | 2 | | 22 | Outlet #5 | rtr-u3-fre | 21 | 1 | | 23 | Outlet #6 | wap-flr01 | 21 | 2 | | 24 | Outlet #7 | wap-flr02 | 21 | 3 | | 25 | Outlet #8 | wap-flr03 | 21 | 4 | | 26 | Bank #3 | Branch Cir. L3/L1 | 11 | 3 | | 27 | Outlet #9 | rtr-m6-he | 26 | 1 | | 28 | Outlet #10 | rtr-m6-att | 26 | 2 | | 29 | Outlet #11 | switch-p989 | 26 | 3 | | 30 | Outlet #12 | switch-t332 | 26 | 4 | | 31 | Input #2 | XFMR #1 feed | 11 | 3 | | 32 | Input #2 - L1 | Line L1 / X / A | 31 | 0 | | 33 | Input #2 - L2 | Line L2 / Y / B | 31 | 0 | | 34 | Input #2 - L3 | Line L3 / Z / C | 31 | 0 | | 35 | Input #2 - N | Line Neutral / N | 31 | 0 | | 36 | Bank #4 | Branch Cir. L1/L2 | 31 | 1 | | 37 | Outlet #13 | filer01-sjc-pwr2 | 36 | 1 | | 38 | Outlet #14 | ... | 36 | 2 | | 39 | Outlet #15 | ... | 36 | 3 | | 40 | Outlet #16 | ... | 36 | 4 | | 41 | Bank #5 | Branch Cir. L2/L3 | 31 | 2 | | 42 | Outlet #17 | ... | 41 | 1 | | 43 | Outlet #18 | ... | 41 | 2 | | 44 | Outlet #19 | ... | 41 | 3 | | 45 | Outlet #20 | ... | 41 | 4 | | 46 | Bank #6 | Branch Cir. L3/L1 | 31 | 3 | | 47 | Outlet #21 | ... | 46 | 1 | | 48 | Outlet #22 | ... | 46 | 2 | | 49 | Outlet #23 | ... | 46 | 3 | | 50 | Outlet #24 | ... | 46 | 4 | | 51 | Outlet Gang 1 | Finance Servers | 6 | 0 | | 52 | Outlet Gang 2 | Sales Servers | 6 | 0 | | 53 | VoIP Phone | VoIP/SIP Phone | 3 | 0 | | 54 | Windows PC | John Smith's PC | 5 | 0 | +-----+---------------+-------------------+-------------+--------------+ entLogicalTable +-----+---------------+ | Idx | Descr | +-----+---------------+ | 1 | Eth. Switch | | 2 | Port 1 | | 3 | Port 2 | | 4 | Port 3 | | 5 | Port 4 | | 6 | ePower PDU | | 7 | NIC | | 8 | LCD | | 9 | Processor | | 10 | RTC Battery | | 11 | Input #1 | | 12 | Input #1 - L1 | | 13 | Input #1 - L2 | | 14 | Input #1 - L3 | | 15 | Input #1 - N | | 16 | Bank #1 | | 17 | Outlet #1 | | 18 | Outlet #2 | | 19 | Outlet #3 | | 20 | Outlet #4 | | 21 | Bank #2 | | 22 | Outlet #5 | | 23 | Outlet #6 | | 24 | Outlet #7 | | 25 | Outlet #8 | | 26 | Bank #3 | | 27 | Outlet #9 | | 28 | Outlet #10 | | 29 | Outlet #11 | | 30 | Outlet #12 | | 31 | Input #2 | | 32 | Input #2 - L1 | | 33 | Input #2 - L2 | | 34 | Input #2 - L3 | | 35 | Input #2 - N | | 36 | Bank #4 | | 37 | Outlet #13 | | 38 | Outlet #14 | | 39 | Outlet #15 | | 40 | Outlet #16 | | 41 | Bank #5 | | 42 | Outlet #17 | | 43 | Outlet #18 | | 44 | Outlet #19 | | 45 | Outlet #20 | | 46 | Bank #6 | | 47 | Outlet #21 | | 48 | Outlet #22 | | 49 | Outlet #23 | | 50 | Outlet #24 | | 51 | Outlet Gang 1 | | 52 | Outlet Gang 2 | | 53 | VoIP Phone | | 54 | Windows PC | +-----+---------------+ entLPMappingTable +------------+-------------+ | LogicalIdx | PhysicalIdx | +------------+-------------+ | 51 | 22 | Outlet Gang #1 -> Outlet #5 | 51 | 23 | -> Outlet #6 | 51 | 24 | -> Outlet #7 | 52 | 23 | Outlet Gang #2 -> Outlet #6 | 52 | 37 | -> Outlet #13 +------------+-------------+ Questions that remain to be answered: 1. When an entity is disconnected/removed (like the ePower PDU being disconnected from the switchport), what is the behavior related to ENTITY-MIB? Are the entries removed and, if so, are the indices for the remaining entries collapsed/adjusted to remove the gap? 2. What happens when an entity is reconnected (like the same ePower PDU being connected to a different switchport), what is the behavior related to ENTITY-MIB? Are the original indices reused? 3. How will an Energy Management System (EMS) or other NMS using this data ensure that the data gathered and control mechanisms used are universally guaranteed? Does a UUID or other form of identification need to be created for an entity and, if so, how is that UUID exposed via ENTITY-MIB? 4. How does this proposed use of ENTITY-MIB for EMAN's purposes relate to the standard, existing use of ENTITY-MIB in the industry? --AhhlLboLdkugWU4S-- From dromasca@avaya.com Sun Mar 6 07:42:20 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775093A67D0 for ; Sun, 6 Mar 2011 07:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSrBmSHCjPSg for ; Sun, 6 Mar 2011 07:42:19 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 70E233A676A for ; Sun, 6 Mar 2011 07:42:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU3GmAcF/2dsb2JhbACmZXSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.62,271,1297054800"; d="scan'208";a="235427800" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Mar 2011 10:43:28 -0500 X-IronPort-AV: E=Sophos;i="4.62,271,1297054800"; d="scan'208";a="590934591" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Mar 2011 10:43:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 6 Mar 2011 16:43:06 +0100 Message-ID: In-Reply-To: <0E32737B-484D-4263-9749-149E61601B03@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] modeling power states Thread-Index: AcvaTs9V2fLo5po8QECEtKNufjkdfABxhOPg References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at> <20110301050601.GA2638@cslinux-build01.cyberswitching.local> <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> <0E32737B-484D-4263-9749-149E61601B03@quittek.at> From: "Romascanu, Dan (Dan)" To: "Juergen Quittek" , "Juergen Schoenwaelder" Cc: eman mailing list Subject: Re: [eman] modeling power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 15:42:20 -0000 =20 > -----Original Message----- > From: Juergen Quittek [mailto:ietf@quittek.at]=20 >=20 > I think Cisco has another example with PCs reporting their=20 > power to switches and the switches report it to the=20 > management system, but this can certainly be explained better=20 > by the people from Cisco. >=20 The standard version of this scheme is by implementing LLDP-MED (ANSI/TIA 1057) which is an extension of IEEE 802.1AB and has also defined a MIB to report on power and other characteristics of the remote devices directly connected to an Ethernet switch.=20 Dan From bclaise@cisco.com Mon Mar 7 00:18:20 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4AE43A6920 for ; Mon, 7 Mar 2011 00:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3t8mIbco4eQ for ; Mon, 7 Mar 2011 00:18:20 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id AD0973A689F for ; Mon, 7 Mar 2011 00:18:19 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p278FlRu011123 for ; Mon, 7 Mar 2011 09:15:47 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p278Fkvq026533 for ; Mon, 7 Mar 2011 09:15:47 +0100 (CET) Message-ID: <4D749432.4020306@cisco.com> Date: Mon, 07 Mar 2011 09:15:46 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: eman mailing list Content-Type: multipart/alternative; boundary="------------030602020701020000010805" Subject: [eman] Call for Agenda items for the EMAN open meeting in Prague X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 08:18:20 -0000 This is a multi-part message in MIME format. --------------030602020701020000010805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Now that we have a final agenda... https://datatracker.ietf.org/meeting/80/agenda.html https://datatracker.ietf.org/meeting/80/agenda.txt http://www.ietf.org/meeting/80/index.html If you plan to ask for presentation or discussion slots in the EMAN meeting in Prague, please send your requests to us. Regards, Bruce and Benoit. --------------030602020701020000010805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Now that we have a final agenda...
    https://datatracker.ietf.org/meeting/80/agenda.html
    http://www.ietf.org/meeting/80/index.html
If you plan to ask for presentation or discussion slots in the EMAN
meeting in Prague, please send your requests to us.

Regards, Bruce and Benoit.


--------------030602020701020000010805-- From j.schoenwaelder@jacobs-university.de Mon Mar 7 01:43:53 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097BD3A6919 for ; Mon, 7 Mar 2011 01:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.122 X-Spam-Level: X-Spam-Status: No, score=-103.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbDq4VA3iBwt for ; Mon, 7 Mar 2011 01:43:50 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4A4413A694D for ; Mon, 7 Mar 2011 01:43:50 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDAB8C0012; Mon, 7 Mar 2011 10:45:02 +0100 (CET) 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 wzEkjkqCaEWJ; Mon, 7 Mar 2011 10:45:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2275FC0010; Mon, 7 Mar 2011 10:45:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6DA5516E0C84; Mon, 7 Mar 2011 10:44:56 +0100 (CET) Date: Mon, 7 Mar 2011 10:44:56 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110307094456.GC32101@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, eman@ietf.org References: <20110306002733.GA14483@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110306002733.GA14483@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] Use of ENTITY-MIB in EMAN X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 09:43:53 -0000 On Sat, Mar 05, 2011 at 04:27:33PM -0800, chrisv@cyberswitching.com wrote: > Hi all, > > The large number of discussions related to the use of ENTITY-MIB > prompted me to look further at its use related to EMAN. I'd like to > thank Dan and Juergen for helping to explain certain concepts during the > development of this analysis. > > I've finished putting together the first draft of the analysis and > invite your feedback. (Especially from those of you who understand > ENTITY-MIB better than I do!) Please take a look and make sure that > such a structural breakdown makes sense and works for the various needs > related to EMAN. > > Thanks, > Chris > On the EMAN working group mailing list recently, there has a been a huge surge > of activity surrounding the use of ENTITY-MIB (RFC4133) to define the list of > core entities. I thought a detailed look at ENTITY-MIB's structures and > philosophical underpinnings would be in order to see if it will work for > EMAN's needs. > > From RFC4133, ENTITY-MIB's description of itself and its purpose: > > "There is a need for a standardized way of representing a single agent, > which supports multiple intstances of one MIB. This is presently true for > at least 3 standard MIBs, and is likely to become true for more and more > MIBs as time passes...." > > "What is needed is a way to determine exactly which logical entities are > managed by the agent (with some version of SNMP) in order to communicate > with the agent about a particular logical entity. When different logical > entities are associated with different physical entities within the overall > physical entity, it is also useful to be able to use this information to > distinguish between logical entities." > > Also from RFC4311, some nomenclature: > > "Logical Entity: a managed system contains one or more logical entities, > each represented by at most one instantiation of each of a particular set > of MIB objects. A set of management functions is associated with each > logical entity. Examples of logical entities include routers, bridges, > print-servers, etc." > > "Physical Entity: a 'physical entity' or 'physical component' represents an > identifiable physical resource within a managed system. Zero or more > logical entities may utilize a physical resource at any given time. > Determining which physical components are represented by an agent in the > EntPhysicalTable is an implementation-specific matter. Typically, physical > resources (e.g., communications ports, backplanes, sensors, daughter-cards, > power supplies, the overall chassis), which can be managed via functions > associated with one or more logical entities, are included in the MIB." > > There exist two key tables in ENTITY-MIB: entPhysicalTable, which identifies > physical system components; and entLogicalTable, which identifies logical > entities. Each contain one row per entity, where each row is indexed by an > arbitrary integer. > > The target system that I am attempting to model is an ePower series > intelligent PDU (iPDU) from Cyber Switching. One representation of this > device's physical construction might be: > > ePower PDU > |-- Network Interface Card > | |-- LCD screen > | |-- Processor > | `-- Real-time clock battery/super-cap > |-- Input #1 (3 Phase AC cord) > | |-- Bank #1 (1Ph branch circuit - L1/L2) > | | |-- Outlet #1 > | | |-- Outlet #2 > | | |-- Outlet #3 > | | `-- Outlet #4 > | |-- Bank #2 (1Ph branch circuit - L2/L3) > | | |-- Outlet #5 > | | |-- Outlet #6 > | | |-- Outlet #7 > | | `-- Outlet #8 > | `-- Bank #3 (1Ph branch circuit - L3/L1) > | |-- Outlet #9 > | |-- Outlet #10 > | |-- Outlet #11 > | `-- Outlet #12 > `-- Input #2 (3 Phase AC cord) > |-- Bank #4 (1Ph branch circuit - L1/L2) > | |-- Outlet #13 > | |-- Outlet #14 > | |-- Outlet #15 > | `-- Outlet #16 > |-- Bank #5 (1Ph branch circuit - L2/L3) > | |-- Outlet #17 > | |-- Outlet #18 > | |-- Outlet #19 > | `-- Outlet #20 > `-- Bank #6 (1Ph branch circuit - L3/L1) > |-- Outlet #21 > |-- Outlet #22 > |-- Outlet #23 > `-- Outlet #24 > > Note that for each 3 Phase AC cord, between three and four separate > sub-entities can exist: > > 3 Phase AC cord > |-- Line L1 / X / A > |-- Line L2 / Y / B > |-- Line L3 / Z / C > `-- Line Neutral / N > > In addition to this physical component breakdown, logical groupings of > physical entities may be created. For example, outlet entities may be > logically associated with one another into an "outlet gang." An outlet may > belong to more than one "outlet gang." One representation of this may be: > > ePower PDU > |-- Outlet Gang #1 > | |-- Outlet #5 > | |-- Outlet #6 > | `-- Outlet #7 > `-- Outlet Gang #2 > |-- Outlet #6 > `-- Outlet #13 > > As this applies to the EMAN goals, our objective is to instantiate the objects > necessary to represent all of these various entities in such a way that power > data and operational state control can be linked to them. I will investigate > several possible scenarios of using ENTITY-MIB's existing structures to > achieve this instantiation. > > In this exercise, we will start by placing all physical entities in > entPhysicalTable. The table below shows key columns from that table along > with sample values. > > entPhysicalTable > +-----+---------------+-------------------+-------------+--------------+ > | Idx | Name | Alias | ContainedIn | ParentRelPos | > +-----+---------------+-------------------+-------------+--------------+ > | 1 | ePower PDU | epower-pdu | 0 | 0 | > | 2 | NIC | Control Logic | 1 | 1 | > | 3 | LCD | Touchscreen Disp. | 2 | 0 | > | 4 | Processor | CPU | 2 | 0 | > | 5 | RTC Battery | Clock battery | 2 | 0 | > | 6 | Input #1 | XFMR #1 feed | 1 | 2 | > | 7 | Input #1 - L1 | Line L1 / X / A | 6 | 0 | > | 8 | Input #1 - L2 | Line L2 / Y / B | 6 | 0 | > | 9 | Input #1 - L3 | Line L3 / Z / C | 6 | 0 | > | 10 | Input #1 - N | Line Neutral / N | 6 | 0 | > | 11 | Bank #1 | Branch Cir. L1/L2 | 6 | 1 | > | 12 | Outlet #1 | filer01-sjc-pwr1 | 11 | 1 | > | 13 | Outlet #2 | filer17-sjc | 11 | 2 | > | 14 | Outlet #3 | filer23-sjc | 11 | 3 | > | 15 | Outlet #4 | san-array05-sjc | 11 | 4 | > | 16 | Bank #2 | Branch Cir. L2/L3 | 6 | 2 | > | 17 | Outlet #5 | rtr-u3-fre | 16 | 1 | > | 18 | Outlet #6 | wap-flr01 | 16 | 2 | > | 19 | Outlet #7 | wap-flr02 | 16 | 3 | > | 20 | Outlet #8 | wap-flr03 | 16 | 4 | > | 21 | Bank #3 | Branch Cir. L3/L1 | 6 | 3 | > | 22 | Outlet #9 | rtr-m6-he | 21 | 1 | > | 23 | Outlet #10 | rtr-m6-att | 21 | 2 | > | 24 | Outlet #11 | switch-p989 | 21 | 3 | > | 25 | Outlet #12 | switch-t332 | 21 | 4 | > | 26 | Input #2 | XFMR #1 feed | 1 | 3 | > | 27 | Input #2 - L1 | Line L1 / X / A | 26 | 0 | > | 28 | Input #2 - L2 | Line L2 / Y / B | 26 | 0 | > | 29 | Input #2 - L3 | Line L3 / Z / C | 26 | 0 | > | 30 | Input #2 - N | Line Neutral / N | 26 | 0 | > | 31 | Bank #4 | Branch Cir. L1/L2 | 26 | 1 | > | 32 | Outlet #13 | filer01-sjc-pwr2 | 31 | 1 | > | 33 | Outlet #14 | ... | 31 | 2 | > | 34 | Outlet #15 | ... | 31 | 3 | > | 35 | Outlet #16 | ... | 31 | 4 | > | 36 | Bank #5 | Branch Cir. L2/L3 | 26 | 2 | > | 37 | Outlet #17 | ... | 36 | 1 | > | 38 | Outlet #18 | ... | 36 | 2 | > | 39 | Outlet #19 | ... | 36 | 3 | > | 40 | Outlet #20 | ... | 36 | 4 | > | 41 | Bank #6 | Branch Cir. L3/L1 | 26 | 3 | > | 42 | Outlet #21 | ... | 41 | 1 | > | 43 | Outlet #22 | ... | 41 | 2 | > | 44 | Outlet #23 | ... | 41 | 3 | > | 44 | Outlet #24 | ... | 41 | 4 | > +-----+---------------+-------------------+-------------+--------------+ > > In the spirit of ENTITY-MIB, the "outlet gang" entities do not belong in > entPhysicalTable, as they are virtual representations of a collection of > outlets. Therefore, we will place them in entLogicalTable. > > entLogicalTable > +-----+----------------+ > | Idx | Descr | > +-----+----------------+ > | 1 | Outlet Gang #1 | > | 2 | Outlet Gang #2 | > +-----+----------------+ > > The logical entities can be mapped onto the physical entities by using > entLPMappingTable. > > entLPMappingTable > +------------+-------------+ > | LogicalIdx | PhysicalIdx | > +------------+-------------+ > | 1 | 17 | Outlet Gang #1 -> Outlet #5 > | 1 | 18 | -> Outlet #6 > | 1 | 19 | -> Outlet #7 > | 2 | 16 | Outlet Gang #2 -> Outlet #6 > | 2 | 32 | -> Outlet #13 > +------------+-------------+ I do not think this is a proper usage of entLogicalTable. The entLogicalTable is used to refer to other SNMP contexts where additional data resides. > The entire model is now implemented using ENTITY-MIB. However, there are some > ramifications to this: > > 1. There is no single "index" that can be referenced for sparse tables in > an EMAN MIB. The use of both entPhysicalTable and entLogicalTable means > that separate indicies must be used, which results in separate EMAN > tables for power data, control, etc. (one for physical entities, one for logical > entities). > > 2. The structure of entPhysicalTable allows an entity to maintain a > constant name (e.g., "Outlet #1") while changing an alias (e.g., > "filer01-sjc-pwr1"). The structure of entLogicalTable does not allow > the same behavior, so logical entities are naturally less feature > capable. > > 3. None of the objects in ENTITY-MIB allow for 'read-create', so creating > new "outlet gangs" would have to be supported by a third-party > mechanism. While not critical to EMAN's needs, it is a major > inconvenience for the various manufacturers who would benefit from such > standard operation. > > One proposed solution on the mailing list for #1 is to duplicate all entries > from entPhysicalTable in entLogicalTable. The resulting structure would allow > a single index to be used (entLogicalIndex), but would not address item #2. This would be more wrong use of entLogicalTable. > One possible solution for #2 would be to list the virtual "outlet gangs" in > entPhysicalTable as well as in entLogicalTable, but this violates the spirit > behind entPhysicalTable as described in RFC4133. > > So both compromise solutions would need to be made in order to handle > "virtual" entities like "outlet gangs" using ENTITY-MIB. How is an outlet gang different from a port module of a switch, except that it allows out outlet to be in multiple outlet groups? > However, even if both solutions are used, establishing a relationship graph > between an "outlet gang" and its parent PDU and between an "outlet gang" and > its associated physical outlets is not handled in a simple manner. The > entPhysicalContainedIn object can be used to relate physical outlets to their > corresponding banks and the "outlet gangs" with the physical PDU. The > entLPMappingTable can establish a mapping between the "outlet gang" and the > physical outlets. However, as you can see, determining the parent/child > relationship between entities is a complex process involving both > entPhysicalContainedIn and entLPMappingTable. > > Another goal for EMAN is to report data on behalf of remote entities. In such > a scenario, the agent must reference multiple physical entities that are > external to the agent's system. > > Ethernet Switch > |-- Port 1 > |-- Port 2 --------------------> VoIP Phone > |-- Port 3 --------------------> ePower PDU > `-- Port 4 --------------------> Windows PC > > In this scenario, the VoIP phone, ePower PDU, and Windows PC report their > power data to the Ethernet Switch, which acts as a collection proxy for the > data. > > The structure underneath "ePower PDU" follows that described above. > > Modeling the switch itself is straight-forward. Following the logic used to > describe an ePower PDU above, we can model all of the entities known/managed > by the switch. > > entPhysicalTable > +-----+---------------+-------------------+-------------+--------------+ > | Idx | Name | Alias | ContainedIn | ParentRelPos | > +-----+---------------+-------------------+-------------+--------------+ > | 1 | Eth. Switch | switch-4-sjc | 0 | 0 | > | 2 | Port 1 | Switchport 1 | 1 | 1 | > | 3 | Port 2 | Switchport 2 | 1 | 2 | > | 4 | Port 3 | Switchport 3 | 1 | 3 | > | 5 | Port 4 | Switchport 4 | 1 | 4 | > | 6 | ePower PDU | epower-pdu | 4 | 0 | > | 7 | NIC | Control Logic | 6 | 1 | > | 8 | LCD | Touchscreen Disp. | 7 | 0 | > | 9 | Processor | CPU | 7 | 0 | > | 10 | RTC Battery | Clock battery | 7 | 0 | > | 11 | Input #1 | XFMR #1 feed | 6 | 2 | > | 12 | Input #1 - L1 | Line L1 / X / A | 11 | 0 | > | 13 | Input #1 - L2 | Line L2 / Y / B | 11 | 0 | > | 14 | Input #1 - L3 | Line L3 / Z / C | 11 | 0 | > | 15 | Input #1 - N | Line Neutral / N | 11 | 0 | > | 16 | Bank #1 | Branch Cir. L1/L2 | 11 | 1 | > | 17 | Outlet #1 | filer01-sjc-pwr1 | 16 | 1 | > | 18 | Outlet #2 | filer17-sjc | 16 | 2 | > | 19 | Outlet #3 | filer23-sjc | 16 | 3 | > | 20 | Outlet #4 | san-array05-sjc | 16 | 4 | > | 21 | Bank #2 | Branch Cir. L2/L3 | 11 | 2 | > | 22 | Outlet #5 | rtr-u3-fre | 21 | 1 | > | 23 | Outlet #6 | wap-flr01 | 21 | 2 | > | 24 | Outlet #7 | wap-flr02 | 21 | 3 | > | 25 | Outlet #8 | wap-flr03 | 21 | 4 | > | 26 | Bank #3 | Branch Cir. L3/L1 | 11 | 3 | > | 27 | Outlet #9 | rtr-m6-he | 26 | 1 | > | 28 | Outlet #10 | rtr-m6-att | 26 | 2 | > | 29 | Outlet #11 | switch-p989 | 26 | 3 | > | 30 | Outlet #12 | switch-t332 | 26 | 4 | > | 31 | Input #2 | XFMR #1 feed | 11 | 3 | > | 32 | Input #2 - L1 | Line L1 / X / A | 31 | 0 | > | 33 | Input #2 - L2 | Line L2 / Y / B | 31 | 0 | > | 34 | Input #2 - L3 | Line L3 / Z / C | 31 | 0 | > | 35 | Input #2 - N | Line Neutral / N | 31 | 0 | > | 36 | Bank #4 | Branch Cir. L1/L2 | 31 | 1 | > | 37 | Outlet #13 | filer01-sjc-pwr2 | 36 | 1 | > | 38 | Outlet #14 | ... | 36 | 2 | > | 39 | Outlet #15 | ... | 36 | 3 | > | 40 | Outlet #16 | ... | 36 | 4 | > | 41 | Bank #5 | Branch Cir. L2/L3 | 31 | 2 | > | 42 | Outlet #17 | ... | 41 | 1 | > | 43 | Outlet #18 | ... | 41 | 2 | > | 44 | Outlet #19 | ... | 41 | 3 | > | 45 | Outlet #20 | ... | 41 | 4 | > | 46 | Bank #6 | Branch Cir. L3/L1 | 31 | 3 | > | 47 | Outlet #21 | ... | 46 | 1 | > | 48 | Outlet #22 | ... | 46 | 2 | > | 49 | Outlet #23 | ... | 46 | 3 | > | 50 | Outlet #24 | ... | 46 | 4 | > | 51 | Outlet Gang 1 | Finance Servers | 6 | 0 | > | 52 | Outlet Gang 2 | Sales Servers | 6 | 0 | > | 53 | VoIP Phone | VoIP/SIP Phone | 3 | 0 | > | 54 | Windows PC | John Smith's PC | 5 | 0 | > +-----+---------------+-------------------+-------------+--------------+ > > entLogicalTable > +-----+---------------+ > | Idx | Descr | > +-----+---------------+ > | 1 | Eth. Switch | > | 2 | Port 1 | > | 3 | Port 2 | > | 4 | Port 3 | > | 5 | Port 4 | > | 6 | ePower PDU | > | 7 | NIC | > | 8 | LCD | > | 9 | Processor | > | 10 | RTC Battery | > | 11 | Input #1 | > | 12 | Input #1 - L1 | > | 13 | Input #1 - L2 | > | 14 | Input #1 - L3 | > | 15 | Input #1 - N | > | 16 | Bank #1 | > | 17 | Outlet #1 | > | 18 | Outlet #2 | > | 19 | Outlet #3 | > | 20 | Outlet #4 | > | 21 | Bank #2 | > | 22 | Outlet #5 | > | 23 | Outlet #6 | > | 24 | Outlet #7 | > | 25 | Outlet #8 | > | 26 | Bank #3 | > | 27 | Outlet #9 | > | 28 | Outlet #10 | > | 29 | Outlet #11 | > | 30 | Outlet #12 | > | 31 | Input #2 | > | 32 | Input #2 - L1 | > | 33 | Input #2 - L2 | > | 34 | Input #2 - L3 | > | 35 | Input #2 - N | > | 36 | Bank #4 | > | 37 | Outlet #13 | > | 38 | Outlet #14 | > | 39 | Outlet #15 | > | 40 | Outlet #16 | > | 41 | Bank #5 | > | 42 | Outlet #17 | > | 43 | Outlet #18 | > | 44 | Outlet #19 | > | 45 | Outlet #20 | > | 46 | Bank #6 | > | 47 | Outlet #21 | > | 48 | Outlet #22 | > | 49 | Outlet #23 | > | 50 | Outlet #24 | > | 51 | Outlet Gang 1 | > | 52 | Outlet Gang 2 | > | 53 | VoIP Phone | > | 54 | Windows PC | > +-----+---------------+ > > entLPMappingTable > +------------+-------------+ > | LogicalIdx | PhysicalIdx | > +------------+-------------+ > | 51 | 22 | Outlet Gang #1 -> Outlet #5 > | 51 | 23 | -> Outlet #6 > | 51 | 24 | -> Outlet #7 > | 52 | 23 | Outlet Gang #2 -> Outlet #6 > | 52 | 37 | -> Outlet #13 > +------------+-------------+ Again, I think this is not a proper use of the entLogicalTable. > Questions that remain to be answered: > > 1. When an entity is disconnected/removed (like the ePower PDU being > disconnected from the switchport), what is the behavior related to > ENTITY-MIB? Are the entries removed and, if so, are the indices for the > remaining entries collapsed/adjusted to remove the gap? PhysicalIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An arbitrary value that uniquely identifies the physical entity. The value should be a small, positive integer. Index values for different physical entities are not necessarily contiguous." SYNTAX Integer32 (1..2147483647) > 2. What happens when an entity is reconnected (like the same ePower PDU > being connected to a different switchport), what is the behavior related > to ENTITY-MIB? Are the original indices reused? I assume this is implementation specific. > 3. How will an Energy Management System (EMS) or other NMS using this data > ensure that the data gathered and control mechanisms used are > universally guaranteed? Does a UUID or other form of identification > need to be created for an entity and, if so, how is that UUID exposed > via ENTITY-MIB? The entPhysicalTable has a number of columns providing identification information. It they are not sufficient and a UUID column is needed, then the entPhysicalTable can be easily augmented. > 4. How does this proposed use of ENTITY-MIB for EMAN's purposes relate to > the standard, existing use of ENTITY-MIB in the industry? This usages of entLogicalTable I believe is pretty much a non-standard usage of the ENTITY-MIB. The switches and routers supporting the ENTITY-MIB do not seem to use it in that way. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From chrisv@cyberswitching.com Mon Mar 7 04:37:29 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF58128C100 for ; Mon, 7 Mar 2011 04:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPYrdrZzNhUF for ; Mon, 7 Mar 2011 04:37:28 -0800 (PST) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by core3.amsl.com (Postfix) with ESMTP id 33A953A67A8 for ; Mon, 7 Mar 2011 04:37:28 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o142.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 1d1d47d4.0.1735.00-394.2915.p01c12o142.mxlogic.net (envelope-from ); Mon, 07 Mar 2011 05:38:42 -0700 (MST) X-MXL-Hash: 4d74d1d24b064aa2-e49a594476196d345f4cb3fe6474f15e5d0cc775 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 04:37:52 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id E90632F6001; Mon, 7 Mar 2011 04:38:40 -0800 (PST) Date: Mon, 7 Mar 2011 04:38:40 -0800 From: chrisv@cyberswitching.com To: Juergen Schoenwaelder Message-ID: <20110307123840.GA14024@cslinux-build01.cyberswitching.local> References: <20110306002733.GA14483@cslinux-build01.cyberswitching.local> <20110307094456.GC32101@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110307094456.GC32101@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 07 Mar 2011 12:37:53.0040 (UTC) FILETIME=[7A19C100:01CBDCC4] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=7W1J9WGJHY0A:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=wzgqfsuUAAAA:8 a=53m] X-AnalysisOut: [7hxIwmpdf7UVMCKwA:9 a=8nnPbSbC_EvNLDB_Q7IA:7 a=wfnvwZqMeWL] X-AnalysisOut: [axzOmbxJTgl6fgNIA:4 a=CjuIK1q_8ugA:10 a=yvfu_RGVus0A:10 a=] X-AnalysisOut: [VoCJHAQHqwzONA5J:21 a=lzxFZ6a76q6gGmOW:21] Cc: eman@ietf.org Subject: Re: [eman] Use of ENTITY-MIB in EMAN X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 12:37:30 -0000 Hi Juergen, Thank you for your reply and thoughts! Additional follow up questions are in-line with you responses. On Mon, Mar 07, 2011 at 10:44:56AM +0100, Juergen Schoenwaelder wrote: > On Sat, Mar 05, 2011 at 04:27:33PM -0800, chrisv@cyberswitching.com wrote: > > In the spirit of ENTITY-MIB, the "outlet gang" entities do not belong in > > entPhysicalTable, as they are virtual representations of a collection of > > outlets. Therefore, we will place them in entLogicalTable. > > > > entLogicalTable > > +-----+----------------+ > > | Idx | Descr | > > +-----+----------------+ > > | 1 | Outlet Gang #1 | > > | 2 | Outlet Gang #2 | > > +-----+----------------+ > > > > The logical entities can be mapped onto the physical entities by using > > entLPMappingTable. > > > > entLPMappingTable > > +------------+-------------+ > > | LogicalIdx | PhysicalIdx | > > +------------+-------------+ > > | 1 | 17 | Outlet Gang #1 -> Outlet #5 > > | 1 | 18 | -> Outlet #6 > > | 1 | 19 | -> Outlet #7 > > | 2 | 16 | Outlet Gang #2 -> Outlet #6 > > | 2 | 32 | -> Outlet #13 > > +------------+-------------+ > > I do not think this is a proper usage of entLogicalTable. The > entLogicalTable is used to refer to other SNMP contexts where > additional data resides. > > > The entire model is now implemented using ENTITY-MIB. However, there are some > > ramifications to this: > > > > 1. There is no single "index" that can be referenced for sparse tables in > > an EMAN MIB. The use of both entPhysicalTable and entLogicalTable means > > that separate indicies must be used, which results in separate EMAN > > tables for power data, control, etc. (one for physical entities, one for logical > > entities). > > > > 2. The structure of entPhysicalTable allows an entity to maintain a > > constant name (e.g., "Outlet #1") while changing an alias (e.g., > > "filer01-sjc-pwr1"). The structure of entLogicalTable does not allow > > the same behavior, so logical entities are naturally less feature > > capable. > > > > 3. None of the objects in ENTITY-MIB allow for 'read-create', so creating > > new "outlet gangs" would have to be supported by a third-party > > mechanism. While not critical to EMAN's needs, it is a major > > inconvenience for the various manufacturers who would benefit from such > > standard operation. > > > > One proposed solution on the mailing list for #1 is to duplicate all entries > > from entPhysicalTable in entLogicalTable. The resulting structure would allow > > a single index to be used (entLogicalIndex), but would not address item #2. > > This would be more wrong use of entLogicalTable. Agreed. Do you have a different proposal of how to structure things? > > One possible solution for #2 would be to list the virtual "outlet gangs" in > > entPhysicalTable as well as in entLogicalTable, but this violates the spirit > > behind entPhysicalTable as described in RFC4133. > > > > So both compromise solutions would need to be made in order to handle > > "virtual" entities like "outlet gangs" using ENTITY-MIB. > > How is an outlet gang different from a port module of a switch, except > that it allows out outlet to be in multiple outlet groups? The primary difference is that a port module on a switch is a physical entity that pre-defines the grouping. The outlet gang is a virtual entity that has an arbitrary grouping which is unrelated to the physical layout of the PDU. > > Questions that remain to be answered: > > > > 1. When an entity is disconnected/removed (like the ePower PDU being > > disconnected from the switchport), what is the behavior related to > > ENTITY-MIB? Are the entries removed and, if so, are the indices for the > > remaining entries collapsed/adjusted to remove the gap? > > PhysicalIndex ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "An arbitrary value that uniquely identifies the physical > entity. The value should be a small, positive integer. > Index values for different physical entities are not > necessarily contiguous." > SYNTAX Integer32 (1..2147483647) I apologize if I'm not understanding your answer properly. I understand the definition of PhysicalIndex, but are you saying that the entPhysicalIndex should not be adjusted? Therefore, new items connected to the switchport would be given new PhysicalIndex values? Would an agent be required to persist and reuse the IDs for a reconnected device? What if the reconnected device is plugged into a different switchport on the same switch? > > 2. What happens when an entity is reconnected (like the same ePower PDU > > being connected to a different switchport), what is the behavior related > > to ENTITY-MIB? Are the original indices reused? > > I assume this is implementation specific. What are the impacts on an EMS/BMS/NMS system if we leave such behavior unspecified? > > 3. How will an Energy Management System (EMS) or other NMS using this data > > ensure that the data gathered and control mechanisms used are > > universally guaranteed? Does a UUID or other form of identification > > need to be created for an entity and, if so, how is that UUID exposed > > via ENTITY-MIB? > > The entPhysicalTable has a number of columns providing identification > information. It they are not sufficient and a UUID column is needed, > then the entPhysicalTable can be easily augmented. So is a UUID needed? For example, if we disconnect a PDU from Switch #1 and connect it to Switch #2, should the EMS/BMS/NMS know that the PDU is the "same" PDU and has just moved connection points? > > 4. How does this proposed use of ENTITY-MIB for EMAN's purposes relate to > > the standard, existing use of ENTITY-MIB in the industry? > > This usages of entLogicalTable I believe is pretty much a non-standard > usage of the ENTITY-MIB. The switches and routers supporting the > ENTITY-MIB do not seem to use it in that way. The reason that entLogicalTable was used this way is to provide a mechanism to enable virtual, arbitrary groupings of non-physical entities as they relate to physical ones. Consider it similar to channel bonding (EtherChannel, Ethernet bonding, link aggregation, etc.) entPhysicalTable seems to not be the proper home for such virtual entities, and I'm hearing that entLogicalTable is also not the proper home. So what is? This is where there appears to be a gap, either in my understanding or in the limitations of ENTITY-MIB. Thanks, Chris From jparello@cisco.com Mon Mar 7 09:45:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95CC83A680E for ; Mon, 7 Mar 2011 09:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbLsLjfAgGzO for ; Mon, 7 Mar 2011 09:45:22 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A202A3A6926 for ; Mon, 7 Mar 2011 09:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=12672; q=dns/txt; s=iport; t=1299519996; x=1300729596; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=q5WSssoH9c1PG8YRqZ0V8POwiI2YsH3ZMLIN4RaTn7s=; b=X01o936F6eb/JHgKAHC2bl+eEmv7+1NKVc0mOAP15QySObxGQlmJ3/Y6 6+ONUSWk2Ek+eE9jdNfvaXhZMVFJg3kohAHR2k4j5cuWXAMMlH0WCmDqT At9mwVArk9grx9l8sUN7hJtyDPLM1Az8mf86I+5UbzrIdHx/AjQ7dmkaQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAOOodE2rRN+K/2dsb2JhbACCT5U4jkd0olabXYViBIUcil0 X-IronPort-AV: E=Sophos;i="4.62,278,1297036800"; d="scan'208,217";a="274327871" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 07 Mar 2011 17:46:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p27HkZhb007995 for ; Mon, 7 Mar 2011 17:46:35 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 09:46:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDCEF.9A4F5274" Date: Mon, 7 Mar 2011 09:45:53 -0800 Message-ID: In-Reply-To: <4D749432.4020306@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for Presentation slot... RE: [eman] Call for Agenda items for the EMAN open meeting in Prague Thread-Index: AcvcoGk1+yEE3IDPTcGrCmUJxHiucAASLPCQ References: <4D749432.4020306@cisco.com> From: "John Parello (jparello)" To: "Benoit Claise (bclaise)" , "eman mailing list" X-OriginalArrivalTime: 07 Mar 2011 17:46:35.0704 (UTC) FILETIME=[9A77FB80:01CBDCEF] Subject: [eman] Request for Presentation slot... RE: Call for Agenda items for the EMAN open meeting in Prague X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 17:45:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDCEF.9A4F5274 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Chairs, =20 I'd like to request a time slot (< 20 min?) to present similar work on Energy Awareness from the ODVA organization.=20 =20 The ODVA is a business league of Industrial automation manufacturing device makers. They specify and maintain the CIP protocol which is used to control manufacturing devices. They recently formed an energy SIG of which I am a member. =20 The SIG has proposed a class addition to CIP that calls for "Energy Awareness" in all manufacturing device and have come up with a data model and format for CIP. =20 I'd like to show the similarities to the IETF EMAN effort. The ODVA would like to see a consistent data model for energy awareness regardless of protocol (ie SNMP, CIP, MODBUS, PROFINET etc) =20 Three concepts they are taking from EMAN - Caliber rating, Parent/Child aggregation, Power States - with a general mantra of simple implementations for simple device. =20 I think it would be educational for the group to see how another group of electrical engineers (non IT) are modeling and responding to the same the same exact problem areas as EMAN. =20 More information at: =20 http://www.odva.org/Home/tabid/53/ctl/Details/mid/372/ItemID/74/lng/en-U S/language/en-US/Default.aspx =20 Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Benoit Claise (bclaise) Sent: Monday, March 07, 2011 12:16 AM To: eman mailing list Subject: [eman] Call for Agenda items for the EMAN open meeting in Prague =20 Dear all, Now that we have a final agenda... https://datatracker.ietf.org/meeting/80/agenda.html =20 https://datatracker.ietf.org/meeting/80/agenda.txt =20 http://www.ietf.org/meeting/80/index.html =20 If you plan to ask for presentation or discussion slots in the EMAN meeting in Prague, please send your requests to us.=20 Regards, Bruce and Benoit. ------_=_NextPart_001_01CBDCEF.9A4F5274 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Chairs,

 

I’d like to request a time slot (< 20 min?) to = present similar work on Energy Awareness from the ODVA organization. =

 

The ODVA  is a business league of Industrial = automation manufacturing device makers. They specify and maintain the CIP protocol which is used = to control manufacturing devices. They recently formed an energy SIG of = which I am a member.

 

The SIG has proposed a class addition to CIP that calls = for "Energy Awareness"  in all manufacturing device and have = come up with a data model and format for CIP.

 

I'd like to show the similarities to the IETF EMAN = effort. The ODVA would like to see a consistent data model for energy awareness = regardless of protocol (ie SNMP, CIP, MODBUS, PROFINET etc)

 

Three concepts they are taking from EMAN -  Caliber = rating, Parent/Child aggregation, Power States - with a general mantra of simple = implementations for simple device.

 

I think it would be educational for the group to see how = another group of electrical engineers (non IT) are modeling and responding to = the same the same exact problem areas as EMAN.

 

More information at:

 

http://www.odva.org/Home/tabid/53/c= tl/Details/mid/372/ItemID/74/lng/en-US/language/en-US/Default.aspx

 

Jp

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Benoit Claise = (bclaise)
Sent: Monday, March 07, 2011 12:16 AM
To: eman mailing list
Subject: [eman] Call for Agenda items for the EMAN open meeting = in Prague

 

Dear all,

Now that we have a final agenda...
  =   https://datatracker.ietf.org/meeting/80/agenda.html

    http://www.ietf.org/meeting/80/index.html
If you plan to ask for presentation or discussion slots in the EMAN
meeting in Prague, please send your requests to us.

Regards, Bruce and Benoit.

------_=_NextPart_001_01CBDCEF.9A4F5274-- From bnordman@lbl.gov Mon Mar 7 21:53:34 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F30C3A681F for ; Mon, 7 Mar 2011 21:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjWcQefg2OYg for ; Mon, 7 Mar 2011 21:53:32 -0800 (PST) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by core3.amsl.com (Postfix) with ESMTP id B42803A67E6 for ; Mon, 7 Mar 2011 21:53:32 -0800 (PST) X-Ironport-SBRS: 4.4 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwBAEdTdU3RVdQ0kGdsb2JhbACCT5V/AYYGAYd5CBUBAQEBCQkMBxEEIaMDmxaCfxmCSgSFHYcViF06 X-IronPort-AV: E=Sophos;i="4.62,283,1297065600"; d="scan'208";a="36367845" Received: from mail-vw0-f52.google.com ([209.85.212.52]) by ironport3.lbl.gov with ESMTP; 07 Mar 2011 21:54:46 -0800 Received: by mail-vw0-f52.google.com with SMTP id 20so5906124vws.39 for ; Mon, 07 Mar 2011 21:54:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.66.241 with SMTP id i17mr2439282vdt.285.1299563686097; Mon, 07 Mar 2011 21:54:46 -0800 (PST) Received: by 10.52.155.40 with HTTP; Mon, 7 Mar 2011 21:54:46 -0800 (PST) Date: Mon, 7 Mar 2011 21:54:46 -0800 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=20cf3079be0edf7316049df23f4b Subject: [eman] Applicability and Considerations X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 05:53:34 -0000 --20cf3079be0edf7316049df23f4b Content-Type: text/plain; charset=ISO-8859-1 (all of the following is as a contributor) I posted an I-D earlier today. It addresses the Applicability topic but is offered as a supplement to the other draft, and I would like to eventually merge their content. The draft I posted is rough and will be improved in the coming week, but this version shows an overall outline and tone (so any comments now most useful on the outline/tone - later on details). I am thinking that this is the document we should guide future readers to who are not literate in IETF; some will read further but many will only read this. The document also needs to fulfill its ordinary IETF applicability requirements. Rolf and I will post a revised Considerations document. Certainly the power state topic remains of concern here, as does the question of identity. I would like to request a modest amount of time on the agenda for these two drafts. Given the volume of discussion on other topics, 10 minutes is likely appropriate. --Bruce -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --20cf3079be0edf7316049df23f4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (all of the following is as a contributor)

I posted an I-D earlier t= oday.=A0 It addresses the Applicability topic but
is offered as a supple= ment to the other draft, and I would like to
eventually merge their con= tent.=A0 The draft I posted is rough and
will be improved in the coming week, but this version shows an
overall o= utline and tone (so any comments now most useful on
the outline/tone - l= ater on details).=A0 I am thinking that this is the
document we should g= uide future readers to who are not literate
in IETF; some will read further but many will only read this.
The docume= nt also needs to fulfill its ordinary IETF applicability
requirements.
Rolf and I will post a revised Considerations document.=A0 Certainly<= br> the power state topic remains of concern here, as does the question
of i= dentity.=A0

I would like to request a modest amount of time on the = agenda for
these two drafts.=A0 Given the volume of discussion on other = topics,
10 minutes is likely appropriate.

--Bruce

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

--20cf3079be0edf7316049df23f4b-- From moulchan@cisco.com Mon Mar 7 22:50:58 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B5F3A67F5 for ; Mon, 7 Mar 2011 22:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+O+-wI7LmzM for ; Mon, 7 Mar 2011 22:50:52 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CE4723A68EA for ; Mon, 7 Mar 2011 22:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=3135; q=dns/txt; s=iport; t=1299567123; x=1300776723; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QTCfrtgmfnnbQI1nayKtchK46RMGTiyvVjcjKfUyKdY=; b=fSzOjbXKwfYnmhNaRdswq+SPb547EKRsjWvyWA3TGgnussr05q86IOoY 4Sr4SUWSaHsJ4hZWw8hIYt7KdarCJn2AINR8sWfX3BFO6nFZLu5ZyRN4x bP69fZTkntl8SpU5TBTnO1fBnFrJuiEFuzz/qyST8PXwaUeHJ4/iCMVXn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAACtgdU2tJXG+/2dsb2JhbACYEo5GdKFrnCyFYgSFHYph X-IronPort-AV: E=Sophos;i="4.62,283,1297036800"; d="scan'208";a="223130367" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-1.cisco.com with ESMTP; 08 Mar 2011 06:52:02 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p286q2x5010722; Tue, 8 Mar 2011 06:52:02 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 00:52:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 00:52:00 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: eman] modeling power states - Entity-MIB Thread-Index: AcvaTs9V2fLo5po8QECEtKNufjkdfABxhOPgAFDRmEA= References: <174E5326-01EC-4641-8F3A-FF2C06D2024A@quittek.at><20110301050601.GA2638@cslinux-build01.cyberswitching.local><20110301102225.GB9233@elstar.local><51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at><20110301111548.GA9369@elstar.local><20110303195243.GC21657@elstar.local><0E32737B-484D-4263-9749-149E61601B03@quittek.at> From: "Mouli Chandramouli (moulchan)" To: "Romascanu, Dan (Dan)" , "Juergen Quittek" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 08 Mar 2011 06:52:03.0050 (UTC) FILETIME=[548E4CA0:01CBDD5D] Cc: eman mailing list Subject: [eman] eman] modeling power states - Entity-MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 06:50:59 -0000 Hello all,=20 If I recall, we had this discussion on the applicability of Entity-MIB at Anaheim - IETF77 meeting.=20 Here is my understanding and summary.=20 Clearly for power monitoring of network devices, it can be argued that Entity MIB should be almost sufficient.=20 In the requirements draft, http://tools.ietf.org/html/draft-ietf-eman-requirements-00 there is a requirement to collect power consumption as a system and also as a breakdown of subcomponents. There are sub-components of network devices that are not considered in Entity MIB RFC 4133 such as ASICs and Memory; i.e. if there is interest to measure power consumption of those components.=20 It has been observed in benchmarking studies that TCAMs in network devices are power hungry.=20 http://www.hpl.hp.com/personal/Partha_Ranganathan/papers/2009/2009_netwo rking_metrics.pdf The intent of the entity MIB is for a different purpose and now its current application is different. Given that physical devices can consume power; we are trying to reuse the entity-MIB as much as possible. Clearly, some of the physical components listed are quite handy from a power monitoring point of view - Chassis, power Supply, fan, module, port, cpu, stack etc. However, the value of assigning a power value to Unknown or Other (as a component) is not clear. =20 Beyond the Entity-MIB, LLDP-MED and RFC3621 provides power negotiation of PoE devices - between a network device (switch) and an attached device (phone).=20 An attempt has been made to reuse the pmLldpPortNumber in those scenario.=20 There are also network power monitoring scenarios, when the device is drawing power from a wall outlet or building HVAC devices and would not have entPhysicalIndex or pmLldpPortNumber. In those situations, we had proposed the use of pmIndex.=20 There was also a point made in the last WG meeting, power consumption of software components (not just physical components) should also be considered.=20 For e.g. an Email program on some platforms can consume power which can be noticed by the rate of battery drain.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Sunday, March 06, 2011 9:13 PM To: Juergen Quittek; Juergen Schoenwaelder Cc: eman mailing list Subject: Re: [eman] modeling power states =20 > -----Original Message----- > From: Juergen Quittek [mailto:ietf@quittek.at]=20 >=20 > I think Cisco has another example with PCs reporting their=20 > power to switches and the switches report it to the=20 > management system, but this can certainly be explained better=20 > by the people from Cisco. >=20 The standard version of this scheme is by implementing LLDP-MED (ANSI/TIA 1057) which is an extension of IEEE 802.1AB and has also defined a MIB to report on power and other characteristics of the remote devices directly connected to an Ethernet switch.=20 Dan _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From dromasca@avaya.com Tue Mar 8 02:01:01 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05093A67DA for ; Tue, 8 Mar 2011 02:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFZ4zAgExw-c for ; Tue, 8 Mar 2011 02:00:58 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id E95FD3A6774 for ; Tue, 8 Mar 2011 02:00:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAO6MdU2HCzI1/2dsb2JhbACCT5VEjip0pCcCmhWFYgSQEg X-IronPort-AV: E=Sophos;i="4.62,283,1297054800"; d="scan'208,217";a="62369317" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 08 Mar 2011 05:02:11 -0500 X-IronPort-AV: E=Sophos;i="4.62,283,1297054800"; d="scan'208,217";a="613040586" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Mar 2011 05:02:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDD77.DBFA4395" Date: Tue, 8 Mar 2011 11:01:55 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Request for Presentation slot... RE: Call for Agenda itemsfor the EMAN open meeting in Prague Thread-Index: AcvcoGk1+yEE3IDPTcGrCmUJxHiucAASLPCQACOdfHA= References: <4D749432.4020306@cisco.com> From: "Romascanu, Dan (Dan)" To: "John Parello (jparello)" , "Benoit Claise (bclaise)" , "eman mailing list" Subject: Re: [eman] Request for Presentation slot... RE: Call for Agenda itemsfor the EMAN open meeting in Prague X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 10:01:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDD77.DBFA4395 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, =20 > The ODVA would like to see a consistent data model for energy awareness regardless of protocol (ie SNMP, CIP, MODBUS, PROFINET etc) =20 In the IETF speech you may be talking about an Information Model. I recommend that you have a look at http://www.rfc-editor.org/rfc/rfc3444.txt . =20 Regards, =20 Dan =20 =20 ________________________________ From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello) Sent: Monday, March 07, 2011 7:46 PM To: Benoit Claise (bclaise); eman mailing list Subject: [eman] Request for Presentation slot... RE: Call for Agenda itemsfor the EMAN open meeting in Prague =09 =09 Hi Chairs, =20 I'd like to request a time slot (< 20 min?) to present similar work on Energy Awareness from the ODVA organization.=20 =20 The ODVA is a business league of Industrial automation manufacturing device makers. They specify and maintain the CIP protocol which is used to control manufacturing devices. They recently formed an energy SIG of which I am a member. =20 The SIG has proposed a class addition to CIP that calls for "Energy Awareness" in all manufacturing device and have come up with a data model and format for CIP. =20 I'd like to show the similarities to the IETF EMAN effort. The ODVA would like to see a consistent data model for energy awareness regardless of protocol (ie SNMP, CIP, MODBUS, PROFINET etc) =20 Three concepts they are taking from EMAN - Caliber rating, Parent/Child aggregation, Power States - with a general mantra of simple implementations for simple device. =20 I think it would be educational for the group to see how another group of electrical engineers (non IT) are modeling and responding to the same the same exact problem areas as EMAN. =20 More information at: =20 =09 http://www.odva.org/Home/tabid/53/ctl/Details/mid/372/ItemID/74/lng/en-U S/language/en-US/Default.aspx =20 Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Benoit Claise (bclaise) Sent: Monday, March 07, 2011 12:16 AM To: eman mailing list Subject: [eman] Call for Agenda items for the EMAN open meeting in Prague =20 Dear all, =09 Now that we have a final agenda... https://datatracker.ietf.org/meeting/80/agenda.html =20 https://datatracker.ietf.org/meeting/80/agenda.txt =20 http://www.ietf.org/meeting/80/index.html =20 If you plan to ask for presentation or discussion slots in the EMAN meeting in Prague, please send your requests to us.=20 =09 Regards, Bruce and Benoit. =09 =09 ------_=_NextPart_001_01CBDD77.DBFA4395 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 John,
 
> The ODVA would like to see a consistent data model for = energy=20 awareness regardless of protocol (ie SNMP, CIP, MODBUS, PROFINET=20 etc)
 
In the=20 IETF speech you may be talking about an Information Model. I = recommend that=20 you have a look at http://www.rfc-editor.org/rfc/rfc3444.txt.
 
Regards,
 
Dan
 
 

From: eman-bounces@ietf.org=20 [mailto:eman-bounces@ietf.org] On Behalf Of John Parello=20 (jparello)
Sent: Monday, March 07, 2011 7:46 = PM
To: Benoit=20 Claise (bclaise); eman mailing list
Subject: [eman] Request = for=20 Presentation slot... RE: Call for Agenda itemsfor the EMAN open = meeting in=20 Prague

Hi=20 Chairs,

 

I’d=20 like to request a time slot (< 20 min?) to present similar work on = Energy=20 Awareness from the ODVA organization.

 

The=20 ODVA  is a business league of Industrial automation manufacturing = device=20 makers. They specify and maintain the CIP protocol which is used to = control=20 manufacturing devices. They recently formed an energy SIG of which I = am a=20 member.

 

The=20 SIG has proposed a class addition to CIP that calls for "Energy = Awareness"=20  in all manufacturing device and have come up with a data model = and=20 format for CIP.

 

I'd=20 like to show the similarities to the IETF EMAN effort. The ODVA would = like to=20 see a consistent data model for energy awareness regardless of = protocol (ie=20 SNMP, CIP, MODBUS, PROFINET etc)

 

Three=20 concepts they are taking from EMAN -  Caliber rating, = Parent/Child=20 aggregation, Power States - with a general mantra of simple = implementations=20 for simple device.

 

I=20 think it would be educational for the group to see how another group = of=20 electrical engineers (non IT) are modeling and responding to the same = the same=20 exact problem areas as EMAN.

 

More=20 information at:

 

http://www.odva.org/Home/tabid/53/c= tl/Details/mid/372/ItemID/74/lng/en-US/language/en-US/Default.aspx

 

Jp

 

From:=20 eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of=20 Benoit Claise (bclaise)
Sent: Monday, March 07, 2011 = 12:16=20 AM
To: eman mailing list
Subject: [eman] Call for = Agenda=20 items for the EMAN open meeting in = Prague

 

Dear all,

Now that we have a final = agenda...
  =  =20 = https://datatracker.ietf.org/meeting/80/agenda.html

  &= nbsp;=20 = https://datatracker.ietf.org/meeting/80/agenda.txt

   =20 http://www.ietf.org/meeting/80/index.html
If you plan to ask = for=20 presentation or discussion slots in the EMAN
meeting in Prague, = please send=20 your requests to us.

Regards, Bruce and=20 Benoit.

------_=_NextPart_001_01CBDD77.DBFA4395-- From moulchan@cisco.com Tue Mar 8 02:07:17 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F6A3A6810 for ; Tue, 8 Mar 2011 02:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8JtezBpyd+x for ; Tue, 8 Mar 2011 02:07:02 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A902E3A67B8 for ; Tue, 8 Mar 2011 02:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=31896; q=dns/txt; s=iport; t=1299578897; x=1300788497; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=CvAvHTM097oX3syot2MgNGNo20vBvOdrSmhbl+gFGjc=; b=GnSdE7yZYSZ/ntQwJV20BOF168U3QB/zBouLADwCVmVb2hctXLrd2d2c 0pheQQ2lnJgMdroXbqbEYMI5N92QqlM9c4ZbjcI2PfgpIXjZ4uco7rRpM HeRx+qEy2Xcd5tCdJTYLlgCp8CpDqMZU87P8DHTS360OulunD156q1ZGc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAEaPdU2tJV2d/2dsb2JhbACCT5VEhkgBh2F0oXecSoMYgkoEhR2KYQ X-IronPort-AV: E=Sophos;i="4.62,283,1297036800"; d="scan'208,217";a="223550157" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 08 Mar 2011 10:07:58 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p28A7vtn019297; Tue, 8 Mar 2011 10:07:57 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 04:07:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDD78.B27E4688" Date: Tue, 8 Mar 2011 04:07:53 -0600 Message-ID: In-Reply-To: <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power States - really Thread-Index: AcvZGsBvbfQdrMTHReqRKgtITmE/OQEWv/XA References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" , "Benoit Claise (bclaise)" X-OriginalArrivalTime: 08 Mar 2011 10:07:57.0818 (UTC) FILETIME=[B2F18DA0:01CBDD78] Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 10:07:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDD78.B27E4688 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Juergen, =20 Firstly, Battery for a PC can be analogous to a UPS for a Data center. =20 During Power outages, UPS can provide power for the network elements in a Data center for a finite period of time.=20 =20 I think a solution to the question you have posed can be to decouple the device and the battery. =20 =20 As a first step, I think it would be useful to understand if the device is on direct power or on UPS/battery power - not sure if this has been captured in the MIB modules.=20 =20 If it is direct power, then we have the measurement variables defined.=20 If the device is on battery (or storage) power, it may be more useful to monitor the drain rate of the battery alone. =20 =20 Regarding the scenarios you have indicated, and if the device is switched-off (ACPI G3-S5 (Off-Hard)),=20 then power consumed is only for the battery charging. Device state is G3-S5 (Off-Hard), while the battery state is "Charging". =20 =20 So, if we consider the following equation,=20 =20 Power consumption of a device =3D power consumption from the grid + = power drained from storage/battery, in case power consumption from grid is zero, the power consumption of device is non-zero.=20 =20 Thanks Mouli =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Thursday, March 03, 2011 2:14 AM To: Benoit Claise (bclaise) Cc: eman mailing list; Bruce Nordman Subject: Re: [eman] Power States - really =20 Hi all, =20 Just a short question: =20 Which power state would apply to my notebook computer when =20 - it is switched of, but charging its batteries.=20 This is an off-state with relatively high power consumption.=20 Is this covered by any ACPI or DMTF states or by the states in the drafts we have? =20 - it is switched on and fully operational, but running on built-in battery only. This is an operational state with zero power consumption, at least as seen from outside. Again, how can we cover this with states described so far? =20 Thanks, =20 Juergen =20 =20 Am 02.03.2011 um 18:39 schrieb Benoit Claise: Dear all, In the industry, there are multiple series of power states: - The ACPI standard. In practice, mainly used for PCs in case of non operational power states - The DMTF Power State Management Profile defines an information model over web services. The DMTF has 6 power states, 5 of them non-operational. They merged all operational power states into a single one: "on". - Some manufacturers have their own power state series. And there is an attempt to define the EMAN states in the EMAN framework, which would be a new power states series, at least for the operational ones. In the world of PCs in case of non operational power states, ACPI seems well accepted. However, my point is the following: there is no clear winner in terms of adopted series of power state in the industry. I believe I would be dangerous to bet on power state series based on our knowledge today. The industry will decide, and maybe it will be a new power states series. What I believe the solution is in terms of EMAN: - we must be ready to support multiple power states series - we must be ready to support a new power states series.=20 - the device must report which power states series it supports In conclusion: be flexible and support all Regards, Benoit. I am reposting Juergen's email about power states. While the subsequent discussion has been important and useful, it is on a different topic. So, please let's also make progress on this topic. --Bruce On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: Dear all, We have two proposals for a Power/Energy MIB module: - draft-claise-energy-monitoring-mib-06 - draft-quittek-power-mib-02 Among the authors of both documents we are currently trying to merge them. But there are some open issues that should be discussed on the mailing list. Here is the probably biggest of them: modeling power states. For simplifying energy management we want to introduce the concept of power states (aka power levels). A power state will indicate roughly how much power a device consumes. Examples for simple power states are off, sleep, and operational states. In the envisioned EMAN MIB modules, a power state is characterized by a descriptive name and the device's expected power input in this state (max/min/average). Power states are not a new concept. The DMTF has already defined a set of power states and there is the Other standards bodies as the DMTF (Distributed Management Task Force) and there is the ACPI (Advanced Configuration and Power Interface) for PC motherboards. And there may be more than these out there. I listed some DMTF and ACPI states at the end of this message. An easy solution for EMAN would be just adopting one of these sets. However, there are issues with the ones we looked at. ACPI was developed for PC motherboards and is quite PC-centric. Also it defines states that seem to be superfluous, because so far, almost no one has implemented them. Also the DMTF model seems to have a narrower scope than envisioned by the EMAN WG. At some point in time, the EMAN WG hast to make a decision, which power state model to adopt. Here is a set of alternatives. The first four have fixed sets of power states. Option 1: fixed minimum Just support three power states (off, sleep (stand-by), operational) This has clear semantics, but there are several people claiming it's too restrictive. Option 2: fixed DMTF Just use the states defined by DMTF. Might be too much focussed n PCs. Option 3: fixed ACPI Just use the states defined by ACPI. Might be too much focussed n PCs. Option 4: fixed EMAN Define a new fixed set of power levels within the EMAN WG. Option 5: IANA-registered power states Have power states be registered at IANA. We would start with registering (off, sleep, operational, the DMTF set, and the ACPI set. Manufacturers can then register further ones. There has been discussions pointing out that these fixed sets may not be sufficient, particularly if non-IT equipment should also be covered. For being more open, the idea to support user-defined or manufacturer-defined power states of devices has been developed. In such a state, for example, certain components of a device may be switched off or put to sleep. Which ones are switched off in which state is to be defined by the user/operator/manufacturer and may be chosen such that operational needs are met. Again, there are several proposals how to do this. All of them favor a two-level approach that distinguishes between rather flexible functional power states and rather fixed basic power states. Functional power states would be defined by the manufacturer, operator, or user. These would be the power states that would be reported by a device. However, in order to better define the semantics of functional power states, Each of these would be mapped to exactly one basic power states. This means that a property of any functional state would be the basic state it maps to. Basic power states would be fixed, such as the ones used in options 1-5. An easy example would be functional power states defined by user/operator/manufacturer with each state indicating whether it is an off state, a sleep state or an operational state. Here are the corresponding options: Option 6: flexible functional states mapped to a fixed set of basic states States could be defined flexibly. But each state would indicate a basic state to which it corresponds. Basic states could be either basic (off/sleep/operational) or the DMTF set or the ACPI set Option 7: flexible functional states mapped to a IANA registered set of basic states This is like Option 6, but basic states would be registered at IANA and can be extended. We would register all DMTF and ACPI states and probably some more at IANA. Manufacturers could add more. Option 8: IANA-registered sets of functional states, only three basic states The main reasoning behind this option is that is should always be clear whether a power state is an off state, a sleep state, or an operational state. Therefore, only these three basic states are supported. This would be in line with an instance of Option 6. However, this option has an extension for the functional states. It suggests that for customizing devices in order to be compliant with given management systems, for example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. An example would be the DMTF states. We would register a flag at IANA that indicates we are using DMTF states only. This would signal the management application that all power state IDs are in line with power state numbering as defined by IANA. Analogously, ACPI and further sets could be registered at IANA. A fallback to Option 6 could be realized by registering a set number of 0 at IANA that does not impose any limit for functional states. Obviously, there are more possible options. If you think there is a better one, please send it to this list. I know this discussion is not easy, but we have to have it in order to make the right decision in the EMAN WG. Please take some time and think about what you consider to be the best way to go. And of course send questions on the issue. Thanks. Juergen DMTF (Distributed Management Task Force) power states: - 2 (Power On) - 3 (Sleep - Light) - 4 (Sleep - Deep) - 5 (Power Cycle (Off Soft)) - 6 (Power Off - Hard) - 7 (Hibernate) - 8 (Power Off - Soft) - 9 (Power Cycle (Off Hard)) - 10 (Master Bus Reset) - 11 (Diagnostic Interrupt (NMI)) - 12 (Power Off - Soft Graceful) - 13 (Power Off - Hard Graceful) - 14 (Master Bus Reset Graceful) - 15 (Power Cycle (Off - Soft Graceful)) - 16 (Power Cycle (Off - Hard Graceful)) ACPI (Advanced Configuration and Power Interface Specification) power states for PC motherboards: - G3-S5 (Off-Hard) - G2-S5 (Off-Soft) - G1-S4 (Hibernate) - G1-S3 (Sleep-Deep) - G1-S2 (Sleep-Light) - G1-S1 (Sleep-Light) - G0-S0-P5 - G0-S0-P4 - G0-S0-P3 - G0-S0-P2 - G0-S0-P2 - G0-S0-P2 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 =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 ------_=_NextPart_001_01CBDD78.B27E4688 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Juergen,

 

Firstly, Battery for a PC can be analogous to a UPS for a Data = center. 

During Power outages, UPS can provide power for the network elements = in a Data center for a finite period of time.

 

I think a solution to the question you have posed can be to decouple = the device and the battery.   

 

As a first step,  I think it would be useful to understand if = the device is on direct power or on UPS/battery power – not sure = if this has been captured in the MIB modules.

 

If it is direct power, then we have the measurement variables = defined.

If the device is on battery (or storage) power, it may be more useful = to monitor the drain rate of the  battery alone. =  

 

Regarding the scenarios you have indicated,  and if the device = is switched-off (ACPI G3-S5 (Off-Hard)),

then power consumed is only for the battery charging.  Device = state is G3-S5 (Off-Hard), while the battery state is = “Charging”.    

 

So, if we consider the following equation,

 

Power consumption of a device =3D power consumption from the grid + = power drained from storage/battery,

in case power consumption from grid is zero, the power consumption = of  device is non-zero.

 

Thanks

Mouli

 

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek
Sent: Thursday, March 03, 2011 2:14 = AM
To: Benoit Claise (bclaise)
Cc: eman mailing = list; Bruce Nordman
Subject: Re: [eman] Power States - = really

 

Hi = all,

 

Just a = short question:

 

Which power state would apply to my notebook computer = when

 

  - it is switched of, but charging its = batteries. 

    This is an off-state with = relatively high power consumption. 

    Is this covered by any ACPI or DMTF = states or by the states in the drafts we = have?

 

  - it is switched on and fully operational, = but running on built-in battery only.

    This is an operational state with = zero power consumption, at least as seen from = outside.

   =  Again, how can we cover this with states described so = far?

 

Thanks,

 

    Juergen

 

 

Am = 02.03.2011 um 18:39 schrieb Benoit Claise:



Dear = all,

In the industry, there are multiple series of power = states:
-  The ACPI standard. In practice, mainly used for PCs = in case of non operational power states
-  The DMTF Power State = Management Profile defines an information model over web services. The = DMTF has 6 power states, 5 of them non-operational. They merged all = operational power states into a single one: "on".
- Some = manufacturers have their own power state series.

And there is an = attempt to define the EMAN states in the EMAN framework, which would be = a new power states series, at least for the operational ones.

In = the world of PCs in case of non operational power states, ACPI seems = well accepted.
However, my point is the following: there is no clear = winner in terms of adopted series of power state in the industry.
I = believe I would be dangerous to bet on power state series based on our = knowledge today. The industry will decide, and maybe it will be a new = power states series.

What I believe the solution is in terms of = EMAN:
- we must be ready to support multiple power states series
- = we must be ready to support a new power states series.
- the device = must report which power states series it supports
In conclusion: be = flexible and support all

Regards, = Benoit.


I am reposting Juergen's email about = power states.
While the subsequent discussion has been = important
and useful, it is on a different topic.  So, please = let's
also make progress on this = topic.
--Bruce

On Mon, Feb = 28, 2011 at 4:07 AM, Juergen Quittek <Quittek@neclab.eu> = wrote:

Dear all,

We have two = proposals for a Power/Energy MIB module:

 - = draft-claise-energy-monitoring-mib-06
 - = draft-quittek-power-mib-02

Among the authors of both documents we = are currently trying to merge them.
But there are some open issues = that should be discussed on the mailing
list.  Here is the = probably biggest of them: modeling power states.

For simplifying = energy management we want to introduce the concept of
power states = (aka power levels).  A power state will indicate roughly = how
much power a device consumes.  Examples for simple power = states are off,
sleep, and operational states.

In the = envisioned EMAN MIB modules, a power state is characterized by = a
descriptive name and the device's expected power input in this = state
(max/min/average).

Power states are not a new concept. =  The DMTF has already defined a set of
power states and there is = the Other standards bodies as the DMTF
(Distributed Management Task = Force) and there  is the ACPI (Advanced
Configuration and Power = Interface) for PC motherboards.  And there may be
more than = these out there.  I listed some DMTF and ACPI states at the = end
of this message.

An easy solution for EMAN would be just = adopting one of these sets.
However, there are issues with the ones = we looked at.  ACPI was developed
for PC motherboards and is = quite PC-centric.  Also it defines states that
seem to be = superfluous, because so far, almost no one has implemented
them. =  Also the DMTF model seems to have a narrower scope than = envisioned
by the EMAN WG.

At some point in time, the EMAN WG = hast to make a decision, which power
state model to adopt.  Here = is a set of alternatives. The first four have
fixed sets of power = states.

Option 1: fixed minimum
Just support three power = states (off, sleep (stand-by), operational)
This has clear semantics, = but there are several people claiming it's = too
restrictive.

Option 2: fixed DMTF
Just use the states = defined by DMTF.
Might be too much focussed n PCs.

Option 3: = fixed ACPI
Just use the states defined by ACPI.
Might be too much = focussed n PCs.



Option 4: fixed EMAN
Define a new = fixed set of power levels within the EMAN WG.

Option 5: = IANA-registered power states
Have power states be registered at = IANA.
We would start with registering (off, sleep, operational, the = DMTF set,
and the ACPI set.
Manufacturers can then register = further ones.


There has been discussions pointing out that = these fixed sets may not be
sufficient, particularly if non-IT = equipment should also be covered.

For being more open, the idea = to support user-defined or
manufacturer-defined power states of = devices has been developed.  In such
a state, for example, = certain components of a device may be switched off
or put to sleep. =  Which ones are switched off in which state is to be
defined by = the user/operator/manufacturer and may be chosen such = that
operational needs are met.

Again, there are several = proposals how to do this.  All of them favor a
two-level = approach that distinguishes between rather flexible functional
power = states and rather fixed basic power states.  Functional power = states
would be defined by the manufacturer, operator, or user. =  These would be
the power states that would be reported by a = device.  However, in order to
better define the semantics of = functional power states, Each of these
would be mapped to exactly one = basic power states.  This means that a
property of any = functional state would be the basic state it maps to.
Basic power = states would be fixed, such as the ones used in options 1-5.
An easy = example would be functional power states defined = by
user/operator/manufacturer with each state indicating whether it = is an off
state, a sleep state or an operational state.

Here = are the corresponding options:

Option 6: flexible functional = states mapped to a fixed set of basic states
States could be defined = flexibly.  But each state would indicate a basic
state to which = it corresponds. Basic states could be either = basic
(off/sleep/operational) or the DMTF set or the ACPI = set

Option 7: flexible functional states mapped to a IANA = registered set of
basic states
This is like Option 6, but basic = states would be registered at IANA and
can be extended.  We = would register all DMTF and ACPI states and probably
some more at = IANA. Manufacturers could add more.

Option 8: IANA-registered = sets of functional states, only three basic
states
The main = reasoning behind this option is that is should always be = clear
whether a power state is an off state, a sleep state, or an = operational
state.  Therefore, only these three basic states are = supported.  This
would be in line with an instance of Option 6. =  However, this option has
an extension for the functional = states.  It suggests that for customizing
devices in order to be = compliant with given management systems, for
example a DMTF-based = system, it should be possible to restrict functional
power states to = a given set that is registered at IANA.  An example would
be the = DMTF states.  We would register a flag at IANA that indicates = we
are using DMTF states only.  This would signal the management = application
that all power state IDs are in line with power state = numbering as defined
by IANA.  Analogously, ACPI and further = sets could be registered at IANA.
A fallback to Option 6 could be = realized by registering a set number of 0
at IANA that does not = impose any limit for functional states.

Obviously, there are more = possible options.  If you think there is a
better one, please = send it to this list.

I know this discussion is not easy, but we = have to have it in order to
make the right decision in the EMAN WG. =  Please take some time and think
about what you consider to be = the best way to go.  And of course send
questions on the = issue.

Thanks.

   Juergen


DMTF = (Distributed Management Task Force) power states:
 - 2 (Power = On)
 - 3 (Sleep - Light)
 - 4 (Sleep - Deep)
 - = 5 (Power Cycle (Off Soft))
 - 6 (Power Off - Hard)
 - 7 = (Hibernate)
 - 8 (Power Off - Soft)
 - 9 (Power Cycle = (Off Hard))
 - 10 (Master Bus Reset)
 - 11 (Diagnostic = Interrupt (NMI))
 - 12 (Power Off - Soft Graceful)
 - 13 = (Power Off - Hard Graceful)
 - 14 (Master Bus Reset = Graceful)
 - 15 (Power Cycle (Off - Soft Graceful))
 - = 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced = Configuration and Power Interface Specification) power
states for PC = motherboards:
 - G3-S5 (Off-Hard)
 - G2-S5 = (Off-Soft)
 - G1-S4 (Hibernate)
 - G1-S3 = (Sleep-Deep)
 - G1-S2 (Sleep-Light)
 - G1-S1 = (Sleep-Light)
 - G0-S0-P5
 - G0-S0-P4
 - = G0-S0-P3
 - G0-S0-P2
 - G0-S0-P2
 - = G0-S0-P2




_____________________________________________= __
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman




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


 
_=
______________________________________________
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

 

------_=_NextPart_001_01CBDD78.B27E4688-- From j.schoenwaelder@jacobs-university.de Tue Mar 8 03:34:18 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB0C3A6857 for ; Tue, 8 Mar 2011 03:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.132 X-Spam-Level: X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUgqw1Z1+CX0 for ; Tue, 8 Mar 2011 03:34:16 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 839993A67DA for ; Tue, 8 Mar 2011 03:34:16 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0186C0079; Tue, 8 Mar 2011 12:35:30 +0100 (CET) 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 yIRtssg8de2b; Tue, 8 Mar 2011 12:35:29 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54797C0008; Tue, 8 Mar 2011 12:35:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4ED0116E492A; Tue, 8 Mar 2011 12:35:22 +0100 (CET) Date: Tue, 8 Mar 2011 12:35:22 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110308113521.GB36852@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, eman@ietf.org References: <20110306002733.GA14483@cslinux-build01.cyberswitching.local> <20110307094456.GC32101@elstar.local> <20110307123840.GA14024@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110307123840.GA14024@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] Use of ENTITY-MIB in EMAN X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 11:34:18 -0000 On Mon, Mar 07, 2011 at 04:38:40AM -0800, chrisv@cyberswitching.com wrote: [...] > Agreed. Do you have a different proposal of how to structure things? Concerning outlet gangs, which seem to be a pure logical aggregation unit as far as I understand things, I would start by asking why they need to be represented on the device in the first place since aggregation can easily be done in flexible ways outside the devices. If outlet gangs need to be represented on devices, the question pops up how they are created. I have not seen that in any of the MIBs either (but I might have overlooked this). > > How is an outlet gang different from a port module of a switch, except > > that it allows out outlet to be in multiple outlet groups? > > The primary difference is that a port module on a switch is a physical > entity that pre-defines the grouping. The outlet gang is a virtual > entity that has an arbitrary grouping which is unrelated to the physical > layout of the PDU. OK > > > Questions that remain to be answered: > > > > > > 1. When an entity is disconnected/removed (like the ePower PDU being > > > disconnected from the switchport), what is the behavior related to > > > ENTITY-MIB? Are the entries removed and, if so, are the indices for the > > > remaining entries collapsed/adjusted to remove the gap? > > > > PhysicalIndex ::= TEXTUAL-CONVENTION > > DISPLAY-HINT "d" > > STATUS current > > DESCRIPTION > > "An arbitrary value that uniquely identifies the physical > > entity. The value should be a small, positive integer. > > Index values for different physical entities are not > > necessarily contiguous." > > SYNTAX Integer32 (1..2147483647) > > I apologize if I'm not understanding your answer properly. I understand > the definition of PhysicalIndex, but are you saying that the > entPhysicalIndex should not be adjusted? yes > Therefore, new items connected > to the switchport would be given new PhysicalIndex values? yes > Would an > agent be required to persist and reuse the IDs for a reconnected device? This does not seem to be clearly spelled out. Since the physical component carries information about itself, I would assume that it is OK to simply allocate a index. I currently do not have access to a hot pluggable device implementing the ENTITY-MIB to check what implementations actually do. > What if the reconnected device is plugged into a different switchport on > the same switch? The ENTITY-MIB requires that values such as the entPhysicalAssetID are retained. If write access is implemented for an instance of entPhysicalAssetID, and a value is written into the instance, the agent must retain the supplied value in the entPhysicalAssetID instance (associated with the same physical entity) for as long as that entity remains instantiated. This includes instantiations across all re-initializations/reboots of the network management system, including those resulting in a change of the physical entity's entPhysicalIndex value. This makes me assume that the index value can change, but the properties of a physical entity should remain. > > > 2. What happens when an entity is reconnected (like the same ePower PDU > > > being connected to a different switchport), what is the behavior related > > > to ENTITY-MIB? Are the original indices reused? > > > > I assume this is implementation specific. > > What are the impacts on an EMS/BMS/NMS system if we leave such behavior > unspecified? I assume that the idea properties of a physical entity persist. While this is not spelled out in the DESCRIPTION of entPhysicalUris, there is text in section 2.12.1. that states: [...] Uniform Resource Names (URNs), RFC 3406 [RFC3406], are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference. > > > 3. How will an Energy Management System (EMS) or other NMS using this data > > > ensure that the data gathered and control mechanisms used are > > > universally guaranteed? Does a UUID or other form of identification > > > need to be created for an entity and, if so, how is that UUID exposed > > > via ENTITY-MIB? > > > > The entPhysicalTable has a number of columns providing identification > > information. It they are not sufficient and a UUID column is needed, > > then the entPhysicalTable can be easily augmented. > > So is a UUID needed? For example, if we disconnect a PDU from Switch #1 > and connect it to Switch #2, should the EMS/BMS/NMS know that the PDU is > the "same" PDU and has just moved connection points? Note that entPhysicalUris can carry UUID URNs (see RFC 4122). > > > 4. How does this proposed use of ENTITY-MIB for EMAN's purposes relate to > > > the standard, existing use of ENTITY-MIB in the industry? > > > > This usages of entLogicalTable I believe is pretty much a non-standard > > usage of the ENTITY-MIB. The switches and routers supporting the > > ENTITY-MIB do not seem to use it in that way. > > The reason that entLogicalTable was used this way is to provide a > mechanism to enable virtual, arbitrary groupings of non-physical > entities as they relate to physical ones. Consider it similar to > channel bonding (EtherChannel, Ethernet bonding, link aggregation, etc.) > > entPhysicalTable seems to not be the proper home for such virtual > entities, and I'm hearing that entLogicalTable is also not the proper > home. So what is? This is where there appears to be a gap, either in > my understanding or in the limitations of ENTITY-MIB. Yes, the ENTITY-MIB does not support arbitrary logical groupings. If this is needed, such a grouping mechanism would have to be added. But also consider the question whether this really needs to be on the device. The ENERGY-AWARE-MIB seems to instead just tag entities and leaves the interpretation of the groups created by tagging to an application. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Mar 8 05:51:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137253A68CC for ; Tue, 8 Mar 2011 05:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.137 X-Spam-Level: X-Spam-Status: No, score=-103.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIb3C4Hei-9F for ; Tue, 8 Mar 2011 05:51:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AB6723A68A7 for ; Tue, 8 Mar 2011 05:51:23 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 370FCC0078; Tue, 8 Mar 2011 14:52:38 +0100 (CET) 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 HQIGa2g0iiXW; Tue, 8 Mar 2011 14:52:37 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3954C001A; Tue, 8 Mar 2011 14:52:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B277616E4D8C; Tue, 8 Mar 2011 14:52:30 +0100 (CET) Date: Tue, 8 Mar 2011 14:52:30 +0100 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20110308135228.GA37400@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , "Romascanu, Dan (Dan)" , Juergen Quittek , eman mailing list References: <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> <0E32737B-484D-4263-9749-149E61601B03@quittek.at> 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 mailing list Subject: Re: [eman] eman] modeling power states - Entity-MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 13:51:30 -0000 On Tue, Mar 08, 2011 at 12:52:00AM -0600, Mouli Chandramouli (moulchan) wrote: > If I recall, we had this discussion on the applicability of Entity-MIB > at Anaheim - IETF77 meeting. Let me start by explaining my involvement in this discussion: I am not pushing for the ENTITY-MIB as _the_ solution for EMAN. All I am looking for is that the design decision is taken well informed and that the decision subsequently is well documented. What caused me to speak up on this list was some confusion I think some people seemed to have about some of the features of the ENTITY-MIB and the lack of any text in the documents explaining how EMAN objects relates to the ENTITY-MIB. Of course, now I am also playing a bit devil's advocate in order to make sure any possible reasons to not extend the ENTITY-MIB are becoming clear. > Here is my understanding and summary. > > Clearly for power monitoring of network devices, it can be argued that > Entity MIB should be almost sufficient. > In the requirements draft, > http://tools.ietf.org/html/draft-ietf-eman-requirements-00 there is a > requirement to collect power consumption as a system and also as a > breakdown of subcomponents. There are sub-components of network devices > that are not considered in Entity MIB RFC 4133 such as ASICs and Memory; > i.e. if there is interest to measure power consumption of those > components. > It has been observed in benchmarking studies that TCAMs in network > devices are power hungry. > http://www.hpl.hp.com/personal/Partha_Ranganathan/papers/2009/2009_netwo > rking_metrics.pdf > > The intent of the entity MIB is for a different purpose and now its > current application is different. Given that physical devices can > consume power; we are trying to reuse the entity-MIB as much as > possible. Clearly, some of the physical components listed are quite > handy from a power monitoring point of view - Chassis, power Supply, > fan, module, port, cpu, stack etc. However, the value of assigning a > power value to Unknown or Other (as a component) is not clear. I agree that the PhysicalClass TC should have been under IANA control to enable extensibility. On the other hand, I have not seen anything in the EMAN MIB proposals that is not also in the ENTITY-MIB. In fact, most EMAN MIBs seem to use simple SnmpAdminStrings, which enables a great deal of flexibility but also makes automation hard if every vendor can label components in arbitrary ways. In other words, the ENTITY-MIB even today is not "worse" than the other proposals (correct me if I am missing something) and it could be fixed by moving the PhysicalClass TC under IANA control. > Beyond the Entity-MIB, LLDP-MED and RFC3621 provides power > negotiation of PoE devices - between a network device (switch) and > an attached device (phone). An attempt has been made to reuse the > pmLldpPortNumber in those scenario. The entAliasMappingTable provides an extensible set of pointers to other MIB table entries that may even exist in other logial entities (contexts). I am not familiar with pmLldpPortNumber, so I am not sure what exactly this is. But existing devices use this mechanism already to relate "port" physical entities to network interfaces. For me, it is most important that relationships between number spaces are well documented so that it is clear how management applications can relate the bits and pieces they get from various MIB modules. And with every additional number space, the pain on the manager side usually increases (and on the device itself unless the devices chooses to not provide the relevant mapping information). > There are also network power monitoring scenarios, when the device is > drawing power from a wall outlet or building HVAC devices and would not > have entPhysicalIndex or pmLldpPortNumber. In those situations, we had > proposed the use of pmIndex. Why do these devices not have entPhysicalIndex or why can't they have an entPhysicalIndex? We do have wirelesse sensor nodes and they do manage to report an entPhysicalIndex. > There was also a point made in the last WG meeting, power > consumption of software components (not just physical components) > should also be considered. For e.g. an Email program on some > platforms can consume power which can be noticed by the rate of > battery drain. But you can't really measure this. People proposing something like this likely measure the physical component's power consumption and relate it to running software and its CPU usage via some magic formula. It is not clear to me that this is necessarily expected to be done and reported via an SNMP agent. If you export the power consumption readings of your physical devices to a management system, you can calculate whatever seems useful off the devices and in much more flexible ways. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From chrisv@cyberswitching.com Tue Mar 8 07:15:48 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0403A689A for ; Tue, 8 Mar 2011 07:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFNf0eN8CW5N for ; Tue, 8 Mar 2011 07:15:47 -0800 (PST) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by core3.amsl.com (Postfix) with ESMTP id 00FD13A67C1 for ; Tue, 8 Mar 2011 07:15:46 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o144.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id d68467d4.0.1610.00-393.3799.p01c11o144.mxlogic.net (envelope-from ); Tue, 08 Mar 2011 08:17:02 -0700 (MST) X-MXL-Hash: 4d76486e4df1be9f-4dc5ea2607b305393922c45911bfa296e4784078 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 07:16:00 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 665AE2F6001; Tue, 8 Mar 2011 07:17:01 -0800 (PST) Date: Tue, 8 Mar 2011 07:17:01 -0800 From: chrisv@cyberswitching.com To: Juergen Schoenwaelder Message-ID: <20110308151701.GA11979@cslinux-build01.cyberswitching.local> References: <20110306002733.GA14483@cslinux-build01.cyberswitching.local> <20110307094456.GC32101@elstar.local> <20110307123840.GA14024@cslinux-build01.cyberswitching.local> <20110308113521.GB36852@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110308113521.GB36852@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 08 Mar 2011 15:16:00.0095 (UTC) FILETIME=[BB3D36F0:01CBDDA3] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=7W1J9WGJHY0A:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=wzgqfsuUAAAA:8 a=2qu] X-AnalysisOut: [iQT0Q5xggbaXhTEgA:9 a=XeCOud4CJGayST5SHgAA:7 a=u6AsR3UaqtQ] X-AnalysisOut: [QNd5Xp771f_iPI40A:4 a=CjuIK1q_8ugA:10 a=yvfu_RGVus0A:10 a=] X-AnalysisOut: [41xCivgK4zD6t8OO:21 a=MoFcWJj-EjSIrc2j:21] Cc: eman@ietf.org Subject: Re: [eman] Use of ENTITY-MIB in EMAN X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 15:15:48 -0000 Hi Juergen, Thanks for the feedback. I'll roll it up into a new revision of the eman-relationship-to-entity-mib document. Some addition answers/questions inline: On Tue, Mar 08, 2011 at 12:35:22PM +0100, Juergen Schoenwaelder wrote: > On Mon, Mar 07, 2011 at 04:38:40AM -0800, chrisv@cyberswitching.com wrote: > > [...] > > > Agreed. Do you have a different proposal of how to structure things? > > Concerning outlet gangs, which seem to be a pure logical aggregation > unit as far as I understand things, I would start by asking why they > need to be represented on the device in the first place since > aggregation can easily be done in flexible ways outside the devices. > If outlet gangs need to be represented on devices, the question pops > up how they are created. I have not seen that in any of the MIBs > either (but I might have overlooked this). Yes, they need to be represented on the device itself. The ganging concept can be enabled from many vendors' HTTP/CLI interfaces. If we can expose these logically created entities over SNMP, it means less duplication of effort for the send user to setup these entities again in the EMS/BMS/NMS. > > > > Questions that remain to be answered: > > > > > > > > 1. When an entity is disconnected/removed (like the ePower PDU being > > > > disconnected from the switchport), what is the behavior related to > > > > ENTITY-MIB? Are the entries removed and, if so, are the indices for the > > > > remaining entries collapsed/adjusted to remove the gap? > > > > > > PhysicalIndex ::= TEXTUAL-CONVENTION > > > DISPLAY-HINT "d" > > > STATUS current > > > DESCRIPTION > > > "An arbitrary value that uniquely identifies the physical > > > entity. The value should be a small, positive integer. > > > Index values for different physical entities are not > > > necessarily contiguous." > > > SYNTAX Integer32 (1..2147483647) > > > > I apologize if I'm not understanding your answer properly. I understand > > the definition of PhysicalIndex, but are you saying that the > > entPhysicalIndex should not be adjusted? > > yes So what begs the question of what to do when we hit the maximum value (2147483647) as we constantly count up. Do we roll over to zero again? If we're adding in a whole collection of entities, like the 30+ rows required for a PDU, and the max value would fall in the middle of the 30+ row group, should we count up to the max value and THEN rollover; or should we rollover first and find a contiugous block to use? > > Would an > > agent be required to persist and reuse the IDs for a reconnected device? > > This does not seem to be clearly spelled out. Since the physical > component carries information about itself, I would assume that it is > OK to simply allocate a index. I currently do not have access to a hot > pluggable device implementing the ENTITY-MIB to check what > implementations actually do. > > > What if the reconnected device is plugged into a different switchport on > > the same switch? > > The ENTITY-MIB requires that values such as the entPhysicalAssetID are > retained. > > If write access is implemented for an instance of > entPhysicalAssetID, and a value is written into the > instance, the agent must retain the supplied value in the > entPhysicalAssetID instance (associated with the same > physical entity) for as long as that entity remains > instantiated. This includes instantiations across all > re-initializations/reboots of the network management system, > including those resulting in a change of the physical > entity's entPhysicalIndex value. > > This makes me assume that the index value can change, but the > properties of a physical entity should remain. > > > > > 2. What happens when an entity is reconnected (like the same ePower PDU > > > > being connected to a different switchport), what is the behavior related > > > > to ENTITY-MIB? Are the original indices reused? > > > > > > I assume this is implementation specific. > > > > What are the impacts on an EMS/BMS/NMS system if we leave such behavior > > unspecified? > > I assume that the idea properties of a physical entity persist. While > this is not spelled out in the DESCRIPTION of entPhysicalUris, there > is text in section 2.12.1. that states: > > [...] Uniform Resource Names (URNs), RFC > 3406 [RFC3406], are resource identifiers with the specific > requirements for enabling location independent identification of a > resource, as well as longevity of reference. > > > > > 3. How will an Energy Management System (EMS) or other NMS using this data > > > > ensure that the data gathered and control mechanisms used are > > > > universally guaranteed? Does a UUID or other form of identification > > > > need to be created for an entity and, if so, how is that UUID exposed > > > > via ENTITY-MIB? > > > > > > The entPhysicalTable has a number of columns providing identification > > > information. It they are not sufficient and a UUID column is needed, > > > then the entPhysicalTable can be easily augmented. > > > > So is a UUID needed? For example, if we disconnect a PDU from Switch #1 > > and connect it to Switch #2, should the EMS/BMS/NMS know that the PDU is > > the "same" PDU and has just moved connection points? > > Note that entPhysicalUris can carry UUID URNs (see RFC 4122). So it sounds like all of the questions in the above quoted block are answered by using entPhysicalUris to carry a UUID for the entity in question. This allows us to vary the entPhysicalIndex arbitrarily, but gives the EMS/BMS/NMS a constant identifier for the entity. > > > > 4. How does this proposed use of ENTITY-MIB for EMAN's purposes relate to > > > > the standard, existing use of ENTITY-MIB in the industry? > > > > > > This usages of entLogicalTable I believe is pretty much a non-standard > > > usage of the ENTITY-MIB. The switches and routers supporting the > > > ENTITY-MIB do not seem to use it in that way. > > > > The reason that entLogicalTable was used this way is to provide a > > mechanism to enable virtual, arbitrary groupings of non-physical > > entities as they relate to physical ones. Consider it similar to > > channel bonding (EtherChannel, Ethernet bonding, link aggregation, etc.) > > > > entPhysicalTable seems to not be the proper home for such virtual > > entities, and I'm hearing that entLogicalTable is also not the proper > > home. So what is? This is where there appears to be a gap, either in > > my understanding or in the limitations of ENTITY-MIB. > > Yes, the ENTITY-MIB does not support arbitrary logical groupings. If > this is needed, such a grouping mechanism would have to be added. But > also consider the question whether this really needs to be on the > device. The ENERGY-AWARE-MIB seems to instead just tag entities and > leaves the interpretation of the groups created by tagging to an > application. I'm not the biggest fan of the current ENERGY-AWARE-MIB proposed in draft-ietf-eman-energy-aware-mib-00. So that argument won't hold much weight. :-) As I indicated above, I do think that outlet groups should be supported on a device. It's a question of whether we want to simplify complexity. Consider the following scenario: An outlet gang has two three-phase AC outlets in it. One of the outlets is wired as a 3PH Wye (line-neutral) and the other as a 3PH Delta (line-line). To "gang" these two outlets together for data reporting purposes requires a mathematical technique known as symmetric component analysis. The 3PH Delta entity must be converted to the 3PH Wye equivalent, and then the two vector tuples can be combined. An EMS/BMS/NMS administrator should never try to figure this out on their own. It's a fairly complex process, and definitely part of a specific domain of knowledge that is unknown to many network administrators. Therefore, we should let the equipment manufacturer who has that specialized knowledge do all of the "heavy lifting" and just simply expose the solution to the user as a logical entity. Thanks, Chris From chrisv@cyberswitching.com Tue Mar 8 07:52:59 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F61C3A68D6 for ; Tue, 8 Mar 2011 07:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.666 X-Spam-Level: X-Spam-Status: No, score=-5.666 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, FRT_LITTLE=1.555, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZHwTnhrLLPx for ; Tue, 8 Mar 2011 07:52:56 -0800 (PST) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by core3.amsl.com (Postfix) with ESMTP id 43D7F3A67D8 for ; Tue, 8 Mar 2011 07:52:55 -0800 (PST) Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c11o149.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 021567d4.0.8878.00-381.21250.p01c11o149.mxlogic.net (envelope-from ); Tue, 08 Mar 2011 08:54:10 -0700 (MST) X-MXL-Hash: 4d7651221d68c406-25b591ce76a72e65872893ef6344a8375f876667 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 07:53:03 -0800 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 9DEC02F6001; Tue, 8 Mar 2011 07:54:05 -0800 (PST) Date: Tue, 8 Mar 2011 07:54:05 -0800 From: chrisv@cyberswitching.com To: eman@ietf.org Message-ID: <20110308155405.GA12027@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 08 Mar 2011 15:53:04.0022 (UTC) FILETIME=[E8CD8B60:01CBDDA8] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [64.81.28.110] X-AnalysisOut: [v=1.0 c=1 a=C-sXqlNc57gA:10 a=BLceEmwcHowA:10 a=4zsJQXJisS] X-AnalysisOut: [Y22NXBO5KRuA==:17 a=48vgC7mUAAAA:8 a=-MqTZFXQu2vHhdpCi9AA:] X-AnalysisOut: [9 a=vcC4DM2yQK9qEEPw8UwA:7 a=UCrKfNswt3NqJU8Hv2AeP4hSAtYA:] X-AnalysisOut: [4 a=CjuIK1q_8ugA:10 a=jtuuZF7Db9MA:10 a=xM_1bhAZbTEA:10 a=] X-AnalysisOut: [Sc2U-mF4V2EA:10 a=s4ddqAbM2P1BVpcZ:21 a=C9j6nl7lFJvoDmAc:2] X-AnalysisOut: [1 a=s1g0aIGbh-4JI1mRYuwA:9 a=GPw6aIhZizGVZhuLBk8A:7 a=Cavz] X-AnalysisOut: [KGZIPcCe3ZqaqIQltENoV6sA:4 a=v2xeMjayfSErGmiQ:21 a=cDDliEZ] X-AnalysisOut: [Gl7cPOJMR:21] Subject: [eman] Use of ENTITY-MIB in EMAN (version 01) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 15:52:59 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, I've integrated the current feedback for the eman-relationship-to-entity-mib-00.txt revision into eman-relationship-to-entity-mib-01.txt. Many thanks to Juergen S. for helping flush things out to this point. The conclusion that I'm coming away with at this point is that ENTITY-MIB was designed to model physical entities, where an "entity" is some construct that is intended for management purposes. Logical entities are not handled by entLogicalTable, which instead manages logical contexts (slight difference in that a context is not intended to be directly managed.) So for EMAN's purposes, a mechanism to manage both physical and logical entities is needed. This may be an extension of ENTITY-MIB (are other WG's needing something like this?) or may be a separate structure wholy contained in the EMAN MIB schema. Looking forward to your thoughts and feedback! Thanks, Chris --------- eman-relationship-to-entity-mib-01.txt --------- On the EMAN working group mailing list recently, there has a been a huge surge of activity surrounding the use of ENTITY-MIB (RFC4133) to define the list of core entities. I thought a detailed look at ENTITY-MIB's structures and philosophical underpinnings would be in order to see if it will work for EMAN's needs. >From RFC4133, ENTITY-MIB's description of itself and its purpose: "There is a need for a standardized way of representing a single agent, which supports multiple intstances of one MIB. This is presently true for at least 3 standard MIBs, and is likely to become true for more and more MIBs as time passes...." "What is needed is a way to determine exactly which logical entities are managed by the agent (with some version of SNMP) in order to communicate with the agent about a particular logical entity. When different logical entities are associated with different physical entities within the overall physical entity, it is also useful to be able to use this information to distinguish between logical entities." Also from RFC4311, some nomenclature: "Logical Entity: a managed system contains one or more logical entities, each represented by at most one instantiation of each of a particular set of MIB objects. A set of management functions is associated with each logical entity. Examples of logical entities include routers, bridges, print-servers, etc." "Physical Entity: a 'physical entity' or 'physical component' represents an identifiable physical resource within a managed system. Zero or more logical entities may utilize a physical resource at any given time. Determining which physical components are represented by an agent in the EntPhysicalTable is an implementation-specific matter. Typically, physical resources (e.g., communications ports, backplanes, sensors, daughter-cards, power supplies, the overall chassis), which can be managed via functions associated with one or more logical entities, are included in the MIB." There exist two key tables in ENTITY-MIB: entPhysicalTable, which identifies physical system components; and entLogicalTable, which identifies logical entities. Each contain one row per entity, where each row is indexed by an arbitrary integer. The target system that I am attempting to model is an ePower series intelligent PDU (iPDU) from Cyber Switching. One representation of this device's physical construction might be: ePower PDU |-- Network Interface Card | |-- LCD screen | |-- Processor | `-- Real-time clock battery/super-cap |-- Input #1 (3 Phase AC cord) | |-- Bank #1 (1Ph branch circuit - L1/L2) | | |-- Outlet #1 | | |-- Outlet #2 | | |-- Outlet #3 | | `-- Outlet #4 | |-- Bank #2 (1Ph branch circuit - L2/L3) | | |-- Outlet #5 | | |-- Outlet #6 | | |-- Outlet #7 | | `-- Outlet #8 | `-- Bank #3 (1Ph branch circuit - L3/L1) | |-- Outlet #9 | |-- Outlet #10 | |-- Outlet #11 | `-- Outlet #12 `-- Input #2 (3 Phase AC cord) |-- Bank #4 (1Ph branch circuit - L1/L2) | |-- Outlet #13 | |-- Outlet #14 | |-- Outlet #15 | `-- Outlet #16 |-- Bank #5 (1Ph branch circuit - L2/L3) | |-- Outlet #17 | |-- Outlet #18 | |-- Outlet #19 | `-- Outlet #20 `-- Bank #6 (1Ph branch circuit - L3/L1) |-- Outlet #21 |-- Outlet #22 |-- Outlet #23 `-- Outlet #24 Note that for each 3 Phase AC cord, between three and four separate sub-entities can exist: 3 Phase AC cord |-- Line L1 / X / A |-- Line L2 / Y / B |-- Line L3 / Z / C `-- Line Neutral / N In addition to this physical component breakdown, logical groupings of physical entities may be created. For example, outlet entities may be logically associated with one another into an "outlet gang." An outlet may belong to more than one "outlet gang." One representation of this may be: ePower PDU |-- Outlet Gang #1 | |-- Outlet #5 | |-- Outlet #6 | `-- Outlet #7 `-- Outlet Gang #2 |-- Outlet #6 `-- Outlet #13 As this applies to the EMAN goals, our objective is to instantiate the objects necessary to represent all of these various entities in such a way that power data and operational state control can be linked to them. I will investigate several possible scenarios of using ENTITY-MIB's existing structures to achieve this instantiation. In this exercise, we will start by placing all physical entities in entPhysicalTable. The table below shows key columns from that table along with sample values. entPhysicalTable +-----+---------------+-------------------+-------------+--------------+ | Idx | Name | Alias | ContainedIn | ParentRelPos | +-----+---------------+-------------------+-------------+--------------+ | 1 | ePower PDU | epower-pdu | 0 | 0 | | 2 | NIC | Control Logic | 1 | 1 | | 3 | LCD | Touchscreen Disp. | 2 | 0 | | 4 | Processor | CPU | 2 | 0 | | 5 | RTC Battery | Clock battery | 2 | 0 | | 6 | Input #1 | XFMR #1 feed | 1 | 2 | | 7 | Input #1 - L1 | Line L1 / X / A | 6 | 0 | | 8 | Input #1 - L2 | Line L2 / Y / B | 6 | 0 | | 9 | Input #1 - L3 | Line L3 / Z / C | 6 | 0 | | 10 | Input #1 - N | Line Neutral / N | 6 | 0 | | 11 | Bank #1 | Branch Cir. L1/L2 | 6 | 1 | | 12 | Outlet #1 | filer01-sjc-pwr1 | 11 | 1 | | 13 | Outlet #2 | filer17-sjc | 11 | 2 | | 14 | Outlet #3 | filer23-sjc | 11 | 3 | | 15 | Outlet #4 | san-array05-sjc | 11 | 4 | | 16 | Bank #2 | Branch Cir. L2/L3 | 6 | 2 | | 17 | Outlet #5 | rtr-u3-fre | 16 | 1 | | 18 | Outlet #6 | wap-flr01 | 16 | 2 | | 19 | Outlet #7 | wap-flr02 | 16 | 3 | | 20 | Outlet #8 | wap-flr03 | 16 | 4 | | 21 | Bank #3 | Branch Cir. L3/L1 | 6 | 3 | | 22 | Outlet #9 | rtr-m6-he | 21 | 1 | | 23 | Outlet #10 | rtr-m6-att | 21 | 2 | | 24 | Outlet #11 | switch-p989 | 21 | 3 | | 25 | Outlet #12 | switch-t332 | 21 | 4 | | 26 | Input #2 | XFMR #1 feed | 1 | 3 | | 27 | Input #2 - L1 | Line L1 / X / A | 26 | 0 | | 28 | Input #2 - L2 | Line L2 / Y / B | 26 | 0 | | 29 | Input #2 - L3 | Line L3 / Z / C | 26 | 0 | | 30 | Input #2 - N | Line Neutral / N | 26 | 0 | | 31 | Bank #4 | Branch Cir. L1/L2 | 26 | 1 | | 32 | Outlet #13 | filer01-sjc-pwr2 | 31 | 1 | | 33 | Outlet #14 | ... | 31 | 2 | | 34 | Outlet #15 | ... | 31 | 3 | | 35 | Outlet #16 | ... | 31 | 4 | | 36 | Bank #5 | Branch Cir. L2/L3 | 26 | 2 | | 37 | Outlet #17 | ... | 36 | 1 | | 38 | Outlet #18 | ... | 36 | 2 | | 39 | Outlet #19 | ... | 36 | 3 | | 40 | Outlet #20 | ... | 36 | 4 | | 41 | Bank #6 | Branch Cir. L3/L1 | 26 | 3 | | 42 | Outlet #21 | ... | 41 | 1 | | 43 | Outlet #22 | ... | 41 | 2 | | 44 | Outlet #23 | ... | 41 | 3 | | 44 | Outlet #24 | ... | 41 | 4 | +-----+---------------+-------------------+-------------+--------------+ In the spirit of ENTITY-MIB, the "outlet gang" entities do not belong in entPhysicalTable, as they are virtual representations of a collection of outlets. Therefore, we will place them in entLogicalTable. entLogicalTable +-----+----------------+ | Idx | Descr | +-----+----------------+ | 1 | Outlet Gang #1 | | 2 | Outlet Gang #2 | +-----+----------------+ The logical entities can be mapped onto the physical entities by using entLPMappingTable. entLPMappingTable +------------+-------------+ | LogicalIdx | PhysicalIdx | +------------+-------------+ | 1 | 17 | Outlet Gang #1 -> Outlet #5 | 1 | 18 | -> Outlet #6 | 1 | 19 | -> Outlet #7 | 2 | 16 | Outlet Gang #2 -> Outlet #6 | 2 | 32 | -> Outlet #13 +------------+-------------+ The entire model is now implemented using ENTITY-MIB. However, there are some ramifications to this: 1. There is no single "index" that can be referenced for sparse tables in an EMAN MIB. The use of both entPhysicalTable and entLogicalTable means that separate indicies must be used, which results in separate EMAN tables for power data, control, etc. (one for physical entities, one for logical entities). 2. The structure of entPhysicalTable allows an entity to maintain a constant name (e.g., "Outlet #1") while changing an alias (e.g., "filer01-sjc-pwr1"). The structure of entLogicalTable does not allow the same behavior, so logical entities are naturally less feature capable. 3. None of the objects in ENTITY-MIB allow for 'read-create', so creating new "outlet gangs" would have to be supported by a third-party mechanism. While not critical to EMAN's needs, it is a major inconvenience for the various manufacturers who would benefit from such standard operation. One proposed solution on the mailing list for #1 is to duplicate all entries from entPhysicalTable in entLogicalTable. The resulting structure would allow a single index to be used (entLogicalIndex), but would not address item #2. One possible solution for #2 would be to list the virtual "outlet gangs" in entPhysicalTable as well as in entLogicalTable, but this violates the spirit behind entPhysicalTable as described in RFC4133. So both compromise solutions would need to be made in order to handle "virtual" entities like "outlet gangs" using ENTITY-MIB. However, even if both solutions are used, establishing a relationship graph between an "outlet gang" and its parent PDU and between an "outlet gang" and its associated physical outlets is not handled in a simple manner. The entPhysicalContainedIn object can be used to relate physical outlets to their corresponding banks and the "outlet gangs" with the physical PDU. The entLPMappingTable can establish a mapping between the "outlet gang" and the physical outlets. However, as you can see, determining the parent/child relationship between entities is a complex process involving both entPhysicalContainedIn and entLPMappingTable. UPDATE 2011-03-08: Juergen Schoenwaelder pointed out in the EMAN WG mailing list (http://www.ietf.org/mail-archive/web/eman/current/msg00265.html) that this use of entLogicalTable is incorrect. The use proposed here assumes that entLogicalTable and entLPMappingTable establish a set of logical entities that can be managed, but Juergen points out that entLogicalTable instead creates a set of SNMP contexts only -- entities that are not intended for management purposes but are instead only used for grouping purposes. Another goal for EMAN is to report data on behalf of remote entities. In such a scenario, the agent must reference multiple physical entities that are external to the agent's system. Ethernet Switch |-- Port 1 |-- Port 2 --------------------> VoIP Phone |-- Port 3 --------------------> ePower PDU `-- Port 4 --------------------> Windows PC In this scenario, the VoIP phone, ePower PDU, and Windows PC report their power data to the Ethernet Switch, which acts as a collection proxy for the data. The structure underneath "ePower PDU" follows that described above. Modeling the switch itself is straight-forward. Following the logic used to describe an ePower PDU above, we can model all of the entities known/managed by the switch. entPhysicalTable +-----+---------------+-------------------+-------------+--------------+ | Idx | Name | Alias | ContainedIn | ParentRelPos | +-----+---------------+-------------------+-------------+--------------+ | 1 | Eth. Switch | switch-4-sjc | 0 | 0 | | 2 | Port 1 | Switchport 1 | 1 | 1 | | 3 | Port 2 | Switchport 2 | 1 | 2 | | 4 | Port 3 | Switchport 3 | 1 | 3 | | 5 | Port 4 | Switchport 4 | 1 | 4 | | 6 | ePower PDU | epower-pdu | 4 | 0 | | 7 | NIC | Control Logic | 6 | 1 | | 8 | LCD | Touchscreen Disp. | 7 | 0 | | 9 | Processor | CPU | 7 | 0 | | 10 | RTC Battery | Clock battery | 7 | 0 | | 11 | Input #1 | XFMR #1 feed | 6 | 2 | | 12 | Input #1 - L1 | Line L1 / X / A | 11 | 0 | | 13 | Input #1 - L2 | Line L2 / Y / B | 11 | 0 | | 14 | Input #1 - L3 | Line L3 / Z / C | 11 | 0 | | 15 | Input #1 - N | Line Neutral / N | 11 | 0 | | 16 | Bank #1 | Branch Cir. L1/L2 | 11 | 1 | | 17 | Outlet #1 | filer01-sjc-pwr1 | 16 | 1 | | 18 | Outlet #2 | filer17-sjc | 16 | 2 | | 19 | Outlet #3 | filer23-sjc | 16 | 3 | | 20 | Outlet #4 | san-array05-sjc | 16 | 4 | | 21 | Bank #2 | Branch Cir. L2/L3 | 11 | 2 | | 22 | Outlet #5 | rtr-u3-fre | 21 | 1 | | 23 | Outlet #6 | wap-flr01 | 21 | 2 | | 24 | Outlet #7 | wap-flr02 | 21 | 3 | | 25 | Outlet #8 | wap-flr03 | 21 | 4 | | 26 | Bank #3 | Branch Cir. L3/L1 | 11 | 3 | | 27 | Outlet #9 | rtr-m6-he | 26 | 1 | | 28 | Outlet #10 | rtr-m6-att | 26 | 2 | | 29 | Outlet #11 | switch-p989 | 26 | 3 | | 30 | Outlet #12 | switch-t332 | 26 | 4 | | 31 | Input #2 | XFMR #1 feed | 11 | 3 | | 32 | Input #2 - L1 | Line L1 / X / A | 31 | 0 | | 33 | Input #2 - L2 | Line L2 / Y / B | 31 | 0 | | 34 | Input #2 - L3 | Line L3 / Z / C | 31 | 0 | | 35 | Input #2 - N | Line Neutral / N | 31 | 0 | | 36 | Bank #4 | Branch Cir. L1/L2 | 31 | 1 | | 37 | Outlet #13 | filer01-sjc-pwr2 | 36 | 1 | | 38 | Outlet #14 | ... | 36 | 2 | | 39 | Outlet #15 | ... | 36 | 3 | | 40 | Outlet #16 | ... | 36 | 4 | | 41 | Bank #5 | Branch Cir. L2/L3 | 31 | 2 | | 42 | Outlet #17 | ... | 41 | 1 | | 43 | Outlet #18 | ... | 41 | 2 | | 44 | Outlet #19 | ... | 41 | 3 | | 45 | Outlet #20 | ... | 41 | 4 | | 46 | Bank #6 | Branch Cir. L3/L1 | 31 | 3 | | 47 | Outlet #21 | ... | 46 | 1 | | 48 | Outlet #22 | ... | 46 | 2 | | 49 | Outlet #23 | ... | 46 | 3 | | 50 | Outlet #24 | ... | 46 | 4 | | 51 | Outlet Gang 1 | Finance Servers | 6 | 0 | | 52 | Outlet Gang 2 | Sales Servers | 6 | 0 | | 53 | VoIP Phone | VoIP/SIP Phone | 3 | 0 | | 54 | Windows PC | John Smith's PC | 5 | 0 | +-----+---------------+-------------------+-------------+--------------+ entLogicalTable +-----+---------------+ | Idx | Descr | +-----+---------------+ | 1 | Eth. Switch | | 2 | Port 1 | | 3 | Port 2 | | 4 | Port 3 | | 5 | Port 4 | | 6 | ePower PDU | | 7 | NIC | | 8 | LCD | | 9 | Processor | | 10 | RTC Battery | | 11 | Input #1 | | 12 | Input #1 - L1 | | 13 | Input #1 - L2 | | 14 | Input #1 - L3 | | 15 | Input #1 - N | | 16 | Bank #1 | | 17 | Outlet #1 | | 18 | Outlet #2 | | 19 | Outlet #3 | | 20 | Outlet #4 | | 21 | Bank #2 | | 22 | Outlet #5 | | 23 | Outlet #6 | | 24 | Outlet #7 | | 25 | Outlet #8 | | 26 | Bank #3 | | 27 | Outlet #9 | | 28 | Outlet #10 | | 29 | Outlet #11 | | 30 | Outlet #12 | | 31 | Input #2 | | 32 | Input #2 - L1 | | 33 | Input #2 - L2 | | 34 | Input #2 - L3 | | 35 | Input #2 - N | | 36 | Bank #4 | | 37 | Outlet #13 | | 38 | Outlet #14 | | 39 | Outlet #15 | | 40 | Outlet #16 | | 41 | Bank #5 | | 42 | Outlet #17 | | 43 | Outlet #18 | | 44 | Outlet #19 | | 45 | Outlet #20 | | 46 | Bank #6 | | 47 | Outlet #21 | | 48 | Outlet #22 | | 49 | Outlet #23 | | 50 | Outlet #24 | | 51 | Outlet Gang 1 | | 52 | Outlet Gang 2 | | 53 | VoIP Phone | | 54 | Windows PC | +-----+---------------+ entLPMappingTable +------------+-------------+ | LogicalIdx | PhysicalIdx | +------------+-------------+ | 51 | 22 | Outlet Gang #1 -> Outlet #5 | 51 | 23 | -> Outlet #6 | 51 | 24 | -> Outlet #7 | 52 | 23 | Outlet Gang #2 -> Outlet #6 | 52 | 37 | -> Outlet #13 +------------+-------------+ UPDATE 2011-03-08: Building on Juergen Schoenwaelder's point about the intended use of entLogicalTable, however, such a structure would be incorrect and not plausible for implementation. Some kind of structure that emulates these requirements, however, would be needed. This is the foundation behind emanEntityTable in draft-verges-eman-separate-modules-mib-00. Questions that remain to be answered: 1. When an entity is disconnected/removed (like the ePower PDU being disconnected from the switchport), what is the behavior related to ENTITY-MIB? Are the entries removed and, if so, are the indices for the remaining entries collapsed/adjusted to remove the gap? UPDATE 2011-03-08: entPhysicalIndex should not be collapsed/adjusted, as described in Juergen S.'s response (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html). 2. What happens when an entity is reconnected (like the same ePower PDU being connected to a different switchport), what is the behavior related to ENTITY-MIB? Are the original indices reused? UPDATE 2011-03-08: New entities would be given a new PhysicalIndex value. Reconnected entities may optionally reuse their old PhysicalIndex value (if that value is available), but do not have to since a UUID can be persisted for the entity via entPhysicalUris. (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html) 3. How will an Energy Management System (EMS) or other NMS using this data ensure that the data gathered and control mechanisms used are universally guaranteed? Does a UUID or other form of identification need to be created for an entity and, if so, how is that UUID exposed via ENTITY-MIB? UPDATE 2011-03-08: Universal identification may be achieved through either entPhysicalAssetID (a user-writable field) or entPhysicalUris (most likely preferred). See RFC4122 for information on using entPhysicalUris to carry UUID URNs. (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html) 4. How does this proposed use of ENTITY-MIB for EMAN's purposes relate to the standard, existing use of ENTITY-MIB in the industry? UPDATE 2011-03-08: ENTITY-MIB does not support arbitrary logical groupings at present, and a mechanism would need to be created to support this functionality. (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html) UPDATE 2011-03-08: There is sufficient complexity involved in some logical groupings at the energy reporting/management level to warrant logical groupings. Allowing the agent to handle these logical groupings rather than burdening the EMS/BMS/NMS puts the domain-specific complexity involved in energy measurements/calculations in the hands of the manufacturer who specializes in it. (http://www.ietf.org/mail-archive/web/eman/current/msg00274.html) --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="eman-relationship-to-entity-mib-01.txt" On the EMAN working group mailing list recently, there has a been a huge surge of activity surrounding the use of ENTITY-MIB (RFC4133) to define the list of core entities. I thought a detailed look at ENTITY-MIB's structures and philosophical underpinnings would be in order to see if it will work for EMAN's needs. >From RFC4133, ENTITY-MIB's description of itself and its purpose: "There is a need for a standardized way of representing a single agent, which supports multiple intstances of one MIB. This is presently true for at least 3 standard MIBs, and is likely to become true for more and more MIBs as time passes...." "What is needed is a way to determine exactly which logical entities are managed by the agent (with some version of SNMP) in order to communicate with the agent about a particular logical entity. When different logical entities are associated with different physical entities within the overall physical entity, it is also useful to be able to use this information to distinguish between logical entities." Also from RFC4311, some nomenclature: "Logical Entity: a managed system contains one or more logical entities, each represented by at most one instantiation of each of a particular set of MIB objects. A set of management functions is associated with each logical entity. Examples of logical entities include routers, bridges, print-servers, etc." "Physical Entity: a 'physical entity' or 'physical component' represents an identifiable physical resource within a managed system. Zero or more logical entities may utilize a physical resource at any given time. Determining which physical components are represented by an agent in the EntPhysicalTable is an implementation-specific matter. Typically, physical resources (e.g., communications ports, backplanes, sensors, daughter-cards, power supplies, the overall chassis), which can be managed via functions associated with one or more logical entities, are included in the MIB." There exist two key tables in ENTITY-MIB: entPhysicalTable, which identifies physical system components; and entLogicalTable, which identifies logical entities. Each contain one row per entity, where each row is indexed by an arbitrary integer. The target system that I am attempting to model is an ePower series intelligent PDU (iPDU) from Cyber Switching. One representation of this device's physical construction might be: ePower PDU |-- Network Interface Card | |-- LCD screen | |-- Processor | `-- Real-time clock battery/super-cap |-- Input #1 (3 Phase AC cord) | |-- Bank #1 (1Ph branch circuit - L1/L2) | | |-- Outlet #1 | | |-- Outlet #2 | | |-- Outlet #3 | | `-- Outlet #4 | |-- Bank #2 (1Ph branch circuit - L2/L3) | | |-- Outlet #5 | | |-- Outlet #6 | | |-- Outlet #7 | | `-- Outlet #8 | `-- Bank #3 (1Ph branch circuit - L3/L1) | |-- Outlet #9 | |-- Outlet #10 | |-- Outlet #11 | `-- Outlet #12 `-- Input #2 (3 Phase AC cord) |-- Bank #4 (1Ph branch circuit - L1/L2) | |-- Outlet #13 | |-- Outlet #14 | |-- Outlet #15 | `-- Outlet #16 |-- Bank #5 (1Ph branch circuit - L2/L3) | |-- Outlet #17 | |-- Outlet #18 | |-- Outlet #19 | `-- Outlet #20 `-- Bank #6 (1Ph branch circuit - L3/L1) |-- Outlet #21 |-- Outlet #22 |-- Outlet #23 `-- Outlet #24 Note that for each 3 Phase AC cord, between three and four separate sub-entities can exist: 3 Phase AC cord |-- Line L1 / X / A |-- Line L2 / Y / B |-- Line L3 / Z / C `-- Line Neutral / N In addition to this physical component breakdown, logical groupings of physical entities may be created. For example, outlet entities may be logically associated with one another into an "outlet gang." An outlet may belong to more than one "outlet gang." One representation of this may be: ePower PDU |-- Outlet Gang #1 | |-- Outlet #5 | |-- Outlet #6 | `-- Outlet #7 `-- Outlet Gang #2 |-- Outlet #6 `-- Outlet #13 As this applies to the EMAN goals, our objective is to instantiate the objects necessary to represent all of these various entities in such a way that power data and operational state control can be linked to them. I will investigate several possible scenarios of using ENTITY-MIB's existing structures to achieve this instantiation. In this exercise, we will start by placing all physical entities in entPhysicalTable. The table below shows key columns from that table along with sample values. entPhysicalTable +-----+---------------+-------------------+-------------+--------------+ | Idx | Name | Alias | ContainedIn | ParentRelPos | +-----+---------------+-------------------+-------------+--------------+ | 1 | ePower PDU | epower-pdu | 0 | 0 | | 2 | NIC | Control Logic | 1 | 1 | | 3 | LCD | Touchscreen Disp. | 2 | 0 | | 4 | Processor | CPU | 2 | 0 | | 5 | RTC Battery | Clock battery | 2 | 0 | | 6 | Input #1 | XFMR #1 feed | 1 | 2 | | 7 | Input #1 - L1 | Line L1 / X / A | 6 | 0 | | 8 | Input #1 - L2 | Line L2 / Y / B | 6 | 0 | | 9 | Input #1 - L3 | Line L3 / Z / C | 6 | 0 | | 10 | Input #1 - N | Line Neutral / N | 6 | 0 | | 11 | Bank #1 | Branch Cir. L1/L2 | 6 | 1 | | 12 | Outlet #1 | filer01-sjc-pwr1 | 11 | 1 | | 13 | Outlet #2 | filer17-sjc | 11 | 2 | | 14 | Outlet #3 | filer23-sjc | 11 | 3 | | 15 | Outlet #4 | san-array05-sjc | 11 | 4 | | 16 | Bank #2 | Branch Cir. L2/L3 | 6 | 2 | | 17 | Outlet #5 | rtr-u3-fre | 16 | 1 | | 18 | Outlet #6 | wap-flr01 | 16 | 2 | | 19 | Outlet #7 | wap-flr02 | 16 | 3 | | 20 | Outlet #8 | wap-flr03 | 16 | 4 | | 21 | Bank #3 | Branch Cir. L3/L1 | 6 | 3 | | 22 | Outlet #9 | rtr-m6-he | 21 | 1 | | 23 | Outlet #10 | rtr-m6-att | 21 | 2 | | 24 | Outlet #11 | switch-p989 | 21 | 3 | | 25 | Outlet #12 | switch-t332 | 21 | 4 | | 26 | Input #2 | XFMR #1 feed | 1 | 3 | | 27 | Input #2 - L1 | Line L1 / X / A | 26 | 0 | | 28 | Input #2 - L2 | Line L2 / Y / B | 26 | 0 | | 29 | Input #2 - L3 | Line L3 / Z / C | 26 | 0 | | 30 | Input #2 - N | Line Neutral / N | 26 | 0 | | 31 | Bank #4 | Branch Cir. L1/L2 | 26 | 1 | | 32 | Outlet #13 | filer01-sjc-pwr2 | 31 | 1 | | 33 | Outlet #14 | ... | 31 | 2 | | 34 | Outlet #15 | ... | 31 | 3 | | 35 | Outlet #16 | ... | 31 | 4 | | 36 | Bank #5 | Branch Cir. L2/L3 | 26 | 2 | | 37 | Outlet #17 | ... | 36 | 1 | | 38 | Outlet #18 | ... | 36 | 2 | | 39 | Outlet #19 | ... | 36 | 3 | | 40 | Outlet #20 | ... | 36 | 4 | | 41 | Bank #6 | Branch Cir. L3/L1 | 26 | 3 | | 42 | Outlet #21 | ... | 41 | 1 | | 43 | Outlet #22 | ... | 41 | 2 | | 44 | Outlet #23 | ... | 41 | 3 | | 44 | Outlet #24 | ... | 41 | 4 | +-----+---------------+-------------------+-------------+--------------+ In the spirit of ENTITY-MIB, the "outlet gang" entities do not belong in entPhysicalTable, as they are virtual representations of a collection of outlets. Therefore, we will place them in entLogicalTable. entLogicalTable +-----+----------------+ | Idx | Descr | +-----+----------------+ | 1 | Outlet Gang #1 | | 2 | Outlet Gang #2 | +-----+----------------+ The logical entities can be mapped onto the physical entities by using entLPMappingTable. entLPMappingTable +------------+-------------+ | LogicalIdx | PhysicalIdx | +------------+-------------+ | 1 | 17 | Outlet Gang #1 -> Outlet #5 | 1 | 18 | -> Outlet #6 | 1 | 19 | -> Outlet #7 | 2 | 16 | Outlet Gang #2 -> Outlet #6 | 2 | 32 | -> Outlet #13 +------------+-------------+ The entire model is now implemented using ENTITY-MIB. However, there are some ramifications to this: 1. There is no single "index" that can be referenced for sparse tables in an EMAN MIB. The use of both entPhysicalTable and entLogicalTable means that separate indicies must be used, which results in separate EMAN tables for power data, control, etc. (one for physical entities, one for logical entities). 2. The structure of entPhysicalTable allows an entity to maintain a constant name (e.g., "Outlet #1") while changing an alias (e.g., "filer01-sjc-pwr1"). The structure of entLogicalTable does not allow the same behavior, so logical entities are naturally less feature capable. 3. None of the objects in ENTITY-MIB allow for 'read-create', so creating new "outlet gangs" would have to be supported by a third-party mechanism. While not critical to EMAN's needs, it is a major inconvenience for the various manufacturers who would benefit from such standard operation. One proposed solution on the mailing list for #1 is to duplicate all entries from entPhysicalTable in entLogicalTable. The resulting structure would allow a single index to be used (entLogicalIndex), but would not address item #2. One possible solution for #2 would be to list the virtual "outlet gangs" in entPhysicalTable as well as in entLogicalTable, but this violates the spirit behind entPhysicalTable as described in RFC4133. So both compromise solutions would need to be made in order to handle "virtual" entities like "outlet gangs" using ENTITY-MIB. However, even if both solutions are used, establishing a relationship graph between an "outlet gang" and its parent PDU and between an "outlet gang" and its associated physical outlets is not handled in a simple manner. The entPhysicalContainedIn object can be used to relate physical outlets to their corresponding banks and the "outlet gangs" with the physical PDU. The entLPMappingTable can establish a mapping between the "outlet gang" and the physical outlets. However, as you can see, determining the parent/child relationship between entities is a complex process involving both entPhysicalContainedIn and entLPMappingTable. UPDATE 2011-03-08: Juergen Schoenwaelder pointed out in the EMAN WG mailing list (http://www.ietf.org/mail-archive/web/eman/current/msg00265.html) that this use of entLogicalTable is incorrect. The use proposed here assumes that entLogicalTable and entLPMappingTable establish a set of logical entities that can be managed, but Juergen points out that entLogicalTable instead creates a set of SNMP contexts only -- entities that are not intended for management purposes but are instead only used for grouping purposes. Another goal for EMAN is to report data on behalf of remote entities. In such a scenario, the agent must reference multiple physical entities that are external to the agent's system. Ethernet Switch |-- Port 1 |-- Port 2 --------------------> VoIP Phone |-- Port 3 --------------------> ePower PDU `-- Port 4 --------------------> Windows PC In this scenario, the VoIP phone, ePower PDU, and Windows PC report their power data to the Ethernet Switch, which acts as a collection proxy for the data. The structure underneath "ePower PDU" follows that described above. Modeling the switch itself is straight-forward. Following the logic used to describe an ePower PDU above, we can model all of the entities known/managed by the switch. entPhysicalTable +-----+---------------+-------------------+-------------+--------------+ | Idx | Name | Alias | ContainedIn | ParentRelPos | +-----+---------------+-------------------+-------------+--------------+ | 1 | Eth. Switch | switch-4-sjc | 0 | 0 | | 2 | Port 1 | Switchport 1 | 1 | 1 | | 3 | Port 2 | Switchport 2 | 1 | 2 | | 4 | Port 3 | Switchport 3 | 1 | 3 | | 5 | Port 4 | Switchport 4 | 1 | 4 | | 6 | ePower PDU | epower-pdu | 4 | 0 | | 7 | NIC | Control Logic | 6 | 1 | | 8 | LCD | Touchscreen Disp. | 7 | 0 | | 9 | Processor | CPU | 7 | 0 | | 10 | RTC Battery | Clock battery | 7 | 0 | | 11 | Input #1 | XFMR #1 feed | 6 | 2 | | 12 | Input #1 - L1 | Line L1 / X / A | 11 | 0 | | 13 | Input #1 - L2 | Line L2 / Y / B | 11 | 0 | | 14 | Input #1 - L3 | Line L3 / Z / C | 11 | 0 | | 15 | Input #1 - N | Line Neutral / N | 11 | 0 | | 16 | Bank #1 | Branch Cir. L1/L2 | 11 | 1 | | 17 | Outlet #1 | filer01-sjc-pwr1 | 16 | 1 | | 18 | Outlet #2 | filer17-sjc | 16 | 2 | | 19 | Outlet #3 | filer23-sjc | 16 | 3 | | 20 | Outlet #4 | san-array05-sjc | 16 | 4 | | 21 | Bank #2 | Branch Cir. L2/L3 | 11 | 2 | | 22 | Outlet #5 | rtr-u3-fre | 21 | 1 | | 23 | Outlet #6 | wap-flr01 | 21 | 2 | | 24 | Outlet #7 | wap-flr02 | 21 | 3 | | 25 | Outlet #8 | wap-flr03 | 21 | 4 | | 26 | Bank #3 | Branch Cir. L3/L1 | 11 | 3 | | 27 | Outlet #9 | rtr-m6-he | 26 | 1 | | 28 | Outlet #10 | rtr-m6-att | 26 | 2 | | 29 | Outlet #11 | switch-p989 | 26 | 3 | | 30 | Outlet #12 | switch-t332 | 26 | 4 | | 31 | Input #2 | XFMR #1 feed | 11 | 3 | | 32 | Input #2 - L1 | Line L1 / X / A | 31 | 0 | | 33 | Input #2 - L2 | Line L2 / Y / B | 31 | 0 | | 34 | Input #2 - L3 | Line L3 / Z / C | 31 | 0 | | 35 | Input #2 - N | Line Neutral / N | 31 | 0 | | 36 | Bank #4 | Branch Cir. L1/L2 | 31 | 1 | | 37 | Outlet #13 | filer01-sjc-pwr2 | 36 | 1 | | 38 | Outlet #14 | ... | 36 | 2 | | 39 | Outlet #15 | ... | 36 | 3 | | 40 | Outlet #16 | ... | 36 | 4 | | 41 | Bank #5 | Branch Cir. L2/L3 | 31 | 2 | | 42 | Outlet #17 | ... | 41 | 1 | | 43 | Outlet #18 | ... | 41 | 2 | | 44 | Outlet #19 | ... | 41 | 3 | | 45 | Outlet #20 | ... | 41 | 4 | | 46 | Bank #6 | Branch Cir. L3/L1 | 31 | 3 | | 47 | Outlet #21 | ... | 46 | 1 | | 48 | Outlet #22 | ... | 46 | 2 | | 49 | Outlet #23 | ... | 46 | 3 | | 50 | Outlet #24 | ... | 46 | 4 | | 51 | Outlet Gang 1 | Finance Servers | 6 | 0 | | 52 | Outlet Gang 2 | Sales Servers | 6 | 0 | | 53 | VoIP Phone | VoIP/SIP Phone | 3 | 0 | | 54 | Windows PC | John Smith's PC | 5 | 0 | +-----+---------------+-------------------+-------------+--------------+ entLogicalTable +-----+---------------+ | Idx | Descr | +-----+---------------+ | 1 | Eth. Switch | | 2 | Port 1 | | 3 | Port 2 | | 4 | Port 3 | | 5 | Port 4 | | 6 | ePower PDU | | 7 | NIC | | 8 | LCD | | 9 | Processor | | 10 | RTC Battery | | 11 | Input #1 | | 12 | Input #1 - L1 | | 13 | Input #1 - L2 | | 14 | Input #1 - L3 | | 15 | Input #1 - N | | 16 | Bank #1 | | 17 | Outlet #1 | | 18 | Outlet #2 | | 19 | Outlet #3 | | 20 | Outlet #4 | | 21 | Bank #2 | | 22 | Outlet #5 | | 23 | Outlet #6 | | 24 | Outlet #7 | | 25 | Outlet #8 | | 26 | Bank #3 | | 27 | Outlet #9 | | 28 | Outlet #10 | | 29 | Outlet #11 | | 30 | Outlet #12 | | 31 | Input #2 | | 32 | Input #2 - L1 | | 33 | Input #2 - L2 | | 34 | Input #2 - L3 | | 35 | Input #2 - N | | 36 | Bank #4 | | 37 | Outlet #13 | | 38 | Outlet #14 | | 39 | Outlet #15 | | 40 | Outlet #16 | | 41 | Bank #5 | | 42 | Outlet #17 | | 43 | Outlet #18 | | 44 | Outlet #19 | | 45 | Outlet #20 | | 46 | Bank #6 | | 47 | Outlet #21 | | 48 | Outlet #22 | | 49 | Outlet #23 | | 50 | Outlet #24 | | 51 | Outlet Gang 1 | | 52 | Outlet Gang 2 | | 53 | VoIP Phone | | 54 | Windows PC | +-----+---------------+ entLPMappingTable +------------+-------------+ | LogicalIdx | PhysicalIdx | +------------+-------------+ | 51 | 22 | Outlet Gang #1 -> Outlet #5 | 51 | 23 | -> Outlet #6 | 51 | 24 | -> Outlet #7 | 52 | 23 | Outlet Gang #2 -> Outlet #6 | 52 | 37 | -> Outlet #13 +------------+-------------+ UPDATE 2011-03-08: Building on Juergen Schoenwaelder's point about the intended use of entLogicalTable, however, such a structure would be incorrect and not plausible for implementation. Some kind of structure that emulates these requirements, however, would be needed. This is the foundation behind emanEntityTable in draft-verges-eman-separate-modules-mib-00. Questions that remain to be answered: 1. When an entity is disconnected/removed (like the ePower PDU being disconnected from the switchport), what is the behavior related to ENTITY-MIB? Are the entries removed and, if so, are the indices for the remaining entries collapsed/adjusted to remove the gap? UPDATE 2011-03-08: entPhysicalIndex should not be collapsed/adjusted, as described in Juergen S.'s response (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html). 2. What happens when an entity is reconnected (like the same ePower PDU being connected to a different switchport), what is the behavior related to ENTITY-MIB? Are the original indices reused? UPDATE 2011-03-08: New entities would be given a new PhysicalIndex value. Reconnected entities may optionally reuse their old PhysicalIndex value (if that value is available), but do not have to since a UUID can be persisted for the entity via entPhysicalUris. (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html) 3. How will an Energy Management System (EMS) or other NMS using this data ensure that the data gathered and control mechanisms used are universally guaranteed? Does a UUID or other form of identification need to be created for an entity and, if so, how is that UUID exposed via ENTITY-MIB? UPDATE 2011-03-08: Universal identification may be achieved through either entPhysicalAssetID (a user-writable field) or entPhysicalUris (most likely preferred). See RFC4122 for information on using entPhysicalUris to carry UUID URNs. (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html) 4. How does this proposed use of ENTITY-MIB for EMAN's purposes relate to the standard, existing use of ENTITY-MIB in the industry? UPDATE 2011-03-08: ENTITY-MIB does not support arbitrary logical groupings at present, and a mechanism would need to be created to support this functionality. (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html) UPDATE 2011-03-08: There is sufficient complexity involved in some logical groupings at the energy reporting/management level to warrant logical groupings. Allowing the agent to handle these logical groupings rather than burdening the EMS/BMS/NMS puts the domain-specific complexity involved in energy measurements/calculations in the hands of the manufacturer who specializes in it. (http://www.ietf.org/mail-archive/web/eman/current/msg00274.html) --fdj2RfSjLxBAspz7-- From jparello@cisco.com Tue Mar 8 08:43:37 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2793A6827 for ; Tue, 8 Mar 2011 08:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTkmMhxX6eST for ; Tue, 8 Mar 2011 08:43:31 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 78ECB3A67E7 for ; Tue, 8 Mar 2011 08:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=19057; q=dns/txt; s=iport; t=1299602686; x=1300812286; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=0RIP4uGuDiu1/Ol7ZRU/MLZfBfKk8Ppr6VIAVY5wlrA=; b=NhBraeajFwWCrZ2p3voRsfVQ47nZiZFs1HkGsgjM9PJlFXu5e6fGEVTb sxq8uo9a68nAQ0GsvqH4PquSJUEYzYfdcf8Gcu1+oeVdNRn4ALaC5HJsr qxRzgcGXjfDu6AgtBWpgEtZDjL/bITEfIG5lGvHfeNHDmzlZhZQ+/nByq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQAAJ/rdU2rRN+J/2dsb2JhbACCT5VTji10pAKcN4VjBIUdimI X-IronPort-AV: E=Sophos;i="4.62,285,1297036800"; d="scan'208,217";a="272582906" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2011 16:44:46 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p28GikCX022003; Tue, 8 Mar 2011 16:44:46 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 08:44:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDDB0.219C1EEE" Date: Tue, 8 Mar 2011 08:40:26 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Request for Presentation slot... RE: Call for Agenda itemsfor the EMAN open meeting in Prague Thread-Index: AcvcoGk1+yEE3IDPTcGrCmUJxHiucAASLPCQACOdfHAADfdnIA== References: <4D749432.4020306@cisco.com> From: "John Parello (jparello)" To: "Romascanu, Dan (Dan)" , "Benoit Claise (bclaise)" , "eman mailing list" X-OriginalArrivalTime: 08 Mar 2011 16:44:46.0248 (UTC) FILETIME=[21DFAA80:01CBDDB0] Subject: Re: [eman] Request for Presentation slot... RE: Call for Agenda itemsfor the EMAN open meeting in Prague X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:43:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDDB0.219C1EEE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Very Cool. Thanks Dan! =20 Yes that would be an information model. =20 Jp =20 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Tuesday, March 08, 2011 2:02 AM To: John Parello (jparello); Benoit Claise (bclaise); eman mailing list Subject: RE: [eman] Request for Presentation slot... RE: Call for Agenda itemsfor the EMAN open meeting in Prague =20 Hi John, =20 > The ODVA would like to see a consistent data model for energy awareness regardless of protocol (ie SNMP, CIP, MODBUS, PROFINET etc) =20 In the IETF speech you may be talking about an Information Model. I recommend that you have a look at http://www.rfc-editor.org/rfc/rfc3444.txt . =20 Regards, =20 Dan =20 =20 =20 =09 ________________________________ From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of John Parello (jparello) Sent: Monday, March 07, 2011 7:46 PM To: Benoit Claise (bclaise); eman mailing list Subject: [eman] Request for Presentation slot... RE: Call for Agenda itemsfor the EMAN open meeting in Prague Hi Chairs, =20 I'd like to request a time slot (< 20 min?) to present similar work on Energy Awareness from the ODVA organization.=20 =20 The ODVA is a business league of Industrial automation manufacturing device makers. They specify and maintain the CIP protocol which is used to control manufacturing devices. They recently formed an energy SIG of which I am a member. =20 The SIG has proposed a class addition to CIP that calls for "Energy Awareness" in all manufacturing device and have come up with a data model and format for CIP. =20 I'd like to show the similarities to the IETF EMAN effort. The ODVA would like to see a consistent data model for energy awareness regardless of protocol (ie SNMP, CIP, MODBUS, PROFINET etc) =20 Three concepts they are taking from EMAN - Caliber rating, Parent/Child aggregation, Power States - with a general mantra of simple implementations for simple device. =20 I think it would be educational for the group to see how another group of electrical engineers (non IT) are modeling and responding to the same the same exact problem areas as EMAN. =20 More information at: =20 =09 http://www.odva.org/Home/tabid/53/ctl/Details/mid/372/ItemID/74/lng/en-U S/language/en-US/Default.aspx =20 Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Benoit Claise (bclaise) Sent: Monday, March 07, 2011 12:16 AM To: eman mailing list Subject: [eman] Call for Agenda items for the EMAN open meeting in Prague =20 Dear all, =09 Now that we have a final agenda... https://datatracker.ietf.org/meeting/80/agenda.html =20 https://datatracker.ietf.org/meeting/80/agenda.txt =20 http://www.ietf.org/meeting/80/index.html =20 If you plan to ask for presentation or discussion slots in the EMAN meeting in Prague, please send your requests to us.=20 =09 Regards, Bruce and Benoit. ------_=_NextPart_001_01CBDDB0.219C1EEE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Very Cool. Thanks Dan!

 

Yes that would be an information = model.

 

Jp

 

From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Tuesday, March 08, 2011 2:02 AM
To: John Parello (jparello); Benoit Claise (bclaise); eman = mailing list
Subject: RE: [eman] Request for Presentation slot... RE: Call for = Agenda itemsfor the EMAN open meeting in Prague

 

Hi John,

 

> The ODVA would like to see a consistent data model for = energy awareness regardless of protocol (ie SNMP, CIP, MODBUS, PROFINET = etc)

 

In the IETF speech you may be talking about an Information = Model. I recommend that you have a look at http://www.rfc-editor.org/rfc/rfc3444.t= xt.<= /span>

 

Regards,

 

Dan

 

 

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = John Parello (jparello)
Sent: Monday, March 07, 2011 7:46 PM
To: Benoit Claise (bclaise); eman mailing list
Subject: [eman] Request for Presentation slot... RE: Call for = Agenda itemsfor the EMAN open meeting in Prague

Hi Chairs,

 

I’d like to request a time slot (< 20 min?) to = present similar work on Energy Awareness from the ODVA organization. =

 

The ODVA  is a business league of Industrial = automation manufacturing device makers. They specify and maintain the CIP protocol = which is used to control manufacturing devices. They recently formed an energy = SIG of which I am a member.

 

The SIG has proposed a class addition to CIP that calls = for "Energy Awareness"  in all manufacturing device and have = come up with a data model and format for CIP.

 

I'd like to show the similarities to the IETF EMAN = effort. The ODVA would like to see a consistent data model for energy awareness = regardless of protocol (ie SNMP, CIP, MODBUS, PROFINET etc)

 

Three concepts they are taking from EMAN -  Caliber = rating, Parent/Child aggregation, Power States - with a general mantra of simple implementations for simple device.

 

I think it would be educational for the group to see how = another group of electrical engineers (non IT) are modeling and responding to = the same the same exact problem areas as EMAN.

 

More information at:

 

http://www.odva.org/Home/tabid/53/c= tl/Details/mid/372/ItemID/74/lng/en-US/language/en-US/Default.aspx

 

Jp

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Benoit Claise = (bclaise)
Sent: Monday, March 07, 2011 12:16 AM
To: eman mailing list
Subject: [eman] Call for Agenda items for the EMAN open meeting = in Prague

 

Dear all,

Now that we have a final agenda...
  =   https://datatracker.ietf.org/meeting/80/agenda.html

    http://www.ietf.org/meeting/80/index.html
If you plan to ask for presentation or discussion slots in the EMAN
meeting in Prague, please send your requests to us.

Regards, Bruce and Benoit.

------_=_NextPart_001_01CBDDB0.219C1EEE-- From j.schoenwaelder@jacobs-university.de Tue Mar 8 08:43:46 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7043A6827 for ; Tue, 8 Mar 2011 08:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.145 X-Spam-Level: X-Spam-Status: No, score=-103.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKeGcAudfPpf for ; Tue, 8 Mar 2011 08:43:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8E24A3A67E7 for ; Tue, 8 Mar 2011 08:43:45 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F28AC0073; Tue, 8 Mar 2011 17:45:00 +0100 (CET) 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 2+cMpMCqkKJN; Tue, 8 Mar 2011 17:44:59 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67637C0013; Tue, 8 Mar 2011 17:44:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9641816E6B9C; Tue, 8 Mar 2011 17:44:54 +0100 (CET) Date: Tue, 8 Mar 2011 17:44:54 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110308164454.GA39498@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, eman@ietf.org References: <20110306002733.GA14483@cslinux-build01.cyberswitching.local> <20110307094456.GC32101@elstar.local> <20110307123840.GA14024@cslinux-build01.cyberswitching.local> <20110308113521.GB36852@elstar.local> <20110308151701.GA11979@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110308151701.GA11979@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] Use of ENTITY-MIB in EMAN X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:43:47 -0000 On Tue, Mar 08, 2011 at 07:17:01AM -0800, chrisv@cyberswitching.com wrote: > So what begs the question of what to do when we hit the maximum value > (2147483647) as we constantly count up. Do we roll over to zero again? > If we're adding in a whole collection of entities, like the 30+ rows > required for a PDU, and the max value would fall in the middle of the > 30+ row group, should we count up to the max value and THEN rollover; or > should we rollover first and find a contiugous block to use? Usually, you count up until you roll over. But realistically speaking, how fast do physical entities change in the real world and what is the overall time it takes to roll over? > > Note that entPhysicalUris can carry UUID URNs (see RFC 4122). > > So it sounds like all of the questions in the above quoted block are > answered by using entPhysicalUris to carry a UUID for the entity in > question. This allows us to vary the entPhysicalIndex arbitrarily, but > gives the EMS/BMS/NMS a constant identifier for the entity. Yes, entPhysicalUris can provide a persistent identifier for the physical entity. That does however not imply that varying entPhysicalIndex arbitrarily is going to be a good thing. You like to keep the stable so that a EMS/BMS/NMS does not constantly have to resynchronize. > As I indicated above, I do think that outlet groups should be supported > on a device. It's a question of whether we want to simplify complexity. > Consider the following scenario: > > An outlet gang has two three-phase AC outlets in it. One of the > outlets is wired as a 3PH Wye (line-neutral) and the other as a 3PH > Delta (line-line). > > To "gang" these two outlets together for data reporting purposes > requires a mathematical technique known as symmetric component analysis. > The 3PH Delta entity must be converted to the 3PH Wye equivalent, and > then the two vector tuples can be combined. > > An EMS/BMS/NMS administrator should never try to figure this out on > their own. It's a fairly complex process, and definitely part of a > specific domain of knowledge that is unknown to many network > administrators. Therefore, we should let the equipment manufacturer who > has that specialized knowledge do all of the "heavy lifting" and just > simply expose the solution to the user as a logical entity. See, I am all ignorant about power supplies. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@quittek.at Tue Mar 8 08:47:00 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1248D3A68B1 for ; Tue, 8 Mar 2011 08:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSP5fYaLhZC9 for ; Tue, 8 Mar 2011 08:46:57 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 4BF313A6827 for ; Tue, 8 Mar 2011 08:46:56 -0800 (PST) Received: from [192.168.1.132] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MBIsH-1PnP9K3MzV-00Aj3B; Tue, 08 Mar 2011 17:47:40 +0100 References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-13--826907470 Message-Id: <5FA5BD45-2905-45FA-A8C3-58972BF71FA4@quittek.at> From: Juergen Quittek Date: Tue, 8 Mar 2011 17:47:19 +0100 To: Mouli Chandramouli (moulchan) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:Mu2o79W9C3g5EkUv2/y/zuD6snr2zvqegzY868CDv4a IWG4A03kJJALsW6abtAYE2gsMhv+v8j+7Ck/KQx5EF9yh06GFB 3vE20Lsq9lZotX8sCsWLFhOuRsSrY/chFw9yYBgqAGZVjni0zV gvGYHWtmDroHtL2eBIjLitzapaqBbYn0qz+FnA7ypG7UFkfBpZ bhc2YFEtDxhIlx7pYyrkw== Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:47:00 -0000 --Apple-Mail-13--826907470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Mouli, Thanks for the summary. That's a good description of the option of=20 treating battery and PC as separate entities But now comes the fun part. Folks here asked for mapping entities to domains, such as=20 'metering domains' and 'power distribution domains'. The problem I see if we treat battery and PC separately is that the PC switches domains whenever switching from main power=20 to battery power or vice versa. I am afraid that this breaks the=20 concept of fixed domains of an entity.=20 It may also break the assumption of constant parent-child relationships. Take this example: There is an external meter measuring the power of the PC. The meter acts as the PC's and the battery's direct parent and reports the visible external power consumed. Now, if you take the battery (or UPS) as = separate entity, it may have its own charging controller and measure charging and=20= draining and report on this. The conclusion is that the PC changes its=20= parent whenever switching from main power to battery power and vice = versa. Hence, the separate treatment of battery and PC requires us to consider dynamic memberships in domains and dynamic parent-child relationships. Thanks, Juergen Am 08.03.2011 um 11:07 schrieb Mouli Chandramouli (moulchan): > Hi Juergen, > =20 > Firstly, Battery for a PC can be analogous to a UPS for a Data center.=20= > During Power outages, UPS can provide power for the network elements = in a Data center for a finite period of time. > =20 > I think a solution to the question you have posed can be to decouple = the device and the battery. =20 > =20 > As a first step, I think it would be useful to understand if the = device is on direct power or on UPS/battery power =96 not sure if this = has been captured in the MIB modules. > =20 > If it is direct power, then we have the measurement variables defined. > If the device is on battery (or storage) power, it may be more useful = to monitor the drain rate of the battery alone. =20 > =20 > Regarding the scenarios you have indicated, and if the device is = switched-off (ACPI G3-S5 (Off-Hard)), > then power consumed is only for the battery charging. Device state is = G3-S5 (Off-Hard), while the battery state is =93Charging=94. =20 > =20 > So, if we consider the following equation, > =20 > Power consumption of a device =3D power consumption from the grid + = power drained from storage/battery, > in case power consumption from grid is zero, the power consumption of = device is non-zero. > =20 > Thanks > Mouli > =20 > =20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of Juergen Quittek > Sent: Thursday, March 03, 2011 2:14 AM > To: Benoit Claise (bclaise) > Cc: eman mailing list; Bruce Nordman > Subject: Re: [eman] Power States - really > =20 > Hi all, > =20 > Just a short question: > =20 > Which power state would apply to my notebook computer when > =20 > - it is switched of, but charging its batteries.=20 > This is an off-state with relatively high power consumption.=20 > Is this covered by any ACPI or DMTF states or by the states in the = drafts we have? > =20 > - it is switched on and fully operational, but running on built-in = battery only. > This is an operational state with zero power consumption, at least = as seen from outside. > Again, how can we cover this with states described so far? > =20 > Thanks, > =20 > Juergen > =20 > =20 > Am 02.03.2011 um 18:39 schrieb Benoit Claise: >=20 >=20 > Dear all, >=20 > In the industry, there are multiple series of power states: > - The ACPI standard. In practice, mainly used for PCs in case of non = operational power states > - The DMTF Power State Management Profile defines an information = model over web services. The DMTF has 6 power states, 5 of them = non-operational. They merged all operational power states into a single = one: "on". > - Some manufacturers have their own power state series. >=20 > And there is an attempt to define the EMAN states in the EMAN = framework, which would be a new power states series, at least for the = operational ones. >=20 > In the world of PCs in case of non operational power states, ACPI = seems well accepted. > However, my point is the following: there is no clear winner in terms = of adopted series of power state in the industry. > I believe I would be dangerous to bet on power state series based on = our knowledge today. The industry will decide, and maybe it will be a = new power states series. >=20 > What I believe the solution is in terms of EMAN: > - we must be ready to support multiple power states series > - we must be ready to support a new power states series.=20 > - the device must report which power states series it supports > In conclusion: be flexible and support all >=20 > Regards, Benoit. >=20 >=20 > I am reposting Juergen's email about power states. > While the subsequent discussion has been important > and useful, it is on a different topic. So, please let's > also make progress on this topic. > --Bruce >=20 > On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek = wrote: > Dear all, >=20 > We have two proposals for a Power/Energy MIB module: >=20 > - draft-claise-energy-monitoring-mib-06 > - draft-quittek-power-mib-02 >=20 > Among the authors of both documents we are currently trying to merge = them. > But there are some open issues that should be discussed on the mailing > list. Here is the probably biggest of them: modeling power states. >=20 > For simplifying energy management we want to introduce the concept of > power states (aka power levels). A power state will indicate roughly = how > much power a device consumes. Examples for simple power states are = off, > sleep, and operational states. >=20 > In the envisioned EMAN MIB modules, a power state is characterized by = a > descriptive name and the device's expected power input in this state > (max/min/average). >=20 > Power states are not a new concept. The DMTF has already defined a = set of > power states and there is the Other standards bodies as the DMTF > (Distributed Management Task Force) and there is the ACPI (Advanced > Configuration and Power Interface) for PC motherboards. And there may = be > more than these out there. I listed some DMTF and ACPI states at the = end > of this message. >=20 > An easy solution for EMAN would be just adopting one of these sets. > However, there are issues with the ones we looked at. ACPI was = developed > for PC motherboards and is quite PC-centric. Also it defines states = that > seem to be superfluous, because so far, almost no one has implemented > them. Also the DMTF model seems to have a narrower scope than = envisioned > by the EMAN WG. >=20 > At some point in time, the EMAN WG hast to make a decision, which = power > state model to adopt. Here is a set of alternatives. The first four = have > fixed sets of power states. >=20 > Option 1: fixed minimum > Just support three power states (off, sleep (stand-by), operational) > This has clear semantics, but there are several people claiming it's = too > restrictive. >=20 > Option 2: fixed DMTF > Just use the states defined by DMTF. > Might be too much focussed n PCs. >=20 > Option 3: fixed ACPI > Just use the states defined by ACPI. > Might be too much focussed n PCs. >=20 >=20 >=20 > Option 4: fixed EMAN > Define a new fixed set of power levels within the EMAN WG. >=20 > Option 5: IANA-registered power states > Have power states be registered at IANA. > We would start with registering (off, sleep, operational, the DMTF = set, > and the ACPI set. > Manufacturers can then register further ones. >=20 >=20 > There has been discussions pointing out that these fixed sets may not = be > sufficient, particularly if non-IT equipment should also be covered. >=20 > For being more open, the idea to support user-defined or > manufacturer-defined power states of devices has been developed. In = such > a state, for example, certain components of a device may be switched = off > or put to sleep. Which ones are switched off in which state is to be > defined by the user/operator/manufacturer and may be chosen such that > operational needs are met. >=20 > Again, there are several proposals how to do this. All of them favor = a > two-level approach that distinguishes between rather flexible = functional > power states and rather fixed basic power states. Functional power = states > would be defined by the manufacturer, operator, or user. These would = be > the power states that would be reported by a device. However, in = order to > better define the semantics of functional power states, Each of these > would be mapped to exactly one basic power states. This means that a > property of any functional state would be the basic state it maps to. > Basic power states would be fixed, such as the ones used in options = 1-5. > An easy example would be functional power states defined by > user/operator/manufacturer with each state indicating whether it is an = off > state, a sleep state or an operational state. >=20 > Here are the corresponding options: >=20 > Option 6: flexible functional states mapped to a fixed set of basic = states > States could be defined flexibly. But each state would indicate a = basic > state to which it corresponds. Basic states could be either basic > (off/sleep/operational) or the DMTF set or the ACPI set >=20 > Option 7: flexible functional states mapped to a IANA registered set = of > basic states > This is like Option 6, but basic states would be registered at IANA = and > can be extended. We would register all DMTF and ACPI states and = probably > some more at IANA. Manufacturers could add more. >=20 > Option 8: IANA-registered sets of functional states, only three basic > states > The main reasoning behind this option is that is should always be = clear > whether a power state is an off state, a sleep state, or an = operational > state. Therefore, only these three basic states are supported. This > would be in line with an instance of Option 6. However, this option = has > an extension for the functional states. It suggests that for = customizing > devices in order to be compliant with given management systems, for > example a DMTF-based system, it should be possible to restrict = functional > power states to a given set that is registered at IANA. An example = would > be the DMTF states. We would register a flag at IANA that indicates = we > are using DMTF states only. This would signal the management = application > that all power state IDs are in line with power state numbering as = defined > by IANA. Analogously, ACPI and further sets could be registered at = IANA. > A fallback to Option 6 could be realized by registering a set number = of 0 > at IANA that does not impose any limit for functional states. >=20 > Obviously, there are more possible options. If you think there is a > better one, please send it to this list. >=20 > I know this discussion is not easy, but we have to have it in order to > make the right decision in the EMAN WG. Please take some time and = think > about what you consider to be the best way to go. And of course send > questions on the issue. >=20 > Thanks. >=20 > Juergen >=20 >=20 > DMTF (Distributed Management Task Force) power states: > - 2 (Power On) > - 3 (Sleep - Light) > - 4 (Sleep - Deep) > - 5 (Power Cycle (Off Soft)) > - 6 (Power Off - Hard) > - 7 (Hibernate) > - 8 (Power Off - Soft) > - 9 (Power Cycle (Off Hard)) > - 10 (Master Bus Reset) > - 11 (Diagnostic Interrupt (NMI)) > - 12 (Power Off - Soft Graceful) > - 13 (Power Off - Hard Graceful) > - 14 (Master Bus Reset Graceful) > - 15 (Power Cycle (Off - Soft Graceful)) > - 16 (Power Cycle (Off - Hard Graceful)) >=20 > ACPI (Advanced Configuration and Power Interface Specification) power > states for PC motherboards: > - G3-S5 (Off-Hard) > - G2-S5 (Off-Soft) > - G1-S4 (Hibernate) > - G1-S3 (Sleep-Deep) > - G1-S2 (Sleep-Light) > - G1-S1 (Sleep-Light) > - G0-S0-P5 > - G0-S0-P4 > - G0-S0-P3 > - G0-S0-P2 > - G0-S0-P2 > - G0-S0-P2 >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 >=20 >=20 > --=20 > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 >=20 > =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 --Apple-Mail-13--826907470 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Mouli,

Thanks for the = summary. That's a good description of the option = of 
treating battery and PC as separate ent
But now comes the fun part.
Folks here asked = for mapping entities to domains, such as 
'metering = domains' and 'power distribution domains'.
The problem I see if we treat battery and PC = separately is that
the PC switches domains whenever switching = from main power 
to battery power or vice versa. I am afraid = that this breaks the 
concept of fixed = domains of an entity. 
It may also break the assumption of = constant parent-child relationships.
Take this = example:
There is an external meter measuring the = power of the PC. The meter
acts as the PC's and the battery's direct = parent and reports the visible
external power consumed. Now, if you take the = battery (or UPS) as separate
entity, it may have its own = charging controller and measure charging = and 
draining and report on this. The conclusion = is that the PC changes its 
parent whenever = switching from main power to battery power and vice = versa.

Hence, the separate treatment of battery and = PC requires us to consider
dynamic memberships in domains and dynamic = parent-child relationships.

Thanks,

   =  Juergen


Am = 08.03.2011 um 11:07 schrieb Mouli Chandramouli (moulchan):

Hi = Juergen,
I = think a solution to the question you have posed can be to decouple the = device and the battery.   
As a = first step,  I think it would be useful to understand if the device = is on direct power or on UPS/battery power =96 not sure if this has been = captured in the MIB modules.
If it = is direct power, then we have the measurement variables = defined.
If = the device is on battery (or storage) power, it may be more useful to = monitor the drain rate of the  battery alone. =  
then power consumed is only for = the battery charging.  Device state is G3-S5 (Off-Hard), while the = battery state is =93Charging=94. =    
So, = if we consider the following equation,
Power = consumption of a device =3D power consumption from the grid + power = drained from storage/battery,
in case power consumption from = grid is zero, the power consumption of  device is = non-zero.
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org= ] On Behalf Of Juergen = Quittek
Sent: Thursday, March 03, 2011 = 2:14 AM
To: Benoit Claise = (bclaise)
Cc: eman mailing list; Bruce = Nordman
Subject: Re: [eman] Power States - = really
Hi = all,
Just a short = question:
Which power state would = apply to my notebook computer when
 
  - = it is switched of, but charging its = batteries. 
   =  This is an off-state with relatively high power = consumption. 
   =  Is this covered by any ACPI or DMTF states or by the states in the = drafts we have?
  - it is = switched on and fully operational, but running on built-in battery = only.
    This = is an operational state with zero power consumption, at least as seen = from outside.
    Again, = how can we cover this with states described so = far?
   =  Juergen
Am 02.03.2011 um 18:39 = schrieb Benoit Claise:
Dear all,

In the = industry, there are multiple series of power states:
-  The ACPI = standard. In practice, mainly used for PCs in case of non operational = power states
-  The DMTF Power State Management Profile defines = an information model over web services. The DMTF has 6 power states, 5 = of them non-operational. They merged all operational power states into a = single one: "on".
- Some manufacturers have their own power state = series.

And there is an attempt to define the EMAN states in the = EMAN framework, which would be a new power states series, at least for = the operational ones.

In the world of PCs in case of non = operational power states, ACPI seems well accepted.
However, my point = is the following: there is no clear winner in terms of adopted series of = power state in the industry.
I believe I would be dangerous to bet on = power state series based on our knowledge today. The industry will = decide, and maybe it will be a new power states series.

What I = believe the solution is in terms of EMAN:
- we must be ready to = support multiple power states series
- we must be ready to support a = new power states series. 
- the device must = report which power states series it supports
In conclusion: be = flexible and support all

Regards, = Benoit.


I am reposting Juergen's email about power states.
While the = subsequent discussion has been important
and useful, it is on a = different topic.  So, please let's
also make progress on this = topic.
--Bruce

On Mon, Feb 28, 2011 at = 4:07 AM, Juergen Quittek <Dear all,

We have two proposals for a Power/Energy MIB = module:

 - draft-claise-energy-monitoring-mib-06
 - = draft-quittek-power-mib-02

Among the authors of both documents we = are currently trying to merge them.
But there are some open issues = that should be discussed on the mailing
list.  Here is the = probably biggest of them: modeling power states.

For simplifying = energy management we want to introduce the concept of
power states = (aka power levels).  A power state will indicate roughly = how
much power a device consumes.  Examples for simple power = states are off,
sleep, and operational states.

In the = envisioned EMAN MIB modules, a power state is characterized by = a
descriptive name and the device's expected power input in this = state
(max/min/average).

Power states are not a new concept. =  The DMTF has already defined a set of
power states and there is = the Other standards bodies as the DMTF
(Distributed Management Task = Force) and there  is the ACPI (Advanced
Configuration and Power = Interface) for PC motherboards.  And there may be
more than = these out there.  I listed some DMTF and ACPI states at the = end
of this message.

An easy solution for EMAN would be just = adopting one of these sets.
However, there are issues with the ones = we looked at.  ACPI was developed
for PC motherboards and is = quite PC-centric.  Also it defines states that
seem to be = superfluous, because so far, almost no one has implemented
them. =  Also the DMTF model seems to have a narrower scope than = envisioned
by the EMAN WG.

At some point in time, the EMAN WG = hast to make a decision, which power
state model to adopt.  Here = is a set of alternatives. The first four have
fixed sets of power = states.

Option 1: fixed minimum
Just support three power = states (off, sleep (stand-by), operational)
This has clear semantics, = but there are several people claiming it's = too
restrictive.

Option 2: fixed DMTF
Just use the states = defined by DMTF.
Might be too much focussed n PCs.

Option 3: = fixed ACPI
Just use the states defined by ACPI.
Might be too much = focussed n PCs.



Option 4: fixed EMAN
Define a new = fixed set of power levels within the EMAN WG.

Option 5: = IANA-registered power states
Have power states be registered at = IANA.
We would start with registering (off, sleep, operational, the = DMTF set,
and the ACPI set.
Manufacturers can then register = further ones.


There has been discussions pointing out that = these fixed sets may not be
sufficient, particularly if non-IT = equipment should also be covered.

For being more open, the idea = to support user-defined or
manufacturer-defined power states of = devices has been developed.  In such
a state, for example, = certain components of a device may be switched off
or put to sleep. =  Which ones are switched off in which state is to be
defined by = the user/operator/manufacturer and may be chosen such = that
operational needs are met.

Again, there are several = proposals how to do this.  All of them favor a
two-level = approach that distinguishes between rather flexible functional
power = states and rather fixed basic power states.  Functional power = states
would be defined by the manufacturer, operator, or user. =  These would be
the power states that would be reported by a = device.  However, in order to
better define the semantics of = functional power states, Each of these
would be mapped to exactly one = basic power states.  This means that a
property of any = functional state would be the basic state it maps to.
Basic power = states would be fixed, such as the ones used in options 1-5.
An easy = example would be functional power states defined = by
user/operator/manufacturer with each state indicating whether it = is an off
state, a sleep state or an operational state.

Here = are the corresponding options:

Option 6: flexible functional = states mapped to a fixed set of basic states
States could be defined = flexibly.  But each state would indicate a basic
state to which = it corresponds. Basic states could be either = basic
(off/sleep/operational) or the DMTF set or the ACPI = set

Option 7: flexible functional states mapped to a IANA = registered set of
basic states
This is like Option 6, but basic = states would be registered at IANA and
can be extended.  We = would register all DMTF and ACPI states and probably
some more at = IANA. Manufacturers could add more.

Option 8: IANA-registered = sets of functional states, only three basic
states
The main = reasoning behind this option is that is should always be = clear
whether a power state is an off state, a sleep state, or an = operational
state.  Therefore, only these three basic states are = supported.  This
would be in line with an instance of Option 6. =  However, this option has
an extension for the functional = states.  It suggests that for customizing
devices in order to be = compliant with given management systems, for
example a DMTF-based = system, it should be possible to restrict functional
power states to = a given set that is registered at IANA.  An example would
be the = DMTF states.  We would register a flag at IANA that indicates = we
are using DMTF states only.  This would signal the management = application
that all power state IDs are in line with power state = numbering as defined
by IANA.  Analogously, ACPI and further = sets could be registered at IANA.
A fallback to Option 6 could be = realized by registering a set number of 0
at IANA that does not = impose any limit for functional states.

Obviously, there are more = possible options.  If you think there is a
better one, please = send it to this list.

I know this discussion is not easy, but we = have to have it in order to
make the right decision in the EMAN WG. =  Please take some time and think
about what you consider to be = the best way to go.  And of course send
questions on the = issue.

Thanks.

   Juergen


DMTF = (Distributed Management Task Force) power states:
 - 2 (Power = On)
 - 3 (Sleep - Light)
 - 4 (Sleep - Deep)
 - = 5 (Power Cycle (Off Soft))
 - 6 (Power Off - Hard)
 - 7 = (Hibernate)
 - 8 (Power Off - Soft)
 - 9 (Power Cycle = (Off Hard))
 - 10 (Master Bus Reset)
 - 11 (Diagnostic = Interrupt (NMI))
 - 12 (Power Off - Soft Graceful)
 - 13 = (Power Off - Hard Graceful)
 - 14 (Master Bus Reset = Graceful)
 - 15 (Power Cycle (Off - Soft Graceful))
 - = 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced = Configuration and Power Interface Specification) power
states for PC = motherboards:
 - G3-S5 (Off-Hard)
 - G2-S5 = (Off-Soft)
 - G1-S4 (Hibernate)
 - G1-S3 = (Sleep-Deep)
 - G1-S2 (Sleep-Light)
 - G1-S1 = (Sleep-Light)
 - G0-S0-P5
 - G0-S0-P4
 - = G0-S0-P3
 - G0-S0-P2
 - G0-S0-P2
 - = G0-S0-P2




______________________________________________= _
eman mailing list
eman@ietf.org



-- 
Bruce Nordman
Lawrence Berkeley National = Laboratory
 
eman =
mailing list
 

<= /div>= --Apple-Mail-13--826907470-- From blueroofmusic@gmail.com Tue Mar 8 11:53:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C561A3A6959 for ; Tue, 8 Mar 2011 11:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wXDu4eCAG5e for ; Tue, 8 Mar 2011 11:53:26 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6E8223A6814 for ; Tue, 8 Mar 2011 11:53:26 -0800 (PST) Received: by fxm15 with SMTP id 15so5939068fxm.31 for ; Tue, 08 Mar 2011 11:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=42Ff8WzB11GzyLXKuVclJRf2W/c0tfxMjGcvPQhwkZo=; b=XnnNWw7/eGh48MiZzu3W0WpOrq4j17fUbKmlW3wdA4V+Czmegs4KWI/OhI0AfB2dUD d8sMhnXBBNvhkd3axEuvE/LNGMenTMyuAEV527Gd/OVhn0VR2h6K8OmVj+sE8/4CYtfU CSitwEkmG4sSU7wlc/SlyPAYgXGcX7IolHPEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mJtGZh9CdSOXjA9RsICQbDzFMvmEGuz9ghx32iJ7Vm7IfgaIbE+H/4ZbAKeJtezuJH cy1aJ6hGDpYjQJDxpYi54e89MDYnHLKZcCOfqSg24BbVQnhIkVqoNgjEruVfn1hr4PjP r6PS+fAZrFAmlQTKKqZkyE8wnfwq3vD8yQYjM= MIME-Version: 1.0 Received: by 10.223.95.199 with SMTP id e7mr4237358fan.82.1299613953272; Tue, 08 Mar 2011 11:52:33 -0800 (PST) Received: by 10.223.66.68 with HTTP; Tue, 8 Mar 2011 11:52:33 -0800 (PST) Date: Tue, 8 Mar 2011 14:52:33 -0500 Message-ID: From: Ira McDonald To: eman mailing list , Ira McDonald Content-Type: multipart/alternative; boundary=00248c176bae07b59d049dfdf4e7 Subject: [eman] Harmonizing standard and vendor power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 19:53:27 -0000 --00248c176bae07b59d049dfdf4e7 Content-Type: text/plain; charset=ISO-8859-1 Hi, To address the tension between using standard enumerated power states and the finer-grained power states many vendors actually support, we used the following approach in our recent IEEE-ISTO PWG Imaging System Power Management Model and companion concrete PWG Imaging System Power MIB: (1) We standardized on the set of DMTF CIM power states. (2) We multiplied all standard DMTF CIM power state enumerated values by 10 and inserted 5 vendor extension power states (i.e., substates) for the base stable states. (3) So our base state 'on(20)' can be augmented by up to 5 more substates: 'onVendor1(21)' through 'onVendor5(25)'. (4) We defined a rule that actual power consumption in vendor extension states MUST be strictly ordered, such that for example 'onVendor1(21)' MUST consume equal or greater power than the base state 'on(20)' - then for interoperability all vendor extension states can be collapsed into their corresponding base states for mapping to DMTF CIM interfaces. (5) We defined a PowerSupport group of properties that gave more details about each base or vendor extension stable state. PowSupportEntry ::= SEQUENCE { powSupportPowerState PowPowerStateTC, powSupportPowerInactiveWatts Integer32, powSupportPowerActiveWatts Integer32, powSupportCanAcceptJobs TruthValue, powSupportCanProcessJobs TruthValue, powSupportCanRequestPowerState TruthValue, powSupportCanUseInterfaces DisplayString, powSupportPowerPeakWatts Integer32 } Perhaps this approach would be useful in the IETF EMAN effort. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Christmas through April: 579 Park Place Saline, MI 48176 734-944-0094 May to Christmas: PO Box 221 Grand Marais, MI 49839 906-494-2434 --00248c176bae07b59d049dfdf4e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

To address the tension between using standard enumerated powerstates and the finer-grained power states many vendors actually
suppor= t, we used the following approach in our recent IEEE-ISTO
PWG Imaging S= ystem Power Management Model and companion
concrete PWG Imaging System Power MIB:

(1) We standardized on the se= t of DMTF CIM power states.

(2) We multiplied all standard DMTF CIM = power state enumerated
values by 10 and inserted 5 vendor extension powe= r states (i.e.,
substates) for the base stable states.

(3) So our base state 'on= (20)' can be augmented by up to 5 more
substates:=A0 'onVendor1(= 21)' through 'onVendor5(25)'.

(4) We defined a rule that= actual power consumption in vendor
extension states MUST be strictly ordered, such that for example
'on= Vendor1(21)' MUST consume equal or greater power than the
base state= 'on(20)' - then for interoperability all vendor extension
state= s can be collapsed into their corresponding base states for
mapping to DMTF CIM interfaces.

(5) We defined a PowerSupport group = of properties that gave more
details about each base or vendor extension= stable state.

P= owSupportEntry ::=3D SEQUENCE {
=A0=A0=A0=A0=A0=A0=A0 p= owSupportPowerState=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PowPowerStateTC,
=A0=A0=A0=A0=A0=A0=A0 powSupportPowerInactiveWa= tts=A0=A0=A0 Integer32,
=A0=A0=A0=A0=A0=A0=A0 p= owSupportPowerActiveWatts=A0=A0=A0=A0=A0 Integer32,
=A0=A0=A0=A0=A0=A0=A0 powSupportCanAcceptJobs=A0=A0=A0=A0=A0=A0= =A0=A0 TruthValue,
=A0=A0=A0=A0=A0=A0=A0 p= owSupportCanProcessJobs=A0=A0=A0=A0=A0=A0=A0 TruthValue,
=A0=A0=A0=A0=A0=A0=A0 powSupportCanRequestPowerState=A0 Trut= hValue,
=A0=A0=A0=A0=A0=A0=A0 p= owSupportCanUseInterfaces=A0=A0=A0=A0=A0 DisplayString,
=A0=A0=A0=A0=A0=A0=A0 powSupportPowerPeakWatts=A0=A0=A0=A0=A0= =A0=A0 Integer32
=A0=A0=A0 }
<= br>Perhaps this approach would be useful in the IETF EMAN effort.

Ch= eers,
- Ira


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

--00248c176bae07b59d049dfdf4e7-- From moulchan@cisco.com Wed Mar 9 01:10:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C653C3A68D8 for ; Wed, 9 Mar 2011 01:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye9Dt6vVRPuD for ; Wed, 9 Mar 2011 01:10:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id F10603A68D5 for ; Wed, 9 Mar 2011 01:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=6464; q=dns/txt; s=iport; t=1299661902; x=1300871502; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ovnwo+YMUQfdpFImwg4zTyFm+t3hq8BW7IRUxEQvjtg=; b=fONKcehVhIu2RaPDif9lWAWq3KJdSxl5c3NVH46m7tU7UibftP4K0gF7 DzCLT5BdNkRaxwVHNXyhuTTGBVjykN3raoBexvuLodg4PbKi9mM7fryw8 BN+zfDI1HpoCs84SoyEKvrFj8xwaOZYcoNAakUc9f5W+T3Ri59xmCFSmq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAPPSdk2tJXG//2dsb2JhbACYP44sdKZZnCMCgxaCTQSFIopm X-IronPort-AV: E=Sophos;i="4.62,289,1297036800"; d="scan'208";a="273047170" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2011 09:11:41 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p299Bf6E018878; Wed, 9 Mar 2011 09:11:41 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 03:11:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2011 03:11:35 -0600 Message-ID: In-Reply-To: <20110308135228.GA37400@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: eman] modeling power states - Entity-MIB Thread-Index: AcvdmCMYvdz28WANQRa7Ar0MUtYDgQAnpfQA References: <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> <0E32737B-484D-4263-9749-149E61601B03@quittek.at> <20110308135228.GA37400@elstar.local> From: "Mouli Chandramouli (moulchan)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 09 Mar 2011 09:11:41.0284 (UTC) FILETIME=[00C91A40:01CBDE3A] Cc: eman mailing list Subject: Re: [eman] eman] modeling power states - Entity-MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 09:10:27 -0000 Hello Juergen S. Thanks for your comments. Certainly your due diligence and questions are appreciated.=20 Replies in line. Thanks Mouli -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, March 08, 2011 7:23 PM To: Mouli Chandramouli (moulchan) Cc: Romascanu, Dan (Dan); Juergen Quittek; eman mailing list Subject: Re: eman] modeling power states - Entity-MIB On Tue, Mar 08, 2011 at 12:52:00AM -0600, Mouli Chandramouli (moulchan) wrote: =20 > If I recall, we had this discussion on the applicability of Entity-MIB > at Anaheim - IETF77 meeting.=20 Let me start by explaining my involvement in this discussion: I am not pushing for the ENTITY-MIB as _the_ solution for EMAN. All I am looking for is that the design decision is taken well informed and that the decision subsequently is well documented. What caused me to speak up on this list was some confusion I think some people seemed to have about some of the features of the ENTITY-MIB and the lack of any text in the documents explaining how EMAN objects relates to the ENTITY-MIB. Of course, now I am also playing a bit devil's advocate in order to make sure any possible reasons to not extend the ENTITY-MIB are becoming clear. > Here is my understanding and summary.=20 >=20 > Clearly for power monitoring of network devices, it can be argued that > Entity MIB should be almost sufficient.=20 > In the requirements draft, > http://tools.ietf.org/html/draft-ietf-eman-requirements-00 there is a > requirement to collect power consumption as a system and also as a > breakdown of subcomponents. There are sub-components of network devices > that are not considered in Entity MIB RFC 4133 such as ASICs and Memory; > i.e. if there is interest to measure power consumption of those > components.=20 > It has been observed in benchmarking studies that TCAMs in network > devices are power hungry.=20 > http://www.hpl.hp.com/personal/Partha_Ranganathan/papers/2009/2009_netwo > rking_metrics.pdf >=20 > The intent of the entity MIB is for a different purpose and now its > current application is different. Given that physical devices can > consume power; we are trying to reuse the entity-MIB as much as > possible. Clearly, some of the physical components listed are quite > handy from a power monitoring point of view - Chassis, power Supply, > fan, module, port, cpu, stack etc. However, the value of assigning a > power value to Unknown or Other (as a component) is not clear. =20 I agree that the PhysicalClass TC should have been under IANA control to enable extensibility. On the other hand, I have not seen anything in the EMAN MIB proposals that is not also in the ENTITY-MIB. In fact, most EMAN MIBs seem to use simple SnmpAdminStrings, which enables a great deal of flexibility but also makes automation hard if every vendor can label components in arbitrary ways. In other words, the ENTITY-MIB even today is not "worse" than the other proposals (correct me if I am missing something) and it could be fixed by moving the PhysicalClass TC under IANA control. YCM> Agreed. There are two questions. How long will it to update the Physical Class TC ?=20 YCM> There is a clear need for energy monitoring in networks now.=20 YCM> So, this approach seemed as an interim solution. YCM> Secondly, entity-MIB is widely implemented in networking devices.=20 YCM> Other power consuming devices such as non-POE devices or building HVAC devices=20 YCM> have not implemented the Entity-MIB.=20 > Beyond the Entity-MIB, LLDP-MED and RFC3621 provides power > negotiation of PoE devices - between a network device (switch) and > an attached device (phone). An attempt has been made to reuse the > pmLldpPortNumber in those scenario. The entAliasMappingTable provides an extensible set of pointers to other MIB table entries that may even exist in other logial entities (contexts). I am not familiar with pmLldpPortNumber, so I am not sure what exactly this is. But existing devices use this mechanism already to relate "port" physical entities to network interfaces. For me, it is most important that relationships between number spaces are well documented so that it is clear how management applications can relate the bits and pieces they get from various MIB modules. And with every additional number space, the pain on the manager side usually increases (and on the device itself unless the devices chooses to not provide the relevant mapping information). > There are also network power monitoring scenarios, when the device is > drawing power from a wall outlet or building HVAC devices and would not > have entPhysicalIndex or pmLldpPortNumber. In those situations, we had > proposed the use of pmIndex.=20 Why do these devices not have entPhysicalIndex or why can't they have an entPhysicalIndex? We do have wirelesse sensor nodes and they do manage to report an entPhysicalIndex. YCM> Sane comment as before. Some of these devices may not implement the Entity-MIB.=20 > There was also a point made in the last WG meeting, power > consumption of software components (not just physical components) > should also be considered. For e.g. an Email program on some > platforms can consume power which can be noticed by the rate of > battery drain. But you can't really measure this. People proposing something like this likely measure the physical component's power consumption and relate it to running software and its CPU usage via some magic formula. It is not clear to me that this is necessarily expected to be done and reported via an SNMP agent. If you export the power consumption readings of your physical devices to a management system, you can calculate whatever seems useful off the devices and in much more flexible ways. YCM> agreed, good point. Even for some physical devices, there may not be a power sensor YCM> for measurement and may have to be estimated. In fact to handle this scenario, in our proposal, a MIB variable=20 YCM> Measurement Caliber to indicate how the measurement was obtained (by direct measurement, estimation, or the max value, ...)=20 /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From moulchan@cisco.com Wed Mar 9 03:04:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873733A68FE for ; Wed, 9 Mar 2011 03:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kraqk-2qj1j for ; Wed, 9 Mar 2011 03:04:06 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B6F883A681A for ; Wed, 9 Mar 2011 03:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=43454; q=dns/txt; s=iport; t=1299668720; x=1300878320; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=hkIFBAcVm62PExd0s9XnBUbPzqwNNcPWU49emShZooU=; b=Nn5JTBLu1AYBuaSElJ7J9ObXyAH8sA7y3mcSe/oMJwlPKiQxh2O7/z/l szteRIMZ4jhoJ/ZHdkkB7v1qM/kXFO2E8zr+zz5VvNQARZcUQEIiDE2F0 tFf3jKbdkye71HSc1XmD6BQYdkXZE9UhTdiZ9vTVBW0IOR+jNjPQeWTIr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAG/tdk2tJXHB/2dsb2JhbACCT5VwhkgBh2N0pimcKIMYgk0EhSKKZg X-IronPort-AV: E=Sophos;i="4.62,289,1297036800"; d="scan'208,217";a="223901931" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 09 Mar 2011 11:05:18 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p29B5IE9028064; Wed, 9 Mar 2011 11:05:18 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 05:05:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDE49.DFF33E8C" Date: Wed, 9 Mar 2011 05:05:15 -0600 Message-ID: In-Reply-To: <5FA5BD45-2905-45FA-A8C3-58972BF71FA4@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power States - really Thread-Index: AcvdsKGySD8W7zLTShC9aodnrhPprQAkyOiA References: <4D6E80B8.6060002@cisco.com> <919FE312-33DE-4520-9C53-5E86AD059A2A@quittek.at> <5FA5BD45-2905-45FA-A8C3-58972BF71FA4@quittek.at> From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" X-OriginalArrivalTime: 09 Mar 2011 11:05:18.0764 (UTC) FILETIME=[E051FEC0:01CBDE49] Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power States - really X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 11:04:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDE49.DFF33E8C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Juergen, =20 Thanks for the email and interesting follow-up questions you have posed - which probably would require more discussion on a separate thread.=20 =20 On the narrow question, I would like to add -=20 =20 In the case of battery and PC, the PC has an IP address and battery is an adjunct device.=20 The battery usage/drain can be observed only when the PC is ON. =20 So, the battery should not be considered a parent, IMHO.=20 =20 Thanks Mouli PS: If I can inject some humor, the role of a parent should be more permanent and not transient lasting only a finite time.=20 =20 From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Tuesday, March 08, 2011 10:17 PM To: Mouli Chandramouli (moulchan) Cc: Benoit Claise (bclaise); eman mailing list; Bruce Nordman Subject: Re: [eman] Power States - really =20 Hi Mouli, =20 Thanks for the summary. That's a good description of the option of=20 treating battery and PC as separate entities =20 But now comes the fun part. Folks here asked for mapping entities to domains, such as=20 'metering domains' and 'power distribution domains'. =20 The problem I see if we treat battery and PC separately is that the PC switches domains whenever switching from main power=20 to battery power or vice versa. I am afraid that this breaks the=20 concept of fixed domains of an entity.=20 =20 It may also break the assumption of constant parent-child relationships. Take this example: There is an external meter measuring the power of the PC. The meter acts as the PC's and the battery's direct parent and reports the visible external power consumed. Now, if you take the battery (or UPS) as separate entity, it may have its own charging controller and measure charging and draining and report on this. The conclusion is that the PC changes its=20 parent whenever switching from main power to battery power and vice versa. =20 Hence, the separate treatment of battery and PC requires us to consider dynamic memberships in domains and dynamic parent-child relationships. =20 Thanks, =20 Juergen =20 =20 Am 08.03.2011 um 11:07 schrieb Mouli Chandramouli (moulchan): Hi Juergen, =20 Firstly, Battery for a PC can be analogous to a UPS for a Data center.=20 During Power outages, UPS can provide power for the network elements in a Data center for a finite period of time. =20 I think a solution to the question you have posed can be to decouple the device and the battery. =20 =20 As a first step, I think it would be useful to understand if the device is on direct power or on UPS/battery power - not sure if this has been captured in the MIB modules. =20 If it is direct power, then we have the measurement variables defined. If the device is on battery (or storage) power, it may be more useful to monitor the drain rate of the battery alone. =20 =20 Regarding the scenarios you have indicated, and if the device is switched-off (ACPI G3-S5 (Off-Hard)), then power consumed is only for the battery charging. Device state is G3-S5 (Off-Hard), while the battery state is "Charging". =20 =20 So, if we consider the following equation, =20 Power consumption of a device =3D power consumption from the grid + = power drained from storage/battery, in case power consumption from grid is zero, the power consumption of device is non-zero. =20 Thanks Mouli =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Thursday, March 03, 2011 2:14 AM To: Benoit Claise (bclaise) Cc: eman mailing list; Bruce Nordman Subject: Re: [eman] Power States - really =20 Hi all, =20 Just a short question: =20 Which power state would apply to my notebook computer when =20 - it is switched of, but charging its batteries.=20 This is an off-state with relatively high power consumption.=20 Is this covered by any ACPI or DMTF states or by the states in the drafts we have? =20 - it is switched on and fully operational, but running on built-in battery only. This is an operational state with zero power consumption, at least as seen from outside. Again, how can we cover this with states described so far? =20 Thanks, =20 Juergen =20 =20 Am 02.03.2011 um 18:39 schrieb Benoit Claise: Dear all, In the industry, there are multiple series of power states: - The ACPI standard. In practice, mainly used for PCs in case of non operational power states - The DMTF Power State Management Profile defines an information model over web services. The DMTF has 6 power states, 5 of them non-operational. They merged all operational power states into a single one: "on". - Some manufacturers have their own power state series. And there is an attempt to define the EMAN states in the EMAN framework, which would be a new power states series, at least for the operational ones. In the world of PCs in case of non operational power states, ACPI seems well accepted. However, my point is the following: there is no clear winner in terms of adopted series of power state in the industry. I believe I would be dangerous to bet on power state series based on our knowledge today. The industry will decide, and maybe it will be a new power states series. What I believe the solution is in terms of EMAN: - we must be ready to support multiple power states series - we must be ready to support a new power states series.=20 - the device must report which power states series it supports In conclusion: be flexible and support all Regards, Benoit. I am reposting Juergen's email about power states. While the subsequent discussion has been important and useful, it is on a different topic. So, please let's also make progress on this topic. --Bruce On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek wrote: Dear all, We have two proposals for a Power/Energy MIB module: - draft-claise-energy-monitoring-mib-06 - draft-quittek-power-mib-02 Among the authors of both documents we are currently trying to merge them. But there are some open issues that should be discussed on the mailing list. Here is the probably biggest of them: modeling power states. For simplifying energy management we want to introduce the concept of power states (aka power levels). A power state will indicate roughly how much power a device consumes. Examples for simple power states are off, sleep, and operational states. In the envisioned EMAN MIB modules, a power state is characterized by a descriptive name and the device's expected power input in this state (max/min/average). Power states are not a new concept. The DMTF has already defined a set of power states and there is the Other standards bodies as the DMTF (Distributed Management Task Force) and there is the ACPI (Advanced Configuration and Power Interface) for PC motherboards. And there may be more than these out there. I listed some DMTF and ACPI states at the end of this message. An easy solution for EMAN would be just adopting one of these sets. However, there are issues with the ones we looked at. ACPI was developed for PC motherboards and is quite PC-centric. Also it defines states that seem to be superfluous, because so far, almost no one has implemented them. Also the DMTF model seems to have a narrower scope than envisioned by the EMAN WG. At some point in time, the EMAN WG hast to make a decision, which power state model to adopt. Here is a set of alternatives. The first four have fixed sets of power states. Option 1: fixed minimum Just support three power states (off, sleep (stand-by), operational) This has clear semantics, but there are several people claiming it's too restrictive. Option 2: fixed DMTF Just use the states defined by DMTF. Might be too much focussed n PCs. Option 3: fixed ACPI Just use the states defined by ACPI. Might be too much focussed n PCs. Option 4: fixed EMAN Define a new fixed set of power levels within the EMAN WG. Option 5: IANA-registered power states Have power states be registered at IANA. We would start with registering (off, sleep, operational, the DMTF set, and the ACPI set. Manufacturers can then register further ones. There has been discussions pointing out that these fixed sets may not be sufficient, particularly if non-IT equipment should also be covered. For being more open, the idea to support user-defined or manufacturer-defined power states of devices has been developed. In such a state, for example, certain components of a device may be switched off or put to sleep. Which ones are switched off in which state is to be defined by the user/operator/manufacturer and may be chosen such that operational needs are met. Again, there are several proposals how to do this. All of them favor a two-level approach that distinguishes between rather flexible functional power states and rather fixed basic power states. Functional power states would be defined by the manufacturer, operator, or user. These would be the power states that would be reported by a device. However, in order to better define the semantics of functional power states, Each of these would be mapped to exactly one basic power states. This means that a property of any functional state would be the basic state it maps to. Basic power states would be fixed, such as the ones used in options 1-5. An easy example would be functional power states defined by user/operator/manufacturer with each state indicating whether it is an off state, a sleep state or an operational state. Here are the corresponding options: Option 6: flexible functional states mapped to a fixed set of basic states States could be defined flexibly. But each state would indicate a basic state to which it corresponds. Basic states could be either basic (off/sleep/operational) or the DMTF set or the ACPI set Option 7: flexible functional states mapped to a IANA registered set of basic states This is like Option 6, but basic states would be registered at IANA and can be extended. We would register all DMTF and ACPI states and probably some more at IANA. Manufacturers could add more. Option 8: IANA-registered sets of functional states, only three basic states The main reasoning behind this option is that is should always be clear whether a power state is an off state, a sleep state, or an operational state. Therefore, only these three basic states are supported. This would be in line with an instance of Option 6. However, this option has an extension for the functional states. It suggests that for customizing devices in order to be compliant with given management systems, for example a DMTF-based system, it should be possible to restrict functional power states to a given set that is registered at IANA. An example would be the DMTF states. We would register a flag at IANA that indicates we are using DMTF states only. This would signal the management application that all power state IDs are in line with power state numbering as defined by IANA. Analogously, ACPI and further sets could be registered at IANA. A fallback to Option 6 could be realized by registering a set number of 0 at IANA that does not impose any limit for functional states. Obviously, there are more possible options. If you think there is a better one, please send it to this list. I know this discussion is not easy, but we have to have it in order to make the right decision in the EMAN WG. Please take some time and think about what you consider to be the best way to go. And of course send questions on the issue. Thanks. Juergen DMTF (Distributed Management Task Force) power states: - 2 (Power On) - 3 (Sleep - Light) - 4 (Sleep - Deep) - 5 (Power Cycle (Off Soft)) - 6 (Power Off - Hard) - 7 (Hibernate) - 8 (Power Off - Soft) - 9 (Power Cycle (Off Hard)) - 10 (Master Bus Reset) - 11 (Diagnostic Interrupt (NMI)) - 12 (Power Off - Soft Graceful) - 13 (Power Off - Hard Graceful) - 14 (Master Bus Reset Graceful) - 15 (Power Cycle (Off - Soft Graceful)) - 16 (Power Cycle (Off - Hard Graceful)) ACPI (Advanced Configuration and Power Interface Specification) power states for PC motherboards: - G3-S5 (Off-Hard) - G2-S5 (Off-Soft) - G1-S4 (Hibernate) - G1-S3 (Sleep-Deep) - G1-S2 (Sleep-Light) - G1-S1 (Sleep-Light) - G0-S0-P5 - G0-S0-P4 - G0-S0-P3 - G0-S0-P2 - G0-S0-P2 - G0-S0-P2 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 =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 =20 ------_=_NextPart_001_01CBDE49.DFF33E8C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Juergen,

 

Thanks for the email and interesting follow-up questions you have = posed – which probably would require more discussion on a separate = thread.

 

On the narrow question, I would like to add - =

 

In the case of battery and PC, the PC has an IP address and battery = is an adjunct device.

The battery usage/drain can be observed only when the PC is = ON.  

So, the battery should not be considered a parent, IMHO. =

 

Thanks

Mouli

PS: If I can inject some humor, the role of a parent should be more = permanent and not transient lasting only a finite time. =

 

From:= = Juergen Quittek [mailto:ietf@quittek.at]
Sent: Tuesday, March = 08, 2011 10:17 PM
To: Mouli Chandramouli = (moulchan)
Cc: Benoit Claise (bclaise); eman mailing list; = Bruce Nordman
Subject: Re: [eman] Power States - = really

 

Hi = Mouli,

 

Thanks for the summary. That's a good description of = the option of 

treating battery and PC as separate entities

<= p class=3DMsoNormal> 

But now comes the fun = part.

Folks here = asked for mapping entities to domains, such = as 

'metering domains' and 'power distribution = domains'.

 

The problem I see if we treat battery and PC = separately is that

the PC switches domains whenever switching = from main power 

to battery power or vice versa. I am afraid = that this breaks the 

concept of fixed domains of an = entity. 

 

It may also break the assumption of = constant parent-child = relationships.

Take this = example:

There is an external meter measuring the = power of the PC. The meter

acts as the PC's and the battery's direct = parent and reports the visible

external power consumed. Now, if you take the = battery (or UPS) as separate

entity, it may have its own = charging controller and measure charging = and 

draining and report on this. The conclusion = is that the PC changes = its 

parent whenever switching from main power to = battery power and vice versa.

 

Hence, the separate treatment of battery and = PC requires us to consider

dynamic memberships in domains and dynamic = parent-child relationships.

 

Thanks,

 

   =  Juergen

 

 

Am 08.03.2011 um 11:07 schrieb Mouli Chandramouli = (moulchan):



Hi Juergen,

 

Firstly, Battery for a PC can be analogous to a UPS for a Data = center. 

During Power outages, UPS can provide power for the network elements = in a Data center for a finite period of = time.

 

I think a solution to the question you have posed can be to decouple = the device and the battery. =   

 

As a first step,  I think it would be useful to understand if = the device is on direct power or on UPS/battery power – not sure = if this has been captured in the MIB = modules.

 

If it is direct power, then we have the measurement variables = defined.

If the device is on battery (or storage) power, it may be more useful = to monitor the drain rate of the  battery alone. =  

 

Regarding the scenarios you have indicated,  and if the device = is switched-off (ACPI G3-S5 = (Off-Hard)),

then power consumed is only for the battery charging.  Device = state is G3-S5 (Off-Hard), while the battery state is = “Charging”. =    

 

So, if we consider the following = equation,

 

Power consumption of a device =3D power consumption from the grid + = power drained from storage/battery,

in case power consumption from grid is zero, the power consumption = of  device is non-zero.

 

Thanks

Mouli

 

 

From:=  eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]=  On Behalf Of Juergen = Quittek
Sent: Thursday, March 03, 2011 2:14 = AM
To: Benoit = Claise (bclaise)
Cc: eman mailing list; Bruce = Nordman
Subject: Re: [eman] Power States - = really

 

Hi all,

 

Just a short = question:

 

Which power state would apply to my notebook computer = when

 

  - it is switched of, but charging its = batteries. 

    This is an off-state with = relatively high power = consumption. 

    Is this covered by any ACPI or DMTF = states or by the states in the drafts we = have?

 

  - it is switched on and fully operational, = but running on built-in battery = only.

    This is an operational state with = zero power consumption, at least as seen from = outside.

    Again, how can we cover this with = states described so far?

 

Thanks,

 

   =  Juergen

 

 

Am 02.03.2011 um 18:39 schrieb Benoit = Claise:




Dear all,

In the industry, there are multiple = series of power states:
-  The ACPI standard. In practice, = mainly used for PCs in case of non operational power states
-  = The DMTF Power State Management Profile defines an information model = over web services. The DMTF has 6 power states, 5 of them = non-operational. They merged all operational power states into a single = one: "on".
- Some manufacturers have their own power state = series.

And there is an attempt to define the EMAN states in the = EMAN framework, which would be a new power states series, at least for = the operational ones.

In the world of PCs in case of non = operational power states, ACPI seems well accepted.
However, my point = is the following: there is no clear winner in terms of adopted series of = power state in the industry.
I believe I would be dangerous to bet on = power state series based on our knowledge today. The industry will = decide, and maybe it will be a new power states series.

What I = believe the solution is in terms of EMAN:
- we must be ready to = support multiple power states series
- we must be ready to support a = new power states series. 
- the device must report = which power states series it supports
In conclusion: be flexible and = support all

Regards, = Benoit.



I am reposting Juergen's email about = power states.
While the subsequent discussion has been = important
and useful, it is on a different topic.  So, please = let's
also make progress on this = topic.
--Bruce

On Mon, = Feb 28, 2011 at 4:07 AM, Juergen Quittek <Quittek@neclab.eu> = wrote:

Dear all,

We = have two proposals for a Power/Energy MIB module:

 - = draft-claise-energy-monitoring-mib-06
 - = draft-quittek-power-mib-02

Among the authors of both documents we = are currently trying to merge them.
But there are some open issues = that should be discussed on the mailing
list.  Here is the = probably biggest of them: modeling power states.

For simplifying = energy management we want to introduce the concept of
power states = (aka power levels).  A power state will indicate roughly = how
much power a device consumes.  Examples for simple power = states are off,
sleep, and operational states.

In the = envisioned EMAN MIB modules, a power state is characterized by = a
descriptive name and the device's expected power input in this = state
(max/min/average).

Power states are not a new concept. =  The DMTF has already defined a set of
power states and there is = the Other standards bodies as the DMTF
(Distributed Management Task = Force) and there  is the ACPI (Advanced
Configuration and Power = Interface) for PC motherboards.  And there may be
more than = these out there.  I listed some DMTF and ACPI states at the = end
of this message.

An easy solution for EMAN would be just = adopting one of these sets.
However, there are issues with the ones = we looked at.  ACPI was developed
for PC motherboards and is = quite PC-centric.  Also it defines states that
seem to be = superfluous, because so far, almost no one has implemented
them. =  Also the DMTF model seems to have a narrower scope than = envisioned
by the EMAN WG.

At some point in time, the EMAN WG = hast to make a decision, which power
state model to adopt.  Here = is a set of alternatives. The first four have
fixed sets of power = states.

Option 1: fixed minimum
Just support three power = states (off, sleep (stand-by), operational)
This has clear semantics, = but there are several people claiming it's = too
restrictive.

Option 2: fixed DMTF
Just use the states = defined by DMTF.
Might be too much focussed n PCs.

Option 3: = fixed ACPI
Just use the states defined by ACPI.
Might be too much = focussed n PCs.



Option 4: fixed EMAN
Define a new = fixed set of power levels within the EMAN WG.

Option 5: = IANA-registered power states
Have power states be registered at = IANA.
We would start with registering (off, sleep, operational, the = DMTF set,
and the ACPI set.
Manufacturers can then register = further ones.


There has been discussions pointing out that = these fixed sets may not be
sufficient, particularly if non-IT = equipment should also be covered.

For being more open, the idea = to support user-defined or
manufacturer-defined power states of = devices has been developed.  In such
a state, for example, = certain components of a device may be switched off
or put to sleep. =  Which ones are switched off in which state is to be
defined by = the user/operator/manufacturer and may be chosen such = that
operational needs are met.

Again, there are several = proposals how to do this.  All of them favor a
two-level = approach that distinguishes between rather flexible functional
power = states and rather fixed basic power states.  Functional power = states
would be defined by the manufacturer, operator, or user. =  These would be
the power states that would be reported by a = device.  However, in order to
better define the semantics of = functional power states, Each of these
would be mapped to exactly one = basic power states.  This means that a
property of any = functional state would be the basic state it maps to.
Basic power = states would be fixed, such as the ones used in options 1-5.
An easy = example would be functional power states defined = by
user/operator/manufacturer with each state indicating whether it = is an off
state, a sleep state or an operational state.

Here = are the corresponding options:

Option 6: flexible functional = states mapped to a fixed set of basic states
States could be defined = flexibly.  But each state would indicate a basic
state to which = it corresponds. Basic states could be either = basic
(off/sleep/operational) or the DMTF set or the ACPI = set

Option 7: flexible functional states mapped to a IANA = registered set of
basic states
This is like Option 6, but basic = states would be registered at IANA and
can be extended.  We = would register all DMTF and ACPI states and probably
some more at = IANA. Manufacturers could add more.

Option 8: IANA-registered = sets of functional states, only three basic
states
The main = reasoning behind this option is that is should always be = clear
whether a power state is an off state, a sleep state, or an = operational
state.  Therefore, only these three basic states are = supported.  This
would be in line with an instance of Option 6. =  However, this option has
an extension for the functional = states.  It suggests that for customizing
devices in order to be = compliant with given management systems, for
example a DMTF-based = system, it should be possible to restrict functional
power states to = a given set that is registered at IANA.  An example would
be the = DMTF states.  We would register a flag at IANA that indicates = we
are using DMTF states only.  This would signal the management = application
that all power state IDs are in line with power state = numbering as defined
by IANA.  Analogously, ACPI and further = sets could be registered at IANA.
A fallback to Option 6 could be = realized by registering a set number of 0
at IANA that does not = impose any limit for functional states.

Obviously, there are more = possible options.  If you think there is a
better one, please = send it to this list.

I know this discussion is not easy, but we = have to have it in order to
make the right decision in the EMAN WG. =  Please take some time and think
about what you consider to be = the best way to go.  And of course send
questions on the = issue.

Thanks.

   Juergen


DMTF = (Distributed Management Task Force) power states:
 - 2 (Power = On)
 - 3 (Sleep - Light)
 - 4 (Sleep - Deep)
 - = 5 (Power Cycle (Off Soft))
 - 6 (Power Off - Hard)
 - 7 = (Hibernate)
 - 8 (Power Off - Soft)
 - 9 (Power Cycle = (Off Hard))
 - 10 (Master Bus Reset)
 - 11 (Diagnostic = Interrupt (NMI))
 - 12 (Power Off - Soft Graceful)
 - 13 = (Power Off - Hard Graceful)
 - 14 (Master Bus Reset = Graceful)
 - 15 (Power Cycle (Off - Soft Graceful))
 - = 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced = Configuration and Power Interface Specification) power
states for PC = motherboards:
 - G3-S5 (Off-Hard)
 - G2-S5 = (Off-Soft)
 - G1-S4 (Hibernate)
 - G1-S3 = (Sleep-Deep)
 - G1-S2 (Sleep-Light)
 - G1-S1 = (Sleep-Light)
 - G0-S0-P5
 - G0-S0-P4
 - = G0-S0-P3
 - G0-S0-P2
 - G0-S0-P2
 - = G0-S0-P2




_____________________________________________= __
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman




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



 
_______________________________________________
=

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

 

 

------_=_NextPart_001_01CBDE49.DFF33E8C-- From j.schoenwaelder@jacobs-university.de Wed Mar 9 03:19:24 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A60F3A693A for ; Wed, 9 Mar 2011 03:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.159 X-Spam-Level: X-Spam-Status: No, score=-103.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yiao7hpOUQoG for ; Wed, 9 Mar 2011 03:19:23 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECC173A6936 for ; Wed, 9 Mar 2011 03:19:22 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE664C000B; Wed, 9 Mar 2011 12:20:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8VhTZSK4q3TM; Wed, 9 Mar 2011 12:20:38 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D16DCC0083; Wed, 9 Mar 2011 12:20:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 823EA16E82A9; Wed, 9 Mar 2011 12:20:31 +0100 (CET) Date: Wed, 9 Mar 2011 12:20:31 +0100 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20110309112031.GA41406@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , "Romascanu, Dan (Dan)" , Juergen Quittek , eman mailing list References: <20110301102225.GB9233@elstar.local> <51F74E9D-31F6-4F4F-9924-D2609B9A381D@quittek.at> <20110301111548.GA9369@elstar.local> <20110303195243.GC21657@elstar.local> <0E32737B-484D-4263-9749-149E61601B03@quittek.at> <20110308135228.GA37400@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 mailing list Subject: Re: [eman] eman] modeling power states - Entity-MIB X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 11:19:24 -0000 On Wed, Mar 09, 2011 at 03:11:35AM -0600, Mouli Chandramouli (moulchan) wrote: > I agree that the PhysicalClass TC should have been under IANA control > to enable extensibility. On the other hand, I have not seen anything > in the EMAN MIB proposals that is not also in the ENTITY-MIB. In fact, > most EMAN MIBs seem to use simple SnmpAdminStrings, which enables a > great deal of flexibility but also makes automation hard if every > vendor can label components in arbitrary ways. In other words, the > ENTITY-MIB even today is not "worse" than the other proposals (correct > me if I am missing something) and it could be fixed by moving the > PhysicalClass TC under IANA control. > > YCM> Agreed. There are two questions. How long will it to update the > Physical Class TC ? > YCM> There is a clear need for energy monitoring in networks now. > YCM> So, this approach seemed as an interim solution. IETF processes never give you now. How long things take in the IETF depends on convergence time, getting thing written down, reviewed, processed etc. > YCM> Secondly, entity-MIB is widely implemented in networking devices. > YCM> Other power consuming devices such as non-POE devices or building > HVAC devices > YCM> have not implemented the Entity-MIB. But those devices also have not implemented any yet to be standardized EMAN MIB modules, so this is pretty much a mood point. > Why do these devices not have entPhysicalIndex or why can't they have > an entPhysicalIndex? We do have wirelesse sensor nodes and they do > manage to report an entPhysicalIndex. > > YCM> Sane comment as before. Some of these devices may not implement the > Entity-MIB. Same answer as above. ;-) > > There was also a point made in the last WG meeting, power > > consumption of software components (not just physical components) > > should also be considered. For e.g. an Email program on some > > platforms can consume power which can be noticed by the rate of > > battery drain. > > But you can't really measure this. People proposing something like > this likely measure the physical component's power consumption and > relate it to running software and its CPU usage via some magic > formula. It is not clear to me that this is necessarily expected to be > done and reported via an SNMP agent. If you export the power > consumption readings of your physical devices to a management system, > you can calculate whatever seems useful off the devices and in much > more flexible ways. > > YCM> agreed, good point. Even for some physical devices, there may not > be a power sensor > YCM> for measurement and may have to be estimated. In fact to handle > this scenario, in our proposal, a MIB variable > YCM> Measurement Caliber to indicate how the measurement was obtained > (by direct measurement, estimation, or the max value, ...) Sure, a value is not just a value. We know that at least since the ENTITY-SENSOR-MIB. The question is more whether reporting power consumptions of applications or even further the power consumption produced by certain users of an organization is in scope or not. There are lots of things people might calculate from the raw measurements, this WG needs to decide what of at that is realistic to report via an SNMP agent. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@quittek.at Wed Mar 9 04:40:02 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16FE3A695E for ; Wed, 9 Mar 2011 04:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgQDePgtG9n7 for ; Wed, 9 Mar 2011 04:40:02 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id DFDDB3A6813 for ; Wed, 9 Mar 2011 04:40:01 -0800 (PST) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M4Bbn-1QE91v3hwZ-00rJEA; Wed, 09 Mar 2011 13:41:15 +0100 Content-Transfer-Encoding: 7bit From: Juergen Quittek Content-Type: text/plain; charset=us-ascii Message-Id: <1B633966-ACAE-4B82-9F0D-8C4AE146C23D@quittek.at> Date: Wed, 9 Mar 2011 13:41:15 +0100 To: eman mailing list Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:aIZGPK6AXf8URyzZz9xDemgB3s6qAILvJshcFKUDz/q DJ+hB6ikE3gZYrhkjn3bD33gbKBsksp1a6T76tz5EIVlyyruhY U8nCOeRZQ9qAl2Y+YkmPzQeMMvzekwMIJ//dUtMUg11USPYJZh 6dQ60mv24O2iwBjGPFlyZbXaUIJoJQRhugz1UHU67pt0POv5Ve rIltdrWfioWTbdwaML61A== Subject: [eman] parent child model and metering domains for notebook PC with battery X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 12:40:03 -0000 Dear all, Mouli asked a separate thread for this topic. I have two questions concerning the case of a PC with a battery: 1. How to model it using the parent-chlid approach 2. How to apply metering domains sub-issues are: 1.1 If the PC reports directly to the management system (as PCs usually should do) is then the PC parent of the battery? 2.1 If the PC runs on battery, do we have to report positive power values for the PC and negative power values (indicating a generator) for the battery? If we don't do so, we may double account energy that first charged the battery and then powers the PC. Thanks, Juergen From ietf@quittek.at Wed Mar 9 04:41:55 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B923A695E for ; Wed, 9 Mar 2011 04:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTFD0yUBplaG for ; Wed, 9 Mar 2011 04:41:54 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id D19793A67A1 for ; Wed, 9 Mar 2011 04:41:53 -0800 (PST) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MXVos-1PQjM30kJa-00Wnqq; Wed, 09 Mar 2011 13:43:09 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-14--755155466 Message-Id: <3C5475C3-49EB-4F2B-8ECE-6D11D56B51AF@quittek.at> From: Juergen Quittek Date: Wed, 9 Mar 2011 13:43:11 +0100 To: Ira McDonald X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:KdRJfF3orJuKMzbhfFEwEe3liv5hPIATihHXhXyeSt0 CNfM3JBvE4H67y+8M+LtuAoHErk/nzYnfq9YTybYtasX+JF+Lz ejs5Laqezwr13LZYhb6Geb/Mrgwd++VuIGKgEeg5Ftm9nR1Ndb 6SM5IQuEjSAxyoG30JkyF9iN/PIMXnvCdMXTF7M2zxF2jZdX2T 08AlnSi6Kb+Qynw3t9T9w== Cc: eman mailing list Subject: Re: [eman] Harmonizing standard and vendor power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 12:41:55 -0000 --Apple-Mail-14--755155466 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Ira, Thank you for this input! I have one question: How do you model energy storages, such as UPS systems or batteries in PCs? Thanks, Juergen Am 08.03.2011 um 20:52 schrieb Ira McDonald: > Hi, > > To address the tension between using standard enumerated power > states and the finer-grained power states many vendors actually > support, we used the following approach in our recent IEEE-ISTO > PWG Imaging System Power Management Model and companion > concrete PWG Imaging System Power MIB: > > (1) We standardized on the set of DMTF CIM power states. > > (2) We multiplied all standard DMTF CIM power state enumerated > values by 10 and inserted 5 vendor extension power states (i.e., > substates) for the base stable states. > > (3) So our base state 'on(20)' can be augmented by up to 5 more > substates: 'onVendor1(21)' through 'onVendor5(25)'. > > (4) We defined a rule that actual power consumption in vendor > extension states MUST be strictly ordered, such that for example > 'onVendor1(21)' MUST consume equal or greater power than the > base state 'on(20)' - then for interoperability all vendor extension > states can be collapsed into their corresponding base states for > mapping to DMTF CIM interfaces. > > (5) We defined a PowerSupport group of properties that gave more > details about each base or vendor extension stable state. > > PowSupportEntry ::= SEQUENCE { > powSupportPowerState PowPowerStateTC, > powSupportPowerInactiveWatts Integer32, > powSupportPowerActiveWatts Integer32, > powSupportCanAcceptJobs TruthValue, > powSupportCanProcessJobs TruthValue, > powSupportCanRequestPowerState TruthValue, > powSupportCanUseInterfaces DisplayString, > powSupportPowerPeakWatts Integer32 > } > > Perhaps this approach would be useful in the IETF EMAN effort. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Co-Chair - IEEE-ISTO PWG IPP WG > Co-Chair - TCG Hardcopy WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > Christmas through April: > 579 Park Place Saline, MI 48176 > 734-944-0094 > May to Christmas: > PO Box 221 Grand Marais, MI 49839 > 906-494-2434 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-14--755155466 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Ira,

Thank you for this input!

I have one question: How do you model energy storages, 
such as UPS systems or batteries in PCs?

Thanks,

    Juergen

Am 08.03.2011 um 20:52 schrieb Ira McDonald:

Hi,

To address the tension between using standard enumerated power
states and the finer-grained power states many vendors actually
support, we used the following approach in our recent IEEE-ISTO
PWG Imaging System Power Management Model and companion
concrete PWG Imaging System Power MIB:

(1) We standardized on the set of DMTF CIM power states.

(2) We multiplied all standard DMTF CIM power state enumerated
values by 10 and inserted 5 vendor extension power states (i.e.,
substates) for the base stable states.

(3) So our base state 'on(20)' can be augmented by up to 5 more
substates:  'onVendor1(21)' through 'onVendor5(25)'.

(4) We defined a rule that actual power consumption in vendor
extension states MUST be strictly ordered, such that for example
'onVendor1(21)' MUST consume equal or greater power than the
base state 'on(20)' - then for interoperability all vendor extension
states can be collapsed into their corresponding base states for
mapping to DMTF CIM interfaces.

(5) We defined a PowerSupport group of properties that gave more
details about each base or vendor extension stable state.

PowSupportEntry ::= SEQUENCE {
        powSupportPowerState            PowPowerStateTC,
        powSupportPowerInactiveWatts    Integer32,
        powSupportPowerActiveWatts      Integer32,
        powSupportCanAcceptJobs         TruthValue,
        powSupportCanProcessJobs        TruthValue,
        powSupportCanRequestPowerState  TruthValue,
        powSupportCanUseInterfaces      DisplayString,
        powSupportPowerPeakWatts        Integer32
    }

Perhaps this approach would be useful in the IETF EMAN effort.

Cheers,
- Ira


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

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

--Apple-Mail-14--755155466-- From blueroofmusic@gmail.com Wed Mar 9 13:57:47 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796453A6407 for ; Wed, 9 Mar 2011 13:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yMpM2jvszeu for ; Wed, 9 Mar 2011 13:57:46 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B5CA93A6AD9 for ; Wed, 9 Mar 2011 13:57:45 -0800 (PST) Received: by fxm15 with SMTP id 15so1073043fxm.31 for ; Wed, 09 Mar 2011 13:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6a6X0nYVLGP9kdXnrCB7lIzmYf3nmelb6RYbs+yJmx8=; b=dh0dksZklSsqqUzaSSOjzbAY2vAW88F5iLd/nRstmeNGJ3w7CcuQgN2TlxtgToHqsI skvV/6asHWE1HsVwdDIcruu6GoBodpay7udEBv0Ph3bnX8ETUfrim2c8s7FynkqFhAke ugxn9Sb5hEnEShqHqUvP6wAlDq/y3eUmDgjik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KJeRzD67RmcfwtYjUzdLgbKzlr5MemhLag83bWR9x365ajR7ykbhu4a7Dt8z8aoVg2 xQu9z7Guy0gQrnsVq3GeMx5ROAyEhWSo1ByMJp0/X21/8Ce1Gvb2sp+YdAQTiJWEvr0d QhDxjyVeyjaBkzNs11lHbFMF4nr1bgEU4MkLs= MIME-Version: 1.0 Received: by 10.223.115.10 with SMTP id g10mr4011464faq.6.1299707941991; Wed, 09 Mar 2011 13:59:01 -0800 (PST) Received: by 10.223.66.68 with HTTP; Wed, 9 Mar 2011 13:59:01 -0800 (PST) In-Reply-To: <3C5475C3-49EB-4F2B-8ECE-6D11D56B51AF@quittek.at> References: <3C5475C3-49EB-4F2B-8ECE-6D11D56B51AF@quittek.at> Date: Wed, 9 Mar 2011 16:59:01 -0500 Message-ID: From: Ira McDonald To: Juergen Quittek , Ira McDonald Content-Type: multipart/alternative; boundary=001636c5b25b31b5f1049e13d69d Cc: eman mailing list Subject: Re: [eman] Harmonizing standard and vendor power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:57:47 -0000 --001636c5b25b31b5f1049e13d69d Content-Type: text/plain; charset=ISO-8859-1 Hi Juergen, Unfortunately, batteries were out-of-scope for our printer and multifunction imaging device power management project. With the exception of some low-end portable scanners and printers (not network-connected), office imaging devices don't use batteries operationally (i.e., the only batteries back up the clock and configuration memory). And office imaging devices also are rarely configured on UPS systems (because of their high power drain when operating). Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Christmas through April: 579 Park Place Saline, MI 48176 734-944-0094 May to Christmas: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Mar 9, 2011 at 7:43 AM, Juergen Quittek wrote: > Hi Ira, > > Thank you for this input! > > I have one question: How do you model energy storages, > such as UPS systems or batteries in PCs? > > Thanks, > > Juergen > > Am 08.03.2011 um 20:52 schrieb Ira McDonald: > > Hi, > > To address the tension between using standard enumerated power > states and the finer-grained power states many vendors actually > support, we used the following approach in our recent IEEE-ISTO > PWG Imaging System Power Management Model and companion > concrete PWG Imaging System Power MIB: > > (1) We standardized on the set of DMTF CIM power states. > > (2) We multiplied all standard DMTF CIM power state enumerated > values by 10 and inserted 5 vendor extension power states (i.e., > substates) for the base stable states. > > (3) So our base state 'on(20)' can be augmented by up to 5 more > substates: 'onVendor1(21)' through 'onVendor5(25)'. > > (4) We defined a rule that actual power consumption in vendor > extension states MUST be strictly ordered, such that for example > 'onVendor1(21)' MUST consume equal or greater power than the > base state 'on(20)' - then for interoperability all vendor extension > states can be collapsed into their corresponding base states for > mapping to DMTF CIM interfaces. > > (5) We defined a PowerSupport group of properties that gave more > details about each base or vendor extension stable state. > > PowSupportEntry ::= SEQUENCE { > powSupportPowerState PowPowerStateTC, > powSupportPowerInactiveWatts Integer32, > powSupportPowerActiveWatts Integer32, > powSupportCanAcceptJobs TruthValue, > powSupportCanProcessJobs TruthValue, > powSupportCanRequestPowerState TruthValue, > powSupportCanUseInterfaces DisplayString, > powSupportPowerPeakWatts Integer32 > } > > Perhaps this approach would be useful in the IETF EMAN effort. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Co-Chair - IEEE-ISTO PWG IPP WG > Co-Chair - TCG Hardcopy WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > Christmas through April: > 579 Park Place Saline, MI 48176 > 734-944-0094 > May to Christmas: > PO Box 221 Grand Marais, MI 49839 > 906-494-2434 > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > > --001636c5b25b31b5f1049e13d69d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Juergen,

Unfortunately, batteries were out-of-scope for our
pr= inter and multifunction imaging device power
management project.
With the exception of some low-end portable scanners
and printers (not = network-connected), office imaging
devices don't use batteries operationally (i.e., the only
batteries = back up the clock and configuration memory).

And office imaging devi= ces also are rarely configured on
UPS systems (because of their high po= wer drain when
operating).

Cheers,
- Ira

Ira McDonald (Musi= cian / Software Architect)
Chair - Linux Foundation Open Printing WG
= Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Desig= nated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic<= /a>
http://sites.google.com/site/highnor= thinc
mailto:blueroo= fmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 S= aline, MI=A0 48176
=A0 734-944-0094
May to Christmas:
=A0 PO Box 2= 21=A0 Grand Marais, MI 49839
=A0 906-494-2434



On Wed, Mar 9, 2011 at 7:43 AM, Juergen = Quittek <ietf@quitt= ek.at> wrote:
Hi Ira,

Thank you = for this input!

I have one question:=A0How do you = model energy storages,=A0
such as UPS systems or batteries in PCs= ?

Thanks,

=A0=A0 =A0Juergen

Am 08.03.2011 um 20:52 schrieb Ira McDonald:

<= blockquote type=3D"cite">
Hi,

To ad= dress the tension between using standard enumerated power
states and the finer-grained power states many vendors actually
support,= we used the following approach in our recent IEEE-ISTO
PWG Imaging Sys= tem Power Management Model and companion
concrete PWG Imaging System Power MIB:

(1) We standardized on the se= t of DMTF CIM power states.

(2) We multiplied all standard DMTF CIM = power state enumerated
values by 10 and inserted 5 vendor extension powe= r states (i.e.,
substates) for the base stable states.

(3) So our base state 'on= (20)' can be augmented by up to 5 more
substates:=A0 'onVendor1(= 21)' through 'onVendor5(25)'.

(4) We defined a rule that= actual power consumption in vendor
extension states MUST be strictly ordered, such that for example
'on= Vendor1(21)' MUST consume equal or greater power than the
base state= 'on(20)' - then for interoperability all vendor extension
states can be collapsed into their corresponding base states for
mapping to DMTF CIM interfaces.

(5) We defined a PowerSupport group = of properties that gave more
details about each base or vendor extension= stable state.

P= owSupportEntry ::=3D SEQUENCE {
=A0=A0=A0=A0=A0=A0=A0 p= owSupportPowerState=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PowPowerStateTC,
=A0=A0=A0=A0=A0=A0=A0 powSupportPowerInactiveWa= tts=A0=A0=A0 Integer32,
=A0=A0=A0=A0=A0=A0=A0 p= owSupportPowerActiveWatts=A0=A0=A0=A0=A0 Integer32,
=A0=A0=A0=A0=A0=A0=A0 powSupportCanAcceptJobs=A0=A0=A0=A0=A0=A0= =A0=A0 TruthValue,
=A0=A0=A0=A0=A0=A0=A0 p= owSupportCanProcessJobs=A0=A0=A0=A0=A0=A0=A0 TruthValue,
=A0=A0=A0=A0=A0=A0=A0 powSupportCanRequestPowerState=A0 Trut= hValue,
=A0=A0=A0=A0=A0=A0=A0 p= owSupportCanUseInterfaces=A0=A0=A0=A0=A0 DisplayString,
=A0=A0=A0=A0=A0=A0=A0 powSupportPowerPeakWatts=A0=A0=A0=A0=A0= =A0=A0 Integer32
=A0=A0=A0 }
<= br>Perhaps this approach would be useful in the IETF EMAN effort.

Ch= eers,
- Ira


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

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


For many decades, electrical products were usually j= ust on or off - a 2-state power model.=A0 In the last several decades, we h= ave added many electronic products with a 3-state model - on, sleep, and of= f.=A0 This is necessary and existing complexity.=A0 Our discussions around = power states boil down to what complexity do we want to add to the 3-state = model, and why the burden is justified.


In discussions on= this email list, in I-drafts, and in person, the existing listings of powe= r states from ACPI and DMTF are often referenced as good candidates for eman to adopt in some way.=A0 ACPI = is a hugely important technology, and it enables large amounts of user func= tionality and energy savings.=A0 I am less familiar with t= he reach of DMTF in practice, but its depth and breadth of membership are c= ompelling.=A0 While I agree they both deserve close examination, I t= hink we can safely drop them from our discussions of what to define as thei= r complexity is more a distraction than an asset.


The basic ACPI list i= s of=A0 =93Global System States=94 which =93apply to the entire system=94.=A0 There are four of these (G0-G3); G0 is on (=93working=94) and G1 is sleep (=93sleepin= g=94).=A0 G2 and G3 both forms of off (only distinguished by whether a device is completely depowered and whether it is safe to disassemble or not, and these distinctions seems quite minor for em= an purposes).=A0 Thus, the ACPI Global states are essentially on/sleep/off, the 3-state power model.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /span>ACPI lists five =93Sx=94 sleep states (S0 is on).=A0 S5 is actually the G2 Off state (so not a sleep state at all), a= nd current implementations do not use S1 or S2, so in practice there are only two ACPI sleep states: S3 and S4.=A0 S3 is the ordinary system sleep, with quick wakeup.=A0 S4 is the hibernate state (with system memory saved in non-volatile memory, possibly a hard dis= k) which typically has long times to return to operation (often tens of seconds).=A0=A0 The 1-2 second wake time from S3 for modern personal computers is compatible with many IP = protocol usages, e.g. initiating a TCP connection.=A0 The tens of seconds time for S4 on current systems is not.=A0 So, the only potential addition that the Sx states add to on/sleep/off is hibernate (and reasonabl= e people can differ on whether it is a fourth basic state, a form of sleep,= or a form of off).

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /span>ACPI does define processor states (Cx) and device states (Dx) (collectively Px),= but these are the states of particular components, not of the system as a whole.=A0 It may be useful to expose these through some mechanism, but they are distinct from the power state.


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /span>DMTF essentially took the ACPI Gx states plus hibernate and added states that ar= e commands and/or transitions.=A0 (Is "Master Bus Reset= " a power state?=A0 I think not).=A0 If we don=92t include commands or transitions (I think we should not), then these reduce to the ACPI states.


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /span>My conclusion: ACPI and DMTF do not significantly change the 3-state power model.=A0 If we want to talk about states beyond the 3-state mod= el, it is more clear to simply reference those extensions directly (e.g. ho= w best to treat hibernate).=A0 Note that this discussion - and all others o= n the list - are grounded in electronic devices.=A0 Other devices generally= have a 2-state model (e.g. a light), or 3 states, but on, off, and "r= eady" (think a microwave oven).


--Bruce



--
Bruce NordmanLawrence Berkeley National Laborat= ory
= eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--20cf3079be0eb29fad049e2f30b0-- From ietf@quittek.at Fri Mar 11 01:36:14 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8A73A6A08 for ; Fri, 11 Mar 2011 01:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo7vh30QaRgk for ; Fri, 11 Mar 2011 01:36:13 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id CB3A43A69FA for ; Fri, 11 Mar 2011 01:36:12 -0800 (PST) Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MAASz-1Pmf3m1qI5-00C3jf; Fri, 11 Mar 2011 10:37:27 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-15--593502832 Message-Id: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> From: Juergen Quittek Date: Fri, 11 Mar 2011 10:37:24 +0100 To: Bruce Nordman X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:erFm9Sl/Vlo4E0k498mkg2dK87H9C98JcRtb8FtIb0k j6OnZQFyU+abBIT517Cs6q3f1GlS9XTRqtO4C9OLt4e5YKasN0 F8P86Qq1//ynXTVYb7D/Q51A4o8GHB/OX3W9MFR5ECOiEFwrVu gbgA6bED+wakzAK1nctRBoRnYWppHGPuHlyZI3hJITItfRDXJe u8F0Ot5UHfxC7znI7jd9Q== Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 09:36:14 -0000 --Apple-Mail-15--593502832 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Bruce, I understand your preference for a simple off-sleep-on model for power = states. How would we model a device with a battery then=20 - it is off, but the empty battery is being charged - it is on, but fully supplied with power from the battery. On way would be treating the (internal) battery as separate device. In this case: Can we map charging/discharging/full/empty to = off-sleep-on? Thanks, Juergen Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > (all below as contributor) >=20 >=20 > For many decades, electrical products were usually just on or off - a = 2-state power model. In the last several decades, we have added many = electronic products with a 3-state model - on, sleep, and off. This is = necessary and existing complexity. Our discussions around power states = boil down to what complexity do we want to add to the 3-state model, and = why the burden is justified. >=20 > In discussions on this email list, in I-drafts, and in person, the = existing listings of power states from ACPI and DMTF are often = referenced as good candidates for eman to adopt in some way. ACPI is a = hugely important technology, and it enables large amounts of user = functionality and energy savings. I am less familiar with the reach of = DMTF in practice, but its depth and breadth of membership are = compelling. While I agree they both deserve close examination, I think = we can safely drop them from our discussions of what to define as their = complexity is more a distraction than an asset. >=20 > The basic ACPI list is of =93Global System States=94 which =93apply = to the entire system=94. There are four of these (G0-G3); G0 is on = (=93working=94) and G1 is sleep (=93sleeping=94). G2 and G3 both forms = of off (only distinguished by whether a device is completely depowered = and whether it is safe to disassemble or not, and these distinctions = seems quite minor for eman purposes). Thus, the ACPI Global states are = essentially on/sleep/off, the 3-state power model. > ACPI lists five =93Sx=94 sleep states (S0 is on). S5 is = actually the G2 Off state (so not a sleep state at all), and current = implementations do not use S1 or S2, so in practice there are only two = ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with = quick wakeup. S4 is the hibernate state (with system memory saved in = non-volatile memory, possibly a hard disk) which typically has long = times to return to operation (often tens of seconds). The 1-2 second = wake time from S3 for modern personal computers is compatible with many = IP protocol usages, e.g. initiating a TCP connection. The tens of = seconds time for S4 on current systems is not. So, the only potential = addition that the Sx states add to on/sleep/off is hibernate (and = reasonable people can differ on whether it is a fourth basic state, a = form of sleep, or a form of off). > ACPI does define processor states (Cx) and device states = (Dx) (collectively Px), but these are the states of particular = components, not of the system as a whole. It may be useful to expose = these through some mechanism, but they are distinct from the power = state. >=20 > DMTF essentially took the ACPI Gx states plus hibernate = and added states that are commands and/or transitions. (Is "Master Bus = Reset" a power state? I think not). If we don=92t include commands or = transitions (I think we should not), then these reduce to the ACPI = states. >=20 > My conclusion: ACPI and DMTF do not significantly change = the 3-state power model. If we want to talk about states beyond the = 3-state model, it is more clear to simply reference those extensions = directly (e.g. how best to treat hibernate). Note that this discussion = - and all others on the list - are grounded in electronic devices. = Other devices generally have a 2-state model (e.g. a light), or 3 = states, but on, off, and "ready" (think a microwave oven). >=20 > --Bruce >=20 >=20 > --=20 > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-15--593502832 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Bruce,

I understand your preference for a simple = off-sleep-on model for power states.
How would we model a = device with a battery then 
  - it is off, = but the empty battery is being charged
  - it = is on, but fully supplied with power from the = battery.

On way would be treating the = (internal) battery as separate device.
In this case: Can we = map charging/discharging/full/empty = to off-sleep-on?

Thanks,

   =  Juergen


Am = 11.03.2011 um 07:37 schrieb Bruce Nordman:

(all below = as contributor)


For many decades, electrical = products were usually just on or off - a 2-state power model.  In = the last several decades, we have added many electronic products with a = 3-state model - on, sleep, and off.  This is necessary and existing = complexity.  Our discussions around power states boil down to what = complexity do we want to add to the 3-state model, and why the burden is = justified.


In discussions = on this email list, in I-drafts, and in person, the existing listings of = power states from ACPI and DMTF are often referenced as good candidates for eman to adopt in some way.  = ACPI is a hugely important technology, and it enables large amounts of = user functionality and energy savings.  I am less = familiar with the reach of DMTF in practice, but its depth and breadth = of membership are compelling.  While I agree they both = deserve close examination, I think we can safely drop them from our = discussions of what to define as their complexity is more a distraction = than an asset.


The basic ACPI list is of  =93Global System = States=94 which =93apply to the entire system=94.  There are four of these (G0-G3); G0 is on (=93working=94) and G1 is sleep = (=93sleeping=94).  G2 and G3 both forms of = off (only distinguished by whether a device is completely depowered and whether it = is safe to disassemble or not, and these distinctions seems quite minor for = eman purposes).  Thus, the ACPI Global states are essentially on/sleep/off, the 3-state power model.

          &nb= sp; ACPI lists five =93Sx=94 sleep states (S0 is on).  S5 is actually the G2 Off state (so not a sleep state at = all), and current implementations do not use S1 or S2, so in practice there are only two ACPI sleep states: S3 and S4.  S3 is the ordinary system sleep, with quick wakeup.  S4 is the hibernate state (with system memory saved in non-volatile memory, possibly a hard = disk) which typically has long times to return to operation (often tens of seconds).   The 1-2 second wake time from S3 for modern personal computers is compatible with many = IP protocol usages, e.g. initiating a TCP connection.  The tens of seconds time for S4 on current systems is not.  So, the only potential addition that the Sx states add to on/sleep/off is hibernate (and = reasonable people can differ on whether it is a fourth basic state, a = form of sleep, or a form of off).

          &nb= sp; ACPI does define processor states (Cx) and device states (Dx) (collectively = Px), but these are the states of particular components, not of the system as a whole.  It may be useful to expose these through some mechanism, but they are distinct from the power = state.


          &nb= sp; DMTF essentially took the ACPI Gx states plus hibernate and added states that = are commands and/or transitions.  (Is "Master Bus = Reset" a power state?  I think not).  If we don=92t include commands or transitions (I think we should not), then = these reduce to the ACPI states.


          &nb= sp; My conclusion: ACPI and DMTF do not significantly change the 3-state = power model.  If we want to talk about states beyond the = 3-state model, it is more clear to simply reference those extensions = directly (e.g. how best to treat hibernate).  Note that this = discussion - and all others on the list - are grounded in electronic = devices.  Other devices generally have a 2-state model (e.g. a = light), or 3 states, but on, off, and "ready" (think a microwave = oven).


--Bruce



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

_______________________________________________
eman mailing = list
eman@ietf.org
https://www.ietf.org/ma= ilman/listinfo/eman

= --Apple-Mail-15--593502832-- From Rolf.Winter@neclab.eu Fri Mar 11 05:35:25 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6BA3A6BF8 for ; Fri, 11 Mar 2011 05:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.288 X-Spam-Level: X-Spam-Status: No, score=-102.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXve6k2cZY1Z for ; Fri, 11 Mar 2011 05:35:22 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5AB0C3A69AE for ; Fri, 11 Mar 2011 05:35:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 837222C000205; Fri, 11 Mar 2011 14:38:20 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fgGYuteMLRu; Fri, 11 Mar 2011 14:38:20 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 5D9B92C0001DE; Fri, 11 Mar 2011 14:38:05 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 11 Mar 2011 14:36:26 +0100 From: Rolf Winter To: Juergen Quittek , Bruce Nordman Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AQHL37bMc1CHhWwxDEKYxTzj/hbcCpQnz6kAgABO82A= Date: Fri, 11 Mar 2011 13:36:25 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> In-Reply-To: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 13:35:25 -0000 Hi, just thinking out loud here. The thing which seems to complicate matters here significantly is batteries= . You either A) try to consider battery state in the devices' power state o= r you B) leave it separate in its own MIB module (as described e.g. here ht= tp://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we have ba= ttery states full(1), partiallyCharged(2), empty(3), charging(4), dischargi= ng(5), unknown(6)). I think these are the trade-offs: Option A) You can always tell from the device power state whether it is dra= wing power or not ("off but charging" e.g.) and you might be able to order = them in a way that a higher state always translates to higher power draw. I= t however seems to complicate power states. Option B) If a battery is present, you cannot tell from the device's power = state whether is it drawing power or not ("off" could be really "off but ch= arging"). The device power states can be modelled cleaner though and you'd = need to look closer to see what the battery state is to be sure there is no= power draw. Is that the trade-off we're talking about or is there anything else that ne= eds to be considered? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Freitag, 11. M=E4rz 2011 10:37 > To: Bruce Nordman > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF >=20 > Hi Bruce, >=20 > I understand your preference for a simple off-sleep-on model for power > states. > How would we model a device with a battery then > - it is off, but the empty battery is being charged > - it is on, but fully supplied with power from the battery. >=20 > On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep- > on? >=20 > Thanks, >=20 > Juergen >=20 >=20 > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: >=20 >=20 > (all below as contributor) >=20 >=20 >=20 >=20 > For many decades, electrical products were usually just on or off > - a 2-state power model. In the last several decades, we have added > many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. Our discussions around > power states boil down to what complexity do we want to add to the 3- > state model, and why the burden is justified. >=20 >=20 >=20 >=20 >=20 > In discussions on this email list, in I-drafts, and in person, > the existing listings of power states from ACPI and DMTF are often > referenced as good candidates for eman to adopt in some way. ACPI is a > hugely important technology, and it enables large amounts of user > functionality and energy savings. I am less familiar with the reach of > DMTF in practice, but its depth and breadth of membership are > compelling. While I agree they both deserve close examination, I think > we can safely drop them from our discussions of what to define as their > complexity is more a distraction than an asset. >=20 >=20 >=20 >=20 > The basic ACPI list is of "Global System States" which "apply to > the entire system". There are four of these (G0-G3); G0 is on > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems > quite minor for eman purposes). Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model. >=20 > ACPI lists five "Sx" sleep states (S0 is on). S5 is > actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > quick wakeup. S4 is the hibernate state (with system memory saved in > non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). The 1-2 second > wake time from S3 for modern personal computers is compatible with many > IP protocol usages, e.g. initiating a TCP connection. The tens of > seconds time for S4 on current systems is not. So, the only potential > addition that the Sx states add to on/sleep/off is hibernate (and > reasonable people can differ on whether it is a fourth basic state, a > form of sleep, or a form of off). >=20 >=20 > ACPI does define processor states (Cx) and device > states (Dx) (collectively Px), but these are the states of particular > components, not of the system as a whole. It may be useful to expose > these through some mechanism, but they are distinct from the power > state. >=20 >=20 >=20 >=20 > DMTF essentially took the ACPI Gx states plus > hibernate and added states that are commands and/or transitions. (Is > "Master Bus Reset" a power state? I think not). If we don't include > commands or transitions (I think we should not), then these reduce to > the ACPI states. >=20 >=20 >=20 >=20 > My conclusion: ACPI and DMTF do not significantly > change the 3-state power model. If we want to talk about states beyond > the 3-state model, it is more clear to simply reference those > extensions directly (e.g. how best to treat hibernate). Note that this > discussion - and all others on the list - are grounded in electronic > devices. Other devices generally have a 2-state model (e.g. a light), > or 3 states, but on, off, and "ready" (think a microwave oven). >=20 >=20 >=20 >=20 > --Bruce >=20 >=20 >=20 >=20 > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > 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 >=20 From tirth.ghose@gmail.com Fri Mar 11 07:59:20 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05903A6A1B for ; Fri, 11 Mar 2011 07:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKArut7sgqAs for ; Fri, 11 Mar 2011 07:59:18 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 8E9913A69F8 for ; Fri, 11 Mar 2011 07:59:18 -0800 (PST) Received: by iyj8 with SMTP id 8so3390453iyj.31 for ; Fri, 11 Mar 2011 08:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=isYBmAG/fmmUlczhvzjTgaHDkfP7bpzB5nrJMEl1r0M=; b=Fm6O75bebJ1ggbS5De+f/fUmbRWlJinaYX8ucSm07m2e040FpM6/QlxdaSDTWRjinw 32koFIRw3D6Eoun1f8jjRAItr8Y6uZYLGEzfcaKRRfr8uEGe6OAL+72MHs/AvI65wWxH RF9g2loucK2hZLCa7sqB619h+4tGQuyRXVLN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=lOVxk+SpQ3QrrC4PXSv4sKIikT7ADP95RsbUuNA3nnnoxtcBx0CR5NnsQ6wdLDy1wG 1a3Kjv7P0YbvIirHMsjq7/h9p1qWDsH5Mkq2DzHrOn4irYkAAWPgdAPtB2+8dL/2z5k0 q9j9GDk+ZmeBHsFzZAwnxTKat7wMH5mSLEWPk= MIME-Version: 1.0 Received: by 10.43.54.133 with SMTP id vu5mr7405849icb.36.1299859236824; Fri, 11 Mar 2011 08:00:36 -0800 (PST) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Fri, 11 Mar 2011 08:00:36 -0800 (PST) In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> Date: Fri, 11 Mar 2011 08:00:36 -0800 X-Google-Sender-Auth: 8m1arJWKLGx5kXuSE7cLFX6Infw Message-ID: From: Ted Ghose To: Rolf Winter Content-Type: multipart/alternative; boundary=bcaec51ddb2f11a5db049e3710ea Cc: Bruce Nordman , eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 15:59:20 -0000 --bcaec51ddb2f11a5db049e3710ea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rolf, Juergen I like Rolf's idea very much. We should extend number of states to accommodate other sub states. Here is one question I do have for Juergon, as handling the battery keeps coming up in all the discussions. If the device is off, but battery is charging, who is reporting that and how? Is battery itself has the intelligence to do so? In that case, can we treat it as a separate device independent of the device it is connected to, and then we could simplify the model. In the other case, though, if device is turned off, there is no one to tell what the battery is doing, unless an intelligent PDU or someone is aware of that device. Which comes to some source - sink model as well. Could you please clarify your thoughts? thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter wrote: > Hi, > > just thinking out loud here. > > The thing which seems to complicate matters here significantly is > batteries. You either A) try to consider battery state in the devices' po= wer > state or you B) leave it separate in its own MIB module (as described e.g= . > here http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where w= e > have battery states full(1), partiallyCharged(2), empty(3), charging(4), > discharging(5), unknown(6)). I think these are the trade-offs: > > Option A) You can always tell from the device power state whether it is > drawing power or not ("off but charging" e.g.) and you might be able to > order them in a way that a higher state always translates to higher power > draw. It however seems to complicate power states. > > Option B) If a battery is present, you cannot tell from the device's powe= r > state whether is it drawing power or not ("off" could be really "off but > charging"). The device power states can be modelled cleaner though and yo= u'd > need to look closer to see what the battery state is to be sure there is = no > power draw. > > Is that the trade-off we're talking about or is there anything else that > needs to be considered? > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n > W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > > Juergen Quittek > > Sent: Freitag, 11. M=E4rz 2011 10:37 > > To: Bruce Nordman > > Cc: eman mailing list > > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Bruce, > > > > I understand your preference for a simple off-sleep-on model for power > > states. > > How would we model a device with a battery then > > - it is off, but the empty battery is being charged > > - it is on, but fully supplied with power from the battery. > > > > On way would be treating the (internal) battery as separate device. > > In this case: Can we map charging/discharging/full/empty to off-sleep- > > on? > > > > Thanks, > > > > Juergen > > > > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > > > > (all below as contributor) > > > > > > > > > > For many decades, electrical products were usually just on or off > > - a 2-state power model. In the last several decades, we have added > > many electronic products with a 3-state model - on, sleep, and off. > > This is necessary and existing complexity. Our discussions around > > power states boil down to what complexity do we want to add to the 3- > > state model, and why the burden is justified. > > > > > > > > > > > > In discussions on this email list, in I-drafts, and in person, > > the existing listings of power states from ACPI and DMTF are often > > referenced as good candidates for eman to adopt in some way. ACPI is a > > hugely important technology, and it enables large amounts of user > > functionality and energy savings. I am less familiar with the reach of > > DMTF in practice, but its depth and breadth of membership are > > compelling. While I agree they both deserve close examination, I think > > we can safely drop them from our discussions of what to define as their > > complexity is more a distraction than an asset. > > > > > > > > > > The basic ACPI list is of "Global System States" which "apply to > > the entire system". There are four of these (G0-G3); G0 is on > > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > > (only distinguished by whether a device is completely depowered and > > whether it is safe to disassemble or not, and these distinctions seems > > quite minor for eman purposes). Thus, the ACPI Global states are > > essentially on/sleep/off, the 3-state power model. > > > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > > actually the G2 Off state (so not a sleep state at all), and current > > implementations do not use S1 or S2, so in practice there are only two > > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > > quick wakeup. S4 is the hibernate state (with system memory saved in > > non-volatile memory, possibly a hard disk) which typically has long > > times to return to operation (often tens of seconds). The 1-2 second > > wake time from S3 for modern personal computers is compatible with many > > IP protocol usages, e.g. initiating a TCP connection. The tens of > > seconds time for S4 on current systems is not. So, the only potential > > addition that the Sx states add to on/sleep/off is hibernate (and > > reasonable people can differ on whether it is a fourth basic state, a > > form of sleep, or a form of off). > > > > > > ACPI does define processor states (Cx) and device > > states (Dx) (collectively Px), but these are the states of particular > > components, not of the system as a whole. It may be useful to expose > > these through some mechanism, but they are distinct from the power > > state. > > > > > > > > > > DMTF essentially took the ACPI Gx states plus > > hibernate and added states that are commands and/or transitions. (Is > > "Master Bus Reset" a power state? I think not). If we don't include > > commands or transitions (I think we should not), then these reduce to > > the ACPI states. > > > > > > > > > > My conclusion: ACPI and DMTF do not significantly > > change the 3-state power model. If we want to talk about states beyond > > the 3-state model, it is more clear to simply reference those > > extensions directly (e.g. how best to treat hibernate). Note that this > > discussion - and all others on the list - are grounded in electronic > > devices. Other devices generally have a 2-state model (e.g. a light), > > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > > > > > > --Bruce > > > > > > > > > > -- > > Bruce Nordman > > Lawrence Berkeley National Laboratory > > eetd.lbl.gov/ea/nordman > > 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 > --bcaec51ddb2f11a5db049e3710ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rolf, Juergen

I like Rolf's idea very much. We sh= ould extend number of states to=A0accommodate=A0other sub states.=A0
<= div>
Here is one question I do have for Juergon, as handling = the battery keeps coming up in all the discussions.=A0

If the device is off, but battery is charging, who is r= eporting that and how? Is battery itself has the=A0intelligence to do so? I= n that case, can we treat it as a=A0separate=A0device=A0independent of the = device it is connected to, and then we could simplify the model.

In the other case, though, if device is turned off, the= re is no one to tell what the battery is doing, unless an=A0intelligent=A0P= DU or someone is aware of that device. Which comes to some source - sink mo= del as well.

Could you please clarify your thoughts?

<= /div>
thanks

-tg-
*:-.,_,.-:*= '``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**= :-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time... see it my way
*:= -.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-= .,_,.-:**:-.,_,.


On Fri, Mar 11, 2011 at 5:36 AM, Rolf Wi= nter <Rolf.Wi= nter@neclab.eu> wrote:
Hi,

just thinking out loud here.

The thing which seems to complicate matters here significantly is batteries= . You either A) try to consider battery state in the devices' power sta= te or you B) leave it separate in its own MIB module (as described e.g. her= e http://tools.ietf.org/html/draft-quittek-eman-battery-mib= -00 where we have battery states full(1), partiallyCharged(2), empty(3)= , charging(4), discharging(5), unknown(6)). I think these are the trade-off= s:

Option A) You can always tell from the device power state whether it is dra= wing power or not ("off but charging" e.g.) and you might be able= to order them in a way that a higher state always translates to higher pow= er draw. It however seems to complicate power states.

Option B) If a battery is present, you cannot tell from the device's po= wer state whether is it drawing power or not ("off" could be real= ly "off but charging"). The device power states can be modelled c= leaner though and you'd need to look closer to see what the battery sta= te is to be sure there is no power draw.

Is that the trade-off we're talking about or is there anything else tha= t needs to be considered?

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014


> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [eman] Power states - time to dump ACPI and DMTF
>
> Hi Bruce,
>
> I understand your preference for a simple off-sleep-on model for power=
> states.
> How would we model a device with a battery then
> =A0 - it is off, but the empty battery is being charged
> =A0 - it is on, but fully supplied with power from the battery.
>
> On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep-=
> on?
>
> Thanks,
>
> =A0 =A0 Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce Nordman:
>
>
> =A0 =A0 =A0 (all below as contributor)
>
>
>
>
> =A0 =A0 =A0 For many decades, electrical products were usually just on= or off
> - a 2-state power model. =A0In the last several decades, we have added=
> many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. =A0Our discussions around > power states boil down to what complexity do we want to add to the 3-<= br> > state model, and why the burden is justified.
>
>
>
>
>
> =A0 =A0 =A0 In discussions on this email list, in I-drafts, and in per= son,
> the existing listings of power states from ACPI and DMTF are often
> referenced as good candidates for eman to adopt in some way. =A0ACPI i= s a
> hugely important technology, and it enables large amounts of user
> functionality and energy savings. =A0I am less familiar with the reach= of
> DMTF in practice, but its depth and breadth of membership are
> compelling. =A0While I agree they both deserve close examination, I th= ink
> we can safely drop them from our discussions of what to define as thei= r
> complexity is more a distraction than an asset.
>
>
>
>
> =A0 =A0 =A0 The basic ACPI list is of =A0"Global System States&qu= ot; which "apply to
> the entire system". =A0There are four of these (G0-G3); G0 is on<= br> > ("working") and G1 is sleep ("sleeping"). =A0G2 an= d G3 both forms of off
> (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems=
> quite minor for eman purposes). =A0Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ACPI lists five "Sx" sle= ep states (S0 is on). =A0S5 is
> actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two=
> ACPI sleep states: S3 and S4. =A0S3 is the ordinary system sleep, with=
> quick wakeup. =A0S4 is the hibernate state (with system memory saved i= n
> non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). =A0 The 1-2 seco= nd
> wake time from S3 for modern personal computers is compatible with man= y
> IP protocol usages, e.g. initiating a TCP connection. =A0The tens of > seconds time for S4 on current systems is not. =A0So, the only potenti= al
> addition that the Sx states add to on/sleep/off is hibernate (and
> reasonable people can differ on whether it is a fourth basic state, a<= br> > form of sleep, or a form of off).
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ACPI does define processor states = (Cx) and device
> states (Dx) (collectively Px), but these are the states of particular<= br> > components, not of the system as a whole. =A0It may be useful to expos= e
> these through some mechanism, but they are distinct from the power
> state.
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DMTF essentially took the ACPI Gx = states plus
> hibernate and added states that are commands and/or transitions. =A0(I= s
> "Master Bus Reset" a power state? =A0I think not). =A0If we = don't include
> commands or transitions (I think we should not), then these reduce to<= br> > the ACPI states.
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 My conclusion: ACPI and DMTF do no= t significantly
> change the 3-state power model. =A0If we want to talk about states bey= ond
> the 3-state model, it is more clear to simply reference those
> extensions directly (e.g. how best to treat hibernate). =A0Note that t= his
> discussion - and all others on the list - are grounded in electronic > devices. =A0Other devices generally have a 2-state model (e.g. a light= ),
> or 3 states, but on, off, and "ready" (think a microwave ove= n).
>
>
>
>
> =A0 =A0 =A0 --Bruce
>
>
>
>
> =A0 =A0 =A0 --
> =A0 =A0 =A0 Bruce Nordman
> =A0 =A0 =A0 Lawrence Berkeley National Laboratory
> =A0 =A0 =A0 eetd.lbl.gov/ea/nordman
> =A0 =A0 =A0 BNordman@LBL.gov
> =A0 =A0 =A0 510-486-7089
> =A0 =A0 =A0 m: 510-501-7943
>
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 eman mailing list
> =A0 =A0 =A0 eman@ietf.org
> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/eman
>
>

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

--bcaec51ddb2f11a5db049e3710ea-- From chrisv@cyberswitching.com Fri Mar 11 08:03:44 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E821E3A6A00 for ; Fri, 11 Mar 2011 08:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwdCpx9cncM1 for ; Fri, 11 Mar 2011 08:03:37 -0800 (PST) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) by core3.amsl.com (Postfix) with ESMTP id C954B3A69F7 for ; Fri, 11 Mar 2011 08:03:36 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o143.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 8284a7d4.0.156791.00-305.332340.p01c11o143.mxlogic.net (envelope-from ); Fri, 11 Mar 2011 09:04:56 -0700 (MST) X-MXL-Hash: 4d7a482871d98e33-524c178ab6cc8a1933d368989fd8328adb580f9b X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE005.FACD83F6" Date: Fri, 11 Mar 2011 08:04:18 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AcvgBXzHE6+LI7LjQqGg7FWeG44+cQAAEYew References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> From: "Chris Verges" To: "Ted Ghose" , "Rolf Winter" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=SbxTRnKmSzQA:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=48vgC7mUAAAA:8 a=xIbi9Fw0kRpFkstK4t8A:] X-AnalysisOut: [9 a=JUGRmI9qRV2Zgpc-VW4A:7 a=2Pk0jTpToLKTn-MbxCbeFAMhYJUA:] X-AnalysisOut: [4 a=wPNLvfGTeEIA:10 a=FnBvD0j_UmcA:10 a=lr71C7C2fScA:10 a=] X-AnalysisOut: [lZB815dzVvQA:10 a=Aeo_T2MqaaFY6dx9:21 a=WRqSgGefZemGpbNB:2] X-AnalysisOut: [1 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=J35dNKfbAAAA:8 a=WzU] X-AnalysisOut: [az1D7oKu_crVL6sIA:9 a=SlNU_ycPJT2aZAiHOysA:7 a=KCX-v2j7OKg] X-AnalysisOut: [4Wlhk29iqN1JrfyYA:4] Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 16:03:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE005.FACD83F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ted, =20 I might be putting words into Rolf's mouth, but here are my thoughts on = this: =20 Certain devices, like servers, that contain a Lights Out Management = (LOM) card will be able to report the server's power supply as "off" but = the battery as "charging". This combination for the server entity = results in the desired effect. =20 Rolf, anywhere in the ballpark? =20 Chris =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Ted Ghose Sent: Friday, March 11, 2011 8:01 AM To: Rolf Winter Cc: Bruce Nordman; eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Hi Rolf, Juergen =20 I like Rolf's idea very much. We should extend number of states to = accommodate other sub states.=20 =20 Here is one question I do have for Juergon, as handling the battery = keeps coming up in all the discussions.=20 =20 If the device is off, but battery is charging, who is reporting that and = how? Is battery itself has the intelligence to do so? In that case, can = we treat it as a separate device independent of the device it is = connected to, and then we could simplify the model. =20 In the other case, though, if device is turned off, there is no one to = tell what the battery is doing, unless an intelligent PDU or someone is = aware of that device. Which comes to some source - sink model as well. =20 Could you please clarify your thoughts? =20 thanks =20 -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = wrote: Hi, just thinking out loud here. The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here = http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we = have battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the trade-offs: Option A) You can always tell from the device power state whether it is = drawing power or not ("off but charging" e.g.) and you might be able to = order them in a way that a higher state always translates to higher = power draw. It however seems to complicate power states. Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be really = "off but charging"). The device power states can be modelled cleaner = though and you'd need to look closer to see what the battery state is to = be sure there is no power draw. Is that the trade-off we're talking about or is there anything else that = needs to be considered? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Juergen Quittek > Sent: Freitag, 11. M=E4rz 2011 10:37 > To: Bruce Nordman > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > Hi Bruce, > > I understand your preference for a simple off-sleep-on model for power > states. > How would we model a device with a battery then > - it is off, but the empty battery is being charged > - it is on, but fully supplied with power from the battery. > > On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep- > on? > > Thanks, > > Juergen > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > (all below as contributor) > > > > > For many decades, electrical products were usually just on or = off > - a 2-state power model. In the last several decades, we have added > many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. Our discussions around > power states boil down to what complexity do we want to add to the 3- > state model, and why the burden is justified. > > > > > > In discussions on this email list, in I-drafts, and in person, > the existing listings of power states from ACPI and DMTF are often > referenced as good candidates for eman to adopt in some way. ACPI is = a > hugely important technology, and it enables large amounts of user > functionality and energy savings. I am less familiar with the reach = of > DMTF in practice, but its depth and breadth of membership are > compelling. While I agree they both deserve close examination, I = think > we can safely drop them from our discussions of what to define as = their > complexity is more a distraction than an asset. > > > > > The basic ACPI list is of "Global System States" which "apply = to > the entire system". There are four of these (G0-G3); G0 is on > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems > quite minor for eman purposes). Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model. > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > quick wakeup. S4 is the hibernate state (with system memory saved in > non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). The 1-2 second > wake time from S3 for modern personal computers is compatible with = many > IP protocol usages, e.g. initiating a TCP connection. The tens of > seconds time for S4 on current systems is not. So, the only potential > addition that the Sx states add to on/sleep/off is hibernate (and > reasonable people can differ on whether it is a fourth basic state, a > form of sleep, or a form of off). > > > ACPI does define processor states (Cx) and device > states (Dx) (collectively Px), but these are the states of particular > components, not of the system as a whole. It may be useful to expose > these through some mechanism, but they are distinct from the power > state. > > > > > DMTF essentially took the ACPI Gx states plus > hibernate and added states that are commands and/or transitions. (Is > "Master Bus Reset" a power state? I think not). If we don't include > commands or transitions (I think we should not), then these reduce to > the ACPI states. > > > > > My conclusion: ACPI and DMTF do not significantly > change the 3-state power model. If we want to talk about states = beyond > the 3-state model, it is more clear to simply reference those > extensions directly (e.g. how best to treat hibernate). Note that = this > discussion - and all others on the list - are grounded in electronic > devices. Other devices generally have a 2-state model (e.g. a light), > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > --Bruce > > > > > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > 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 =20 ------_=_NextPart_001_01CBE005.FACD83F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ted,

 

I might be putting words into Rolf’s mouth, but here are my = thoughts on this:

 

Certain devices, like servers, that contain a Lights Out Management = (LOM) card will be able to report the server’s power supply as = “off” but the battery as “charging”.=A0 This = combination for the server entity results in the desired = effect.

 

Rolf, anywhere in the ballpark?

 

Chris

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Ted Ghose
Sent: Friday, March 11, 2011 8:01 = AM
To: Rolf Winter
Cc: Bruce Nordman; eman mailing = list
Subject: Re: [eman] Power states - time to dump ACPI and = DMTF

 

Hi Rolf, Juergen

 

I = like Rolf's idea very much. We should extend number of states = to accommodate other sub = states. 

 

Here is one question I do have for Juergon, as = handling the battery keeps coming up in all the = discussions. 

 

If the device is off, but battery is charging, who is = reporting that and how? Is battery itself has the intelligence to = do so? In that case, can we treat it as = a separate device independent of the device it is = connected to, and then we could simplify the = model.

 

In the other case, though, if device is turned off, = there is no one to tell what the battery is doing, unless = an intelligent PDU or someone is aware of that device. Which = comes to some source - sink model as well.

 

Could you please clarify your = thoughts?

 

thanks

 

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:*= *:-.,_,.
                =      Save time... see it my = way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,= _,.

On Fri, Mar 11, 2011 = at 5:36 AM, Rolf Winter <Rolf.Winter@neclab.eu> = wrote:

Hi,

just thinking out = loud here.

The thing which seems to complicate matters here = significantly is batteries. You either A) try to consider battery state = in the devices' power state or you B) leave it separate in its own MIB = module (as described e.g. here http://tools.ietf.org/html/draft-quittek-eman-battery-m= ib-00 where we have battery states full(1), partiallyCharged(2), = empty(3), charging(4), discharging(5), unknown(6)). I think these are = the trade-offs:

Option A) You can always tell from the device = power state whether it is drawing power or not ("off but = charging" e.g.) and you might be able to order them in a way that a = higher state always translates to higher power draw. It however seems to = complicate power states.

Option B) If a battery is present, you = cannot tell from the device's power state whether is it drawing power or = not ("off" could be really "off but charging"). The = device power states can be modelled cleaner though and you'd need to = look closer to see what the battery state is to be sure there is no = power draw.

Is that the trade-off we're talking about or is there = anything else that needs to be = considered?

Best,

Rolf

NEC Europe Limited | = Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014



> -----Original Message-----
> From: = eman-bounces@ietf.org = [mailto:eman-bounces@ietf.org] On = Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 = 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> = Subject: Re: [eman] Power states - time to dump ACPI and = DMTF
>
> Hi Bruce,
>
> I understand your = preference for a simple off-sleep-on model for power
> = states.
> How would we model a device with a battery then
> =   - it is off, but the empty battery is being charged
> =   - it is on, but fully supplied with power from the = battery.
>
> On way would be treating the (internal) battery = as separate device.
> In this case: Can we map = charging/discharging/full/empty to off-sleep-
> = on?
>
> Thanks,
>
>     = Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce = Nordman:
>
>
>       (all below as = contributor)
>
>
>
>
>     =   For many decades, electrical products were usually just on or = off
> - a 2-state power model.  In the last several decades, = we have added
> many electronic products with a 3-state model - = on, sleep, and off.
> This is necessary and existing complexity. =  Our discussions around
> power states boil down to what = complexity do we want to add to the 3-
> state model, and why the = burden is justified.
>
>
>
>
>
> =       In discussions on this email list, in I-drafts, and = in person,
> the existing listings of power states from ACPI and = DMTF are often
> referenced as good candidates for eman to adopt = in some way.  ACPI is a
> hugely important technology, and it = enables large amounts of user
> functionality and energy savings. =  I am less familiar with the reach of
> DMTF in practice, but = its depth and breadth of membership are
> compelling.  While = I agree they both deserve close examination, I think
> we can = safely drop them from our discussions of what to define as their
> = complexity is more a distraction than an = asset.
>
>
>
>
>       The = basic ACPI list is of  "Global System States" which = "apply to
> the entire system".  There are four of = these (G0-G3); G0 is on
> ("working") and G1 is sleep = ("sleeping").  G2 and G3 both forms of off
> (only = distinguished by whether a device is completely depowered and
> = whether it is safe to disassemble or not, and these distinctions = seems
> quite minor for eman purposes).  Thus, the ACPI = Global states are
> essentially on/sleep/off, the 3-state power = model.
>
>               =     ACPI lists five "Sx" sleep states (S0 is on). =  S5 is
> actually the G2 Off state (so not a sleep state at = all), and current
> implementations do not use S1 or S2, so in = practice there are only two
> ACPI sleep states: S3 and S4. =  S3 is the ordinary system sleep, with
> quick wakeup. =  S4 is the hibernate state (with system memory saved in
> = non-volatile memory, possibly a hard disk) which typically has = long
> times to return to operation (often tens of seconds). =   The 1-2 second
> wake time from S3 for modern personal = computers is compatible with many
> IP protocol usages, e.g. = initiating a TCP connection.  The tens of
> seconds time for = S4 on current systems is not.  So, the only potential
> = addition that the Sx states add to on/sleep/off is hibernate = (and
> reasonable people can differ on whether it is a fourth = basic state, a
> form of sleep, or a form of = off).
>
>
>             =       ACPI does define processor states (Cx) and = device
> states (Dx) (collectively Px), but these are the states = of particular
> components, not of the system as a whole.  It = may be useful to expose
> these through some mechanism, but they = are distinct from the power
> = state.
>
>
>
>
>       =             DMTF essentially took the ACPI = Gx states plus
> hibernate and added states that are commands = and/or transitions.  (Is
> "Master Bus Reset" a = power state?  I think not).  If we don't include
> = commands or transitions (I think we should not), then these reduce = to
> the ACPI states.
>
>
>
>
> =                   My = conclusion: ACPI and DMTF do not significantly
> change the = 3-state power model.  If we want to talk about states = beyond
> the 3-state model, it is more clear to simply reference = those
> extensions directly (e.g. how best to treat hibernate). =  Note that this
> discussion - and all others on the list - = are grounded in electronic
> devices.  Other devices = generally have a 2-state model (e.g. a light),
> or 3 states, but = on, off, and "ready" (think a microwave = oven).
>
>
>
>
>       = --Bruce
>
>
>
>
>       = --
>       Bruce Nordman
>     =   Lawrence Berkeley National Laboratory
>     =   eetd.lbl.gov/ea/nordman
>     =   BNordman@LBL.gov
> =       510-486-7089
>       = m: 510-501-7943
>
>   =     _______________________________________________
> =       eman mailing list
>       eman@ietf.org
>     =   https://www.ietf.org/mailman/listinfo/eman
><= br>>

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

 

------_=_NextPart_001_01CBE005.FACD83F6-- From jparello@cisco.com Fri Mar 11 09:38:21 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E663A6A5A for ; Fri, 11 Mar 2011 09:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29wEKaIk-Lpk for ; Fri, 11 Mar 2011 09:38:11 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D7E003A6927 for ; Fri, 11 Mar 2011 09:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=21750; q=dns/txt; s=iport; t=1299865171; x=1301074771; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=KlMa279jHV/t3oVJIyPD9ro0hTGYyHMn+/7te2RYGTA=; b=dAAVwJfJ4N+E1lNLDoth6/Mxx/QZBHsB4mqtIAKn+aO87E8FpbzA/6Kh oLACQQsDKaBH3fX8f4JqO8mAdLHQKqyjU1876cKSxqilddA7b8YbTzuBx V6wNn6VKumwXENzynyvobkKvcB9Vv/qx0PQ5/jbQAoXLfSciverPlj6QT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0AAIvseU2tJV2Y/2dsb2JhbACCW5YJhkkBhwN3pgOcKYMVgk0EhSmKdg X-IronPort-AV: E=Sophos;i="4.62,304,1297036800"; d="scan'208,217";a="666589044" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 11 Mar 2011 17:39:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2BHdRTD018885; Fri, 11 Mar 2011 17:39:30 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Mar 2011 09:39:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE013.45494556" Date: Fri, 11 Mar 2011 09:34:57 -0800 Message-ID: In-Reply-To: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to enhance ACPI and DMTF Thread-Index: Acvfz/jVSfDczN0BSAa8JQYPHZmRBgAQOe6A References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" , "Bruce Nordman" X-OriginalArrivalTime: 11 Mar 2011 17:39:28.0611 (UTC) FILETIME=[458DC330:01CBE013] Cc: eman mailing list Subject: Re: [eman] Power states - time to enhance ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 17:38:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE013.45494556 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HI Bruce, =20 I would also add to that how would you model a simple motor with gears. If you want to monitor the power over time (energy) you would not be able to trend or compare the usage of the motor as it did useful work. =20 With EEE and the changes in networking gear the power characteristic will vary as the device does useful work exactly as motors do. =20 An analogy would be a car with gears. The power characteristics of a car is very different depending upon what gear you are in. Your proposal would be to ignore the power capabilities and just model it as on? So as you see a trend of usage increase did the motor become in disrepair or did you change gears. =20 Also I'd like to draw from experience here. We had on and off for decades on our product lines. Once we introduced the notion of a spectrum of states our product teams (over 20 that are comparable to small companies) and 40 partners all embraced it and were able to model and provide lower operational states by choosing to implement states from that spectrum of possibilities. =20 On and off and standby is just saying there is only black and white and other and does provide not color into the spectrum of states. =20 Jp =20 =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Friday, March 11, 2011 1:37 AM To: Bruce Nordman Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Hi Bruce, =20 I understand your preference for a simple off-sleep-on model for power states. How would we model a device with a battery then=20 - it is off, but the empty battery is being charged - it is on, but fully supplied with power from the battery. =20 On way would be treating the (internal) battery as separate device. In this case: Can we map charging/discharging/full/empty to off-sleep-on? =20 Thanks, =20 Juergen =20 =20 Am 11.03.2011 um 07:37 schrieb Bruce Nordman: (all below as contributor) For many decades, electrical products were usually just on or off - a 2-state power model. In the last several decades, we have added many electronic products with a 3-state model - on, sleep, and off. This is necessary and existing complexity. Our discussions around power states boil down to what complexity do we want to add to the 3-state model, and why the burden is justified. =20 In discussions on this email list, in I-drafts, and in person, the existing listings of power states from ACPI and DMTF are often referenced as good candidates for eman to adopt in some way. ACPI is a hugely important technology, and it enables large amounts of user functionality and energy savings. I am less familiar with the reach of DMTF in practice, but its depth and breadth of membership are compelling. While I agree they both deserve close examination, I think we can safely drop them from our discussions of what to define as their complexity is more a distraction than an asset. =20 The basic ACPI list is of "Global System States" which "apply to the entire system". There are four of these (G0-G3); G0 is on ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off (only distinguished by whether a device is completely depowered and whether it is safe to disassemble or not, and these distinctions seems quite minor for eman purposes). Thus, the ACPI Global states are essentially on/sleep/off, the 3-state power model. ACPI lists five "Sx" sleep states (S0 is on). S5 is actually the G2 Off state (so not a sleep state at all), and current implementations do not use S1 or S2, so in practice there are only two ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with quick wakeup. S4 is the hibernate state (with system memory saved in non-volatile memory, possibly a hard disk) which typically has long times to return to operation (often tens of seconds). The 1-2 second wake time from S3 for modern personal computers is compatible with many IP protocol usages, e.g. initiating a TCP connection. The tens of seconds time for S4 on current systems is not. So, the only potential addition that the Sx states add to on/sleep/off is hibernate (and reasonable people can differ on whether it is a fourth basic state, a form of sleep, or a form of off). ACPI does define processor states (Cx) and device states (Dx) (collectively Px), but these are the states of particular components, not of the system as a whole. It may be useful to expose these through some mechanism, but they are distinct from the power state. =20 DMTF essentially took the ACPI Gx states plus hibernate and added states that are commands and/or transitions. (Is "Master Bus Reset" a power state? I think not). If we don't include commands or transitions (I think we should not), then these reduce to the ACPI states. =20 My conclusion: ACPI and DMTF do not significantly change the 3-state power model. If we want to talk about states beyond the 3-state model, it is more clear to simply reference those extensions directly (e.g. how best to treat hibernate). Note that this discussion - and all others on the list - are grounded in electronic devices. Other devices generally have a 2-state model (e.g. a light), or 3 states, but on, off, and "ready" (think a microwave oven). =20 --Bruce --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman =20 ------_=_NextPart_001_01CBE013.45494556 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

HI Bruce,

 

I would also add to that how would you model a simple = motor with gears. If you want to monitor the power over time (energy)  you = would not be able to trend  or compare the usage of the motor as it did = useful work.

 

With EEE and the changes in networking gear the power characteristic will vary as the device does useful work exactly as = motors do.

 

An analogy would be a car with gears. The power = characteristics of a car is very different depending upon what gear you are in. Your = proposal would be to ignore the power capabilities and just model it as on? So as = you see a trend of usage increase did the motor become in disrepair or did = you change gears.

 

Also I’d like to draw from experience here.  = We had on and off for decades on our product lines. Once we introduced the = notion of a spectrum of states our product teams (over 20 that are comparable to = small companies) and 40 partners all embraced it and were able to model and = provide lower operational states by choosing to implement states from that = spectrum of possibilities.

 

On and off and standby  is just saying there is only = black and white and other and does provide not color into the spectrum of = states.

 

Jp

 

 

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek
Sent: Friday, March 11, 2011 1:37 AM
To: Bruce Nordman
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and = DMTF

 

Hi Bruce,

 

I understand your preference for a simple = off-sleep-on model for power states.

How would we model a device with a = battery then 

  - it is off, but the empty = battery is being charged

  - it is on, but fully supplied with = power from the battery.

 

On way would be treating the (internal) battery as = separate device.

In this case: Can we map = charging/discharging/full/empty to off-sleep-on?

 

Thanks,

 

    Juergen

 

 

Am 11.03.2011 um 07:37 schrieb Bruce = Nordman:



(all below as = contributor)

For many decades, electrical products were usually = just on or off - a 2-state power model.  In the last several decades, we = have added many electronic products with a 3-state model - on, sleep, and = off.  This is necessary and existing complexity.  Our discussions around = power states boil down to what complexity do we want to add to the 3-state = model, and why the burden is justified.

 

In discussions on this email list, in I-drafts, and = in person, the existing listings of power states from ACPI and DMTF are = often referenced as good candidates for eman to adopt in some way.  ACPI = is a hugely important technology, and it enables large amounts of user = functionality and energy savings.  I am less familiar with the reach of DMTF in practice, but its depth and breadth of membership are compelling.  = While I agree they both deserve close examination, I think we can safely drop = them from our discussions of what to define as their complexity is more a = distraction than an asset.

 

The basic ACPI list is of  “Global = System States” which “apply to the entire system”.  = There are four of these (G0-G3); G0 is on (“working”) and G1 is sleep (“sleeping”).  G2 and G3 both forms of off (only = distinguished by whether a device is completely depowered and whether it is safe to disassemble or not, and these distinctions seems quite minor for eman = purposes).  Thus, the ACPI Global states are essentially on/sleep/off, the 3-state = power model.

         &= nbsp;  ACPI lists five “Sx” sleep states (S0 is on).  S5 is = actually the G2 Off state (so not a sleep state at all), and current = implementations do not use S1 or S2, so in practice there are only two ACPI sleep states: = S3 and S4.  S3 is the ordinary system sleep, with quick wakeup.  S4 = is the hibernate state (with system memory saved in non-volatile memory, = possibly a hard disk) which typically has long times to return to operation (often = tens of seconds).   The 1-2 second wake time from S3 for modern = personal computers is compatible with many IP protocol usages, e.g. initiating a = TCP connection.  The tens of seconds time for S4 on current systems is not.  So, the only potential addition that the Sx states add to on/sleep/off is hibernate (and reasonable people can differ on whether = it is a fourth basic state, a form of sleep, or a form of off).

         &= nbsp;  ACPI does define processor states (Cx) and device states (Dx) = (collectively Px), but these are the states of particular components, not of the = system as a whole.  It may be useful to expose these through some mechanism, = but they are distinct from the power state.

 

         &= nbsp;  DMTF essentially took the ACPI Gx states plus hibernate and added states = that are commands and/or transitions.  (Is "Master Bus Reset" = a power state?  I think not).  If we don’t include commands or transitions (I think we should not), then these reduce to the ACPI = states.

 

         &= nbsp;  My conclusion: ACPI and DMTF do not significantly change the 3-state = power model.  If we want to talk about states beyond the = 3-state model, it is more clear to simply reference those extensions directly = (e.g. how best to treat hibernate).  Note that this discussion - and all = others on the list - are grounded in electronic devices.  Other devices = generally have a 2-state model (e.g. a light), or 3 states, but on, off, and "ready" (think a microwave oven).

 

--Bruce



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

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

 

------_=_NextPart_001_01CBE013.45494556-- From bnordman@lbl.gov Fri Mar 11 16:41:24 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DFB3A6A7C for ; Fri, 11 Mar 2011 16:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYmWO6CrTaF5 for ; Fri, 11 Mar 2011 16:41:22 -0800 (PST) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by core3.amsl.com (Postfix) with ESMTP id 64BC83A672F for ; Fri, 11 Mar 2011 16:41:22 -0800 (PST) X-Ironport-SBRS: 5.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8BAHNPek3RVdy0mGdsb2JhbACCW5xaAYYqUQgUAQEBAQEICQ0HFCWnK5pygnwZgk0EhSmHJohrOg X-IronPort-AV: E=Sophos;i="4.62,306,1297065600"; d="scan'208";a="36723937" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport3.lbl.gov with ESMTP; 11 Mar 2011 16:42:41 -0800 Received: by vxk12 with SMTP id 12so4026vxk.39 for ; Fri, 11 Mar 2011 16:42:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.91.232 with SMTP id ch8mr5660871vdb.85.1299890559590; Fri, 11 Mar 2011 16:42:39 -0800 (PST) Received: by 10.52.155.40 with HTTP; Fri, 11 Mar 2011 16:42:39 -0800 (PST) In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> Date: Fri, 11 Mar 2011 16:42:39 -0800 Message-ID: From: Bruce Nordman To: Rolf Winter Content-Type: multipart/alternative; boundary=20cf307c9c3c0d2063049e3e5baf Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 00:41:24 -0000 --20cf307c9c3c0d2063049e3e5baf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good discussion. Batteries are a specific example of a case in which a device has a secondar= y function which can consume significant amounts of power, and the secondary function is independent of the primary one. My computer is an iMac with an integrated display, so the display is secondary to the primary function of computation, but unlike the battery, its function is not independent (display always powered down when the computational part is). Another example like the battery could be a TV with an integral video recorder. The recorder can be active when the TV display is asleep or off. A third example is an imaging MFD that does printing, copying, and scanning; it may have th= e scanner active at relatively low power, but the heat-intensive toner fusing unit powered down. Life would be simpler if devices were not multi-functional. I think we should insist on devices having a primary function (that is afterall how "identity" works), and the power state reflects that function. Simple devices with internal batteries can consume a lot of power in sleep or off. More sophisticated devices may choose to use the eman features for exposing the consumption of the battery and balance of the system, and then have a state for the batter exposed. We need to enable this but not require it. I am assuming that we will usually have both power state and current power draw in watts, so the NMS will look at both (and the product's identity) in deciding what is going on. (Perhaps part of identity is reporting if a non-trivial battery is present (though this can be a dynamic characteristic).) So, one can look at power level, at power state, or both. I think having both addresses Rolf's concerns. For Juergen's note about the states of off-but charging (so high power), and on (and presumably AC-connected) but running only off of battery power (so no AC draw), that confirms the need to have the actual mains power level. There have been notebook PCs designed to go off-grid in the afternoon to avoid times of high electricity demand, so this is a very real scenario. More important from my point of view, is that no one on this thread has jumped to the defense of ACPI/DMTF. I am more convinced than ever that they are a distraction for our purposes. --Bruce On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter wrote: > Hi, > > just thinking out loud here. > > The thing which seems to complicate matters here significantly is > batteries. You either A) try to consider battery state in the devices' po= wer > state or you B) leave it separate in its own MIB module (as described e.g= . > here http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where w= e > have battery states full(1), partiallyCharged(2), empty(3), charging(4), > discharging(5), unknown(6)). I think these are the trade-offs: > > Option A) You can always tell from the device power state whether it is > drawing power or not ("off but charging" e.g.) and you might be able to > order them in a way that a higher state always translates to higher power > draw. It however seems to complicate power states. > > Option B) If a battery is present, you cannot tell from the device's powe= r > state whether is it drawing power or not ("off" could be really "off but > charging"). The device power states can be modelled cleaner though and yo= u'd > need to look closer to see what the battery state is to be sure there is = no > power draw. > > Is that the trade-off we're talking about or is there anything else that > needs to be considered? > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n > W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > > Juergen Quittek > > Sent: Freitag, 11. M=E4rz 2011 10:37 > > To: Bruce Nordman > > Cc: eman mailing list > > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Bruce, > > > > I understand your preference for a simple off-sleep-on model for power > > states. > > How would we model a device with a battery then > > - it is off, but the empty battery is being charged > > - it is on, but fully supplied with power from the battery. > > > > On way would be treating the (internal) battery as separate device. > > In this case: Can we map charging/discharging/full/empty to off-sleep- > > on? > > > > Thanks, > > > > Juergen > > > > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > > > > (all below as contributor) > > > > > > > > > > For many decades, electrical products were usually just on or off > > - a 2-state power model. In the last several decades, we have added > > many electronic products with a 3-state model - on, sleep, and off. > > This is necessary and existing complexity. Our discussions around > > power states boil down to what complexity do we want to add to the 3- > > state model, and why the burden is justified. > > > > > > > > > > > > In discussions on this email list, in I-drafts, and in person, > > the existing listings of power states from ACPI and DMTF are often > > referenced as good candidates for eman to adopt in some way. ACPI is a > > hugely important technology, and it enables large amounts of user > > functionality and energy savings. I am less familiar with the reach of > > DMTF in practice, but its depth and breadth of membership are > > compelling. While I agree they both deserve close examination, I think > > we can safely drop them from our discussions of what to define as their > > complexity is more a distraction than an asset. > > > > > > > > > > The basic ACPI list is of "Global System States" which "apply to > > the entire system". There are four of these (G0-G3); G0 is on > > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > > (only distinguished by whether a device is completely depowered and > > whether it is safe to disassemble or not, and these distinctions seems > > quite minor for eman purposes). Thus, the ACPI Global states are > > essentially on/sleep/off, the 3-state power model. > > > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > > actually the G2 Off state (so not a sleep state at all), and current > > implementations do not use S1 or S2, so in practice there are only two > > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > > quick wakeup. S4 is the hibernate state (with system memory saved in > > non-volatile memory, possibly a hard disk) which typically has long > > times to return to operation (often tens of seconds). The 1-2 second > > wake time from S3 for modern personal computers is compatible with many > > IP protocol usages, e.g. initiating a TCP connection. The tens of > > seconds time for S4 on current systems is not. So, the only potential > > addition that the Sx states add to on/sleep/off is hibernate (and > > reasonable people can differ on whether it is a fourth basic state, a > > form of sleep, or a form of off). > > > > > > ACPI does define processor states (Cx) and device > > states (Dx) (collectively Px), but these are the states of particular > > components, not of the system as a whole. It may be useful to expose > > these through some mechanism, but they are distinct from the power > > state. > > > > > > > > > > DMTF essentially took the ACPI Gx states plus > > hibernate and added states that are commands and/or transitions. (Is > > "Master Bus Reset" a power state? I think not). If we don't include > > commands or transitions (I think we should not), then these reduce to > > the ACPI states. > > > > > > > > > > My conclusion: ACPI and DMTF do not significantly > > change the 3-state power model. If we want to talk about states beyond > > the 3-state model, it is more clear to simply reference those > > extensions directly (e.g. how best to treat hibernate). Note that this > > discussion - and all others on the list - are grounded in electronic > > devices. Other devices generally have a 2-state model (e.g. a light), > > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > > > > > > --Bruce > > > > > > > > > > -- > > Bruce Nordman > > Lawrence Berkeley National Laboratory > > eetd.lbl.gov/ea/nordman > > BNordman@LBL.gov > > 510-486-7089 > > m: 510-501-7943 > > > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman > > > > > > --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --20cf307c9c3c0d2063049e3e5baf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good discussion.

Batteries are a specific example of a case in which= a device has a secondary
function which can consume significant amounts= of power, and the secondary
function is independent of the primary one.= =A0 My computer is an iMac with an
integrated display, so the display is secondary to the primary function of = computation,
but unlike the battery, its function is not independent (di= splay always powered
down when the computational part is).

Anothe= r example like the battery could be a TV with an integral video recorder. The recorder can be active when the TV display is asleep or off.=A0 A third= example
is an imaging MFD that does printing, copying, and scanning; it= may have the
scanner active at relatively low power, but the heat-inten= sive toner fusing unit
powered down.=A0 Life would be simpler if devices were not multi-functional= .

I think we should insist on devices having a primary function (tha= t is afterall
how "identity" works), and the power state refle= cts that function.=A0 Simple devices
with internal batteries can consume a lot of power in sleep or off.=A0 More= sophisticated
devices may choose to use the eman features for exposing = the consumption of the
battery and balance of the system, and then have = a state for the batter exposed.
We need to enable this but not require it.

I am assuming that we wil= l usually have both power state and current power
draw in watts, so the = NMS will look at both (and the product's identity) in
deciding what = is going on.=A0 (Perhaps part of identity is reporting if a non-trivial
battery is present (though this can be a dynamic characteristic).)
So, o= ne can look at power level, at power state, or both.=A0 I think having
b= oth addresses Rolf's concerns.=A0

For Juergen's note about = the states of off-but charging (so high power),
and on (and presumably AC-connected) but running only off of battery power<= br>(so no AC draw), that confirms the need to have the actual mains powerlevel.=A0 There have been notebook PCs designed to go off-grid in the aft= ernoon
to avoid times of high electricity demand, so this is a very real scenario.=


More important from my point of view, is that no one on this th= read has jumped
to the defense of ACPI/DMTF.=A0 I am more convinced than= ever that they are
a distraction for our purposes.

--Bruce

On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter <Rolf.Winter@neclab.eu>= wrote:
Hi,

just thinking out loud here.

The thing which seems to complicate matters here significantly is batteries= . You either A) try to consider battery state in the devices' power sta= te or you B) leave it separate in its own MIB module (as described e.g. her= e http://tools.ietf.org/html/draft-quittek-eman-battery-mib= -00 where we have battery states full(1), partiallyCharged(2), empty(3)= , charging(4), discharging(5), unknown(6)). I think these are the trade-off= s:

Option A) You can always tell from the device power state whether it is dra= wing power or not ("off but charging" e.g.) and you might be able= to order them in a way that a higher state always translates to higher pow= er draw. It however seems to complicate power states.

Option B) If a battery is present, you cannot tell from the device's po= wer state whether is it drawing power or not ("off" could be real= ly "off but charging"). The device power states can be modelled c= leaner though and you'd need to look closer to see what the battery sta= te is to be sure there is no power draw.

Is that the trade-off we're talking about or is there anything else tha= t needs to be considered?

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014


> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [eman] Power states - time to dump ACPI and DMTF
>
> Hi Bruce,
>
> I understand your preference for a simple off-sleep-on model for power=
> states.
> How would we model a device with a battery then
> =A0 - it is off, but the empty battery is being charged
> =A0 - it is on, but fully supplied with power from the battery.
>
> On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep-=
> on?
>
> Thanks,
>
> =A0 =A0 Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce Nordman:
>
>
> =A0 =A0 =A0 (all below as contributor)
>
>
>
>
> =A0 =A0 =A0 For many decades, electrical products were usually just on= or off
> - a 2-state power model. =A0In the last several decades, we have added=
> many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. =A0Our discussions around > power states boil down to what complexity do we want to add to the 3-<= br> > state model, and why the burden is justified.
>
>
>
>
>
> =A0 =A0 =A0 In discussions on this email list, in I-drafts, and in per= son,
> the existing listings of power states from ACPI and DMTF are often
> referenced as good candidates for eman to adopt in some way. =A0ACPI i= s a
> hugely important technology, and it enables large amounts of user
> functionality and energy savings. =A0I am less familiar with the reach= of
> DMTF in practice, but its depth and breadth of membership are
> compelling. =A0While I agree they both deserve close examination, I th= ink
> we can safely drop them from our discussions of what to define as thei= r
> complexity is more a distraction than an asset.
>
>
>
>
> =A0 =A0 =A0 The basic ACPI list is of =A0"Global System States&qu= ot; which "apply to
> the entire system". =A0There are four of these (G0-G3); G0 is on<= br> > ("working") and G1 is sleep ("sleeping"). =A0G2 an= d G3 both forms of off
> (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems=
> quite minor for eman purposes). =A0Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ACPI lists five "Sx" sle= ep states (S0 is on). =A0S5 is
> actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two=
> ACPI sleep states: S3 and S4. =A0S3 is the ordinary system sleep, with=
> quick wakeup. =A0S4 is the hibernate state (with system memory saved i= n
> non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). =A0 The 1-2 seco= nd
> wake time from S3 for modern personal computers is compatible with man= y
> IP protocol usages, e.g. initiating a TCP connection. =A0The tens of > seconds time for S4 on current systems is not. =A0So, the only potenti= al
> addition that the Sx states add to on/sleep/off is hibernate (and
> reasonable people can differ on whether it is a fourth basic state, a<= br> > form of sleep, or a form of off).
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ACPI does define processor states = (Cx) and device
> states (Dx) (collectively Px), but these are the states of particular<= br> > components, not of the system as a whole. =A0It may be useful to expos= e
> these through some mechanism, but they are distinct from the power
> state.
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DMTF essentially took the ACPI Gx = states plus
> hibernate and added states that are commands and/or transitions. =A0(I= s
> "Master Bus Reset" a power state? =A0I think not). =A0If we = don't include
> commands or transitions (I think we should not), then these reduce to<= br> > the ACPI states.
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 My conclusion: ACPI and DMTF do no= t significantly
> change the 3-state power model. =A0If we want to talk about states bey= ond
> the 3-state model, it is more clear to simply reference those
> extensions directly (e.g. how best to treat hibernate). =A0Note that t= his
> discussion - and all others on the list - are grounded in electronic > devices. =A0Other devices generally have a 2-state model (e.g. a light= ),
> or 3 states, but on, off, and "ready" (think a microwave ove= n).
>
>
>
>
> =A0 =A0 =A0 --Bruce
>
>
>
>
> =A0 =A0 =A0 --
> =A0 =A0 =A0 Bruce Nordman
> =A0 =A0 =A0 Lawrence Berkeley National Laboratory
> =A0 =A0 =A0 eetd.lbl.gov/ea/nordman
> =A0 =A0 =A0 BNordman@LBL.gov
> =A0 =A0 =A0 510-486-7089
> =A0 =A0 =A0 m: 510-501-7943
>
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 eman mailing list
> =A0 =A0 =A0 eman@ietf.org
> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/eman
>
>




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

--20cf307c9c3c0d2063049e3e5baf-- From chrisv@cyberswitching.com Fri Mar 11 17:06:37 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9FC3A6B4C for ; Fri, 11 Mar 2011 17:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0jG+eZas49d for ; Fri, 11 Mar 2011 17:06:25 -0800 (PST) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by core3.amsl.com (Postfix) with ESMTP id 62E243A6AF8 for ; Fri, 11 Mar 2011 17:06:24 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o149.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 067ca7d4.0.37451.00-388.81824.p01c11o149.mxlogic.net (envelope-from ); Fri, 11 Mar 2011 18:07:44 -0700 (MST) X-MXL-Hash: 4d7ac760256b4154-ab4a0510453ef50756b8d6493add3a99fc8c0b36 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE051.CCFE13E2" Date: Fri, 11 Mar 2011 17:07:03 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CF36845@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AcvgTlH9Bg0OvbsTScGN5is2YGzi/gAAm0KQ References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> From: "Chris Verges" To: "Bruce Nordman" , "Rolf Winter" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=SbxTRnKmSzQA:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=48vgC7mUAAAA:8 a=_uilagmqgqI8Ns8k20sA:] X-AnalysisOut: [9 a=h68GW-OzY1_vWfTzoroA:7 a=fsmYXZvAXNw7AZ5AxeHEJa8ho8kA:] X-AnalysisOut: [4 a=wPNLvfGTeEIA:10 a=FnBvD0j_UmcA:10 a=lr71C7C2fScA:10 a=] X-AnalysisOut: [lZB815dzVvQA:10 a=y6sBMSooRaw9hiBB:21 a=iVcZsoyqacJZeVHm:2] X-AnalysisOut: [1 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=J35dNKfbAAAA:8 a=-r4] X-AnalysisOut: [mvNWO6qNHwtMsewEA:9 a=F7wJqG0vK-j__qgG8m4A:7 a=npoqn6Bod4y] X-AnalysisOut: [WO9miVEorROdHTTkA:4] Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 01:06:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE051.CCFE13E2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruce, =20 Please don't take silence as a form of acceptance. That's a dangerous = assumption. =20 My position is that a single state mechanism is not appropriate for EMAN = to consider. EMAN should support multiple state mechanisms, that = coexist with each other. =20 Consider the following scenario: =20 Three forms of state management: ACPI, DMTF, and PDU State Management. = (PDU states include on, off, reboot, tripped, and shed. Only for = example purposes, exact details to be worked out later.) =20 server-a - supports ACPI only server-b - supports ACPI and DMTF PDU - supports EMAN PDU State Management =20 I propose that we allow each device to support the modality that makes = sense for that device. The key is not in which modality is supported, = but rather how the user accesses the modality. Why would we try to = limit innovation by restricting what people can do? =20 Expose different hooks to allow a user to access ACPI, DMTF, and/or PDU = State Management through three different interfaces: =20 emanStateControlAcpi - implemented by entities which know how to respond = to ACPI states emanStateControlDmtf - implemented by entities which know how to respond = to DMTF states emanStateControlPdu - implemented by entities which know how to respond = to PDU State Management =20 This makes the EMAN schema more powerful and allows the market to adapt = easily as future changes in technologies and our understanding of how to = use those technologies improves. =20 Chris =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Bruce Nordman Sent: Friday, March 11, 2011 4:43 PM To: Rolf Winter Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Good discussion. Batteries are a specific example of a case in which a device has a = secondary function which can consume significant amounts of power, and the = secondary function is independent of the primary one. My computer is an iMac with = an integrated display, so the display is secondary to the primary function = of computation, but unlike the battery, its function is not independent (display always = powered down when the computational part is). Another example like the battery could be a TV with an integral video = recorder. The recorder can be active when the TV display is asleep or off. A = third example is an imaging MFD that does printing, copying, and scanning; it may have = the scanner active at relatively low power, but the heat-intensive toner = fusing unit powered down. Life would be simpler if devices were not = multi-functional. I think we should insist on devices having a primary function (that is = afterall how "identity" works), and the power state reflects that function. = Simple devices with internal batteries can consume a lot of power in sleep or off. = More sophisticated devices may choose to use the eman features for exposing the consumption = of the battery and balance of the system, and then have a state for the batter = exposed. We need to enable this but not require it. I am assuming that we will usually have both power state and current = power draw in watts, so the NMS will look at both (and the product's identity) = in deciding what is going on. (Perhaps part of identity is reporting if a = non-trivial battery is present (though this can be a dynamic characteristic).) So, one can look at power level, at power state, or both. I think = having both addresses Rolf's concerns. =20 For Juergen's note about the states of off-but charging (so high power), and on (and presumably AC-connected) but running only off of battery = power (so no AC draw), that confirms the need to have the actual mains power level. There have been notebook PCs designed to go off-grid in the = afternoon to avoid times of high electricity demand, so this is a very real = scenario. More important from my point of view, is that no one on this thread has = jumped to the defense of ACPI/DMTF. I am more convinced than ever that they = are a distraction for our purposes. --Bruce On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = wrote: Hi, just thinking out loud here. The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here = http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we = have battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the trade-offs: Option A) You can always tell from the device power state whether it is = drawing power or not ("off but charging" e.g.) and you might be able to = order them in a way that a higher state always translates to higher = power draw. It however seems to complicate power states. Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be really = "off but charging"). The device power states can be modelled cleaner = though and you'd need to look closer to see what the battery state is to = be sure there is no power draw. Is that the trade-off we're talking about or is there anything else that = needs to be considered? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Juergen Quittek > Sent: Freitag, 11. M=E4rz 2011 10:37 > To: Bruce Nordman > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > Hi Bruce, > > I understand your preference for a simple off-sleep-on model for power > states. > How would we model a device with a battery then > - it is off, but the empty battery is being charged > - it is on, but fully supplied with power from the battery. > > On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep- > on? > > Thanks, > > Juergen > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > (all below as contributor) > > > > > For many decades, electrical products were usually just on or = off > - a 2-state power model. In the last several decades, we have added > many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. Our discussions around > power states boil down to what complexity do we want to add to the 3- > state model, and why the burden is justified. > > > > > > In discussions on this email list, in I-drafts, and in person, > the existing listings of power states from ACPI and DMTF are often > referenced as good candidates for eman to adopt in some way. ACPI is = a > hugely important technology, and it enables large amounts of user > functionality and energy savings. I am less familiar with the reach = of > DMTF in practice, but its depth and breadth of membership are > compelling. While I agree they both deserve close examination, I = think > we can safely drop them from our discussions of what to define as = their > complexity is more a distraction than an asset. > > > > > The basic ACPI list is of "Global System States" which "apply = to > the entire system". There are four of these (G0-G3); G0 is on > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems > quite minor for eman purposes). Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model. > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > quick wakeup. S4 is the hibernate state (with system memory saved in > non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). The 1-2 second > wake time from S3 for modern personal computers is compatible with = many > IP protocol usages, e.g. initiating a TCP connection. The tens of > seconds time for S4 on current systems is not. So, the only potential > addition that the Sx states add to on/sleep/off is hibernate (and > reasonable people can differ on whether it is a fourth basic state, a > form of sleep, or a form of off). > > > ACPI does define processor states (Cx) and device > states (Dx) (collectively Px), but these are the states of particular > components, not of the system as a whole. It may be useful to expose > these through some mechanism, but they are distinct from the power > state. > > > > > DMTF essentially took the ACPI Gx states plus > hibernate and added states that are commands and/or transitions. (Is > "Master Bus Reset" a power state? I think not). If we don't include > commands or transitions (I think we should not), then these reduce to > the ACPI states. > > > > > My conclusion: ACPI and DMTF do not significantly > change the 3-state power model. If we want to talk about states = beyond > the 3-state model, it is more clear to simply reference those > extensions directly (e.g. how best to treat hibernate). Note that = this > discussion - and all others on the list - are grounded in electronic > devices. Other devices generally have a 2-state model (e.g. a light), > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > --Bruce > > > > > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 ------_=_NextPart_001_01CBE051.CCFE13E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bruce,

 

Please don’t take silence as a form of acceptance.=A0 = That’s a dangerous assumption.

 

My position is that a single state mechanism is not appropriate for = EMAN to consider.=A0 EMAN should support multiple state mechanisms, that = coexist with each other.

 

Consider the following scenario:

 

Three forms of state management: ACPI, DMTF, and PDU State = Management.=A0 (PDU states include on, off, reboot, tripped, and = shed.=A0 Only for example purposes, exact details to be worked = out later.)

 

server-a – supports ACPI only

server-b – supports ACPI and DMTF

PDU – supports EMAN PDU State Management

 

I propose that we allow each device to support the modality that = makes sense for that device.=A0 The key is not in which modality is = supported, but rather how the user accesses the modality.=A0 Why would = we try to limit innovation by restricting what people can = do?

 

Expose different hooks to allow a user to access ACPI, DMTF, and/or = PDU State Management through three different = interfaces:

 

emanStateControlAcpi – implemented by entities which know how = to respond to ACPI states

emanStateControlDmtf – implemented by entities which know how = to respond to DMTF states

emanStateControlPdu – implemented by entities which know how to = respond to PDU State Management

 

This makes the EMAN schema more powerful and allows the market to = adapt easily as future changes in technologies and our understanding of = how to use those technologies improves.

 

Chris

 

 

From:= = eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Bruce Nordman
Sent: Friday, March 11, 2011 4:43 = PM
To: Rolf Winter
Cc: eman mailing = list
Subject: Re: [eman] Power states - time to dump ACPI and = DMTF

 

Good = discussion.

Batteries are a specific example of a case in which a = device has a secondary
function which can consume significant amounts = of power, and the secondary
function is independent of the primary = one.  My computer is an iMac with an
integrated display, so the = display is secondary to the primary function of computation,
but = unlike the battery, its function is not independent (display always = powered
down when the computational part is).

Another example = like the battery could be a TV with an integral video recorder.
The = recorder can be active when the TV display is asleep or off.  A = third example
is an imaging MFD that does printing, copying, and = scanning; it may have the
scanner active at relatively low power, but = the heat-intensive toner fusing unit
powered down.  Life would = be simpler if devices were not multi-functional.

I think we = should insist on devices having a primary function (that is = afterall
how "identity" works), and the power state = reflects that function.  Simple devices
with internal batteries = can consume a lot of power in sleep or off.  More = sophisticated
devices may choose to use the eman features for = exposing the consumption of the
battery and balance of the system, = and then have a state for the batter exposed.
We need to enable this = but not require it.

I am assuming that we will usually have both = power state and current power
draw in watts, so the NMS will look at = both (and the product's identity) in
deciding what is going on.  = (Perhaps part of identity is reporting if a non-trivial
battery is = present (though this can be a dynamic characteristic).)
So, one can = look at power level, at power state, or both.  I think = having
both addresses Rolf's concerns. 

For Juergen's = note about the states of off-but charging (so high power),
and on = (and presumably AC-connected) but running only off of battery = power
(so no AC draw), that confirms the need to have the actual = mains power
level.  There have been notebook PCs designed to go = off-grid in the afternoon
to avoid times of high electricity demand, = so this is a very real scenario.


More important from my point = of view, is that no one on this thread has jumped
to the defense of = ACPI/DMTF.  I am more convinced than ever that they are
a = distraction for our purposes.

--Bruce

On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter <Rolf.Winter@neclab.eu> = wrote:

Hi,

just thinking out = loud here.

The thing which seems to complicate matters here = significantly is batteries. You either A) try to consider battery state = in the devices' power state or you B) leave it separate in its own MIB = module (as described e.g. here http://tools.ietf.org/html/draft-quittek-eman-battery-m= ib-00 where we have battery states full(1), partiallyCharged(2), = empty(3), charging(4), discharging(5), unknown(6)). I think these are = the trade-offs:

Option A) You can always tell from the device = power state whether it is drawing power or not ("off but = charging" e.g.) and you might be able to order them in a way that a = higher state always translates to higher power draw. It however seems to = complicate power states.

Option B) If a battery is present, you = cannot tell from the device's power state whether is it drawing power or = not ("off" could be really "off but charging"). The = device power states can be modelled cleaner though and you'd need to = look closer to see what the battery state is to be sure there is no = power draw.

Is that the trade-off we're talking about or is there = anything else that needs to be = considered?

Best,

Rolf

NEC Europe Limited | = Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014



> = -----Original Message-----
> From: eman-bounces@ietf.org = [mailto:eman-bounces@ietf.org] On = Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 = 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> = Subject: Re: [eman] Power states - time to dump ACPI and = DMTF
>
> Hi Bruce,
>
> I understand your = preference for a simple off-sleep-on model for power
> = states.
> How would we model a device with a battery then
> =   - it is off, but the empty battery is being charged
> =   - it is on, but fully supplied with power from the = battery.
>
> On way would be treating the (internal) battery = as separate device.
> In this case: Can we map = charging/discharging/full/empty to off-sleep-
> = on?
>
> Thanks,
>
>     = Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce = Nordman:
>
>
>       (all below as = contributor)
>
>
>
>
>     =   For many decades, electrical products were usually just on or = off
> - a 2-state power model.  In the last several decades, = we have added
> many electronic products with a 3-state model - = on, sleep, and off.
> This is necessary and existing complexity. =  Our discussions around
> power states boil down to what = complexity do we want to add to the 3-
> state model, and why the = burden is justified.
>
>
>
>
>
> =       In discussions on this email list, in I-drafts, and = in person,
> the existing listings of power states from ACPI and = DMTF are often
> referenced as good candidates for eman to adopt = in some way.  ACPI is a
> hugely important technology, and it = enables large amounts of user
> functionality and energy savings. =  I am less familiar with the reach of
> DMTF in practice, but = its depth and breadth of membership are
> compelling.  While = I agree they both deserve close examination, I think
> we can = safely drop them from our discussions of what to define as their
> = complexity is more a distraction than an = asset.
>
>
>
>
>       The = basic ACPI list is of  "Global System States" which = "apply to
> the entire system".  There are four of = these (G0-G3); G0 is on
> ("working") and G1 is sleep = ("sleeping").  G2 and G3 both forms of off
> (only = distinguished by whether a device is completely depowered and
> = whether it is safe to disassemble or not, and these distinctions = seems
> quite minor for eman purposes).  Thus, the ACPI = Global states are
> essentially on/sleep/off, the 3-state power = model.
>
>               =     ACPI lists five "Sx" sleep states (S0 is on). =  S5 is
> actually the G2 Off state (so not a sleep state at = all), and current
> implementations do not use S1 or S2, so in = practice there are only two
> ACPI sleep states: S3 and S4. =  S3 is the ordinary system sleep, with
> quick wakeup. =  S4 is the hibernate state (with system memory saved in
> = non-volatile memory, possibly a hard disk) which typically has = long
> times to return to operation (often tens of seconds). =   The 1-2 second
> wake time from S3 for modern personal = computers is compatible with many
> IP protocol usages, e.g. = initiating a TCP connection.  The tens of
> seconds time for = S4 on current systems is not.  So, the only potential
> = addition that the Sx states add to on/sleep/off is hibernate = (and
> reasonable people can differ on whether it is a fourth = basic state, a
> form of sleep, or a form of = off).
>
>
>             =       ACPI does define processor states (Cx) and = device
> states (Dx) (collectively Px), but these are the states = of particular
> components, not of the system as a whole.  It = may be useful to expose
> these through some mechanism, but they = are distinct from the power
> = state.
>
>
>
>
>       =             DMTF essentially took the ACPI = Gx states plus
> hibernate and added states that are commands = and/or transitions.  (Is
> "Master Bus Reset" a = power state?  I think not).  If we don't include
> = commands or transitions (I think we should not), then these reduce = to
> the ACPI states.
>
>
>
>
> =                   My = conclusion: ACPI and DMTF do not significantly
> change the = 3-state power model.  If we want to talk about states = beyond
> the 3-state model, it is more clear to simply reference = those
> extensions directly (e.g. how best to treat hibernate). =  Note that this
> discussion - and all others on the list - = are grounded in electronic
> devices.  Other devices = generally have a 2-state model (e.g. a light),
> or 3 states, but = on, off, and "ready" (think a microwave = oven).
>
>
>
>
>       = --Bruce
>
>
>
>
>       = --
>       Bruce Nordman
>     =   Lawrence Berkeley National Laboratory
>     =   eetd.lbl.gov/ea/nordman
>     =   BNordman@LBL.gov
> =       510-486-7089
>       = m: 510-501-7943
>
>   =     _______________________________________________
> =       eman mailing list
>       eman@ietf.org
>     =   https://www.ietf.org/mailman/listinfo/eman
><= br>>




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

------_=_NextPart_001_01CBE051.CCFE13E2-- From chrisv@cyberswitching.com Sat Mar 12 16:59:07 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADCFE3A6AA2 for ; Sat, 12 Mar 2011 16:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYdJlAJxCo2w for ; Sat, 12 Mar 2011 16:59:04 -0800 (PST) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by core3.amsl.com (Postfix) with ESMTP id 535EC3A6A85 for ; Sat, 12 Mar 2011 16:59:03 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o149.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 8271c7d4.0.20384.00-390.35909.p01c12o149.mxlogic.net (envelope-from ); Sat, 12 Mar 2011 18:00:25 -0700 (MST) X-MXL-Hash: 4d7c172909442861-7e4d9290d4791b5ca4100e8cd69d062cf90463dc X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE119.E8DBC238" Date: Sat, 12 Mar 2011 16:59:29 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CF3684F@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: Acvg/kavw+vjApkQRYC47lR6Cr2kAwAG4Lvw References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> From: "Chris Verges" To: "Ted Ghose" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=SbxTRnKmSzQA:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=ZEaZD8YCAAAA:8 a=pGLkceISAAAA:8 a=wzgq] X-AnalysisOut: [fsuUAAAA:8 a=48vgC7mUAAAA:8 a=7BqBpzB0lSIcS6ZHLikA:9 a=B0J] X-AnalysisOut: [M02Chu-6R9sXSJzsA:7 a=8AsquNSjYaycZFg-Qzw8PCCo2t8A:4 a=QEX] X-AnalysisOut: [dDO2ut3YA:10 a=FnBvD0j_UmcA:10 a=lr71C7C2fScA:10 a=aNFqd2O] X-AnalysisOut: [uFYIA:10 a=MSl-tDqOz04A:10 a=yvfu_RGVus0A:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=VxF7Es0IeU9fKOtu:21 a=ZWWIXgUF2lfQ6Y18:21 a=yMhMjlu] X-AnalysisOut: [bAAAA:8 a=SSmOFEACAAAA:8 a=J35dNKfbAAAA:8 a=6alU_g5KVUf7wr] X-AnalysisOut: [G1HsEA:9 a=muMHKb5o8s5FF8LxtMwA:7 a=JITzBqbJTtTM9jBJin8ukk] X-AnalysisOut: [wTIE0A:4] Cc: eman mailing list , Rolf Winter , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 00:59:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE119.E8DBC238 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VyZSwgdGhlIFJUQy9CSU9TIGJhdHRlcnksIFVQUyBzeXN0ZW1zLCBldGMuICBHb29nbGUgZXZl biBtb2RpZmllZCBhIHBsYWluIHNlcnZlciB0byBpbmNsdWRlIGEgMTJWREMgYmF0dGVyeToNCg0K IA0KDQpodHRwOi8vbmV3cy5jbmV0LmNvbS84MzAxLTEwMDFfMy0xMDIwOTU4MC05Mi5odG1sDQoN CiANCg0KQ2hyaXMNCg0KIA0KDQpGcm9tOiBUZWQgR2hvc2UgW21haWx0bzp0aXJ0aC5naG9zZUBn bWFpbC5jb21dIA0KU2VudDogU2F0dXJkYXksIE1hcmNoIDEyLCAyMDExIDE6NDIgUE0NClRvOiBD aHJpcyBWZXJnZXMNCkNjOiBUZWQgR2hvc2U7IFJvbGYgV2ludGVyOyBCcnVjZSBOb3JkbWFuOyBl bWFuIG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IFtlbWFuXSBQb3dlciBzdGF0ZXMgLSB0aW1l IHRvIGR1bXAgQUNQSSBhbmQgRE1URg0KDQogDQoNClNlcnZlcnMgaGF2ZSBiYXR0ZXJpZXM/IA0K DQogDQoNCi10Zy0NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQoNCk9uIE1hciAxMSwgMjAxMSwg YXQgODowNCBBTSwgIkNocmlzIFZlcmdlcyIgPGNocmlzdkBjeWJlcnN3aXRjaGluZy5jb20+IHdy b3RlOg0KDQoJSGkgVGVkLA0KDQoJIA0KDQoJSSBtaWdodCBiZSBwdXR0aW5nIHdvcmRzIGludG8g Um9sZuKAmXMgbW91dGgsIGJ1dCBoZXJlIGFyZSBteSB0aG91Z2h0cyBvbiB0aGlzOg0KDQoJIA0K DQoJQ2VydGFpbiBkZXZpY2VzLCBsaWtlIHNlcnZlcnMsIHRoYXQgY29udGFpbiBhIExpZ2h0cyBP dXQgTWFuYWdlbWVudCAoTE9NKSBjYXJkIHdpbGwgYmUgYWJsZSB0byByZXBvcnQgdGhlIHNlcnZl cuKAmXMgcG93ZXIgc3VwcGx5IGFzIOKAnG9mZuKAnSBidXQgdGhlIGJhdHRlcnkgYXMg4oCcY2hh cmdpbmfigJ0uICBUaGlzIGNvbWJpbmF0aW9uIGZvciB0aGUgc2VydmVyIGVudGl0eSByZXN1bHRz IGluIHRoZSBkZXNpcmVkIGVmZmVjdC4NCg0KCSANCg0KCVJvbGYsIGFueXdoZXJlIGluIHRoZSBi YWxscGFyaz8NCg0KCSANCg0KCUNocmlzDQoNCgkgDQoNCglGcm9tOiBlbWFuLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzplbWFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZWQgR2hv c2UNCglTZW50OiBGcmlkYXksIE1hcmNoIDExLCAyMDExIDg6MDEgQU0NCglUbzogUm9sZiBXaW50 ZXINCglDYzogQnJ1Y2UgTm9yZG1hbjsgZW1hbiBtYWlsaW5nIGxpc3QNCglTdWJqZWN0OiBSZTog W2VtYW5dIFBvd2VyIHN0YXRlcyAtIHRpbWUgdG8gZHVtcCBBQ1BJIGFuZCBETVRGDQoNCgkgDQoN CglIaSBSb2xmLCBKdWVyZ2VuDQoNCgkgDQoNCglJIGxpa2UgUm9sZidzIGlkZWEgdmVyeSBtdWNo LiBXZSBzaG91bGQgZXh0ZW5kIG51bWJlciBvZiBzdGF0ZXMgdG8gYWNjb21tb2RhdGUgb3RoZXIg c3ViIHN0YXRlcy4gDQoNCgkgDQoNCglIZXJlIGlzIG9uZSBxdWVzdGlvbiBJIGRvIGhhdmUgZm9y IEp1ZXJnb24sIGFzIGhhbmRsaW5nIHRoZSBiYXR0ZXJ5IGtlZXBzIGNvbWluZyB1cCBpbiBhbGwg dGhlIGRpc2N1c3Npb25zLiANCg0KCSANCg0KCUlmIHRoZSBkZXZpY2UgaXMgb2ZmLCBidXQgYmF0 dGVyeSBpcyBjaGFyZ2luZywgd2hvIGlzIHJlcG9ydGluZyB0aGF0IGFuZCBob3c/IElzIGJhdHRl cnkgaXRzZWxmIGhhcyB0aGUgaW50ZWxsaWdlbmNlIHRvIGRvIHNvPyBJbiB0aGF0IGNhc2UsIGNh biB3ZSB0cmVhdCBpdCBhcyBhIHNlcGFyYXRlIGRldmljZSBpbmRlcGVuZGVudCBvZiB0aGUgZGV2 aWNlIGl0IGlzIGNvbm5lY3RlZCB0bywgYW5kIHRoZW4gd2UgY291bGQgc2ltcGxpZnkgdGhlIG1v ZGVsLg0KDQoJIA0KDQoJSW4gdGhlIG90aGVyIGNhc2UsIHRob3VnaCwgaWYgZGV2aWNlIGlzIHR1 cm5lZCBvZmYsIHRoZXJlIGlzIG5vIG9uZSB0byB0ZWxsIHdoYXQgdGhlIGJhdHRlcnkgaXMgZG9p bmcsIHVubGVzcyBhbiBpbnRlbGxpZ2VudCBQRFUgb3Igc29tZW9uZSBpcyBhd2FyZSBvZiB0aGF0 IGRldmljZS4gV2hpY2ggY29tZXMgdG8gc29tZSBzb3VyY2UgLSBzaW5rIG1vZGVsIGFzIHdlbGwu DQoNCgkgDQoNCglDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgeW91ciB0aG91Z2h0cz8NCg0KCSAN Cg0KCXRoYW5rcw0KDQoJIA0KDQoJLXRnLQ0KCSo6LS4sXywuLToqJ2BgJyo6LS4sXywuLToqJ2Bg Jyo6LS4sXywuLToqJ2BgJyo6LS4sXzotLixfLC4tOioqOi0uLF8sLg0KCSAgICAgICAgICAgICAg ICAgICAgIFNhdmUgdGltZS4uLiBzZWUgaXQgbXkgd2F5DQoJKjotLixfLC4tOionYGAnKjotLixf LC4tOionYGAnKjotLixfLC4tOionYGAnKjotLixfOi0uLF8sLi06Kio6LS4sXywuDQoJDQoJDQoJ DQoNCglPbiBGcmksIE1hciAxMSwgMjAxMSBhdCA1OjM2IEFNLCBSb2xmIFdpbnRlciA8Um9sZi5X aW50ZXJAbmVjbGFiLmV1PiB3cm90ZToNCg0KCUhpLA0KCQ0KCWp1c3QgdGhpbmtpbmcgb3V0IGxv dWQgaGVyZS4NCgkNCglUaGUgdGhpbmcgd2hpY2ggc2VlbXMgdG8gY29tcGxpY2F0ZSBtYXR0ZXJz IGhlcmUgc2lnbmlmaWNhbnRseSBpcyBiYXR0ZXJpZXMuIFlvdSBlaXRoZXIgQSkgdHJ5IHRvIGNv bnNpZGVyIGJhdHRlcnkgc3RhdGUgaW4gdGhlIGRldmljZXMnIHBvd2VyIHN0YXRlIG9yIHlvdSBC KSBsZWF2ZSBpdCBzZXBhcmF0ZSBpbiBpdHMgb3duIE1JQiBtb2R1bGUgKGFzIGRlc2NyaWJlZCBl LmcuIGhlcmUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpdHRlay1lbWFuLWJh dHRlcnktbWliLTAwIHdoZXJlIHdlIGhhdmUgYmF0dGVyeSBzdGF0ZXMgZnVsbCgxKSwgcGFydGlh bGx5Q2hhcmdlZCgyKSwgZW1wdHkoMyksIGNoYXJnaW5nKDQpLCBkaXNjaGFyZ2luZyg1KSwgdW5r bm93big2KSkuIEkgdGhpbmsgdGhlc2UgYXJlIHRoZSB0cmFkZS1vZmZzOg0KCQ0KCU9wdGlvbiBB KSBZb3UgY2FuIGFsd2F5cyB0ZWxsIGZyb20gdGhlIGRldmljZSBwb3dlciBzdGF0ZSB3aGV0aGVy IGl0IGlzIGRyYXdpbmcgcG93ZXIgb3Igbm90ICgib2ZmIGJ1dCBjaGFyZ2luZyIgZS5nLikgYW5k IHlvdSBtaWdodCBiZSBhYmxlIHRvIG9yZGVyIHRoZW0gaW4gYSB3YXkgdGhhdCBhIGhpZ2hlciBz dGF0ZSBhbHdheXMgdHJhbnNsYXRlcyB0byBoaWdoZXIgcG93ZXIgZHJhdy4gSXQgaG93ZXZlciBz ZWVtcyB0byBjb21wbGljYXRlIHBvd2VyIHN0YXRlcy4NCgkNCglPcHRpb24gQikgSWYgYSBiYXR0 ZXJ5IGlzIHByZXNlbnQsIHlvdSBjYW5ub3QgdGVsbCBmcm9tIHRoZSBkZXZpY2UncyBwb3dlciBz dGF0ZSB3aGV0aGVyIGlzIGl0IGRyYXdpbmcgcG93ZXIgb3Igbm90ICgib2ZmIiBjb3VsZCBiZSBy ZWFsbHkgIm9mZiBidXQgY2hhcmdpbmciKS4gVGhlIGRldmljZSBwb3dlciBzdGF0ZXMgY2FuIGJl IG1vZGVsbGVkIGNsZWFuZXIgdGhvdWdoIGFuZCB5b3UnZCBuZWVkIHRvIGxvb2sgY2xvc2VyIHRv IHNlZSB3aGF0IHRoZSBiYXR0ZXJ5IHN0YXRlIGlzIHRvIGJlIHN1cmUgdGhlcmUgaXMgbm8gcG93 ZXIgZHJhdy4NCgkNCglJcyB0aGF0IHRoZSB0cmFkZS1vZmYgd2UncmUgdGFsa2luZyBhYm91dCBv ciBpcyB0aGVyZSBhbnl0aGluZyBlbHNlIHRoYXQgbmVlZHMgdG8gYmUgY29uc2lkZXJlZD8NCgkN CglCZXN0LA0KCQ0KCVJvbGYNCgkNCglORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9m ZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwgfCBSZWdpc3Rl cmVkIGluIEVuZ2xhbmQgMjgzMjAxNA0KDQoJDQoJDQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KCT4gRnJvbTogZW1hbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZW1hbi1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCgk+IEp1ZXJnZW4gUXVpdHRlaw0KCT4gU2VudDogRnJl aXRhZywgMTEuIE3DpHJ6IDIwMTEgMTA6MzcNCgk+IFRvOiBCcnVjZSBOb3JkbWFuDQoJPiBDYzog ZW1hbiBtYWlsaW5nIGxpc3QNCgk+IFN1YmplY3Q6IFJlOiBbZW1hbl0gUG93ZXIgc3RhdGVzIC0g dGltZSB0byBkdW1wIEFDUEkgYW5kIERNVEYNCgk+DQoJPiBIaSBCcnVjZSwNCgk+DQoJPiBJIHVu ZGVyc3RhbmQgeW91ciBwcmVmZXJlbmNlIGZvciBhIHNpbXBsZSBvZmYtc2xlZXAtb24gbW9kZWwg Zm9yIHBvd2VyDQoJPiBzdGF0ZXMuDQoJPiBIb3cgd291bGQgd2UgbW9kZWwgYSBkZXZpY2Ugd2l0 aCBhIGJhdHRlcnkgdGhlbg0KCT4gICAtIGl0IGlzIG9mZiwgYnV0IHRoZSBlbXB0eSBiYXR0ZXJ5 IGlzIGJlaW5nIGNoYXJnZWQNCgk+ICAgLSBpdCBpcyBvbiwgYnV0IGZ1bGx5IHN1cHBsaWVkIHdp dGggcG93ZXIgZnJvbSB0aGUgYmF0dGVyeS4NCgk+DQoJPiBPbiB3YXkgd291bGQgYmUgdHJlYXRp bmcgdGhlIChpbnRlcm5hbCkgYmF0dGVyeSBhcyBzZXBhcmF0ZSBkZXZpY2UuDQoJPiBJbiB0aGlz IGNhc2U6IENhbiB3ZSBtYXAgY2hhcmdpbmcvZGlzY2hhcmdpbmcvZnVsbC9lbXB0eSB0byBvZmYt c2xlZXAtDQoJPiBvbj8NCgk+DQoJPiBUaGFua3MsDQoJPg0KCT4gICAgIEp1ZXJnZW4NCgk+DQoJ Pg0KCT4gQW0gMTEuMDMuMjAxMSB1bSAwNzozNyBzY2hyaWViIEJydWNlIE5vcmRtYW46DQoJPg0K CT4NCgk+ICAgICAgIChhbGwgYmVsb3cgYXMgY29udHJpYnV0b3IpDQoJPg0KCT4NCgk+DQoJPg0K CT4gICAgICAgRm9yIG1hbnkgZGVjYWRlcywgZWxlY3RyaWNhbCBwcm9kdWN0cyB3ZXJlIHVzdWFs bHkganVzdCBvbiBvciBvZmYNCgk+IC0gYSAyLXN0YXRlIHBvd2VyIG1vZGVsLiAgSW4gdGhlIGxh c3Qgc2V2ZXJhbCBkZWNhZGVzLCB3ZSBoYXZlIGFkZGVkDQoJPiBtYW55IGVsZWN0cm9uaWMgcHJv ZHVjdHMgd2l0aCBhIDMtc3RhdGUgbW9kZWwgLSBvbiwgc2xlZXAsIGFuZCBvZmYuDQoJPiBUaGlz IGlzIG5lY2Vzc2FyeSBhbmQgZXhpc3RpbmcgY29tcGxleGl0eS4gIE91ciBkaXNjdXNzaW9ucyBh cm91bmQNCgk+IHBvd2VyIHN0YXRlcyBib2lsIGRvd24gdG8gd2hhdCBjb21wbGV4aXR5IGRvIHdl IHdhbnQgdG8gYWRkIHRvIHRoZSAzLQ0KCT4gc3RhdGUgbW9kZWwsIGFuZCB3aHkgdGhlIGJ1cmRl biBpcyBqdXN0aWZpZWQuDQoJPg0KCT4NCgk+DQoJPg0KCT4NCgk+ICAgICAgIEluIGRpc2N1c3Np b25zIG9uIHRoaXMgZW1haWwgbGlzdCwgaW4gSS1kcmFmdHMsIGFuZCBpbiBwZXJzb24sDQoJPiB0 aGUgZXhpc3RpbmcgbGlzdGluZ3Mgb2YgcG93ZXIgc3RhdGVzIGZyb20gQUNQSSBhbmQgRE1URiBh cmUgb2Z0ZW4NCgk+IHJlZmVyZW5jZWQgYXMgZ29vZCBjYW5kaWRhdGVzIGZvciBlbWFuIHRvIGFk b3B0IGluIHNvbWUgd2F5LiAgQUNQSSBpcyBhDQoJPiBodWdlbHkgaW1wb3J0YW50IHRlY2hub2xv Z3ksIGFuZCBpdCBlbmFibGVzIGxhcmdlIGFtb3VudHMgb2YgdXNlcg0KCT4gZnVuY3Rpb25hbGl0 eSBhbmQgZW5lcmd5IHNhdmluZ3MuICBJIGFtIGxlc3MgZmFtaWxpYXIgd2l0aCB0aGUgcmVhY2gg b2YNCgk+IERNVEYgaW4gcHJhY3RpY2UsIGJ1dCBpdHMgZGVwdGggYW5kIGJyZWFkdGggb2YgbWVt YmVyc2hpcCBhcmUNCgk+IGNvbXBlbGxpbmcuICBXaGlsZSBJIGFncmVlIHRoZXkgYm90aCBkZXNl cnZlIGNsb3NlIGV4YW1pbmF0aW9uLCBJIHRoaW5rDQoJPiB3ZSBjYW4gc2FmZWx5IGRyb3AgdGhl bSBmcm9tIG91ciBkaXNjdXNzaW9ucyBvZiB3aGF0IHRvIGRlZmluZSBhcyB0aGVpcg0KCT4gY29t cGxleGl0eSBpcyBtb3JlIGEgZGlzdHJhY3Rpb24gdGhhbiBhbiBhc3NldC4NCgk+DQoJPg0KCT4N Cgk+DQoJPiAgICAgICBUaGUgYmFzaWMgQUNQSSBsaXN0IGlzIG9mICAiR2xvYmFsIFN5c3RlbSBT dGF0ZXMiIHdoaWNoICJhcHBseSB0bw0KCT4gdGhlIGVudGlyZSBzeXN0ZW0iLiAgVGhlcmUgYXJl IGZvdXIgb2YgdGhlc2UgKEcwLUczKTsgRzAgaXMgb24NCgk+ICgid29ya2luZyIpIGFuZCBHMSBp cyBzbGVlcCAoInNsZWVwaW5nIikuICBHMiBhbmQgRzMgYm90aCBmb3JtcyBvZiBvZmYNCgk+IChv bmx5IGRpc3Rpbmd1aXNoZWQgYnkgd2hldGhlciBhIGRldmljZSBpcyBjb21wbGV0ZWx5IGRlcG93 ZXJlZCBhbmQNCgk+IHdoZXRoZXIgaXQgaXMgc2FmZSB0byBkaXNhc3NlbWJsZSBvciBub3QsIGFu ZCB0aGVzZSBkaXN0aW5jdGlvbnMgc2VlbXMNCgk+IHF1aXRlIG1pbm9yIGZvciBlbWFuIHB1cnBv c2VzKS4gIFRodXMsIHRoZSBBQ1BJIEdsb2JhbCBzdGF0ZXMgYXJlDQoJPiBlc3NlbnRpYWxseSBv bi9zbGVlcC9vZmYsIHRoZSAzLXN0YXRlIHBvd2VyIG1vZGVsLg0KCT4NCgk+ICAgICAgICAgICAg ICAgICAgIEFDUEkgbGlzdHMgZml2ZSAiU3giIHNsZWVwIHN0YXRlcyAoUzAgaXMgb24pLiAgUzUg aXMNCgk+IGFjdHVhbGx5IHRoZSBHMiBPZmYgc3RhdGUgKHNvIG5vdCBhIHNsZWVwIHN0YXRlIGF0 IGFsbCksIGFuZCBjdXJyZW50DQoJPiBpbXBsZW1lbnRhdGlvbnMgZG8gbm90IHVzZSBTMSBvciBT Miwgc28gaW4gcHJhY3RpY2UgdGhlcmUgYXJlIG9ubHkgdHdvDQoJPiBBQ1BJIHNsZWVwIHN0YXRl czogUzMgYW5kIFM0LiAgUzMgaXMgdGhlIG9yZGluYXJ5IHN5c3RlbSBzbGVlcCwgd2l0aA0KCT4g cXVpY2sgd2FrZXVwLiAgUzQgaXMgdGhlIGhpYmVybmF0ZSBzdGF0ZSAod2l0aCBzeXN0ZW0gbWVt b3J5IHNhdmVkIGluDQoJPiBub24tdm9sYXRpbGUgbWVtb3J5LCBwb3NzaWJseSBhIGhhcmQgZGlz aykgd2hpY2ggdHlwaWNhbGx5IGhhcyBsb25nDQoJPiB0aW1lcyB0byByZXR1cm4gdG8gb3BlcmF0 aW9uIChvZnRlbiB0ZW5zIG9mIHNlY29uZHMpLiAgIFRoZSAxLTIgc2Vjb25kDQoJPiB3YWtlIHRp bWUgZnJvbSBTMyBmb3IgbW9kZXJuIHBlcnNvbmFsIGNvbXB1dGVycyBpcyBjb21wYXRpYmxlIHdp dGggbWFueQ0KCT4gSVAgcHJvdG9jb2wgdXNhZ2VzLCBlLmcuIGluaXRpYXRpbmcgYSBUQ1AgY29u bmVjdGlvbi4gIFRoZSB0ZW5zIG9mDQoJPiBzZWNvbmRzIHRpbWUgZm9yIFM0IG9uIGN1cnJlbnQg c3lzdGVtcyBpcyBub3QuICBTbywgdGhlIG9ubHkgcG90ZW50aWFsDQoJPiBhZGRpdGlvbiB0aGF0 IHRoZSBTeCBzdGF0ZXMgYWRkIHRvIG9uL3NsZWVwL29mZiBpcyBoaWJlcm5hdGUgKGFuZA0KCT4g cmVhc29uYWJsZSBwZW9wbGUgY2FuIGRpZmZlciBvbiB3aGV0aGVyIGl0IGlzIGEgZm91cnRoIGJh c2ljIHN0YXRlLCBhDQoJPiBmb3JtIG9mIHNsZWVwLCBvciBhIGZvcm0gb2Ygb2ZmKS4NCgk+DQoJ Pg0KCT4gICAgICAgICAgICAgICAgICAgQUNQSSBkb2VzIGRlZmluZSBwcm9jZXNzb3Igc3RhdGVz IChDeCkgYW5kIGRldmljZQ0KCT4gc3RhdGVzIChEeCkgKGNvbGxlY3RpdmVseSBQeCksIGJ1dCB0 aGVzZSBhcmUgdGhlIHN0YXRlcyBvZiBwYXJ0aWN1bGFyDQoJPiBjb21wb25lbnRzLCBub3Qgb2Yg dGhlIHN5c3RlbSBhcyBhIHdob2xlLiAgSXQgbWF5IGJlIHVzZWZ1bCB0byBleHBvc2UNCgk+IHRo ZXNlIHRocm91Z2ggc29tZSBtZWNoYW5pc20sIGJ1dCB0aGV5IGFyZSBkaXN0aW5jdCBmcm9tIHRo ZSBwb3dlcg0KCT4gc3RhdGUuDQoJPg0KCT4NCgk+DQoJPg0KCT4gICAgICAgICAgICAgICAgICAg RE1URiBlc3NlbnRpYWxseSB0b29rIHRoZSBBQ1BJIEd4IHN0YXRlcyBwbHVzDQoJPiBoaWJlcm5h dGUgYW5kIGFkZGVkIHN0YXRlcyB0aGF0IGFyZSBjb21tYW5kcyBhbmQvb3IgdHJhbnNpdGlvbnMu ICAoSXMNCgk+ICJNYXN0ZXIgQnVzIFJlc2V0IiBhIHBvd2VyIHN0YXRlPyAgSSB0aGluayBub3Qp LiAgSWYgd2UgZG9uJ3QgaW5jbHVkZQ0KCT4gY29tbWFuZHMgb3IgdHJhbnNpdGlvbnMgKEkgdGhp bmsgd2Ugc2hvdWxkIG5vdCksIHRoZW4gdGhlc2UgcmVkdWNlIHRvDQoJPiB0aGUgQUNQSSBzdGF0 ZXMuDQoJPg0KCT4NCgk+DQoJPg0KCT4gICAgICAgICAgICAgICAgICAgTXkgY29uY2x1c2lvbjog QUNQSSBhbmQgRE1URiBkbyBub3Qgc2lnbmlmaWNhbnRseQ0KCT4gY2hhbmdlIHRoZSAzLXN0YXRl IHBvd2VyIG1vZGVsLiAgSWYgd2Ugd2FudCB0byB0YWxrIGFib3V0IHN0YXRlcyBiZXlvbmQNCgk+ IHRoZSAzLXN0YXRlIG1vZGVsLCBpdCBpcyBtb3JlIGNsZWFyIHRvIHNpbXBseSByZWZlcmVuY2Ug dGhvc2UNCgk+IGV4dGVuc2lvbnMgZGlyZWN0bHkgKGUuZy4gaG93IGJlc3QgdG8gdHJlYXQgaGli ZXJuYXRlKS4gIE5vdGUgdGhhdCB0aGlzDQoJPiBkaXNjdXNzaW9uIC0gYW5kIGFsbCBvdGhlcnMg b24gdGhlIGxpc3QgLSBhcmUgZ3JvdW5kZWQgaW4gZWxlY3Ryb25pYw0KCT4gZGV2aWNlcy4gIE90 aGVyIGRldmljZXMgZ2VuZXJhbGx5IGhhdmUgYSAyLXN0YXRlIG1vZGVsIChlLmcuIGEgbGlnaHQp LA0KCT4gb3IgMyBzdGF0ZXMsIGJ1dCBvbiwgb2ZmLCBhbmQgInJlYWR5IiAodGhpbmsgYSBtaWNy b3dhdmUgb3ZlbikuDQoJPg0KCT4NCgk+DQoJPg0KCT4gICAgICAgLS1CcnVjZQ0KCT4NCgk+DQoJ Pg0KCT4NCgk+ICAgICAgIC0tDQoJPiAgICAgICBCcnVjZSBOb3JkbWFuDQoJPiAgICAgICBMYXdy ZW5jZSBCZXJrZWxleSBOYXRpb25hbCBMYWJvcmF0b3J5DQoJPiAgICAgICBlZXRkLmxibC5nb3Yv ZWEvbm9yZG1hbg0KCT4gICAgICAgQk5vcmRtYW5ATEJMLmdvdg0KCT4gICAgICAgNTEwLTQ4Ni03 MDg5DQoJPiAgICAgICBtOiA1MTAtNTAxLTc5NDMNCgk+DQoJPiAgICAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4gICAgICAgZW1hbiBtYWlsaW5n IGxpc3QNCgk+ICAgICAgIGVtYW5AaWV0Zi5vcmcNCgk+ICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZW1hbg0KCT4NCgk+DQoJDQoJX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgllbWFuIG1haWxpbmcgbGlzdA0KCWVtYW5A aWV0Zi5vcmcNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtYW4NCg0K CSANCg0K ------_=_NextPart_001_01CBE119.E8DBC238 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdl aWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUg bm9uZTt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPjwvaGVhZD48Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TdXJlLCB0aGUgUlRDL0JJT1MgYmF0dGVyeSwgVVBTIHN5 c3RlbXMsIGV0Yy4gwqBHb29nbGUgZXZlbiBtb2RpZmllZCBhIHBsYWluIHNlcnZlciB0byBpbmNs dWRlIGEgMTJWREMgYmF0dGVyeTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9Imh0dHA6Ly9u ZXdzLmNuZXQuY29tLzgzMDEtMTAwMV8zLTEwMjA5NTgwLTkyLmh0bWwiPmh0dHA6Ly9uZXdzLmNu ZXQuY29tLzgzMDEtMTAwMV8zLTEwMjA5NTgwLTkyLmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkNocmlzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gVGVkIEdob3NlIFttYWlsdG86dGlydGguZ2hvc2VAZ21h aWwuY29tXSA8YnI+PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBNYXJjaCAxMiwgMjAxMSAxOjQyIFBN PGJyPjxiPlRvOjwvYj4gQ2hyaXMgVmVyZ2VzPGJyPjxiPkNjOjwvYj4gVGVkIEdob3NlOyBSb2xm IFdpbnRlcjsgQnJ1Y2UgTm9yZG1hbjsgZW1hbiBtYWlsaW5nIGxpc3Q8YnI+PGI+U3ViamVjdDo8 L2I+IFJlOiBbZW1hbl0gUG93ZXIgc3RhdGVzIC0gdGltZSB0byBkdW1wIEFDUEkgYW5kIERNVEY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNlcnZlcnMgaGF2ZSBiYXR0 ZXJpZXM/Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LXRnLTxi cj48YnI+U2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPk9uIE1hciAxMSwg MjAxMSwgYXQgODowNCBBTSwgJnF1b3Q7Q2hyaXMgVmVyZ2VzJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86Y2hyaXN2QGN5YmVyc3dpdGNoaW5nLmNvbSI+Y2hyaXN2QGN5YmVyc3dpdGNoaW5nLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpIFRlZCw8L3NwYW4+PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5JIG1pZ2h0IGJlIHB1dHRpbmcgd29yZHMgaW50byBSb2xm4oCZcyBtb3V0aCwgYnV0 IGhlcmUgYXJlIG15IHRob3VnaHRzIG9uIHRoaXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q2Vy dGFpbiBkZXZpY2VzLCBsaWtlIHNlcnZlcnMsIHRoYXQgY29udGFpbiBhIExpZ2h0cyBPdXQgTWFu YWdlbWVudCAoTE9NKSBjYXJkIHdpbGwgYmUgYWJsZSB0byByZXBvcnQgdGhlIHNlcnZlcuKAmXMg cG93ZXIgc3VwcGx5IGFzIOKAnG9mZuKAnSBidXQgdGhlIGJhdHRlcnkgYXMg4oCcY2hhcmdpbmfi gJ0uJm5ic3A7IFRoaXMgY29tYmluYXRpb24gZm9yIHRoZSBzZXJ2ZXIgZW50aXR5IHJlc3VsdHMg aW4gdGhlIGRlc2lyZWQgZWZmZWN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJvbGYsIGFueXdo ZXJlIGluIHRoZSBiYWxscGFyaz88L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5DaHJpczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWlsdG86ZW1hbi1ib3VuY2Vz QGlldGYub3JnIj5lbWFuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86ZW1hbi1ib3VuY2Vz QGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBHaG9zZTxicj48Yj5TZW50OjwvYj4g RnJpZGF5LCBNYXJjaCAxMSwgMjAxMSA4OjAxIEFNPGJyPjxiPlRvOjwvYj4gUm9sZiBXaW50ZXI8 YnI+PGI+Q2M6PC9iPiBCcnVjZSBOb3JkbWFuOyBlbWFuIG1haWxpbmcgbGlzdDxicj48Yj5TdWJq ZWN0OjwvYj4gUmU6IFtlbWFuXSBQb3dlciBzdGF0ZXMgLSB0aW1lIHRvIGR1bXAgQUNQSSBhbmQg RE1URjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5IaSBSb2xmLCBKdWVyZ2VuPG86cD48L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkkgbGlrZSBSb2xmJ3MgaWRlYSB2ZXJ5IG11Y2gu IFdlIHNob3VsZCBleHRlbmQgbnVtYmVyIG9mIHN0YXRlcyB0byZuYnNwO2FjY29tbW9kYXRlJm5i c3A7b3RoZXIgc3ViIHN0YXRlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+SGVyZSBpcyBvbmUgcXVlc3Rpb24gSSBkbyBoYXZlIGZvciBKdWVyZ29uLCBh cyBoYW5kbGluZyB0aGUgYmF0dGVyeSBrZWVwcyBjb21pbmcgdXAgaW4gYWxsIHRoZSBkaXNjdXNz aW9ucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SWYg dGhlIGRldmljZSBpcyBvZmYsIGJ1dCBiYXR0ZXJ5IGlzIGNoYXJnaW5nLCB3aG8gaXMgcmVwb3J0 aW5nIHRoYXQgYW5kIGhvdz8gSXMgYmF0dGVyeSBpdHNlbGYgaGFzIHRoZSZuYnNwO2ludGVsbGln ZW5jZSB0byBkbyBzbz8gSW4gdGhhdCBjYXNlLCBjYW4gd2UgdHJlYXQgaXQgYXMgYSZuYnNwO3Nl cGFyYXRlJm5ic3A7ZGV2aWNlJm5ic3A7aW5kZXBlbmRlbnQgb2YgdGhlIGRldmljZSBpdCBpcyBj b25uZWN0ZWQgdG8sIGFuZCB0aGVuIHdlIGNvdWxkIHNpbXBsaWZ5IHRoZSBtb2RlbC48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SW4gdGhlIG90aGVyIGNhc2UsIHRo b3VnaCwgaWYgZGV2aWNlIGlzIHR1cm5lZCBvZmYsIHRoZXJlIGlzIG5vIG9uZSB0byB0ZWxsIHdo YXQgdGhlIGJhdHRlcnkgaXMgZG9pbmcsIHVubGVzcyBhbiZuYnNwO2ludGVsbGlnZW50Jm5ic3A7 UERVIG9yIHNvbWVvbmUgaXMgYXdhcmUgb2YgdGhhdCBkZXZpY2UuIFdoaWNoIGNvbWVzIHRvIHNv bWUgc291cmNlIC0gc2luayBtb2RlbCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz5Db3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgeW91ciB0aG91Z2h0cz88 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+dGhhbmtzPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQnPi10Zy08YnIgY2xlYXI9YWxsPio6LS4sXywuLToq J2BgJyo6LS4sXywuLToqJ2BgJyo6LS4sXywuLToqJ2BgJyo6LS4sXzotLixfLC4tOioqOi0uLF8s Ljxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgU2F2ZSB0aW1lLi4uIHNlZSBpdCBteSB3YXk8YnI+Kjot LixfLC4tOionYGAnKjotLixfLC4tOionYGAnKjotLixfLC4tOionYGAnKjotLixfOi0uLF8sLi06 Kio6LS4sXywuPGJyPjxicj48YnI+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz5PbiBGcmksIE1hciAxMSwgMjAxMSBhdCA1OjM2IEFNLCBSb2xmIFdpbnRlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOlJvbGYuV2ludGVyQG5lY2xhYi5ldSI+Um9sZi5XaW50ZXJAbmVjbGFiLmV1 PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SGksPGJy Pjxicj5qdXN0IHRoaW5raW5nIG91dCBsb3VkIGhlcmUuPGJyPjxicj5UaGUgdGhpbmcgd2hpY2gg c2VlbXMgdG8gY29tcGxpY2F0ZSBtYXR0ZXJzIGhlcmUgc2lnbmlmaWNhbnRseSBpcyBiYXR0ZXJp ZXMuIFlvdSBlaXRoZXIgQSkgdHJ5IHRvIGNvbnNpZGVyIGJhdHRlcnkgc3RhdGUgaW4gdGhlIGRl dmljZXMnIHBvd2VyIHN0YXRlIG9yIHlvdSBCKSBsZWF2ZSBpdCBzZXBhcmF0ZSBpbiBpdHMgb3du IE1JQiBtb2R1bGUgKGFzIGRlc2NyaWJlZCBlLmcuIGhlcmUgPGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcXVpdHRlay1lbWFuLWJhdHRlcnktbWliLTAwIj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWl0dGVrLWVtYW4tYmF0dGVyeS1taWItMDA8L2E+ IHdoZXJlIHdlIGhhdmUgYmF0dGVyeSBzdGF0ZXMgZnVsbCgxKSwgcGFydGlhbGx5Q2hhcmdlZCgy KSwgZW1wdHkoMyksIGNoYXJnaW5nKDQpLCBkaXNjaGFyZ2luZyg1KSwgdW5rbm93big2KSkuIEkg dGhpbmsgdGhlc2UgYXJlIHRoZSB0cmFkZS1vZmZzOjxicj48YnI+T3B0aW9uIEEpIFlvdSBjYW4g YWx3YXlzIHRlbGwgZnJvbSB0aGUgZGV2aWNlIHBvd2VyIHN0YXRlIHdoZXRoZXIgaXQgaXMgZHJh d2luZyBwb3dlciBvciBub3QgKCZxdW90O29mZiBidXQgY2hhcmdpbmcmcXVvdDsgZS5nLikgYW5k IHlvdSBtaWdodCBiZSBhYmxlIHRvIG9yZGVyIHRoZW0gaW4gYSB3YXkgdGhhdCBhIGhpZ2hlciBz dGF0ZSBhbHdheXMgdHJhbnNsYXRlcyB0byBoaWdoZXIgcG93ZXIgZHJhdy4gSXQgaG93ZXZlciBz ZWVtcyB0byBjb21wbGljYXRlIHBvd2VyIHN0YXRlcy48YnI+PGJyPk9wdGlvbiBCKSBJZiBhIGJh dHRlcnkgaXMgcHJlc2VudCwgeW91IGNhbm5vdCB0ZWxsIGZyb20gdGhlIGRldmljZSdzIHBvd2Vy IHN0YXRlIHdoZXRoZXIgaXMgaXQgZHJhd2luZyBwb3dlciBvciBub3QgKCZxdW90O29mZiZxdW90 OyBjb3VsZCBiZSByZWFsbHkgJnF1b3Q7b2ZmIGJ1dCBjaGFyZ2luZyZxdW90OykuIFRoZSBkZXZp Y2UgcG93ZXIgc3RhdGVzIGNhbiBiZSBtb2RlbGxlZCBjbGVhbmVyIHRob3VnaCBhbmQgeW91J2Qg bmVlZCB0byBsb29rIGNsb3NlciB0byBzZWUgd2hhdCB0aGUgYmF0dGVyeSBzdGF0ZSBpcyB0byBi ZSBzdXJlIHRoZXJlIGlzIG5vIHBvd2VyIGRyYXcuPGJyPjxicj5JcyB0aGF0IHRoZSB0cmFkZS1v ZmYgd2UncmUgdGFsa2luZyBhYm91dCBvciBpcyB0aGVyZSBhbnl0aGluZyBlbHNlIHRoYXQgbmVl ZHMgdG8gYmUgY29uc2lkZXJlZD88YnI+PGJyPkJlc3QsPGJyPjxicj5Sb2xmPGJyPjxicj5ORUMg RXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3Rvcmlh IFJvYWQsIExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgzMjAxNDxvOnA+ PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48YnI+PGJyPiZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86ZW1h bi1ib3VuY2VzQGlldGYub3JnIj5lbWFuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmVtYW4tYm91bmNlc0BpZXRmLm9yZyI+ZW1hbi1ib3VuY2VzQGlldGYub3Jn PC9hPl0gT24gQmVoYWxmIE9mPGJyPiZndDsgSnVlcmdlbiBRdWl0dGVrPGJyPiZndDsgU2VudDog RnJlaXRhZywgMTEuIE3DpHJ6IDIwMTEgMTA6Mzc8YnI+Jmd0OyBUbzogQnJ1Y2UgTm9yZG1hbjxi cj4mZ3Q7IENjOiBlbWFuIG1haWxpbmcgbGlzdDxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbZW1hbl0g UG93ZXIgc3RhdGVzIC0gdGltZSB0byBkdW1wIEFDUEkgYW5kIERNVEY8YnI+Jmd0Ozxicj4mZ3Q7 IEhpIEJydWNlLDxicj4mZ3Q7PGJyPiZndDsgSSB1bmRlcnN0YW5kIHlvdXIgcHJlZmVyZW5jZSBm b3IgYSBzaW1wbGUgb2ZmLXNsZWVwLW9uIG1vZGVsIGZvciBwb3dlcjxicj4mZ3Q7IHN0YXRlcy48 YnI+Jmd0OyBIb3cgd291bGQgd2UgbW9kZWwgYSBkZXZpY2Ugd2l0aCBhIGJhdHRlcnkgdGhlbjxi cj4mZ3Q7ICZuYnNwOyAtIGl0IGlzIG9mZiwgYnV0IHRoZSBlbXB0eSBiYXR0ZXJ5IGlzIGJlaW5n IGNoYXJnZWQ8YnI+Jmd0OyAmbmJzcDsgLSBpdCBpcyBvbiwgYnV0IGZ1bGx5IHN1cHBsaWVkIHdp dGggcG93ZXIgZnJvbSB0aGUgYmF0dGVyeS48YnI+Jmd0Ozxicj4mZ3Q7IE9uIHdheSB3b3VsZCBi ZSB0cmVhdGluZyB0aGUgKGludGVybmFsKSBiYXR0ZXJ5IGFzIHNlcGFyYXRlIGRldmljZS48YnI+ Jmd0OyBJbiB0aGlzIGNhc2U6IENhbiB3ZSBtYXAgY2hhcmdpbmcvZGlzY2hhcmdpbmcvZnVsbC9l bXB0eSB0byBvZmYtc2xlZXAtPGJyPiZndDsgb24/PGJyPiZndDs8YnI+Jmd0OyBUaGFua3MsPGJy PiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7IEp1ZXJnZW48YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZn dDsgQW0gMTEuMDMuMjAxMSB1bSAwNzozNyBzY2hyaWViIEJydWNlIE5vcmRtYW46PGJyPiZndDs8 YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IChhbGwgYmVsb3cgYXMgY29udHJp YnV0b3IpPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBGb3IgbWFueSBkZWNhZGVzLCBlbGVjdHJpY2FsIHByb2R1Y3RzIHdlcmUgdXN1 YWxseSBqdXN0IG9uIG9yIG9mZjxicj4mZ3Q7IC0gYSAyLXN0YXRlIHBvd2VyIG1vZGVsLiAmbmJz cDtJbiB0aGUgbGFzdCBzZXZlcmFsIGRlY2FkZXMsIHdlIGhhdmUgYWRkZWQ8YnI+Jmd0OyBtYW55 IGVsZWN0cm9uaWMgcHJvZHVjdHMgd2l0aCBhIDMtc3RhdGUgbW9kZWwgLSBvbiwgc2xlZXAsIGFu ZCBvZmYuPGJyPiZndDsgVGhpcyBpcyBuZWNlc3NhcnkgYW5kIGV4aXN0aW5nIGNvbXBsZXhpdHku ICZuYnNwO091ciBkaXNjdXNzaW9ucyBhcm91bmQ8YnI+Jmd0OyBwb3dlciBzdGF0ZXMgYm9pbCBk b3duIHRvIHdoYXQgY29tcGxleGl0eSBkbyB3ZSB3YW50IHRvIGFkZCB0byB0aGUgMy08YnI+Jmd0 OyBzdGF0ZSBtb2RlbCwgYW5kIHdoeSB0aGUgYnVyZGVuIGlzIGp1c3RpZmllZC48YnI+Jmd0Ozxi cj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgSW4gZGlzY3Vzc2lvbnMgb24gdGhpcyBlbWFpbCBsaXN0LCBpbiBJLWRyYWZ0cywgYW5kIGlu IHBlcnNvbiw8YnI+Jmd0OyB0aGUgZXhpc3RpbmcgbGlzdGluZ3Mgb2YgcG93ZXIgc3RhdGVzIGZy b20gQUNQSSBhbmQgRE1URiBhcmUgb2Z0ZW48YnI+Jmd0OyByZWZlcmVuY2VkIGFzIGdvb2QgY2Fu ZGlkYXRlcyBmb3IgZW1hbiB0byBhZG9wdCBpbiBzb21lIHdheS4gJm5ic3A7QUNQSSBpcyBhPGJy PiZndDsgaHVnZWx5IGltcG9ydGFudCB0ZWNobm9sb2d5LCBhbmQgaXQgZW5hYmxlcyBsYXJnZSBh bW91bnRzIG9mIHVzZXI8YnI+Jmd0OyBmdW5jdGlvbmFsaXR5IGFuZCBlbmVyZ3kgc2F2aW5ncy4g Jm5ic3A7SSBhbSBsZXNzIGZhbWlsaWFyIHdpdGggdGhlIHJlYWNoIG9mPGJyPiZndDsgRE1URiBp biBwcmFjdGljZSwgYnV0IGl0cyBkZXB0aCBhbmQgYnJlYWR0aCBvZiBtZW1iZXJzaGlwIGFyZTxi cj4mZ3Q7IGNvbXBlbGxpbmcuICZuYnNwO1doaWxlIEkgYWdyZWUgdGhleSBib3RoIGRlc2VydmUg Y2xvc2UgZXhhbWluYXRpb24sIEkgdGhpbms8YnI+Jmd0OyB3ZSBjYW4gc2FmZWx5IGRyb3AgdGhl bSBmcm9tIG91ciBkaXNjdXNzaW9ucyBvZiB3aGF0IHRvIGRlZmluZSBhcyB0aGVpcjxicj4mZ3Q7 IGNvbXBsZXhpdHkgaXMgbW9yZSBhIGRpc3RyYWN0aW9uIHRoYW4gYW4gYXNzZXQuPGJyPiZndDs8 YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUg YmFzaWMgQUNQSSBsaXN0IGlzIG9mICZuYnNwOyZxdW90O0dsb2JhbCBTeXN0ZW0gU3RhdGVzJnF1 b3Q7IHdoaWNoICZxdW90O2FwcGx5IHRvPGJyPiZndDsgdGhlIGVudGlyZSBzeXN0ZW0mcXVvdDsu ICZuYnNwO1RoZXJlIGFyZSBmb3VyIG9mIHRoZXNlIChHMC1HMyk7IEcwIGlzIG9uPGJyPiZndDsg KCZxdW90O3dvcmtpbmcmcXVvdDspIGFuZCBHMSBpcyBzbGVlcCAoJnF1b3Q7c2xlZXBpbmcmcXVv dDspLiAmbmJzcDtHMiBhbmQgRzMgYm90aCBmb3JtcyBvZiBvZmY8YnI+Jmd0OyAob25seSBkaXN0 aW5ndWlzaGVkIGJ5IHdoZXRoZXIgYSBkZXZpY2UgaXMgY29tcGxldGVseSBkZXBvd2VyZWQgYW5k PGJyPiZndDsgd2hldGhlciBpdCBpcyBzYWZlIHRvIGRpc2Fzc2VtYmxlIG9yIG5vdCwgYW5kIHRo ZXNlIGRpc3RpbmN0aW9ucyBzZWVtczxicj4mZ3Q7IHF1aXRlIG1pbm9yIGZvciBlbWFuIHB1cnBv c2VzKS4gJm5ic3A7VGh1cywgdGhlIEFDUEkgR2xvYmFsIHN0YXRlcyBhcmU8YnI+Jmd0OyBlc3Nl bnRpYWxseSBvbi9zbGVlcC9vZmYsIHRoZSAzLXN0YXRlIHBvd2VyIG1vZGVsLjxicj4mZ3Q7PGJy PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgQUNQSSBsaXN0cyBmaXZlICZxdW90O1N4JnF1b3Q7IHNsZWVwIHN0YXRlcyAo UzAgaXMgb24pLiAmbmJzcDtTNSBpczxicj4mZ3Q7IGFjdHVhbGx5IHRoZSBHMiBPZmYgc3RhdGUg KHNvIG5vdCBhIHNsZWVwIHN0YXRlIGF0IGFsbCksIGFuZCBjdXJyZW50PGJyPiZndDsgaW1wbGVt ZW50YXRpb25zIGRvIG5vdCB1c2UgUzEgb3IgUzIsIHNvIGluIHByYWN0aWNlIHRoZXJlIGFyZSBv bmx5IHR3bzxicj4mZ3Q7IEFDUEkgc2xlZXAgc3RhdGVzOiBTMyBhbmQgUzQuICZuYnNwO1MzIGlz IHRoZSBvcmRpbmFyeSBzeXN0ZW0gc2xlZXAsIHdpdGg8YnI+Jmd0OyBxdWljayB3YWtldXAuICZu YnNwO1M0IGlzIHRoZSBoaWJlcm5hdGUgc3RhdGUgKHdpdGggc3lzdGVtIG1lbW9yeSBzYXZlZCBp bjxicj4mZ3Q7IG5vbi12b2xhdGlsZSBtZW1vcnksIHBvc3NpYmx5IGEgaGFyZCBkaXNrKSB3aGlj aCB0eXBpY2FsbHkgaGFzIGxvbmc8YnI+Jmd0OyB0aW1lcyB0byByZXR1cm4gdG8gb3BlcmF0aW9u IChvZnRlbiB0ZW5zIG9mIHNlY29uZHMpLiAmbmJzcDsgVGhlIDEtMiBzZWNvbmQ8YnI+Jmd0OyB3 YWtlIHRpbWUgZnJvbSBTMyBmb3IgbW9kZXJuIHBlcnNvbmFsIGNvbXB1dGVycyBpcyBjb21wYXRp YmxlIHdpdGggbWFueTxicj4mZ3Q7IElQIHByb3RvY29sIHVzYWdlcywgZS5nLiBpbml0aWF0aW5n IGEgVENQIGNvbm5lY3Rpb24uICZuYnNwO1RoZSB0ZW5zIG9mPGJyPiZndDsgc2Vjb25kcyB0aW1l IGZvciBTNCBvbiBjdXJyZW50IHN5c3RlbXMgaXMgbm90LiAmbmJzcDtTbywgdGhlIG9ubHkgcG90 ZW50aWFsPGJyPiZndDsgYWRkaXRpb24gdGhhdCB0aGUgU3ggc3RhdGVzIGFkZCB0byBvbi9zbGVl cC9vZmYgaXMgaGliZXJuYXRlIChhbmQ8YnI+Jmd0OyByZWFzb25hYmxlIHBlb3BsZSBjYW4gZGlm ZmVyIG9uIHdoZXRoZXIgaXQgaXMgYSBmb3VydGggYmFzaWMgc3RhdGUsIGE8YnI+Jmd0OyBmb3Jt IG9mIHNsZWVwLCBvciBhIGZvcm0gb2Ygb2ZmKS48YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgQUNQSSBkb2VzIGRlZmluZSBwcm9jZXNzb3Igc3RhdGVzIChDeCkgYW5kIGRldmljZTxicj4m Z3Q7IHN0YXRlcyAoRHgpIChjb2xsZWN0aXZlbHkgUHgpLCBidXQgdGhlc2UgYXJlIHRoZSBzdGF0 ZXMgb2YgcGFydGljdWxhcjxicj4mZ3Q7IGNvbXBvbmVudHMsIG5vdCBvZiB0aGUgc3lzdGVtIGFz IGEgd2hvbGUuICZuYnNwO0l0IG1heSBiZSB1c2VmdWwgdG8gZXhwb3NlPGJyPiZndDsgdGhlc2Ug dGhyb3VnaCBzb21lIG1lY2hhbmlzbSwgYnV0IHRoZXkgYXJlIGRpc3RpbmN0IGZyb20gdGhlIHBv d2VyPGJyPiZndDsgc3RhdGUuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBETVRGIGVzc2VudGlhbGx5IHRvb2sgdGhlIEFDUEkgR3ggc3RhdGVzIHBsdXM8YnI+ Jmd0OyBoaWJlcm5hdGUgYW5kIGFkZGVkIHN0YXRlcyB0aGF0IGFyZSBjb21tYW5kcyBhbmQvb3Ig dHJhbnNpdGlvbnMuICZuYnNwOyhJczxicj4mZ3Q7ICZxdW90O01hc3RlciBCdXMgUmVzZXQmcXVv dDsgYSBwb3dlciBzdGF0ZT8gJm5ic3A7SSB0aGluayBub3QpLiAmbmJzcDtJZiB3ZSBkb24ndCBp bmNsdWRlPGJyPiZndDsgY29tbWFuZHMgb3IgdHJhbnNpdGlvbnMgKEkgdGhpbmsgd2Ugc2hvdWxk IG5vdCksIHRoZW4gdGhlc2UgcmVkdWNlIHRvPGJyPiZndDsgdGhlIEFDUEkgc3RhdGVzLjxicj4m Z3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTXkgY29uY2x1c2lvbjog QUNQSSBhbmQgRE1URiBkbyBub3Qgc2lnbmlmaWNhbnRseTxicj4mZ3Q7IGNoYW5nZSB0aGUgMy1z dGF0ZSBwb3dlciBtb2RlbC4gJm5ic3A7SWYgd2Ugd2FudCB0byB0YWxrIGFib3V0IHN0YXRlcyBi ZXlvbmQ8YnI+Jmd0OyB0aGUgMy1zdGF0ZSBtb2RlbCwgaXQgaXMgbW9yZSBjbGVhciB0byBzaW1w bHkgcmVmZXJlbmNlIHRob3NlPGJyPiZndDsgZXh0ZW5zaW9ucyBkaXJlY3RseSAoZS5nLiBob3cg YmVzdCB0byB0cmVhdCBoaWJlcm5hdGUpLiAmbmJzcDtOb3RlIHRoYXQgdGhpczxicj4mZ3Q7IGRp c2N1c3Npb24gLSBhbmQgYWxsIG90aGVycyBvbiB0aGUgbGlzdCAtIGFyZSBncm91bmRlZCBpbiBl bGVjdHJvbmljPGJyPiZndDsgZGV2aWNlcy4gJm5ic3A7T3RoZXIgZGV2aWNlcyBnZW5lcmFsbHkg aGF2ZSBhIDItc3RhdGUgbW9kZWwgKGUuZy4gYSBsaWdodCksPGJyPiZndDsgb3IgMyBzdGF0ZXMs IGJ1dCBvbiwgb2ZmLCBhbmQgJnF1b3Q7cmVhZHkmcXVvdDsgKHRoaW5rIGEgbWljcm93YXZlIG92 ZW4pLjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgLS1CcnVjZTxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLS08YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCcnVj ZSBOb3JkbWFuPGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTGF3cmVuY2UgQmVya2VsZXkg TmF0aW9uYWwgTGFib3JhdG9yeTxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9 Imh0dHA6Ly9lZXRkLmxibC5nb3YvZWEvbm9yZG1hbiI+ZWV0ZC5sYmwuZ292L2VhL25vcmRtYW48 L2E+PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkJOb3JkbWFu QExCTC5nb3YiPkJOb3JkbWFuQExCTC5nb3Y8L2E+PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgPGEgaHJlZj0idGVsOjUxMC00ODYtNzA4OSI+NTEwLTQ4Ni03MDg5PC9hPjxicj4mZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IG06IDxhIGhyZWY9InRlbDo1MTAtNTAxLTc5NDMiPjUxMC01MDEt Nzk0MzwvYT48YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgZW1hbiBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8 YSBocmVmPSJtYWlsdG86ZW1hbkBpZXRmLm9yZyI+ZW1hbkBpZXRmLm9yZzwvYT48YnI+Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2VtYW4iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW1h bjwvYT48YnI+Jmd0Ozxicj4mZ3Q7PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj5lbWFuIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWls dG86ZW1hbkBpZXRmLm9yZyI+ZW1hbkBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbWFuIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2VtYW48L2E+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9k aXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYm9keT48L2h0bWw+ ------_=_NextPart_001_01CBE119.E8DBC238-- From tirth.ghose@gmail.com Sat Mar 12 19:29:31 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E7B3A6AC4 for ; Sat, 12 Mar 2011 19:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcRPn9eDUvxS for ; Sat, 12 Mar 2011 19:29:28 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 90BC03A6AA7 for ; Sat, 12 Mar 2011 19:29:28 -0800 (PST) Received: by iwl42 with SMTP id 42so4809998iwl.31 for ; Sat, 12 Mar 2011 19:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bS+q2ozQX3BVShcD1PhbUBngv4cftLYB+mmzTDqGaqo=; b=BrfB8kxqti7+7H7xJAnKc5gppYs7BNXTEhs+1S1gH/REssetTn/v88wCtaXfsc69tv 4WeX2yJ/bJF4XYGL5dafm+xj0y24LEzTj8HqLG23ziPRtj0mm+wqmFwRW9MCGx+9G4xb /yhtFZcZVHjHzyegLcy4Vycvof04q7X+uQlPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Xsif+aAyqJIFmNS1xSHvQD9cCECXMx2MVSB6wRfpaIiHAVRRRStSZjQzdDkhxIWUtI CiGKh1sq0fn9eh+HKV3I7ilIGq22EBfRfuLudSIzjFyo9yQodzUL0MAUG5WIhTL6jvyh 7b559Txr2IFPMc+LPcoez1vtPPJpDD4MBfBbI= MIME-Version: 1.0 Received: by 10.43.54.133 with SMTP id vu5mr9590708icb.36.1299987049668; Sat, 12 Mar 2011 19:30:49 -0800 (PST) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Sat, 12 Mar 2011 19:30:49 -0800 (PST) In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> Date: Sat, 12 Mar 2011 19:30:49 -0800 X-Google-Sender-Auth: SmCvw-nOfiat2kPTdCczTemaDqA Message-ID: From: Ted Ghose To: Chris Verges Content-Type: multipart/alternative; boundary=bcaec51ddb2f4edfad049e54d284 Cc: eman mailing list , Rolf Winter , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 03:29:31 -0000 --bcaec51ddb2f4edfad049e54d284 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable servers running on batteries? really? -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Fri, Mar 11, 2011 at 8:04 AM, Chris Verges wr= ote: > Hi Ted, > > > > I might be putting words into Rolf=92s mouth, but here are my thoughts on > this: > > > > Certain devices, like servers, that contain a Lights Out Management (LOM) > card will be able to report the server=92s power supply as =93off=94 but = the > battery as =93charging=94. This combination for the server entity result= s in > the desired effect. > > > > Rolf, anywhere in the ballpark? > > > > Chris > > > > *From:* eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] *On Behalf O= f > *Ted Ghose > *Sent:* Friday, March 11, 2011 8:01 AM > *To:* Rolf Winter > *Cc:* Bruce Nordman; eman mailing list > > *Subject:* Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Rolf, Juergen > > > > I like Rolf's idea very much. We should extend number of states > to accommodate other sub states. > > > > Here is one question I do have for Juergon, as handling the battery keeps > coming up in all the discussions. > > > > If the device is off, but battery is charging, who is reporting that and > how? Is battery itself has the intelligence to do so? In that case, can w= e > treat it as a separate device independent of the device it is connected t= o, > and then we could simplify the model. > > > > In the other case, though, if device is turned off, there is no one to te= ll > what the battery is doing, unless an intelligent PDU or someone is aware = of > that device. Which comes to some source - sink model as well. > > > > Could you please clarify your thoughts? > > > > thanks > > > > -tg- > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > Save time... see it my way > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > > On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter > wrote: > > Hi, > > just thinking out loud here. > > The thing which seems to complicate matters here significantly is > batteries. You either A) try to consider battery state in the devices' po= wer > state or you B) leave it separate in its own MIB module (as described e.g= . > here http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where w= e > have battery states full(1), partiallyCharged(2), empty(3), charging(4), > discharging(5), unknown(6)). I think these are the trade-offs: > > Option A) You can always tell from the device power state whether it is > drawing power or not ("off but charging" e.g.) and you might be able to > order them in a way that a higher state always translates to higher power > draw. It however seems to complicate power states. > > Option B) If a battery is present, you cannot tell from the device's powe= r > state whether is it drawing power or not ("off" could be really "off but > charging"). The device power states can be modelled cleaner though and yo= u'd > need to look closer to see what the battery state is to be sure there is = no > power draw. > > Is that the trade-off we're talking about or is there anything else that > needs to be considered? > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n > W3 6BL | Registered in England 2832014 > > > > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > > Juergen Quittek > > Sent: Freitag, 11. M=E4rz 2011 10:37 > > To: Bruce Nordman > > Cc: eman mailing list > > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Bruce, > > > > I understand your preference for a simple off-sleep-on model for power > > states. > > How would we model a device with a battery then > > - it is off, but the empty battery is being charged > > - it is on, but fully supplied with power from the battery. > > > > On way would be treating the (internal) battery as separate device. > > In this case: Can we map charging/discharging/full/empty to off-sleep- > > on? > > > > Thanks, > > > > Juergen > > > > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > > > > (all below as contributor) > > > > > > > > > > For many decades, electrical products were usually just on or off > > - a 2-state power model. In the last several decades, we have added > > many electronic products with a 3-state model - on, sleep, and off. > > This is necessary and existing complexity. Our discussions around > > power states boil down to what complexity do we want to add to the 3- > > state model, and why the burden is justified. > > > > > > > > > > > > In discussions on this email list, in I-drafts, and in person, > > the existing listings of power states from ACPI and DMTF are often > > referenced as good candidates for eman to adopt in some way. ACPI is a > > hugely important technology, and it enables large amounts of user > > functionality and energy savings. I am less familiar with the reach of > > DMTF in practice, but its depth and breadth of membership are > > compelling. While I agree they both deserve close examination, I think > > we can safely drop them from our discussions of what to define as their > > complexity is more a distraction than an asset. > > > > > > > > > > The basic ACPI list is of "Global System States" which "apply to > > the entire system". There are four of these (G0-G3); G0 is on > > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > > (only distinguished by whether a device is completely depowered and > > whether it is safe to disassemble or not, and these distinctions seems > > quite minor for eman purposes). Thus, the ACPI Global states are > > essentially on/sleep/off, the 3-state power model. > > > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > > actually the G2 Off state (so not a sleep state at all), and current > > implementations do not use S1 or S2, so in practice there are only two > > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > > quick wakeup. S4 is the hibernate state (with system memory saved in > > non-volatile memory, possibly a hard disk) which typically has long > > times to return to operation (often tens of seconds). The 1-2 second > > wake time from S3 for modern personal computers is compatible with many > > IP protocol usages, e.g. initiating a TCP connection. The tens of > > seconds time for S4 on current systems is not. So, the only potential > > addition that the Sx states add to on/sleep/off is hibernate (and > > reasonable people can differ on whether it is a fourth basic state, a > > form of sleep, or a form of off). > > > > > > ACPI does define processor states (Cx) and device > > states (Dx) (collectively Px), but these are the states of particular > > components, not of the system as a whole. It may be useful to expose > > these through some mechanism, but they are distinct from the power > > state. > > > > > > > > > > DMTF essentially took the ACPI Gx states plus > > hibernate and added states that are commands and/or transitions. (Is > > "Master Bus Reset" a power state? I think not). If we don't include > > commands or transitions (I think we should not), then these reduce to > > the ACPI states. > > > > > > > > > > My conclusion: ACPI and DMTF do not significantly > > change the 3-state power model. If we want to talk about states beyond > > the 3-state model, it is more clear to simply reference those > > extensions directly (e.g. how best to treat hibernate). Note that this > > discussion - and all others on the list - are grounded in electronic > > devices. Other devices generally have a 2-state model (e.g. a light), > > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > > > > > > --Bruce > > > > > > > > > > -- > > Bruce Nordman > > Lawrence Berkeley National Laboratory > > eetd.lbl.gov/ea/nordman > > BNordman@LBL.gov > > <510-486-7089>510-486-7089 > > m: <510-501-7943>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 > > > --bcaec51ddb2f4edfad049e54d284 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable servers running on batteries? really?

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:= -.,_:-.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save t= ime... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_= :-.,_,.-:**:-.,_,.


On Fri, Mar 11, 2011 at 8:04 AM, Chris V= erges <ch= risv@cyberswitching.com> wrote:

Hi Ted,

=A0<= /p>

I might be putting words int= o Rolf=92s mouth, but here are my thoughts on this:

=A0

Certain devices, like server= s, that contain a Lights Out Management (LOM) card will be able to report t= he server=92s power supply as =93off=94 but the battery as =93charging=94.= =A0 This combination for the server entity results in the desired effect.

=A0

Rolf, anywhere in the ballpark?

=A0

Chris=

=A0

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.o= rg] On Behalf Of Ted Ghose
Sent: Friday, March 11, 2011 8:01 AM
To: Rolf Winter
Cc: Bruce Nordman; eman mailing list


Subject: Re: [eman] Power states - time to dump ACPI = and DMTF

=A0

Hi Rolf, Juergen

= =A0

I like Rolf's idea very much. = We should extend number of states to=A0accommodate=A0other sub states.=A0

=A0

= Here is one question I do have for Juergon, as handling the battery keeps c= oming up in all the discussions.=A0

= =A0

If the device is off, but battery is charging, = who is reporting that and how? Is battery itself has the=A0intelligence to = do so? In that case, can we treat it as a=A0separate=A0device=A0independent= of the device it is connected to, and then we could simplify the model.

=A0

= In the other case, though, if device is turned off, there is no one to tell= what the battery is doing, unless an=A0intelligent=A0PDU or someone is awa= re of that device. Which comes to some source - sink model as well.

=A0

= Could you please clarify your thoughts?

=A0

thanks

=A0

-tg= -
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:= *'``'*:-.,_:-.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0=A0 Save time... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_= :-.,_,.-:**:-.,_,.

On Fri, Mar 11, 2= 011 at 5:36 AM, Rolf Winter <Rolf.Winter@neclab.eu> wrote:

Hi,

just thinking out loud here.

The t= hing which seems to complicate matters here significantly is batteries. You= either A) try to consider battery state in the devices' power state or= you B) leave it separate in its own MIB module (as described e.g. here http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we have battery states full(1), partiallyCharged(2), empty(3), cha= rging(4), discharging(5), unknown(6)). I think these are the trade-offs:
Option A) You can always tell from the device power state whether it is= drawing power or not ("off but charging" e.g.) and you might be = able to order them in a way that a higher state always translates to higher= power draw. It however seems to complicate power states.

Option B) If a battery is present, you cannot tell from the device'= s power state whether is it drawing power or not ("off" could be = really "off but charging"). The device power states can be modell= ed cleaner though and you'd need to look closer to see what the battery= state is to be sure there is no power draw.

Is that the trade-off we're talking about or is there anything else= that needs to be considered?

Best,

Rolf

NEC Europe Li= mited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Regi= stered in England 2832014



> -----Original Message-----> From: eman= -bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 10:37
> T= o: Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [eman] = Power states - time to dump ACPI and DMTF
>
> Hi Bruce,
>=
> I understand your preference for a simple off-sleep-on model for power=
> states.
> How would we model a device with a battery then> =A0 - it is off, but the empty battery is being charged
> =A0 -= it is on, but fully supplied with power from the battery.
>
> On way would be treating the (internal) battery as separate de= vice.
> In this case: Can we map charging/discharging/full/empty to o= ff-sleep-
> on?
>
> Thanks,
>
> =A0 =A0 Juerg= en
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce Nordman:
><= br>>
> =A0 =A0 =A0 (all below as contributor)
>
>
&= gt;
>
> =A0 =A0 =A0 For many decades, electrical products were = usually just on or off
> - a 2-state power model. =A0In the last several decades, we have added=
> many electronic products with a 3-state model - on, sleep, and off= .
> This is necessary and existing complexity. =A0Our discussions aro= und
> power states boil down to what complexity do we want to add to the 3-<= br>> state model, and why the burden is justified.
>
>
&g= t;
>
>
> =A0 =A0 =A0 In discussions on this email list, i= n I-drafts, and in person,
> the existing listings of power states from ACPI and DMTF are often
= > referenced as good candidates for eman to adopt in some way. =A0ACPI i= s a
> hugely important technology, and it enables large amounts of us= er
> functionality and energy savings. =A0I am less familiar with the reach= of
> DMTF in practice, but its depth and breadth of membership are> compelling. =A0While I agree they both deserve close examination, I = think
> we can safely drop them from our discussions of what to define as thei= r
> complexity is more a distraction than an asset.
>
>>
>
> =A0 =A0 =A0 The basic ACPI list is of =A0"Globa= l System States" which "apply to
> the entire system". =A0There are four of these (G0-G3); G0 is on<= br>> ("working") and G1 is sleep ("sleeping"). =A0G2= and G3 both forms of off
> (only distinguished by whether a device i= s completely depowered and
> whether it is safe to disassemble or not, and these distinctions seems=
> quite minor for eman purposes). =A0Thus, the ACPI Global states ar= e
> essentially on/sleep/off, the 3-state power model.
>
>= ; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ACPI lists five "Sx" sleep = states (S0 is on). =A0S5 is
> actually the G2 Off state (so not a sleep state at all), and current> implementations do not use S1 or S2, so in practice there are only t= wo
> ACPI sleep states: S3 and S4. =A0S3 is the ordinary system sleep= , with
> quick wakeup. =A0S4 is the hibernate state (with system memory saved i= n
> non-volatile memory, possibly a hard disk) which typically has lo= ng
> times to return to operation (often tens of seconds). =A0 The 1-= 2 second
> wake time from S3 for modern personal computers is compatible with man= y
> IP protocol usages, e.g. initiating a TCP connection. =A0The tens= of
> seconds time for S4 on current systems is not. =A0So, the only = potential
> addition that the Sx states add to on/sleep/off is hibernate (and
&= gt; reasonable people can differ on whether it is a fourth basic state, a> form of sleep, or a form of off).
>
>
> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 ACPI does define processor states (Cx) and devi= ce
> states (Dx) (collectively Px), but these are the states of particular<= br>> components, not of the system as a whole. =A0It may be useful to ex= pose
> these through some mechanism, but they are distinct from the p= ower
> state.
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 DMTF essentially took the ACPI Gx states plus
> hibernat= e and added states that are commands and/or transitions. =A0(Is
> &qu= ot;Master Bus Reset" a power state? =A0I think not). =A0If we don'= t include
> commands or transitions (I think we should not), then these reduce to<= br>> the ACPI states.
>
>
>
>
> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 My conclusion: ACPI and DMTF do not significant= ly
> change the 3-state power model. =A0If we want to talk about stat= es beyond
> the 3-state model, it is more clear to simply reference those
> = extensions directly (e.g. how best to treat hibernate). =A0Note that this> discussion - and all others on the list - are grounded in electronic=
> devices. =A0Other devices generally have a 2-state model (e.g. a light= ),
> or 3 states, but on, off, and "ready" (think a microwa= ve oven).
>
>
>
>
> =A0 =A0 =A0 --Bruce
&g= t;
>
>
>
> =A0 =A0 =A0 --
> =A0 =A0 =A0 Bruce Nordm= an
> =A0 =A0 =A0 Lawrence Berkeley National Laboratory
> =A0 = =A0 =A0 eetd.l= bl.gov/ea/nordman
> =A0 =A0 =A0 BNordman@LBL.gov
> =A0 =A0 =A0 510-486-7089
> =A0 =A0 = =A0 m: 510-501-7943
>
> =A0 =A0 =A0 _______________________________________________> =A0 =A0 =A0 eman mailing list
> =A0 =A0 =A0 eman@ietf.org
> =A0 =A0 =A0 https:/= /www.ietf.org/mailman/listinfo/eman
>
>

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

=A0


--bcaec51ddb2f4edfad049e54d284-- From chrisv@cyberswitching.com Sat Mar 12 19:32:45 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A9B3A67FF for ; Sat, 12 Mar 2011 19:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0GExUtJEUIs for ; Sat, 12 Mar 2011 19:32:35 -0800 (PST) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by core3.amsl.com (Postfix) with ESMTP id DADE73A67FC for ; Sat, 12 Mar 2011 19:32:34 -0800 (PST) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o149.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 32b3c7d4.0.30104.00-367.51882.p01c12o149.mxlogic.net (envelope-from ); Sat, 12 Mar 2011 20:33:56 -0700 (MST) X-MXL-Hash: 4d7c3b246b9f0a9a-2709b578417185f39701001d550c80141718a455 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE12F.5B77A522" Date: Sat, 12 Mar 2011 19:33:00 -0800 Message-ID: <68FBE0F3CE97264395875AC1C468F22CF36850@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AcvhLu3yIDc1Lvr7SyuI95PmJOKbHAAADbMg References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd><68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> From: "Chris Verges" To: "Ted Ghose" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=SbxTRnKmSzQA:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=pGLkceISAAAA:8 a=wzgqfsuUAAAA:8 a=48vg] X-AnalysisOut: [C7mUAAAA:8 a=W6XBYL2aoS0ivxSWwW0A:9 a=xYTeO2brJflwHKqRFgQA] X-AnalysisOut: [:7 a=Zv8UUE5V1GlTa6MArBzL0aDxclQA:4 a=wPNLvfGTeEIA:10 a=Fn] X-AnalysisOut: [BvD0j_UmcA:10 a=lr71C7C2fScA:10 a=MSl-tDqOz04A:10 a=yvfu_R] X-AnalysisOut: [GVus0A:10 a=lZB815dzVvQA:10 a=zFovntDArtb4hZ45:21 a=Bff1PO] X-AnalysisOut: [XxOdLAgkQ0:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=J35dNKfb] X-AnalysisOut: [AAAA:8 a=6alU_g5KVUf7wrG1HsEA:9 a=penxccGsR1Ek0uMcUowA:7 a] X-AnalysisOut: [=yN3p8dImau5E9DOdEWDQLW0q9hsA:4] Cc: eman mailing list , Rolf Winter , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 03:32:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE12F.5B77A522 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I assume you're being rhetorical, but I'll follow up anyway to make sure = we all understand your point. What's so hard to believe about that? = Especially given the examples shown during this discussion. =20 Thanks, Chris =20 From: tirth.ghose@gmail.com [mailto:tirth.ghose@gmail.com] On Behalf Of = Ted Ghose Sent: Saturday, March 12, 2011 7:31 PM To: Chris Verges Cc: Rolf Winter; Bruce Nordman; eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 servers running on batteries? really? =20 -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Fri, Mar 11, 2011 at 8:04 AM, Chris Verges = wrote: Hi Ted, =20 I might be putting words into Rolf's mouth, but here are my thoughts on = this: =20 Certain devices, like servers, that contain a Lights Out Management = (LOM) card will be able to report the server's power supply as "off" but = the battery as "charging". This combination for the server entity = results in the desired effect. =20 Rolf, anywhere in the ballpark? =20 Chris =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Ted Ghose Sent: Friday, March 11, 2011 8:01 AM To: Rolf Winter Cc: Bruce Nordman; eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Hi Rolf, Juergen =20 I like Rolf's idea very much. We should extend number of states to = accommodate other sub states.=20 =20 Here is one question I do have for Juergon, as handling the battery = keeps coming up in all the discussions.=20 =20 If the device is off, but battery is charging, who is reporting that and = how? Is battery itself has the intelligence to do so? In that case, can = we treat it as a separate device independent of the device it is = connected to, and then we could simplify the model. =20 In the other case, though, if device is turned off, there is no one to = tell what the battery is doing, unless an intelligent PDU or someone is = aware of that device. Which comes to some source - sink model as well. =20 Could you please clarify your thoughts? =20 thanks =20 -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = wrote: Hi, just thinking out loud here. The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here = http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we = have battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the trade-offs: Option A) You can always tell from the device power state whether it is = drawing power or not ("off but charging" e.g.) and you might be able to = order them in a way that a higher state always translates to higher = power draw. It however seems to complicate power states. Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be really = "off but charging"). The device power states can be modelled cleaner = though and you'd need to look closer to see what the battery state is to = be sure there is no power draw. Is that the trade-off we're talking about or is there anything else that = needs to be considered? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Juergen Quittek > Sent: Freitag, 11. M=E4rz 2011 10:37 > To: Bruce Nordman > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > Hi Bruce, > > I understand your preference for a simple off-sleep-on model for power > states. > How would we model a device with a battery then > - it is off, but the empty battery is being charged > - it is on, but fully supplied with power from the battery. > > On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep- > on? > > Thanks, > > Juergen > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > (all below as contributor) > > > > > For many decades, electrical products were usually just on or = off > - a 2-state power model. In the last several decades, we have added > many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. Our discussions around > power states boil down to what complexity do we want to add to the 3- > state model, and why the burden is justified. > > > > > > In discussions on this email list, in I-drafts, and in person, > the existing listings of power states from ACPI and DMTF are often > referenced as good candidates for eman to adopt in some way. ACPI is = a > hugely important technology, and it enables large amounts of user > functionality and energy savings. I am less familiar with the reach = of > DMTF in practice, but its depth and breadth of membership are > compelling. While I agree they both deserve close examination, I = think > we can safely drop them from our discussions of what to define as = their > complexity is more a distraction than an asset. > > > > > The basic ACPI list is of "Global System States" which "apply = to > the entire system". There are four of these (G0-G3); G0 is on > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems > quite minor for eman purposes). Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model. > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > quick wakeup. S4 is the hibernate state (with system memory saved in > non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). The 1-2 second > wake time from S3 for modern personal computers is compatible with = many > IP protocol usages, e.g. initiating a TCP connection. The tens of > seconds time for S4 on current systems is not. So, the only potential > addition that the Sx states add to on/sleep/off is hibernate (and > reasonable people can differ on whether it is a fourth basic state, a > form of sleep, or a form of off). > > > ACPI does define processor states (Cx) and device > states (Dx) (collectively Px), but these are the states of particular > components, not of the system as a whole. It may be useful to expose > these through some mechanism, but they are distinct from the power > state. > > > > > DMTF essentially took the ACPI Gx states plus > hibernate and added states that are commands and/or transitions. (Is > "Master Bus Reset" a power state? I think not). If we don't include > commands or transitions (I think we should not), then these reduce to > the ACPI states. > > > > > My conclusion: ACPI and DMTF do not significantly > change the 3-state power model. If we want to talk about states = beyond > the 3-state model, it is more clear to simply reference those > extensions directly (e.g. how best to treat hibernate). Note that = this > discussion - and all others on the list - are grounded in electronic > devices. Other devices generally have a 2-state model (e.g. a light), > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > --Bruce > > > > > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > 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 =20 =20 ------_=_NextPart_001_01CBE12F.5B77A522 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I assume you’re being rhetorical, but I’ll follow up = anyway to make sure we all understand your point.=A0 What’s so = hard to believe about that?=A0 Especially given the examples shown = during this discussion.

 

Thanks,

Chris

 

From:= = tirth.ghose@gmail.com [mailto:tirth.ghose@gmail.com] On Behalf Of = Ted Ghose
Sent: Saturday, March 12, 2011 7:31 = PM
To: Chris Verges
Cc: Rolf Winter; Bruce Nordman; = eman mailing list
Subject: Re: [eman] Power states - time to = dump ACPI and DMTF

 

servers = running on batteries? really?

 

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:*= *:-.,_,.
                =      Save time... see it my = way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,= _,.

On Fri, Mar 11, 2011 = at 8:04 AM, Chris Verges <chrisv@cyberswitching.com&g= t; wrote:

Hi Ted,

 

I might be putting words into = Rolf’s mouth, but here are my thoughts on = this:

 

Certain devices, like servers, = that contain a Lights Out Management (LOM) card will be able to report = the server’s power supply as “off” but the battery as = “charging”.  This combination for the server entity = results in the desired effect.

 

Rolf, anywhere in the = ballpark?

 

Chris

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Ted = Ghose
Sent: Friday, March 11, 2011 8:01 AM
To: Rolf = Winter
Cc: Bruce Nordman; eman mailing = list


Subject: Re: [eman] Power states - time to = dump ACPI and DMTF

 <= /o:p>

Hi Rolf, = Juergen

 <= /o:p>

I like = Rolf's idea very much. We should extend number of states = to accommodate other sub = states. 

 <= /o:p>

Here is one = question I do have for Juergon, as handling the battery keeps coming up = in all the discussions. 

 <= /o:p>

If the = device is off, but battery is charging, who is reporting that and how? = Is battery itself has the intelligence to do so? In that case, can = we treat it as a separate device independent of the = device it is connected to, and then we could simplify the = model.

 <= /o:p>

In the = other case, though, if device is turned off, there is no one to tell = what the battery is doing, unless an intelligent PDU or = someone is aware of that device. Which comes to some source - sink model = as well.

 <= /o:p>

Could you = please clarify your thoughts?

 <= /o:p>

thanks<= /o:p>

 <= /o:p>

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:*= *:-.,_,.
                =      Save time... see it my = way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,= _,.

On Fri, Mar = 11, 2011 at 5:36 AM, Rolf Winter <Rolf.Winter@neclab.eu> wrote:

Hi,

j= ust thinking out loud here.

The thing which seems to complicate = matters here significantly is batteries. You either A) try to consider = battery state in the devices' power state or you B) leave it separate in = its own MIB module (as described e.g. here http://tools.ietf.org/html/draft-quittek-eman-battery-m= ib-00 where we have battery states full(1), partiallyCharged(2), = empty(3), charging(4), discharging(5), unknown(6)). I think these are = the trade-offs:

Option A) You can always tell from the device = power state whether it is drawing power or not ("off but = charging" e.g.) and you might be able to order them in a way that a = higher state always translates to higher power draw. It however seems to = complicate power states.

Option B) If a battery is present, you = cannot tell from the device's power state whether is it drawing power or = not ("off" could be really "off but charging"). The = device power states can be modelled cleaner though and you'd need to = look closer to see what the battery state is to be sure there is no = power draw.

Is that the trade-off we're talking about or is there = anything else that needs to be = considered?

Best,

Rolf

NEC Europe Limited | = Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014



>= -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> = Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 10:37
> To: = Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [eman] = Power states - time to dump ACPI and DMTF
>
> Hi = Bruce,
>
> I understand your preference for a simple = off-sleep-on model for power
> states.
> How would we model = a device with a battery then
>   - it is off, but the empty = battery is being charged
>   - it is on, but fully supplied = with power from the battery.
>
> On way would be treating = the (internal) battery as separate device.
> In this case: Can we = map charging/discharging/full/empty to off-sleep-
> = on?
>
> Thanks,
>
>     = Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce = Nordman:
>
>
>       (all below as = contributor)
>
>
>
>
>     =   For many decades, electrical products were usually just on or = off
> - a 2-state power model.  In the last several decades, = we have added
> many electronic products with a 3-state model - = on, sleep, and off.
> This is necessary and existing complexity. =  Our discussions around
> power states boil down to what = complexity do we want to add to the 3-
> state model, and why the = burden is justified.
>
>
>
>
>
> =       In discussions on this email list, in I-drafts, and = in person,
> the existing listings of power states from ACPI and = DMTF are often
> referenced as good candidates for eman to adopt = in some way.  ACPI is a
> hugely important technology, and it = enables large amounts of user
> functionality and energy savings. =  I am less familiar with the reach of
> DMTF in practice, but = its depth and breadth of membership are
> compelling.  While = I agree they both deserve close examination, I think
> we can = safely drop them from our discussions of what to define as their
> = complexity is more a distraction than an = asset.
>
>
>
>
>       The = basic ACPI list is of  "Global System States" which = "apply to
> the entire system".  There are four of = these (G0-G3); G0 is on
> ("working") and G1 is sleep = ("sleeping").  G2 and G3 both forms of off
> (only = distinguished by whether a device is completely depowered and
> = whether it is safe to disassemble or not, and these distinctions = seems
> quite minor for eman purposes).  Thus, the ACPI = Global states are
> essentially on/sleep/off, the 3-state power = model.
>
>               =     ACPI lists five "Sx" sleep states (S0 is on). =  S5 is
> actually the G2 Off state (so not a sleep state at = all), and current
> implementations do not use S1 or S2, so in = practice there are only two
> ACPI sleep states: S3 and S4. =  S3 is the ordinary system sleep, with
> quick wakeup. =  S4 is the hibernate state (with system memory saved in
> = non-volatile memory, possibly a hard disk) which typically has = long
> times to return to operation (often tens of seconds). =   The 1-2 second
> wake time from S3 for modern personal = computers is compatible with many
> IP protocol usages, e.g. = initiating a TCP connection.  The tens of
> seconds time for = S4 on current systems is not.  So, the only potential
> = addition that the Sx states add to on/sleep/off is hibernate = (and
> reasonable people can differ on whether it is a fourth = basic state, a
> form of sleep, or a form of = off).
>
>
>             =       ACPI does define processor states (Cx) and = device
> states (Dx) (collectively Px), but these are the states = of particular
> components, not of the system as a whole.  It = may be useful to expose
> these through some mechanism, but they = are distinct from the power
> = state.
>
>
>
>
>       =             DMTF essentially took the ACPI = Gx states plus
> hibernate and added states that are commands = and/or transitions.  (Is
> "Master Bus Reset" a = power state?  I think not).  If we don't include
> = commands or transitions (I think we should not), then these reduce = to
> the ACPI states.
>
>
>
>
> =                   My = conclusion: ACPI and DMTF do not significantly
> change the = 3-state power model.  If we want to talk about states = beyond
> the 3-state model, it is more clear to simply reference = those
> extensions directly (e.g. how best to treat hibernate). =  Note that this
> discussion - and all others on the list - = are grounded in electronic
> devices.  Other devices = generally have a 2-state model (e.g. a light),
> or 3 states, but = on, off, and "ready" (think a microwave = oven).
>
>
>
>
>       = --Bruce
>
>
>
>
>       = --
>       Bruce Nordman
>     =   Lawrence Berkeley National Laboratory
>     =   eetd.lbl.gov/ea/nordman
>     =   BNordman@LBL.gov
>       510-486-7089
> =       m: 510-501-7943
>
>       = _______________________________________________
>     =   eman mailing list
>       eman@ietf.org
>       https://www.ietf.org/mailman/listinfo/eman
><= br>>

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

 <= /o:p>

 

------_=_NextPart_001_01CBE12F.5B77A522-- From leonard.tsai@gmail.com Sat Mar 12 19:56:25 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70BCB3A6AC4 for ; Sat, 12 Mar 2011 19:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B52RAt9k9WrP for ; Sat, 12 Mar 2011 19:56:20 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7D6D53A67FC for ; Sat, 12 Mar 2011 19:56:20 -0800 (PST) Received: by iyi12 with SMTP id 12so905049iyi.31 for ; Sat, 12 Mar 2011 19:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=KfD6L/zQPQfFSQHBMSNci1R+xHh2ADLsnNUUPzKLoUE=; b=kZXp4T1GrteJcTHw6GJZ2eMqZtgE4QWx9aVx0rzrM/ICPlkoU+cV3UDnIoL/dxvQQw GBNP3P4dFXScpIpQUh5Iyl55wTOCwm2o8fI4UvJVh/qdiGWgCNKDVBfBHd1PbNsFJrgG c7TtOZraz7fhdcT59JMQZSUuYFkWZvjBWbDX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=SGMUOv7SPuC0MFkHXjLkw6I2HoJWYmrcf6Y03RrglDSbZiHMi9uOLhu2BCdMCl8o4P l4m9s7Ukrscsy8mO8W2nbCYhtaoXLJek298hzyn8LRosw98MtpwSEVlo5x8LmsP6mtBq K3ZhCaFacUKfmWTcefRZbqjI42Wqx/l+yPdTw= Received: by 10.231.3.134 with SMTP id 6mr8648712ibn.98.1299988661877; Sat, 12 Mar 2011 19:57:41 -0800 (PST) Received: from [180.204.138.175] ([180.204.138.175]) by mx.google.com with ESMTPS id gy41sm5137714ibb.5.2011.03.12.19.57.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2011 19:57:40 -0800 (PST) References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> <68FBE0F3CE97264395875AC1C468F22CF36850@mail03.cyberswitching.local> In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CF36850@mail03.cyberswitching.local> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--441142273 Message-Id: X-Mailer: iPhone Mail (8C148) From: Leonard Tsai Date: Sun, 13 Mar 2011 11:56:39 +0800 To: Chris Verges Cc: Rolf Winter , eman mailing list , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 03:56:26 -0000 --Apple-Mail-1--441142273 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There are already 1U server with battery built in. But they also have a serv= ice processor on the side.=20 Send from iPhone 4G On 2011/3/13, at 11:33, "Chris Verges" wrote: > I assume you=E2=80=99re being rhetorical, but I=E2=80=99ll follow up anywa= y to make sure we all understand your point. What=E2=80=99s so hard to beli= eve about that? Especially given the examples shown during this discussion.= >=20 > =20 >=20 > Thanks, >=20 > Chris >=20 > =20 >=20 > From: tirth.ghose@gmail.com [mailto:tirth.ghose@gmail.com] On Behalf Of Te= d Ghose > Sent: Saturday, March 12, 2011 7:31 PM > To: Chris Verges > Cc: Rolf Winter; Bruce Nordman; eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF >=20 > =20 >=20 > servers running on batteries? really? >=20 > =20 >=20 > -tg- > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > Save time... see it my way > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. >=20 >=20 > On Fri, Mar 11, 2011 at 8:04 AM, Chris Verges w= rote: >=20 > Hi Ted, >=20 > =20 >=20 > I might be putting words into Rolf=E2=80=99s mouth, but here are my though= ts on this: >=20 > =20 >=20 > Certain devices, like servers, that contain a Lights Out Management (LOM) c= ard will be able to report the server=E2=80=99s power supply as =E2=80=9Coff= =E2=80=9D but the battery as =E2=80=9Ccharging=E2=80=9D. This combination f= or the server entity results in the desired effect. >=20 > =20 >=20 > Rolf, anywhere in the ballpark? >=20 > =20 >=20 > Chris >=20 > =20 >=20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Te= d Ghose > Sent: Friday, March 11, 2011 8:01 AM > To: Rolf Winter > Cc: Bruce Nordman; eman mailing list >=20 >=20 > Subject: Re: [eman] Power states - time to dump ACPI and DMTF >=20 > =20 >=20 > Hi Rolf, Juergen >=20 > =20 >=20 > I like Rolf's idea very much. We should extend number of states to accommo= date other sub states.=20 >=20 > =20 >=20 > Here is one question I do have for Juergon, as handling the battery keeps c= oming up in all the discussions.=20 >=20 > =20 >=20 > If the device is off, but battery is charging, who is reporting that and h= ow? Is battery itself has the intelligence to do so? In that case, can we tr= eat it as a separate device independent of the device it is connected to, an= d then we could simplify the model. >=20 > =20 >=20 > In the other case, though, if device is turned off, there is no one to tel= l what the battery is doing, unless an intelligent PDU or someone is aware o= f that device. Which comes to some source - sink model as well. >=20 > =20 >=20 > Could you please clarify your thoughts? >=20 > =20 >=20 > thanks >=20 > =20 >=20 > -tg- > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > Save time... see it my way > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. >=20 > On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter wrote= : >=20 > Hi, >=20 > just thinking out loud here. >=20 > The thing which seems to complicate matters here significantly is batterie= s. You either A) try to consider battery state in the devices' power state o= r you B) leave it separate in its own MIB module (as described e.g. here htt= p://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we have batt= ery states full(1), partiallyCharged(2), empty(3), charging(4), discharging(= 5), unknown(6)). I think these are the trade-offs: >=20 > Option A) You can always tell from the device power state whether it is dr= awing power or not ("off but charging" e.g.) and you might be able to order t= hem in a way that a higher state always translates to higher power draw. It h= owever seems to complicate power states. >=20 > Option B) If a battery is present, you cannot tell from the device's power= state whether is it drawing power or not ("off" could be really "off but ch= arging"). The device power states can be modelled cleaner though and you'd n= eed to look closer to see what the battery state is to be sure there is no p= ower draw. >=20 > Is that the trade-off we're talking about or is there anything else that n= eeds to be considered? >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London= W3 6BL | Registered in England 2832014 >=20 >=20 >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > > Juergen Quittek > > Sent: Freitag, 11. M=C3=A4rz 2011 10:37 > > To: Bruce Nordman > > Cc: eman mailing list > > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Bruce, > > > > I understand your preference for a simple off-sleep-on model for power > > states. > > How would we model a device with a battery then > > - it is off, but the empty battery is being charged > > - it is on, but fully supplied with power from the battery. > > > > On way would be treating the (internal) battery as separate device. > > In this case: Can we map charging/discharging/full/empty to off-sleep- > > on? > > > > Thanks, > > > > Juergen > > > > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > > > > (all below as contributor) > > > > > > > > > > For many decades, electrical products were usually just on or off > > - a 2-state power model. In the last several decades, we have added > > many electronic products with a 3-state model - on, sleep, and off. > > This is necessary and existing complexity. Our discussions around > > power states boil down to what complexity do we want to add to the 3- > > state model, and why the burden is justified. > > > > > > > > > > > > In discussions on this email list, in I-drafts, and in person, > > the existing listings of power states from ACPI and DMTF are often > > referenced as good candidates for eman to adopt in some way. ACPI is a > > hugely important technology, and it enables large amounts of user > > functionality and energy savings. I am less familiar with the reach of > > DMTF in practice, but its depth and breadth of membership are > > compelling. While I agree they both deserve close examination, I think > > we can safely drop them from our discussions of what to define as their > > complexity is more a distraction than an asset. > > > > > > > > > > The basic ACPI list is of "Global System States" which "apply to > > the entire system". There are four of these (G0-G3); G0 is on > > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > > (only distinguished by whether a device is completely depowered and > > whether it is safe to disassemble or not, and these distinctions seems > > quite minor for eman purposes). Thus, the ACPI Global states are > > essentially on/sleep/off, the 3-state power model. > > > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > > actually the G2 Off state (so not a sleep state at all), and current > > implementations do not use S1 or S2, so in practice there are only two > > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > > quick wakeup. S4 is the hibernate state (with system memory saved in > > non-volatile memory, possibly a hard disk) which typically has long > > times to return to operation (often tens of seconds). The 1-2 second > > wake time from S3 for modern personal computers is compatible with many > > IP protocol usages, e.g. initiating a TCP connection. The tens of > > seconds time for S4 on current systems is not. So, the only potential > > addition that the Sx states add to on/sleep/off is hibernate (and > > reasonable people can differ on whether it is a fourth basic state, a > > form of sleep, or a form of off). > > > > > > ACPI does define processor states (Cx) and device > > states (Dx) (collectively Px), but these are the states of particular > > components, not of the system as a whole. It may be useful to expose > > these through some mechanism, but they are distinct from the power > > state. > > > > > > > > > > DMTF essentially took the ACPI Gx states plus > > hibernate and added states that are commands and/or transitions. (Is > > "Master Bus Reset" a power state? I think not). If we don't include > > commands or transitions (I think we should not), then these reduce to > > the ACPI states. > > > > > > > > > > My conclusion: ACPI and DMTF do not significantly > > change the 3-state power model. If we want to talk about states beyond > > the 3-state model, it is more clear to simply reference those > > extensions directly (e.g. how best to treat hibernate). Note that this > > discussion - and all others on the list - are grounded in electronic > > devices. Other devices generally have a 2-state model (e.g. a light), > > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > > > > > > --Bruce > > > > > > > > > > -- > > Bruce Nordman > > Lawrence Berkeley National Laboratory > > eetd.lbl.gov/ea/nordman > > BNordman@LBL.gov > > 510-486-7089 > > m: 510-501-7943 > > > > _______________________________________________ > > 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 > =20 >=20 > =20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-1--441142273 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
There are already 1U server with batter= y built in. But they also have a service processor on the side. 
Send from iPhone 4G

On 2011/3/13, at 11:33, "Chris= Verges" <chrisv@cyberswitch= ing.com> wrote:

I assume you=E2=80=99re being rhetorical, but I=E2=80=99ll follow up anyway= to make sure we all understand your point.  What=E2=80=99s so hard to b= elieve about that?  Especially given the examples shown during this dis= cussion.

 

Thanks,

Chris

 

From:<= /span> tirth.ghose@g= mail.com [mailto:tirth.ghose@gmail.com] On Behalf Of Ted GhoseSent: Saturday, March 12, 2011 7:31 PM
To: Chris VergesCc: Rolf Winter; Bruce Nordman; eman mailing list
Subject:= Re: [eman] Power states - time to dump ACPI and DMTF

<= p class=3D"MsoNormal"> 

servers ru= nning on batteries? really?

&= nbsp;

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,= _:-.,_,.-:**:-.,_,.
              &nbs= p;      Save time... see it my way
*:-.,_,.-:*'``'*:-.,_,.= -:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.

On Fri, Mar 11, 2011 at 8:04 AM, Chris Verges <chrisv@cyberswitching.com> wrote:

Hi Ted,=

 

I mi= ght be putting words into Rolf=E2=80=99s mouth, but here are my thoughts on t= his:

 

Certain devices, like servers, that contain a Lights Out Managem= ent (LOM) card will be able to report the server=E2=80=99s power supply as =E2= =80=9Coff=E2=80=9D but the battery as =E2=80=9Ccharging=E2=80=9D.  This= combination for the server entity results in the desired effect.

 

Rol= f, anywhere in the ballpark?

 

Chris

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Ted= Ghose
Sent: Friday, March 11, 2011 8:01 AM
To: Rolf Win= ter
Cc: Bruce Nordman; eman mailing list


Subject: Re: [eman] Power states - t= ime to dump ACPI and DMTF

 =

Hi Rolf, Juergen

 

I like Rolf's idea very much. We should exten= d number of states to accommodate other sub states. 

 

Here is one= question I do have for Juergon, as handling the battery keeps coming up in a= ll the discussions. 

 =

If the device is off, but battery is charging, who is= reporting that and how? Is battery itself has the intelligence to do s= o? In that case, can we treat it as a separate device indepen= dent of the device it is connected to, and then we could simplify the model.=

 

In t= he other case, though, if device is turned off, there is no one to tell what= the battery is doing, unless an intelligent PDU or someone is awa= re of that device. Which comes to some source - sink model as well.

 

Could you p= lease clarify your thoughts?

 

thanks

 

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'= *:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.
         = ;            Save time... see it my way
*:-= .,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.

On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter <Rolf.Winter@neclab.eu> wrote:

Hi,

just thinking out loud here.

The thing which seems to com= plicate matters here significantly is batteries. You either A) try to consid= er battery state in the devices' power state or you B) leave it separate in i= ts own MIB module (as described e.g. here http://tools.ietf.org/= html/draft-quittek-eman-battery-mib-00 where we have battery states f= ull(1), partiallyCharged(2), empty(3), charging(4), discharging(5), unknown(= 6)). I think these are the trade-offs:

Option A) You can always tell f= rom the device power state whether it is drawing power or not ("off but char= ging" e.g.) and you might be able to order them in a way that a higher state= always translates to higher power draw. It however seems to complicate powe= r states.

Option B) If a battery is present, you cannot tell from the= device's power state whether is it drawing power or not ("off" could be rea= lly "off but charging"). The device power states can be modelled cleaner tho= ugh and you'd need to look closer to see what the battery state is to be sur= e there is no power draw.

Is that the trade-off we're talking about o= r is there anything else that needs to be considered?

Best,

Ro= lf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road= , London W3 6BL | Registered in England 2832014



> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bou= nces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Fre= itag, 11. M=C3=A4rz 2011 10:37
> To: Bruce Nordman
> Cc: eman ma= iling list
> Subject: Re: [eman] Power states - time to dump ACPI and D= MTF
>
> Hi Bruce,
>
> I understand your preference f= or a simple off-sleep-on model for power
> states.
> How would w= e model a device with a battery then
>   - it is off, but the emp= ty battery is being charged
>   - it is on, but fully supplied wi= th power from the battery.
>
> On way would be treating the (int= ernal) battery as separate device.
> In this case: Can we map charging= /discharging/full/empty to off-sleep-
> on?
>
> Thanks,>
>     Juergen
>
>
> Am 11.03.2011 um= 07:37 schrieb Bruce Nordman:
>
>
>       (= all below as contributor)
>
>
>
>
>   &nb= sp;   For many decades, electrical products were usually just on or off=
> - a 2-state power model.  In the last several decades, we have= added
> many electronic products with a 3-state model - on, sleep, an= d off.
> This is necessary and existing complexity.  Our discussi= ons around
> power states boil down to what complexity do we want to a= dd to the 3-
> state model, and why the burden is justified.
>>
>
>
>
>       In discussions o= n this email list, in I-drafts, and in person,
> the existing listings= of power states from ACPI and DMTF are often
> referenced as good can= didates for eman to adopt in some way.  ACPI is a
> hugely import= ant technology, and it enables large amounts of user
> functionality a= nd energy savings.  I am less familiar with the reach of
> DMTF i= n practice, but its depth and breadth of membership are
> compelling. &= nbsp;While I agree they both deserve close examination, I think
> we c= an safely drop them from our discussions of what to define as their
> c= omplexity is more a distraction than an asset.
>
>
>
&g= t;
>       The basic ACPI list is of  "Global Syst= em States" which "apply to
> the entire system".  There are four o= f these (G0-G3); G0 is on
> ("working") and G1 is sleep ("sleeping"). &= nbsp;G2 and G3 both forms of off
> (only distinguished by whether a de= vice is completely depowered and
> whether it is safe to disassemble o= r not, and these distinctions seems
> quite minor for eman purposes). &= nbsp;Thus, the ACPI Global states are
> essentially on/sleep/off, the 3= -state power model.
>
>            = ;       ACPI lists five "Sx" sleep states (S0 is on).  S= 5 is
> actually the G2 Off state (so not a sleep state at all), and cu= rrent
> implementations do not use S1 or S2, so in practice there are o= nly two
> ACPI sleep states: S3 and S4.  S3 is the ordinary syste= m sleep, with
> quick wakeup.  S4 is the hibernate state (with sy= stem memory saved in
> non-volatile memory, possibly a hard disk) whic= h typically has long
> times to return to operation (often tens of sec= onds).   The 1-2 second
> wake time from S3 for modern personal c= omputers is compatible with many
> IP protocol usages, e.g. initiating= a TCP connection.  The tens of
> seconds time for S4 on current s= ystems is not.  So, the only potential
> addition that the Sx sta= tes add to on/sleep/off is hibernate (and
> reasonable people can diff= er on whether it is a fourth basic state, a
> form of sleep, or a form= of off).
>
>
>             &= nbsp;     ACPI does define processor states (Cx) and device
>= ; states (Dx) (collectively Px), but these are the states of particular
&= gt; components, not of the system as a whole.  It may be useful to expo= se
> these through some mechanism, but they are distinct from the powe= r
> state.
>
>
>
>
>      = ;             DMTF essentially took the ACPI G= x states plus
> hibernate and added states that are commands and/or tr= ansitions.  (Is
> "Master Bus Reset" a power state?  I think= not).  If we don't include
> commands or transitions (I think we= should not), then these reduce to
> the ACPI states.
>
><= br>>
>
>               &nb= sp;   My conclusion: ACPI and DMTF do not significantly
> change t= he 3-state power model.  If we want to talk about states beyond
>= the 3-state model, it is more clear to simply reference those
> exten= sions directly (e.g. how best to treat hibernate).  Note that this
&= gt; discussion - and all others on the list - are grounded in electronic
= > devices.  Other devices generally have a 2-state model (e.g. a lig= ht),
> or 3 states, but on, off, and "ready" (think a microwave oven).=
>
>
>
>
>       --Bruce
>= ;
>
>
>
>       --
>   &nb= sp;   Bruce Nordman
>       Lawrence Berkeley Nati= onal Laboratory
>       eet= d.lbl.gov/ea/nordman
>       BNor= dman@LBL.gov
>       510-486-7089
>       m: 510-501-7943
>
> &n= bsp;     _______________________________________________
> &= nbsp;     eman mailing list
>       em= an@ietf.org
>       https://www.ietf.org/mailman/listinfo/eman<= br>>
>

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

 

=

 

________________= _______________________________
eman mailing list
= eman@ietf.org
https://www.ietf.org/mail= man/listinfo/eman
= --Apple-Mail-1--441142273-- From Internet-Drafts@ietf.org Sun Mar 13 03:00:02 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7A33A6955; Sun, 13 Mar 2011 03:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nlz-rVFTe2YJ; Sun, 13 Mar 2011 03:00:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED063A68BF; Sun, 13 Mar 2011 03:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110313100001.3664.52791.idtracker@localhost> Date: Sun, 13 Mar 2011 03:00:01 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action:draft-ietf-eman-energy-aware-mib-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 10:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Energy-aware Networks and Devices MIB Author(s) : B. Claise, J. Parello Filename : draft-ietf-eman-energy-aware-mib-01.txt Pages : 27 Date : 2011-03-13 This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. The module addresses devices identification, context information, and the relationship between reporting devices, remote devices, and monitoring probes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-energy-aware-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eman-energy-aware-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-13014946.I-D@ietf.org> --NextPart-- From Rolf.Winter@neclab.eu Sun Mar 13 06:33:38 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF763A68CB for ; Sun, 13 Mar 2011 06:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZDZAWuQZARO for ; Sun, 13 Mar 2011 06:33:36 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id ED3643A681A for ; Sun, 13 Mar 2011 06:33:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3210D2C000205; Sun, 13 Mar 2011 14:36:43 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnnfNl0SX1G5; Sun, 13 Mar 2011 14:36:43 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 082C72C000204; Sun, 13 Mar 2011 14:36:23 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Sun, 13 Mar 2011 14:34:37 +0100 From: Rolf Winter To: Chris Verges , Ted Ghose Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AQHL37bMc1CHhWwxDEKYxTzj/hbcCgAAEYewlCtB3uA= Date: Sun, 13 Mar 2011 13:34:36 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd> References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.200] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 13:33:38 -0000 Chris, Ted, I wasn't really implying anything here. To me, it seemed that a lot of the = discussion was triggered by the fact that it is difficult to accommodate ba= tteries directly in a device's power state. So I was wondering why one woul= d actually do that (instead of treating it as a completely different entity= ). My mail tried to summarize the differences and I was asking whether ther= e is more. I believe this is something we want to figure out quickly as a b= unch of things will rely on this decision. But it might be that a simple mo= del would work here. E.g. you'd have the state sleep (which means e.g. that= the functional components draw little power) and a sub-state that says bat= teries charging (or not, or which "type" of charging) which tells you that = the device as a whole is drawing significant power. The same for on and off= states of course. Or you can have all separate in a battery MIB. In either= case, I think other battery related information should be in a separate MI= B. E.g. whether a battery is fully charged, empty, it's age, number of char= ging cycles and so forth. So which one should it be, which of the tradeoffs= is most important to us? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Chris Verges [mailto:chrisv@cyberswitching.com] > Sent: Freitag, 11. M=E4rz 2011 17:04 > To: Ted Ghose; Rolf Winter > Cc: Bruce Nordman; eman mailing list > Subject: RE: [eman] Power states - time to dump ACPI and DMTF >=20 > Hi Ted, >=20 >=20 >=20 > I might be putting words into Rolf's mouth, but here are my thoughts on > this: >=20 >=20 >=20 > Certain devices, like servers, that contain a Lights Out Management > (LOM) card will be able to report the server's power supply as "off" > but the battery as "charging". This combination for the server entity > results in the desired effect. >=20 >=20 >=20 > Rolf, anywhere in the ballpark? >=20 >=20 >=20 > Chris >=20 >=20 >=20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Ted Ghose > Sent: Friday, March 11, 2011 8:01 AM > To: Rolf Winter > Cc: Bruce Nordman; eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF >=20 >=20 >=20 > Hi Rolf, Juergen >=20 >=20 >=20 > I like Rolf's idea very much. We should extend number of states to > accommodate other sub states. >=20 >=20 >=20 > Here is one question I do have for Juergon, as handling the battery > keeps coming up in all the discussions. >=20 >=20 >=20 > If the device is off, but battery is charging, who is reporting that > and how? Is battery itself has the intelligence to do so? In that case, > can we treat it as a separate device independent of the device it is > connected to, and then we could simplify the model. >=20 >=20 >=20 > In the other case, though, if device is turned off, there is no one to > tell what the battery is doing, unless an intelligent PDU or someone is > aware of that device. Which comes to some source - sink model as well. >=20 >=20 >=20 > Could you please clarify your thoughts? >=20 >=20 >=20 > thanks >=20 >=20 >=20 > -tg- > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > Save time... see it my way > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. >=20 >=20 >=20 > On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter > wrote: >=20 > Hi, >=20 > just thinking out loud here. >=20 > The thing which seems to complicate matters here significantly is > batteries. You either A) try to consider battery state in the devices' > power state or you B) leave it separate in its own MIB module (as > described e.g. here http://tools.ietf.org/html/draft-quittek-eman- > battery-mib-00 where we have battery states full(1), > partiallyCharged(2), empty(3), charging(4), discharging(5), unknown(6)). > I think these are the trade-offs: >=20 > Option A) You can always tell from the device power state whether it is > drawing power or not ("off but charging" e.g.) and you might be able to > order them in a way that a higher state always translates to higher > power draw. It however seems to complicate power states. >=20 > Option B) If a battery is present, you cannot tell from the device's > power state whether is it drawing power or not ("off" could be really > "off but charging"). The device power states can be modelled cleaner > though and you'd need to look closer to see what the battery state is > to be sure there is no power draw. >=20 > Is that the trade-off we're talking about or is there anything else > that needs to be considered? >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of > > Juergen Quittek > > Sent: Freitag, 11. M=E4rz 2011 10:37 > > To: Bruce Nordman > > Cc: eman mailing list > > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Bruce, > > > > I understand your preference for a simple off-sleep-on model for > power > > states. > > How would we model a device with a battery then > > - it is off, but the empty battery is being charged > > - it is on, but fully supplied with power from the battery. > > > > On way would be treating the (internal) battery as separate device. > > In this case: Can we map charging/discharging/full/empty to off- > sleep- > > on? > > > > Thanks, > > > > Juergen > > > > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > > > > (all below as contributor) > > > > > > > > > > For many decades, electrical products were usually just on or > off > > - a 2-state power model. In the last several decades, we have added > > many electronic products with a 3-state model - on, sleep, and off. > > This is necessary and existing complexity. Our discussions around > > power states boil down to what complexity do we want to add to the 3- > > state model, and why the burden is justified. > > > > > > > > > > > > In discussions on this email list, in I-drafts, and in person, > > the existing listings of power states from ACPI and DMTF are often > > referenced as good candidates for eman to adopt in some way. ACPI is > a > > hugely important technology, and it enables large amounts of user > > functionality and energy savings. I am less familiar with the reach > of > > DMTF in practice, but its depth and breadth of membership are > > compelling. While I agree they both deserve close examination, I > think > > we can safely drop them from our discussions of what to define as > their > > complexity is more a distraction than an asset. > > > > > > > > > > The basic ACPI list is of "Global System States" which "apply > to > > the entire system". There are four of these (G0-G3); G0 is on > > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of > off > > (only distinguished by whether a device is completely depowered and > > whether it is safe to disassemble or not, and these distinctions > seems > > quite minor for eman purposes). Thus, the ACPI Global states are > > essentially on/sleep/off, the 3-state power model. > > > > ACPI lists five "Sx" sleep states (S0 is on). S5 > is > > actually the G2 Off state (so not a sleep state at all), and current > > implementations do not use S1 or S2, so in practice there are only > two > > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > > quick wakeup. S4 is the hibernate state (with system memory saved in > > non-volatile memory, possibly a hard disk) which typically has long > > times to return to operation (often tens of seconds). The 1-2 > second > > wake time from S3 for modern personal computers is compatible with > many > > IP protocol usages, e.g. initiating a TCP connection. The tens of > > seconds time for S4 on current systems is not. So, the only > potential > > addition that the Sx states add to on/sleep/off is hibernate (and > > reasonable people can differ on whether it is a fourth basic state, a > > form of sleep, or a form of off). > > > > > > ACPI does define processor states (Cx) and device > > states (Dx) (collectively Px), but these are the states of particular > > components, not of the system as a whole. It may be useful to expose > > these through some mechanism, but they are distinct from the power > > state. > > > > > > > > > > DMTF essentially took the ACPI Gx states plus > > hibernate and added states that are commands and/or transitions. (Is > > "Master Bus Reset" a power state? I think not). If we don't include > > commands or transitions (I think we should not), then these reduce to > > the ACPI states. > > > > > > > > > > My conclusion: ACPI and DMTF do not significantly > > change the 3-state power model. If we want to talk about states > beyond > > the 3-state model, it is more clear to simply reference those > > extensions directly (e.g. how best to treat hibernate). Note that > this > > discussion - and all others on the list - are grounded in electronic > > devices. Other devices generally have a 2-state model (e.g. a light), > > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > > > > > > --Bruce > > > > > > > > > > -- > > Bruce Nordman > > Lawrence Berkeley National Laboratory > > eetd.lbl.gov/ea/nordman > > BNordman@LBL.gov > > 510-486-7089 > > m: 510-501-7943 > > > > _______________________________________________ > > 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 >=20 From ietf@quittek.at Sun Mar 13 13:05:23 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C403A6B8B for ; Sun, 13 Mar 2011 13:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQmHC-Jf53WQ for ; Sun, 13 Mar 2011 13:05:22 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id C637B3A6B88 for ; Sun, 13 Mar 2011 13:05:21 -0700 (PDT) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MP2NL-1Pteki1DrL-005mke; Sun, 13 Mar 2011 21:06:28 +0100 References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> <791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <0851C4CF-D108-4BE9-AB17-A24F05FB72D4@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Sun, 13 Mar 2011 21:06:25 +0100 To: Rolf Winter X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:rOomrbOkUS2uU1yExQzIXak+DbJG2RwPQpqpe3Y89Bo bHJ+0xpvlCy9WtUSWBN4BZ9TxQcigxe4rDrfg7vl7dGGY+SjvX VtZ/UB7yi1e7O0hQSEWD/DO+fY/UAfhuvpqW/hRfEvN2q5abD1 qpBcwRFWlFe39uB5T1yLaQFnzQsBUkfuvLmth8DUlwSNODu+7r QDDQV9M/q+X3cFpbF8Bkg== Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 20:05:23 -0000 Hi Rolf, One of the important questions to be answered is: Do we want to be able to make assumptions on a device's energy = consumption based on the power state? If a devices's power state is off, what would it tell us, if not: The = devices does not need any power. If this is not the case, we are rather talking about functional states = with some power-related properties, But if these states do not serve as basis for power-related assumptions = on the device, then the name POWER state is misleading and not appropriate any more. Thanks, Juergen Am 13.03.2011 um 14:34 schrieb Rolf Winter: > Chris, Ted, >=20 > I wasn't really implying anything here. To me, it seemed that a lot of = the discussion was triggered by the fact that it is difficult to = accommodate batteries directly in a device's power state. So I was = wondering why one would actually do that (instead of treating it as a = completely different entity). My mail tried to summarize the differences = and I was asking whether there is more. I believe this is something we = want to figure out quickly as a bunch of things will rely on this = decision. But it might be that a simple model would work here. E.g. = you'd have the state sleep (which means e.g. that the functional = components draw little power) and a sub-state that says batteries = charging (or not, or which "type" of charging) which tells you that the = device as a whole is drawing significant power. The same for on and off = states of course. Or you can have all separate in a battery MIB. In = either case, I think other battery related information should be in a = separate MIB. E.g. whether a battery is fully charged, empty, it's age, = number of charging cycles and so forth. So which one should it be, which = of the tradeoffs is most important to us? >=20 >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 >=20 >=20 >> -----Original Message----- >> From: Chris Verges [mailto:chrisv@cyberswitching.com] >> Sent: Freitag, 11. M=E4rz 2011 17:04 >> To: Ted Ghose; Rolf Winter >> Cc: Bruce Nordman; eman mailing list >> Subject: RE: [eman] Power states - time to dump ACPI and DMTF >>=20 >> Hi Ted, >>=20 >>=20 >>=20 >> I might be putting words into Rolf's mouth, but here are my thoughts = on >> this: >>=20 >>=20 >>=20 >> Certain devices, like servers, that contain a Lights Out Management >> (LOM) card will be able to report the server's power supply as "off" >> but the battery as "charging". This combination for the server = entity >> results in the desired effect. >>=20 >>=20 >>=20 >> Rolf, anywhere in the ballpark? >>=20 >>=20 >>=20 >> Chris >>=20 >>=20 >>=20 >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of >> Ted Ghose >> Sent: Friday, March 11, 2011 8:01 AM >> To: Rolf Winter >> Cc: Bruce Nordman; eman mailing list >> Subject: Re: [eman] Power states - time to dump ACPI and DMTF >>=20 >>=20 >>=20 >> Hi Rolf, Juergen >>=20 >>=20 >>=20 >> I like Rolf's idea very much. We should extend number of states to >> accommodate other sub states. >>=20 >>=20 >>=20 >> Here is one question I do have for Juergon, as handling the battery >> keeps coming up in all the discussions. >>=20 >>=20 >>=20 >> If the device is off, but battery is charging, who is reporting that >> and how? Is battery itself has the intelligence to do so? In that = case, >> can we treat it as a separate device independent of the device it is >> connected to, and then we could simplify the model. >>=20 >>=20 >>=20 >> In the other case, though, if device is turned off, there is no one = to >> tell what the battery is doing, unless an intelligent PDU or someone = is >> aware of that device. Which comes to some source - sink model as = well. >>=20 >>=20 >>=20 >> Could you please clarify your thoughts? >>=20 >>=20 >>=20 >> thanks >>=20 >>=20 >>=20 >> -tg- >> *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. >> Save time... see it my way >> *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. >>=20 >>=20 >>=20 >> On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter >> wrote: >>=20 >> Hi, >>=20 >> just thinking out loud here. >>=20 >> The thing which seems to complicate matters here significantly is >> batteries. You either A) try to consider battery state in the = devices' >> power state or you B) leave it separate in its own MIB module (as >> described e.g. here http://tools.ietf.org/html/draft-quittek-eman- >> battery-mib-00 where we have battery states full(1), >> partiallyCharged(2), empty(3), charging(4), discharging(5), = unknown(6)). >> I think these are the trade-offs: >>=20 >> Option A) You can always tell from the device power state whether it = is >> drawing power or not ("off but charging" e.g.) and you might be able = to >> order them in a way that a higher state always translates to higher >> power draw. It however seems to complicate power states. >>=20 >> Option B) If a battery is present, you cannot tell from the device's >> power state whether is it drawing power or not ("off" could be really >> "off but charging"). The device power states can be modelled cleaner >> though and you'd need to look closer to see what the battery state is >> to be sure there is no power draw. >>=20 >> Is that the trade-off we're talking about or is there anything else >> that needs to be considered? >>=20 >> Best, >>=20 >> Rolf >>=20 >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> London W3 6BL | Registered in England 2832014 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf >> Of >>> Juergen Quittek >>> Sent: Freitag, 11. M=E4rz 2011 10:37 >>> To: Bruce Nordman >>> Cc: eman mailing list >>> Subject: Re: [eman] Power states - time to dump ACPI and DMTF >>>=20 >>> Hi Bruce, >>>=20 >>> I understand your preference for a simple off-sleep-on model for >> power >>> states. >>> How would we model a device with a battery then >>> - it is off, but the empty battery is being charged >>> - it is on, but fully supplied with power from the battery. >>>=20 >>> On way would be treating the (internal) battery as separate device. >>> In this case: Can we map charging/discharging/full/empty to off- >> sleep- >>> on? >>>=20 >>> Thanks, >>>=20 >>> Juergen >>>=20 >>>=20 >>> Am 11.03.2011 um 07:37 schrieb Bruce Nordman: >>>=20 >>>=20 >>> (all below as contributor) >>>=20 >>>=20 >>>=20 >>>=20 >>> For many decades, electrical products were usually just on or >> off >>> - a 2-state power model. In the last several decades, we have added >>> many electronic products with a 3-state model - on, sleep, and off. >>> This is necessary and existing complexity. Our discussions around >>> power states boil down to what complexity do we want to add to the = 3- >>> state model, and why the burden is justified. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> In discussions on this email list, in I-drafts, and in person, >>> the existing listings of power states from ACPI and DMTF are often >>> referenced as good candidates for eman to adopt in some way. ACPI = is >> a >>> hugely important technology, and it enables large amounts of user >>> functionality and energy savings. I am less familiar with the reach >> of >>> DMTF in practice, but its depth and breadth of membership are >>> compelling. While I agree they both deserve close examination, I >> think >>> we can safely drop them from our discussions of what to define as >> their >>> complexity is more a distraction than an asset. >>>=20 >>>=20 >>>=20 >>>=20 >>> The basic ACPI list is of "Global System States" which "apply >> to >>> the entire system". There are four of these (G0-G3); G0 is on >>> ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of >> off >>> (only distinguished by whether a device is completely depowered and >>> whether it is safe to disassemble or not, and these distinctions >> seems >>> quite minor for eman purposes). Thus, the ACPI Global states are >>> essentially on/sleep/off, the 3-state power model. >>>=20 >>> ACPI lists five "Sx" sleep states (S0 is on). S5 >> is >>> actually the G2 Off state (so not a sleep state at all), and current >>> implementations do not use S1 or S2, so in practice there are only >> two >>> ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with >>> quick wakeup. S4 is the hibernate state (with system memory saved = in >>> non-volatile memory, possibly a hard disk) which typically has long >>> times to return to operation (often tens of seconds). The 1-2 >> second >>> wake time from S3 for modern personal computers is compatible with >> many >>> IP protocol usages, e.g. initiating a TCP connection. The tens of >>> seconds time for S4 on current systems is not. So, the only >> potential >>> addition that the Sx states add to on/sleep/off is hibernate (and >>> reasonable people can differ on whether it is a fourth basic state, = a >>> form of sleep, or a form of off). >>>=20 >>>=20 >>> ACPI does define processor states (Cx) and device >>> states (Dx) (collectively Px), but these are the states of = particular >>> components, not of the system as a whole. It may be useful to = expose >>> these through some mechanism, but they are distinct from the power >>> state. >>>=20 >>>=20 >>>=20 >>>=20 >>> DMTF essentially took the ACPI Gx states plus >>> hibernate and added states that are commands and/or transitions. = (Is >>> "Master Bus Reset" a power state? I think not). If we don't = include >>> commands or transitions (I think we should not), then these reduce = to >>> the ACPI states. >>>=20 >>>=20 >>>=20 >>>=20 >>> My conclusion: ACPI and DMTF do not significantly >>> change the 3-state power model. If we want to talk about states >> beyond >>> the 3-state model, it is more clear to simply reference those >>> extensions directly (e.g. how best to treat hibernate). Note that >> this >>> discussion - and all others on the list - are grounded in electronic >>> devices. Other devices generally have a 2-state model (e.g. a = light), >>> or 3 states, but on, off, and "ready" (think a microwave oven). >>>=20 >>>=20 >>>=20 >>>=20 >>> --Bruce >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Bruce Nordman >>> Lawrence Berkeley National Laboratory >>> eetd.lbl.gov/ea/nordman >>> 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 >>>=20 >>=20 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >>=20 >>=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bnordman@lbl.gov Sun Mar 13 14:19:18 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158213A6BC5 for ; Sun, 13 Mar 2011 14:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq2w1xeXvsIp for ; Sun, 13 Mar 2011 14:19:16 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by core3.amsl.com (Postfix) with ESMTP id 8FBB33A65A6 for ; Sun, 13 Mar 2011 14:19:16 -0700 (PDT) X-Ironport-SBRS: 5.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoAAFbSfE3RVdy0mGdsb2JhbACCXJwzAYZ+CBQBAQEBAQgJDQcUJaZSmUiCfBmCTQSFK4cniHc6 X-IronPort-AV: E=Sophos;i="4.62,312,1297065600"; d="scan'208";a="36239251" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 13 Mar 2011 14:20:18 -0700 Received: by vxk12 with SMTP id 12so1004014vxk.39 for ; Sun, 13 Mar 2011 14:20:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.231 with SMTP id cl7mr3094109vdc.45.1300051217406; Sun, 13 Mar 2011 14:20:17 -0700 (PDT) Received: by 10.52.155.40 with HTTP; Sun, 13 Mar 2011 14:20:17 -0700 (PDT) In-Reply-To: <0851C4CF-D108-4BE9-AB17-A24F05FB72D4@quittek.at> References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> <791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd> <0851C4CF-D108-4BE9-AB17-A24F05FB72D4@quittek.at> Date: Sun, 13 Mar 2011 14:20:17 -0700 Message-ID: From: Bruce Nordman To: Juergen Quittek Content-Type: multipart/alternative; boundary=bcaec5015d3100d9d8049e63c324 Cc: eman mailing list , Rolf Winter Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 21:19:18 -0000 --bcaec5015d3100d9d8049e63c324 Content-Type: text/plain; charset=ISO-8859-1 I think we are making this more complicated than necessary. First, our mandate is for monitoring, not control. We should be thinking about control (as we are), but should not complicate the monitoring protocol for control reasons. I know that eman will in future be used by some devices for control (and I support their ability to do so in future), but the great majority I believe will only use its monitoring features. Second, the NMS will know the identity of the device being monitored, so can use that information in drawing conclusions. The power state does not need to be burdened with trying to be highly informative by itself. The device HAS a basic power state already - we are just trying to expose that which already exists. When devices have the ability and need to be more elaborate in what they communicate (e.g. exposing battery details), we can facilitate that, but for those that can't or don't need this, we should allow them to be simple. Batteries are not involved in the vast majority of electricity use, and the NMS will know if the device does (or could) have one and so can draw appropriate conclusions. To Juergen's question, the assumptions that can be made about a device's energy based solely on the power state depends on the device. We don't need to say more. --Bruce On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek wrote: > Hi Rolf, > > One of the important questions to be answered is: > Do we want to be able to make assumptions on a device's energy consumption > based on the power state? > If a devices's power state is off, what would it tell us, if not: The > devices does not need any power. > > If this is not the case, we are rather talking about functional states with > some power-related properties, > But if these states do not serve as basis for power-related assumptions on > the device, then the name > POWER state is misleading and not appropriate any more. > > Thanks, > > Juergen > > > Am 13.03.2011 um 14:34 schrieb Rolf Winter: > > > Chris, Ted, > > > > I wasn't really implying anything here. To me, it seemed that a lot of > the discussion was triggered by the fact that it is difficult to accommodate > batteries directly in a device's power state. So I was wondering why one > would actually do that (instead of treating it as a completely different > entity). My mail tried to summarize the differences and I was asking whether > there is more. I believe this is something we want to figure out quickly as > a bunch of things will rely on this decision. But it might be that a simple > model would work here. E.g. you'd have the state sleep (which means e.g. > that the functional components draw little power) and a sub-state that says > batteries charging (or not, or which "type" of charging) which tells you > that the device as a whole is drawing significant power. The same for on and > off states of course. Or you can have all separate in a battery MIB. In > either case, I think other battery related information should be in a > separate MIB. E.g. whether a battery is fully charged, empty, it's age, > number of charging cycles and so forth. So which one should it be, which of > the tradeoffs is most important to us? > > > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > ... > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec5015d3100d9d8049e63c324 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we are making this more complicated than necessary.
First, our m= andate is for monitoring, not control.=A0 We should be
thinking about co= ntrol (as we are), but should not complicate
the monitoring protocol for= control reasons.=A0 I know that eman
will in future be used by some devices for control (and I support
their = ability to do so in future), but the great majority I believe will
only= use its monitoring features.

Second, the NMS will know the identity= of the device being
monitored, so can use that information in drawing conclusions.
The power= state does not need to be burdened with trying to
be highly informative= by itself.=A0 The device HAS a basic power
state already - we are just = trying to expose that which already
exists.

When devices have the ability and need to be more elaborate<= br>in what they communicate (e.g. exposing battery details), we
can faci= litate that, but for those that can't or don't need this,
we sho= uld allow them to be simple.

Batteries are not involved in the vast majority of electricity
use, = and the NMS will know if the device does (or could)
have one and so can = draw appropriate conclusions.

To Juergen's question, the assumpt= ions that can be made
about a device's energy based solely on the power state
depends on t= he device.=A0 We don't need to say more.

--Bruce


On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek <ietf@quittek.at&g= t; wrote:
Hi Rolf,

One of the important questions to be answered is:
Do we want to be able to make assumptions on a device's energy consumpt= ion based on the power state?
If a devices's power state is off, what would it tell us, if not: The d= evices does not need any power.

If this is not the case, we are rather talking about functional states with= some power-related properties,
But if these states do not serve as basis for power-related assumptions on = the device, then the name
POWER state is misleading and not appropriate any more.

Thanks,

=A0 =A0Juergen


Am 13.03.2011 um 14:34 schrieb Rolf Winter:

> Chris, Ted,
>
> I wasn't really implying anything here. To me, it seemed that a lo= t of the discussion was triggered by the fact that it is difficult to accom= modate batteries directly in a device's power state. So I was wondering= why one would actually do that (instead of treating it as a completely dif= ferent entity). My mail tried to summarize the differences and I was asking= whether there is more. I believe this is something we want to figure out q= uickly as a bunch of things will rely on this decision. But it might be tha= t a simple model would work here. E.g. you'd have the state sleep (whic= h means e.g. that the functional components draw little power) and a sub-st= ate that says batteries charging (or not, or which "type" of char= ging) which tells you that the device as a whole is drawing significant pow= er. The same for on and off states of course. Or you can have all separate = in a battery MIB. In either case, I think other battery related information= should be in a separate MIB. E.g. whether a battery is fully charged, empt= y, it's age, number of charging cycles and so forth. So which one shoul= d it be, which of the tradeoffs is most important to us?
>
>
> Best,
>
> Rolf
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lo= ndon W3 6BL | Registered in England 2832014
...




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

--bcaec5015d3100d9d8049e63c324-- From ietf@quittek.at Sun Mar 13 15:10:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B573A6BE4 for ; Sun, 13 Mar 2011 15:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN795rb8rZD1 for ; Sun, 13 Mar 2011 15:10:21 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 0F08F3A6BE3 for ; Sun, 13 Mar 2011 15:10:20 -0700 (PDT) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M852L-1QBu7G2r8T-00w3wr; Sun, 13 Mar 2011 23:11:40 +0100 References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> <791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd> <0851C4CF-D108-4BE9-AB17-A24F05FB72D4@quittek.at> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-19--375444760 Message-Id: From: Juergen Quittek Date: Sun, 13 Mar 2011 23:11:42 +0100 To: Bruce Nordman X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:1ZABHwvhV4So+Y8x5Dctx8NEzE/DL3R13e3ea2jZPwL t5hRq5R2EqMDUJIClNA11jrYVYY5oemMC099rRgMPAE0NWaTFN C8q8CtVNqpaz4LmTDbtu0ZZhoxKHbaLzuWDpIB3oJ9Z5+GHCI6 rZDx1b9bTaWiM9HjarXBLzqpWxGo3Wc/tsPSSf+1toL6chS/Ni /pgKErtkjRDyCPyl+SZTg== Cc: eman mailing list , Rolf Winter Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 22:10:22 -0000 --Apple-Mail-19--375444760 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bruce, I still have the basic question:=20 What is the purpose of defining power states? What do we need them for in addition to functional device states? We should have a clear answer in the eman WG. Thanks, Juergen Am 13.03.2011 um 22:20 schrieb Bruce Nordman: > I think we are making this more complicated than necessary. > First, our mandate is for monitoring, not control. We should be > thinking about control (as we are), but should not complicate > the monitoring protocol for control reasons. I know that eman > will in future be used by some devices for control (and I support > their ability to do so in future), but the great majority I believe = will=20 > only use its monitoring features. >=20 > Second, the NMS will know the identity of the device being > monitored, so can use that information in drawing conclusions. > The power state does not need to be burdened with trying to > be highly informative by itself. The device HAS a basic power > state already - we are just trying to expose that which already > exists. >=20 > When devices have the ability and need to be more elaborate > in what they communicate (e.g. exposing battery details), we > can facilitate that, but for those that can't or don't need this, > we should allow them to be simple. >=20 > Batteries are not involved in the vast majority of electricity > use, and the NMS will know if the device does (or could) > have one and so can draw appropriate conclusions. >=20 > To Juergen's question, the assumptions that can be made > about a device's energy based solely on the power state > depends on the device. We don't need to say more. >=20 > --Bruce >=20 >=20 > On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek = wrote: > Hi Rolf, >=20 > One of the important questions to be answered is: > Do we want to be able to make assumptions on a device's energy = consumption based on the power state? > If a devices's power state is off, what would it tell us, if not: The = devices does not need any power. >=20 > If this is not the case, we are rather talking about functional states = with some power-related properties, > But if these states do not serve as basis for power-related = assumptions on the device, then the name > POWER state is misleading and not appropriate any more. >=20 > Thanks, >=20 > Juergen >=20 >=20 > Am 13.03.2011 um 14:34 schrieb Rolf Winter: >=20 > > Chris, Ted, > > > > I wasn't really implying anything here. To me, it seemed that a lot = of the discussion was triggered by the fact that it is difficult to = accommodate batteries directly in a device's power state. So I was = wondering why one would actually do that (instead of treating it as a = completely different entity). My mail tried to summarize the differences = and I was asking whether there is more. I believe this is something we = want to figure out quickly as a bunch of things will rely on this = decision. But it might be that a simple model would work here. E.g. = you'd have the state sleep (which means e.g. that the functional = components draw little power) and a sub-state that says batteries = charging (or not, or which "type" of charging) which tells you that the = device as a whole is drawing significant power. The same for on and off = states of course. Or you can have all separate in a battery MIB. In = either case, I think other battery related information should be in a = separate MIB. E.g. whether a battery is fully charged, empty, it's age, = number of charging cycles and so forth. So which one should it be, which = of the tradeoffs is most important to us? > > > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > ... >=20 >=20 >=20 >=20 > --=20 > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 --Apple-Mail-19--375444760 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Bruce,

I still have the basic = question: 
What is the purpose of defining power = states?
What do we need them for in addition to functional = device states?

We should have a clear answer in = the eman = WG.

Thanks,

  =  Juergen


Am 13.03.2011 um = 22:20 schrieb Bruce Nordman:

I think we = are making this more complicated than necessary.
First, our mandate = is for monitoring, not control.  We should be
thinking about = control (as we are), but should not complicate
the monitoring = protocol for control reasons.  I know that eman
will in future be used by some devices for control (and I = support
their ability to do so in future), but the great majority I = believe will
only use its monitoring features.

Second, the = NMS will know the identity of the device being
monitored, so can use that information in drawing conclusions.
The = power state does not need to be burdened with trying to
be highly = informative by itself.  The device HAS a basic power
state = already - we are just trying to expose that which already
exists.

When devices have the ability and need to be more = elaborate
in what they communicate (e.g. exposing battery details), = we
can facilitate that, but for those that can't or don't need = this,
we should allow them to be simple.

Batteries are not involved in the vast majority of = electricity
use, and the NMS will know if the device does (or = could)
have one and so can draw appropriate conclusions.

To = Juergen's question, the assumptions that can be made
about a device's energy based solely on the power state
depends on = the device.  We don't need to say = more.

--Bruce


On Sun, Mar = 13, 2011 at 1:06 PM, Juergen Quittek <ietf@quittek.at> = wrote:
Hi = Rolf,

One of the important questions to be answered is:
Do we want to be able to make assumptions on a device's energy = consumption based on the power state?
If a devices's power state is off, what would it tell us, if not: The = devices does not need any power.

If this is not the case, we are rather talking about functional states = with some power-related properties,
But if these states do not serve as basis for power-related assumptions = on the device, then the name
POWER state is misleading and not appropriate any more.

Thanks,

   Juergen


Am 13.03.2011 um 14:34 schrieb Rolf Winter:

> Chris, Ted,
>
> I wasn't really implying anything here. To me, it seemed that a lot = of the discussion was triggered by the fact that it is difficult to = accommodate batteries directly in a device's power state. So I was = wondering why one would actually do that (instead of treating it as a = completely different entity). My mail tried to summarize the differences = and I was asking whether there is more. I believe this is something we = want to figure out quickly as a bunch of things will rely on this = decision. But it might be that a simple model would work here. E.g. = you'd have the state sleep (which means e.g. that the functional = components draw little power) and a sub-state that says batteries = charging (or not, or which "type" of charging) which tells you that the = device as a whole is drawing significant power. The same for on and off = states of course. Or you can have all separate in a battery MIB. In = either case, I think other battery related information should be in a = separate MIB. E.g. whether a battery is fully charged, empty, it's age, = number of charging cycles and so forth. So which one should it be, which = of the tradeoffs is most important to us?
>
>
> Best,
>
> Rolf
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014
...




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


= --Apple-Mail-19--375444760-- From ietf@quittek.at Sun Mar 13 15:23:56 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE40E3A6BFA for ; Sun, 13 Mar 2011 15:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tGA9u-7RLPE for ; Sun, 13 Mar 2011 15:23:54 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id D381F3A6BFF for ; Sun, 13 Mar 2011 15:23:53 -0700 (PDT) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MQA1H-1PunFw46XT-005DqP; Sun, 13 Mar 2011 23:25:08 +0100 References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CF36845@mail03.cyberswitching.local> In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CF36845@mail03.cyberswitching.local> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-20--374636614 Message-Id: From: Juergen Quittek Date: Sun, 13 Mar 2011 23:25:10 +0100 To: Chris Verges X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:wEf0ym5PlACrbKMNLgcIp2J37JABmuj/aFMm6KOvakK Pe4FGK+lVGZlMZ9TfK0ru0whCWre+yGdlkXQMYBxu7tWi8ifMd ooFiVSMKYol01d0ZZDaA4z32Y2FnVB44DAwBWgJKdBq45A8bgT 7Rmhae0JyDzumSnK872CBO8x+YvtlQcsIjLKD6yh7z0Vme0XHM 7lYmrRtkxKCcky39yXIuQ== Cc: eman mailing list , Rolf Winter , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 22:23:56 -0000 --Apple-Mail-20--374636614 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Chris, I have just a question for clarification:=20 What do you call an 'interface'? Is it just a set of power states,=20 such as the set of DMTF power states=20 or the set of ACPI power states? Or is it more than this? Thanks, Juergen Am 12.03.2011 um 02:07 schrieb Chris Verges: > Hi Bruce, > =20 > Please don=92t take silence as a form of acceptance. That=92s a = dangerous assumption. > =20 > My position is that a single state mechanism is not appropriate for = EMAN to consider. EMAN should support multiple state mechanisms, that = coexist with each other. > =20 > Consider the following scenario: > =20 > Three forms of state management: ACPI, DMTF, and PDU State Management. = (PDU states include on, off, reboot, tripped, and shed. Only for = example purposes, exact details to be worked out later.) > =20 > server-a =96 supports ACPI only > server-b =96 supports ACPI and DMTF > PDU =96 supports EMAN PDU State Management > =20 > I propose that we allow each device to support the modality that makes = sense for that device. The key is not in which modality is supported, = but rather how the user accesses the modality. Why would we try to = limit innovation by restricting what people can do? > =20 > Expose different hooks to allow a user to access ACPI, DMTF, and/or = PDU State Management through three different interfaces: > =20 > emanStateControlAcpi =96 implemented by entities which know how to = respond to ACPI states > emanStateControlDmtf =96 implemented by entities which know how to = respond to DMTF states > emanStateControlPdu =96 implemented by entities which know how to = respond to PDU State Management > =20 > This makes the EMAN schema more powerful and allows the market to = adapt easily as future changes in technologies and our understanding of = how to use those technologies improves. > =20 > Chris > =20 > =20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of Bruce Nordman > Sent: Friday, March 11, 2011 4:43 PM > To: Rolf Winter > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > =20 > Good discussion. >=20 > Batteries are a specific example of a case in which a device has a = secondary > function which can consume significant amounts of power, and the = secondary > function is independent of the primary one. My computer is an iMac = with an > integrated display, so the display is secondary to the primary = function of computation, > but unlike the battery, its function is not independent (display = always powered > down when the computational part is). >=20 > Another example like the battery could be a TV with an integral video = recorder. > The recorder can be active when the TV display is asleep or off. A = third example > is an imaging MFD that does printing, copying, and scanning; it may = have the > scanner active at relatively low power, but the heat-intensive toner = fusing unit > powered down. Life would be simpler if devices were not = multi-functional. >=20 > I think we should insist on devices having a primary function (that is = afterall > how "identity" works), and the power state reflects that function. = Simple devices > with internal batteries can consume a lot of power in sleep or off. = More sophisticated > devices may choose to use the eman features for exposing the = consumption of the > battery and balance of the system, and then have a state for the = batter exposed. > We need to enable this but not require it. >=20 > I am assuming that we will usually have both power state and current = power > draw in watts, so the NMS will look at both (and the product's = identity) in > deciding what is going on. (Perhaps part of identity is reporting if = a non-trivial > battery is present (though this can be a dynamic characteristic).) > So, one can look at power level, at power state, or both. I think = having > both addresses Rolf's concerns. =20 >=20 > For Juergen's note about the states of off-but charging (so high = power), > and on (and presumably AC-connected) but running only off of battery = power > (so no AC draw), that confirms the need to have the actual mains power > level. There have been notebook PCs designed to go off-grid in the = afternoon > to avoid times of high electricity demand, so this is a very real = scenario. >=20 >=20 > More important from my point of view, is that no one on this thread = has jumped > to the defense of ACPI/DMTF. I am more convinced than ever that they = are > a distraction for our purposes. >=20 > --Bruce >=20 > On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = wrote: > Hi, >=20 > just thinking out loud here. >=20 > The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here = http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we = have battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the trade-offs: >=20 > Option A) You can always tell from the device power state whether it = is drawing power or not ("off but charging" e.g.) and you might be able = to order them in a way that a higher state always translates to higher = power draw. It however seems to complicate power states. >=20 > Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be really = "off but charging"). The device power states can be modelled cleaner = though and you'd need to look closer to see what the battery state is to = be sure there is no power draw. >=20 > Is that the trade-off we're talking about or is there anything else = that needs to be considered? >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > > Juergen Quittek > > Sent: Freitag, 11. M=E4rz 2011 10:37 > > To: Bruce Nordman > > Cc: eman mailing list > > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Bruce, > > > > I understand your preference for a simple off-sleep-on model for = power > > states. > > How would we model a device with a battery then > > - it is off, but the empty battery is being charged > > - it is on, but fully supplied with power from the battery. > > > > On way would be treating the (internal) battery as separate device. > > In this case: Can we map charging/discharging/full/empty to = off-sleep- > > on? > > > > Thanks, > > > > Juergen > > > > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > > > > (all below as contributor) > > > > > > > > > > For many decades, electrical products were usually just on or = off > > - a 2-state power model. In the last several decades, we have added > > many electronic products with a 3-state model - on, sleep, and off. > > This is necessary and existing complexity. Our discussions around > > power states boil down to what complexity do we want to add to the = 3- > > state model, and why the burden is justified. > > > > > > > > > > > > In discussions on this email list, in I-drafts, and in person, > > the existing listings of power states from ACPI and DMTF are often > > referenced as good candidates for eman to adopt in some way. ACPI = is a > > hugely important technology, and it enables large amounts of user > > functionality and energy savings. I am less familiar with the reach = of > > DMTF in practice, but its depth and breadth of membership are > > compelling. While I agree they both deserve close examination, I = think > > we can safely drop them from our discussions of what to define as = their > > complexity is more a distraction than an asset. > > > > > > > > > > The basic ACPI list is of "Global System States" which "apply = to > > the entire system". There are four of these (G0-G3); G0 is on > > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of = off > > (only distinguished by whether a device is completely depowered and > > whether it is safe to disassemble or not, and these distinctions = seems > > quite minor for eman purposes). Thus, the ACPI Global states are > > essentially on/sleep/off, the 3-state power model. > > > > ACPI lists five "Sx" sleep states (S0 is on). S5 = is > > actually the G2 Off state (so not a sleep state at all), and current > > implementations do not use S1 or S2, so in practice there are only = two > > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > > quick wakeup. S4 is the hibernate state (with system memory saved = in > > non-volatile memory, possibly a hard disk) which typically has long > > times to return to operation (often tens of seconds). The 1-2 = second > > wake time from S3 for modern personal computers is compatible with = many > > IP protocol usages, e.g. initiating a TCP connection. The tens of > > seconds time for S4 on current systems is not. So, the only = potential > > addition that the Sx states add to on/sleep/off is hibernate (and > > reasonable people can differ on whether it is a fourth basic state, = a > > form of sleep, or a form of off). > > > > > > ACPI does define processor states (Cx) and device > > states (Dx) (collectively Px), but these are the states of = particular > > components, not of the system as a whole. It may be useful to = expose > > these through some mechanism, but they are distinct from the power > > state. > > > > > > > > > > DMTF essentially took the ACPI Gx states plus > > hibernate and added states that are commands and/or transitions. = (Is > > "Master Bus Reset" a power state? I think not). If we don't = include > > commands or transitions (I think we should not), then these reduce = to > > the ACPI states. > > > > > > > > > > My conclusion: ACPI and DMTF do not significantly > > change the 3-state power model. If we want to talk about states = beyond > > the 3-state model, it is more clear to simply reference those > > extensions directly (e.g. how best to treat hibernate). Note that = this > > discussion - and all others on the list - are grounded in electronic > > devices. Other devices generally have a 2-state model (e.g. a = light), > > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > > > > > > --Bruce > > > > > > > > > > -- > > Bruce Nordman > > Lawrence Berkeley National Laboratory > > eetd.lbl.gov/ea/nordman > > BNordman@LBL.gov > > 510-486-7089 > > m: 510-501-7943 > > > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman > > > > >=20 >=20 >=20 >=20 > --=20 > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-20--374636614 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Chris,

I have just a question = for clarification: 
What do you call an = 'interface'?
Is it just a set of power = states, 
such as the set of DMTF power = states 
or the set of ACPI power states?
Or is = it more than = this?

Thanks,

 &nbs= p;  Juergen


Am 12.03.2011 um = 02:07 schrieb Chris Verges:

Hi = Bruce,
 
My position is that a single = state mechanism is not appropriate for EMAN to consider.  EMAN = should support multiple state mechanisms, that coexist with each = other.
Three forms of state management: ACPI, DMTF, and PDU = State Management.  (PDU states include on, off, reboot, = tripped, and shed.  Only for = example purposes, exact details to be worked out = later.)
server-a =96 supports ACPI = only
 =96 supports ACPI and = DMTF
 =96 supports EMAN PDU State = Management
I = propose that we allow each device to support the modality that makes = sense for that device.  The key is not in which modality is = supported, but rather how the user accesses the modality.  Why = would we try to limit innovation by restricting what people can = do?
emanStateControlAcpi =96 implemented by entities = which know how to respond to ACPI states
emanStateControlDmtf =96 = implemented by entities which know how to respond to DMTF = states
emanStateControlPdu =96 implemented by entities = which know how to respond to PDU State = Management
This = makes the EMAN schema more powerful and allows the market to adapt = easily as future changes in technologies and our understanding of how to = use those technologies improves.
 eman-bounces@ietf.org [mailto:eman-bounces@ietf.org= ] On Behalf Of Bruce = Nordman
Sent: Friday, March 11, 2011 4:43 = PM
To: Rolf = Winter
Cc: eman mailing = list
Subject: Re: [eman] Power states - = time to dump ACPI and DMTF
 

Good discussion.

Batteries are a specific example of a = case in which a device has a secondary
function which can consume = significant amounts of power, and the secondary
function is = independent of the primary one.  My computer is an iMac with = an
integrated display, so the display is secondary to the primary = function of computation,
but unlike the battery, its function is not = independent (display always powered
down when the computational part = is).

Another example like the battery could be a TV with an = integral video recorder.
The recorder can be active when the TV = display is asleep or off.  A third example
is an imaging MFD = that does printing, copying, and scanning; it may have the
scanner = active at relatively low power, but the heat-intensive toner fusing = unit
powered down.  Life would be simpler if devices were not = multi-functional.

I think we should insist on devices having a = primary function (that is afterall
how "identity" works), and the = power state reflects that function.  Simple devices
with = internal batteries can consume a lot of power in sleep or off.  = More sophisticated
devices may choose to use the eman features for = exposing the consumption of the
battery and balance of the system, = and then have a state for the batter exposed.
We need to enable this = but not require it.

I am assuming that we will usually have both = power state and current power
draw in watts, so the NMS will look at = both (and the product's identity) in
deciding what is going on.  = (Perhaps part of identity is reporting if a non-trivial
battery is = present (though this can be a dynamic characteristic).)
So, one can = look at power level, at power state, or both.  I think = having
both addresses Rolf's concerns.  

For Juergen's note = about the states of off-but charging (so high power),
and on (and = presumably AC-connected) but running only off of battery power
(so no = AC draw), that confirms the need to have the actual mains = power
level.  There have been notebook PCs designed to go = off-grid in the afternoon
to avoid times of high electricity demand, = so this is a very real scenario.


More important from my point = of view, is that no one on this thread has jumped
to the defense of = ACPI/DMTF.  I am more convinced than ever that they are
a = distraction for our purposes.

--Bruce

On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter <Rolf.Winter@neclab.eu> = wrote:
Hi,

just thinking out loud = here.

The thing which seems to complicate matters here = significantly is batteries. You either A) try to consider battery state = in the devices' power state or you B) leave it separate in its own MIB = module (as described e.g. here  where we have battery = states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the = trade-offs:

Option A) You can always tell from the device power = state whether it is drawing power or not ("off but charging" e.g.) and = you might be able to order them in a way that a higher state always = translates to higher power draw. It however seems to complicate power = states.

Option B) If a battery is present, you cannot tell from = the device's power state whether is it drawing power or not ("off" could = be really "off but charging"). The device power states can be modelled = cleaner though and you'd need to look closer to see what the battery = state is to be sure there is no power draw.

Is that the trade-off = we're talking about or is there anything else that needs to be = considered?

Best,

Rolf

NEC Europe Limited | = Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014



> -----Original = Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 = 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> = Subject: Re: [eman] Power states - time to dump ACPI and = DMTF
>
> Hi Bruce,
>
> I understand your = preference for a simple off-sleep-on model for power
> = states.
> How would we model a device with a battery then
> =   - it is off, but the empty battery is being charged
> =   - it is on, but fully supplied with power from the = battery.
>
> On way would be treating the (internal) battery = as separate device.
> In this case: Can we map = charging/discharging/full/empty to off-sleep-
> = on?
>
> Thanks,
>
>     = Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce = Nordman:
>
>
>       (all below as = contributor)
>
>
>
>
>     =   For many decades, electrical products were usually just on or = off
> - a 2-state power model.  In the last several decades, = we have added
> many electronic products with a 3-state model - = on, sleep, and off.
> This is necessary and existing complexity. =  Our discussions around
> power states boil down to what = complexity do we want to add to the 3-
> state model, and why the = burden is justified.
>
>
>
>
>
> =       In discussions on this email list, in I-drafts, and = in person,
> the existing listings of power states from ACPI and = DMTF are often
> referenced as good candidates for eman to adopt = in some way.  ACPI is a
> hugely important technology, and it = enables large amounts of user
> functionality and energy savings. =  I am less familiar with the reach of
> DMTF in practice, but = its depth and breadth of membership are
> compelling.  While = I agree they both deserve close examination, I think
> we can = safely drop them from our discussions of what to define as their
> = complexity is more a distraction than an = asset.
>
>
>
>
>       The = basic ACPI list is of  "Global System States" which "apply = to
> the entire system".  There are four of these (G0-G3); G0 = is on
> ("working") and G1 is sleep ("sleeping").  G2 and G3 = both forms of off
> (only distinguished by whether a device is = completely depowered and
> whether it is safe to disassemble or = not, and these distinctions seems
> quite minor for eman = purposes).  Thus, the ACPI Global states are
> essentially = on/sleep/off, the 3-state power model.
>
>     =               ACPI lists five "Sx" = sleep states (S0 is on).  S5 is
> actually the G2 Off state = (so not a sleep state at all), and current
> implementations do = not use S1 or S2, so in practice there are only two
> ACPI sleep = states: S3 and S4.  S3 is the ordinary system sleep, with
> = quick wakeup.  S4 is the hibernate state (with system memory saved = in
> non-volatile memory, possibly a hard disk) which typically = has long
> times to return to operation (often tens of seconds). =   The 1-2 second
> wake time from S3 for modern personal = computers is compatible with many
> IP protocol usages, e.g. = initiating a TCP connection.  The tens of
> seconds time for = S4 on current systems is not.  So, the only potential
> = addition that the Sx states add to on/sleep/off is hibernate = (and
> reasonable people can differ on whether it is a fourth = basic state, a
> form of sleep, or a form of = off).
>
>
>             =       ACPI does define processor states (Cx) and = device
> states (Dx) (collectively Px), but these are the states = of particular
> components, not of the system as a whole.  It = may be useful to expose
> these through some mechanism, but they = are distinct from the power
> = state.
>
>
>
>
>       =             DMTF essentially took the ACPI = Gx states plus
> hibernate and added states that are commands = and/or transitions.  (Is
> "Master Bus Reset" a power state? =  I think not).  If we don't include
> commands or = transitions (I think we should not), then these reduce to
> the = ACPI states.
>
>
>
>
>     =               My conclusion: ACPI and = DMTF do not significantly
> change the 3-state power model. =  If we want to talk about states beyond
> the 3-state model, = it is more clear to simply reference those
> extensions directly = (e.g. how best to treat hibernate).  Note that this
> = discussion - and all others on the list - are grounded in = electronic
> devices.  Other devices generally have a 2-state = model (e.g. a light),
> or 3 states, but on, off, and "ready" = (think a microwave oven).
>
>
>
>
>   =     --Bruce
>
>
>
>
>   =     --
>       Bruce Nordman
> =       Lawrence Berkeley National Laboratory
> =       eetd.lbl.gov/ea/nordman
> =       BNordman@LBL.gov
>         eman@ietf.org
>       


-- 
Bruce Nordman
Lawrence Berkeley National = Laboratory
; Sun, 13 Mar 2011 15:27:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.34 with SMTP id dh2mr1608631vdb.245.1300055268757; Sun, 13 Mar 2011 15:27:48 -0700 (PDT) Received: by 10.52.155.40 with HTTP; Sun, 13 Mar 2011 15:27:48 -0700 (PDT) In-Reply-To: References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> <791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd> <0851C4CF-D108-4BE9-AB17-A24F05FB72D4@quittek.at> Date: Sun, 13 Mar 2011 15:27:48 -0700 Message-ID: From: Bruce Nordman To: Juergen Quittek Content-Type: multipart/alternative; boundary=20cf307cfef47b9321049e64b4cc Cc: Rolf Winter , eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 22:26:31 -0000 --20cf307cfef47b9321049e64b4cc Content-Type: text/plain; charset=ISO-8859-1 Good question. I would say we shouldn't try to define power states, as specific definitions inevitably collide with the wide variety of products in scope. Devices already have power states - we are not creating them. We are only providing a standard way to expose them to the network (or at least to the NMS). The distribution of time and energy across basic power states is always a topic of interest and discussion in understanding energy use, and reducing it, whether it is in the context of a single building, of technology, or energy policy. Exposing power state can be a useful piece of information in how devices interact with each other, in what this suggests for degrees of network connectivity (including none), and capability. Reporting basic power state enables the NMS to use this information in interpreting the power and energy data. When specific meaning about a particular product type is intended, then other mechanisms will usually be called for, whether they are part of eman or some other protocol. Creating one or more IANA registries for functional device states by product type does seem like something that we should explore. These would have no expectation of being universal in the way that power states can be (though harmonization across product types is certainly to be strived for, particularly for ones that are more closely related). --Bruce On Sun, Mar 13, 2011 at 3:11 PM, Juergen Quittek wrote: > Hi Bruce, > > I still have the basic question: > What is the purpose of defining power states? > What do we need them for in addition to functional device states? > > We should have a clear answer in the eman WG. > > Thanks, > > Juergen > > > Am 13.03.2011 um 22:20 schrieb Bruce Nordman: > > I think we are making this more complicated than necessary. > First, our mandate is for monitoring, not control. We should be > thinking about control (as we are), but should not complicate > the monitoring protocol for control reasons. I know that eman > will in future be used by some devices for control (and I support > their ability to do so in future), but the great majority I believe will > only use its monitoring features. > > Second, the NMS will know the identity of the device being > monitored, so can use that information in drawing conclusions. > The power state does not need to be burdened with trying to > be highly informative by itself. The device HAS a basic power > state already - we are just trying to expose that which already > exists. > > When devices have the ability and need to be more elaborate > in what they communicate (e.g. exposing battery details), we > can facilitate that, but for those that can't or don't need this, > we should allow them to be simple. > > Batteries are not involved in the vast majority of electricity > use, and the NMS will know if the device does (or could) > have one and so can draw appropriate conclusions. > > To Juergen's question, the assumptions that can be made > about a device's energy based solely on the power state > depends on the device. We don't need to say more. > > --Bruce > > > On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek wrote: > >> Hi Rolf, >> >> One of the important questions to be answered is: >> Do we want to be able to make assumptions on a device's energy consumption >> based on the power state? >> If a devices's power state is off, what would it tell us, if not: The >> devices does not need any power. >> >> If this is not the case, we are rather talking about functional states >> with some power-related properties, >> But if these states do not serve as basis for power-related assumptions on >> the device, then the name >> POWER state is misleading and not appropriate any more. >> >> Thanks, >> >> Juergen >> >> >> Am 13.03.2011 um 14:34 schrieb Rolf Winter: >> >> > Chris, Ted, >> > >> > I wasn't really implying anything here. To me, it seemed that a lot of >> the discussion was triggered by the fact that it is difficult to accommodate >> batteries directly in a device's power state. So I was wondering why one >> would actually do that (instead of treating it as a completely different >> entity). My mail tried to summarize the differences and I was asking whether >> there is more. I believe this is something we want to figure out quickly as >> a bunch of things will rely on this decision. But it might be that a simple >> model would work here. E.g. you'd have the state sleep (which means e.g. >> that the functional components draw little power) and a sub-state that says >> batteries charging (or not, or which "type" of charging) which tells you >> that the device as a whole is drawing significant power. The same for on and >> off states of course. Or you can have all separate in a battery MIB. In >> either case, I think other battery related information should be in a >> separate MIB. E.g. whether a battery is fully charged, empty, it's age, >> number of charging cycles and so forth. So which one should it be, which of >> the tradeoffs is most important to us? >> > >> > >> > Best, >> > >> > Rolf >> > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> London W3 6BL | Registered in England 2832014 >> ... >> >> > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --20cf307cfef47b9321049e64b4cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good question.=A0 I would say we shouldn't try to define power states,<= br>as specific definitions inevitably collide with the wide variety of prod= ucts
in scope.=A0 Devices already have power states - we are not creatin= g them.
We are only providing a standard way to expose them to the network
(or a= t least to the NMS).=A0 The distribution of time and energy across
basic= power states is always a topic of interest and discussion in understanding=
energy use, and reducing it, whether it is in the context of a single build= ing, of
technology, or energy policy.=A0 Exposing power state can be a u= seful
piece of information in how devices interact with each other, in w= hat
this suggests for degrees of network connectivity (including none),
and = capability.=A0 Reporting basic power state enables the NMS to use
this i= nformation in interpreting the power and energy data.

When specific = meaning about a particular product type is intended,
then other mechanisms will usually be called for, whether they are part
= of eman or some other protocol.=A0 Creating one or more IANA registries
= for functional device states by product type does seem like something
that we should explore.=A0 These would have no expectation of being
univ= ersal in the way that power states can be (though harmonization
across p= roduct types is certainly to be strived for, particularly for ones
that = are more closely related).

--Bruce



On Sun, Mar 13, 2011 = at 3:11 PM, Juergen Quittek <ietf@quittek.at> wrote:
Hi Bruce,

I still = have the basic question:=A0
What is the purpose of defining power= states?
What do we need them for in addition to functional devic= e states?

We should have a clear answer in the eman WG.

Thanks,

=A0=A0 =A0Juergen


Am 13.03.2011 um 22:20 schrieb Bruce Nordman= :

I think we = are making this more complicated than necessary.
First, our mandate is f= or monitoring, not control.=A0 We should be
thinking about control (as w= e are), but should not complicate
the monitoring protocol for control reasons.=A0 I know that eman
will in future be used by some devices for control (and I support
their = ability to do so in future), but the great majority I believe will
only= use its monitoring features.

Second, the NMS will know the identity= of the device being
monitored, so can use that information in drawing conclusions.
The power= state does not need to be burdened with trying to
be highly informative= by itself.=A0 The device HAS a basic power
state already - we are just = trying to expose that which already
exists.

When devices have the ability and need to be more elaborate<= br>in what they communicate (e.g. exposing battery details), we
can faci= litate that, but for those that can't or don't need this,
we sho= uld allow them to be simple.

Batteries are not involved in the vast majority of electricity
use, = and the NMS will know if the device does (or could)
have one and so can = draw appropriate conclusions.

To Juergen's question, the assumpt= ions that can be made
about a device's energy based solely on the power state
depends on t= he device.=A0 We don't need to say more.

--Bruce


On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek <iet= f@quittek.at> wrote:
Hi Rolf,

One of the important questions to be answered is:
Do we want to be able to make assumptions on a device's energy consumpt= ion based on the power state?
If a devices's power state is off, what would it tell us, if not: The d= evices does not need any power.

If this is not the case, we are rather talking about functional states with= some power-related properties,
But if these states do not serve as basis for power-related assumptions on = the device, then the name
POWER state is misleading and not appropriate any more.

Thanks,

=A0 =A0Juergen


Am 13.03.2011 um 14:34 schrieb Rolf Winter:

> Chris, Ted,
>
> I wasn't really implying anything here. To me, it seemed that a lo= t of the discussion was triggered by the fact that it is difficult to accom= modate batteries directly in a device's power state. So I was wondering= why one would actually do that (instead of treating it as a completely dif= ferent entity). My mail tried to summarize the differences and I was asking= whether there is more. I believe this is something we want to figure out q= uickly as a bunch of things will rely on this decision. But it might be tha= t a simple model would work here. E.g. you'd have the state sleep (whic= h means e.g. that the functional components draw little power) and a sub-st= ate that says batteries charging (or not, or which "type" of char= ging) which tells you that the device as a whole is drawing significant pow= er. The same for on and off states of course. Or you can have all separate = in a battery MIB. In either case, I think other battery related information= should be in a separate MIB. E.g. whether a battery is fully charged, empt= y, it's age, number of charging cycles and so forth. So which one shoul= d it be, which of the tradeoffs is most important to us?
>
>
> Best,
>
> Rolf
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lo= ndon W3 6BL | Registered in England 2832014
...




--
Bruce Nordman
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov<= br>510-486-7089
m: 510-501-7943



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




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

--20cf307cfef47b9321049e64b4cc-- From ietf@quittek.at Sun Mar 13 16:02:41 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210F13A690A for ; Sun, 13 Mar 2011 16:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usDMEd1-SJmF for ; Sun, 13 Mar 2011 16:02:39 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id F15F53A68AB for ; Sun, 13 Mar 2011 16:02:38 -0700 (PDT) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LzYuY-1Q3yoU1TIg-014Djt; Mon, 14 Mar 2011 00:04:00 +0100 References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> <791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd> <0851C4CF-D108-4BE9-AB17-A24F05FB72D4@quittek.at> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-21--373414415 Message-Id: <0E8D43D8-30EE-4483-ADC5-BEF9C210E62F@quittek.at> From: Juergen Quittek Date: Sun, 13 Mar 2011 23:45:32 +0100 To: Bruce Nordman X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:yhulx6qreTae8Hw5r5xdkCvNDbGmjXaisxBG2EPlZJQ a9UI9je8cG7D0p6VA1BKmcLu6ZwQtfBqBbE/mhZb1tg9VR5ujM Yu9dej33NLEuV0CEeqhE3JQPWdyCsOFvzJK3Fj5U/cbPi9j9Ki 7T1Wq5MmmPtkLeSw5wCmzxcMpNtDT74M27F0/UJOkyGzfVJyxe g878oUZIXddJWI0EZJYSw== Cc: Rolf Winter , eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 23:02:41 -0000 --Apple-Mail-21--373414415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bruce, I still would prefer having a definition. The basic motivation is that "if you can't define it, you probably don't = know what it is". Maybe we can say that a power state just indicates the current energy=20 consumption POLICY of a device and not necessary its actual consumption=20= rate. Then a sleep mode would be a mode in which a device saves=20 energy by not providing major parts of its core function. =20 But this would not necessarily imply that the devices consumes energy=20 at a low rate (low power) because the device may charge its batteries=20 or do something else that needs significant power. Still, the device=20 saves energy in sleep mode, because its main function is on sleep. Analogous considerations would apply to the 'off' state. Juergen Am 13.03.2011 um 23:27 schrieb Bruce Nordman: > Good question. I would say we shouldn't try to define power states, > as specific definitions inevitably collide with the wide variety of = products > in scope. Devices already have power states - we are not creating = them. > We are only providing a standard way to expose them to the network > (or at least to the NMS). The distribution of time and energy across > basic power states is always a topic of interest and discussion in = understanding > energy use, and reducing it, whether it is in the context of a single = building, of > technology, or energy policy. Exposing power state can be a useful > piece of information in how devices interact with each other, in what > this suggests for degrees of network connectivity (including none), > and capability. Reporting basic power state enables the NMS to use > this information in interpreting the power and energy data. >=20 > When specific meaning about a particular product type is intended, > then other mechanisms will usually be called for, whether they are = part > of eman or some other protocol. Creating one or more IANA registries > for functional device states by product type does seem like something > that we should explore. These would have no expectation of being > universal in the way that power states can be (though harmonization > across product types is certainly to be strived for, particularly for = ones > that are more closely related). >=20 > --Bruce >=20 >=20 >=20 > On Sun, Mar 13, 2011 at 3:11 PM, Juergen Quittek = wrote: > Hi Bruce, >=20 > I still have the basic question:=20 > What is the purpose of defining power states? > What do we need them for in addition to functional device states? >=20 > We should have a clear answer in the eman WG. >=20 > Thanks, >=20 > Juergen >=20 >=20 > Am 13.03.2011 um 22:20 schrieb Bruce Nordman: >=20 >> I think we are making this more complicated than necessary. >> First, our mandate is for monitoring, not control. We should be >> thinking about control (as we are), but should not complicate >> the monitoring protocol for control reasons. I know that eman >> will in future be used by some devices for control (and I support >> their ability to do so in future), but the great majority I believe = will=20 >> only use its monitoring features. >>=20 >> Second, the NMS will know the identity of the device being >> monitored, so can use that information in drawing conclusions. >> The power state does not need to be burdened with trying to >> be highly informative by itself. The device HAS a basic power >> state already - we are just trying to expose that which already >> exists. >>=20 >> When devices have the ability and need to be more elaborate >> in what they communicate (e.g. exposing battery details), we >> can facilitate that, but for those that can't or don't need this, >> we should allow them to be simple. >>=20 >> Batteries are not involved in the vast majority of electricity >> use, and the NMS will know if the device does (or could) >> have one and so can draw appropriate conclusions. >>=20 >> To Juergen's question, the assumptions that can be made >> about a device's energy based solely on the power state >> depends on the device. We don't need to say more. >>=20 >> --Bruce >>=20 >>=20 >> On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek = wrote: >> Hi Rolf, >>=20 >> One of the important questions to be answered is: >> Do we want to be able to make assumptions on a device's energy = consumption based on the power state? >> If a devices's power state is off, what would it tell us, if not: The = devices does not need any power. >>=20 >> If this is not the case, we are rather talking about functional = states with some power-related properties, >> But if these states do not serve as basis for power-related = assumptions on the device, then the name >> POWER state is misleading and not appropriate any more. >>=20 >> Thanks, >>=20 >> Juergen >>=20 >>=20 >> Am 13.03.2011 um 14:34 schrieb Rolf Winter: >>=20 >> > Chris, Ted, >> > >> > I wasn't really implying anything here. To me, it seemed that a lot = of the discussion was triggered by the fact that it is difficult to = accommodate batteries directly in a device's power state. So I was = wondering why one would actually do that (instead of treating it as a = completely different entity). My mail tried to summarize the differences = and I was asking whether there is more. I believe this is something we = want to figure out quickly as a bunch of things will rely on this = decision. But it might be that a simple model would work here. E.g. = you'd have the state sleep (which means e.g. that the functional = components draw little power) and a sub-state that says batteries = charging (or not, or which "type" of charging) which tells you that the = device as a whole is drawing significant power. The same for on and off = states of course. Or you can have all separate in a battery MIB. In = either case, I think other battery related information should be in a = separate MIB. E.g. whether a battery is fully charged, empty, it's age, = number of charging cycles and so forth. So which one should it be, which = of the tradeoffs is most important to us? >> > >> > >> > Best, >> > >> > Rolf >> > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 >> ... >>=20 >>=20 >>=20 >>=20 >> --=20 >> Bruce Nordman >> Lawrence Berkeley National Laboratory >> eetd.lbl.gov/ea/nordman >> BNordman@LBL.gov >> 510-486-7089 >> m: 510-501-7943 >>=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 >=20 >=20 >=20 > --=20 > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 --Apple-Mail-21--373414415 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Maybe = we can say that a power state just indicates the current = energy 
consumption POLICY of a device and not = necessary its actual consumption 
rate.  Then a = sleep mode would be a mode in which a device = saves 
energy by not providing major parts of its = core function.
 
But this would not necessarily = imply that the devices consumes energy 
at a low rate = (low power) because the device may charge its = batteries 
or do something else that needs significant = power.  Still, the device 
saves energy in sleep = mode, because its main function is on sleep.
Analogous = considerations would apply to the 'off' = state.

   =  Juergen


Am 13.03.2011 um 23:27 = schrieb Bruce Nordman:

Good = question.  I would say we shouldn't try to define power = states,
as specific definitions inevitably collide with the wide = variety of products
in scope.  Devices already have power states = - we are not creating them.
We are only providing a standard way to expose them to the = network
(or at least to the NMS).  The distribution of time and = energy across
basic power states is always a topic of interest and = discussion in understanding
energy use, and reducing it, whether it is in the context of a single = building, of
technology, or energy policy.  Exposing power state = can be a useful
piece of information in how devices interact with = each other, in what
this suggests for degrees of network connectivity (including = none),
and capability.  Reporting basic power state enables the = NMS to use
this information in interpreting the power and energy = data.

When specific meaning about a particular product type is = intended,
then other mechanisms will usually be called for, whether they are = part
of eman or some other protocol.  Creating one or more IANA = registries
for functional device states by product type does seem = like something
that we should explore.  These would have no expectation of = being
universal in the way that power states can be (though = harmonization
across product types is certainly to be strived for, = particularly for ones
that are more closely related).

--Bruce



On Sun, Mar 13, = 2011 at 3:11 PM, Juergen Quittek <ietf@quittek.at> = wrote:
Hi Bruce,

I = still have the basic question: 
What is the purpose of = defining power states?
What do we need them for in addition to = functional device states?

We should have a clear answer in the eman = WG.

Thanks,

  =  Juergen


Am 13.03.2011 um = 22:20 schrieb Bruce Nordman:

I think = we are making this more complicated than necessary.
First, our = mandate is for monitoring, not control.  We should be
thinking = about control (as we are), but should not complicate
the monitoring protocol for control reasons.  I know that eman
will in future be used by some devices for control (and I = support
their ability to do so in future), but the great majority I = believe will
only use its monitoring features.

Second, the = NMS will know the identity of the device being
monitored, so can use that information in drawing conclusions.
The = power state does not need to be burdened with trying to
be highly = informative by itself.  The device HAS a basic power
state = already - we are just trying to expose that which already
exists.

When devices have the ability and need to be more = elaborate
in what they communicate (e.g. exposing battery details), = we
can facilitate that, but for those that can't or don't need = this,
we should allow them to be simple.

Batteries are not involved in the vast majority of = electricity
use, and the NMS will know if the device does (or = could)
have one and so can draw appropriate conclusions.

To = Juergen's question, the assumptions that can be made
about a device's energy based solely on the power state
depends on = the device.  We don't need to say = more.

--Bruce


On Sun, Mar = 13, 2011 at 1:06 PM, Juergen Quittek <ietf@quittek.at> wrote:
Hi = Rolf,

One of the important questions to be answered is:
Do we want to be able to make assumptions on a device's energy = consumption based on the power state?
If a devices's power state is off, what would it tell us, if not: The = devices does not need any power.

If this is not the case, we are rather talking about functional states = with some power-related properties,
But if these states do not serve as basis for power-related assumptions = on the device, then the name
POWER state is misleading and not appropriate any more.

Thanks,

   Juergen


Am 13.03.2011 um 14:34 schrieb Rolf Winter:

> Chris, Ted,
>
> I wasn't really implying anything here. To me, it seemed that a lot = of the discussion was triggered by the fact that it is difficult to = accommodate batteries directly in a device's power state. So I was = wondering why one would actually do that (instead of treating it as a = completely different entity). My mail tried to summarize the differences = and I was asking whether there is more. I believe this is something we = want to figure out quickly as a bunch of things will rely on this = decision. But it might be that a simple model would work here. E.g. = you'd have the state sleep (which means e.g. that the functional = components draw little power) and a sub-state that says batteries = charging (or not, or which "type" of charging) which tells you that the = device as a whole is drawing significant power. The same for on and off = states of course. Or you can have all separate in a battery MIB. In = either case, I think other battery related information should be in a = separate MIB. E.g. whether a battery is fully charged, empty, it's age, = number of charging cycles and so forth. So which one should it be, which = of the tradeoffs is most important to us?
>
>
> Best,
>
> Rolf
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014
...




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

=


_______________________= ________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman




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


= --Apple-Mail-21--373414415-- From ietf@quittek.at Sun Mar 13 16:07:19 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35913A690A for ; Sun, 13 Mar 2011 16:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDjROzXvMw8e for ; Sun, 13 Mar 2011 16:07:18 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 877EB3A68AB for ; Sun, 13 Mar 2011 16:07:17 -0700 (PDT) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LkRpr-1QWJHE0bvf-00bqf3; Mon, 14 Mar 2011 00:08:35 +0100 References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-22--372029679 Message-Id: <865E90F5-30BD-40D5-8713-D5C222ECE359@quittek.at> From: Juergen Quittek Date: Mon, 14 Mar 2011 00:08:37 +0100 To: Ted Ghose X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:gTvdLHcA76qYh1PB517oZHivCYOWSVpvugrSU2f2akR vJ6tB2CEfNxLmiHe1ol3IahYlqsWbinhVbFLb7TJSSQmYiuSd0 QvcdKsXmlCuDFCKsyqx175iLx0xQ32+bMZxSAagXJF6KBnDOQF 8zZT3DTvccfekkJ8JOV8inbxXzCYHt0z0jaMRLtbSpQzR3Usqu jlAF9+d7KLJDxs+xfxx8w== Cc: eman mailing list , Rolf Winter , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 23:07:19 -0000 --Apple-Mail-22--372029679 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Ted, Am 11.03.2011 um 17:00 schrieb Ted Ghose: > Hi Rolf, Juergen >=20 > I like Rolf's idea very much. We should extend number of states to = accommodate other sub states.=20 >=20 > Here is one question I do have for Juergon, as handling the battery = keeps coming up in all the discussions.=20 >=20 > If the device is off, but battery is charging, who is reporting that = and how? Is battery itself has the intelligence to do so? In that case, = can we treat it as a separate device independent of the device it is = connected to, and then we could simplify the model. Yes, Then we need power states for batteries, which may be different to = (off, sleep, on). > In the other case, though, if device is turned off, there is no one to = tell what the battery is doing, unless an intelligent PDU or someone is = aware of that device. Which comes to some source - sink model as well. Devices have the capability to notify a management system when they = switch power states.=20 There is no need for continuous reporting once you reported you're off. = A PC may send a=20 notification before going to off or sleep mode. And of course it may = send a wake-up notification when waking up from sleep or when booting. It does not seem to be a smart idea to wake up the device just to report = that charging of=20 the battery is complete and thus common devices don't do so. But if you = measure power=20 with an external meter, a management system (or your "parent") might be = able to detect=20 this point in time. Alternatively, you could send a notification to your = management system=20 (or parent) indicating: I'm going to sleep mode an expect a charging = time of 75 minutes. Then the management system (or parent) could assume (and report) for 75 = minutes=20 "device in state "sleep with charging batteries" and then switch to = plain "sleep". Thanks, Juergen > Could you please clarify your thoughts? >=20 > thanks >=20 > -tg- > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > Save time... see it my way > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. >=20 >=20 > On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = wrote: > Hi, >=20 > just thinking out loud here. >=20 > The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here = http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we = have battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the trade-offs: >=20 > Option A) You can always tell from the device power state whether it = is drawing power or not ("off but charging" e.g.) and you might be able = to order them in a way that a higher state always translates to higher = power draw. It however seems to complicate power states. >=20 > Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be really = "off but charging"). The device power states can be modelled cleaner = though and you'd need to look closer to see what the battery state is to = be sure there is no power draw. >=20 > Is that the trade-off we're talking about or is there anything else = that needs to be considered? >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > > Juergen Quittek > > Sent: Freitag, 11. M=E4rz 2011 10:37 > > To: Bruce Nordman > > Cc: eman mailing list > > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Bruce, > > > > I understand your preference for a simple off-sleep-on model for = power > > states. > > How would we model a device with a battery then > > - it is off, but the empty battery is being charged > > - it is on, but fully supplied with power from the battery. > > > > On way would be treating the (internal) battery as separate device. > > In this case: Can we map charging/discharging/full/empty to = off-sleep- > > on? > > > > Thanks, > > > > Juergen > > > > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > > > > (all below as contributor) > > > > > > > > > > For many decades, electrical products were usually just on or = off > > - a 2-state power model. In the last several decades, we have added > > many electronic products with a 3-state model - on, sleep, and off. > > This is necessary and existing complexity. Our discussions around > > power states boil down to what complexity do we want to add to the = 3- > > state model, and why the burden is justified. > > > > > > > > > > > > In discussions on this email list, in I-drafts, and in person, > > the existing listings of power states from ACPI and DMTF are often > > referenced as good candidates for eman to adopt in some way. ACPI = is a > > hugely important technology, and it enables large amounts of user > > functionality and energy savings. I am less familiar with the reach = of > > DMTF in practice, but its depth and breadth of membership are > > compelling. While I agree they both deserve close examination, I = think > > we can safely drop them from our discussions of what to define as = their > > complexity is more a distraction than an asset. > > > > > > > > > > The basic ACPI list is of "Global System States" which "apply = to > > the entire system". There are four of these (G0-G3); G0 is on > > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of = off > > (only distinguished by whether a device is completely depowered and > > whether it is safe to disassemble or not, and these distinctions = seems > > quite minor for eman purposes). Thus, the ACPI Global states are > > essentially on/sleep/off, the 3-state power model. > > > > ACPI lists five "Sx" sleep states (S0 is on). S5 = is > > actually the G2 Off state (so not a sleep state at all), and current > > implementations do not use S1 or S2, so in practice there are only = two > > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > > quick wakeup. S4 is the hibernate state (with system memory saved = in > > non-volatile memory, possibly a hard disk) which typically has long > > times to return to operation (often tens of seconds). The 1-2 = second > > wake time from S3 for modern personal computers is compatible with = many > > IP protocol usages, e.g. initiating a TCP connection. The tens of > > seconds time for S4 on current systems is not. So, the only = potential > > addition that the Sx states add to on/sleep/off is hibernate (and > > reasonable people can differ on whether it is a fourth basic state, = a > > form of sleep, or a form of off). > > > > > > ACPI does define processor states (Cx) and device > > states (Dx) (collectively Px), but these are the states of = particular > > components, not of the system as a whole. It may be useful to = expose > > these through some mechanism, but they are distinct from the power > > state. > > > > > > > > > > DMTF essentially took the ACPI Gx states plus > > hibernate and added states that are commands and/or transitions. = (Is > > "Master Bus Reset" a power state? I think not). If we don't = include > > commands or transitions (I think we should not), then these reduce = to > > the ACPI states. > > > > > > > > > > My conclusion: ACPI and DMTF do not significantly > > change the 3-state power model. If we want to talk about states = beyond > > the 3-state model, it is more clear to simply reference those > > extensions directly (e.g. how best to treat hibernate). Note that = this > > discussion - and all others on the list - are grounded in electronic > > devices. Other devices generally have a 2-state model (e.g. a = light), > > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > > > > > > --Bruce > > > > > > > > > > -- > > Bruce Nordman > > Lawrence Berkeley National Laboratory > > eetd.lbl.gov/ea/nordman > > BNordman@LBL.gov > > 510-486-7089 > > m: 510-501-7943 > > > > _______________________________________________ > > 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 --Apple-Mail-22--372029679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Ted,

Am 11.03.2011 um 17:00 schrieb Ted = Ghose:

Hi Rolf, Juergen

I like Rolf's idea = very much. We should extend number of states = to accommodate other sub = states. 

Here is one question I do have = for Juergon, as handling the battery keeps coming up in all the = discussions. 

If the device is off, but battery is charging, who = is reporting that and how? Is battery itself has the intelligence = to do so? In that case, can we treat it as = a separate device independent of the device it is = connected to, and then we could simplify the = model.

Yes, Then we need power states = for batteries, which may be different to (off, sleep, = on).

In the other case, = though, if device is turned off, there is no one to tell what the = battery is doing, unless an intelligent PDU or someone is = aware of that device. Which comes to some source - sink model as = well.

Devices have the capability to = notify a management system when they switch power = states. 
There is no need for continuous reporting once = you reported you're off. A PC may send a 
notification = before going to off or sleep mode. And of course it may send a wake-up = notification
when waking up from sleep or when = booting.

It does not seem to be a smart idea to = wake up the device just to report that charging of 
the = battery is complete and thus common devices don't do so. But if you = measure power 
with an external meter, a management = system (or your "parent")  might be able to =  detect 
this point in time. Alternatively, you = could send a notification to your = management system 
(or parent) indicating: I'm going = to sleep mode an expect a charging time of = 75 minutes.
Then the management system (or parent) could = assume (and report) for 75 minutes 
"device in state = "sleep with charging batteries" and then switch to plain = "sleep".

Thanks,

 &= nbsp;  Juergen

Could = you please clarify your = thoughts?

thanks

-tg-*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:= **:-.,_,.
                  =    Save time... see it my = way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_= ,.


On Fri, Mar 11, 2011 at 5:36 AM, Rolf = Winter <Rolf.Winter@neclab.eu>= wrote:
Hi,

just thinking out loud here.

The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here http://tools.ietf.org/html/draft-quittek-eman-battery-mi= b-00 where we have battery states full(1), partiallyCharged(2), = empty(3), charging(4), discharging(5), unknown(6)). I think these are = the trade-offs:

Option A) You can always tell from the device power state whether it is = drawing power or not ("off but charging" e.g.) and you might be able to = order them in a way that a higher state always translates to higher = power draw. It however seems to complicate power states.

Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be really = "off but charging"). The device power states can be modelled cleaner = though and you'd need to look closer to see what the battery state is to = be sure there is no power draw.

Is that the trade-off we're talking about or is there anything else that = needs to be considered?

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014


> -----Original Message-----
> From: eman-bounces@ietf.org = [mailto:eman-bounces@ietf.org] On = Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [eman] Power states - time to dump ACPI and DMTF
>
> Hi Bruce,
>
> I understand your preference for a simple off-sleep-on model for = power
> states.
> How would we model a device with a battery then
>   - it is off, but the empty battery is being charged
>   - it is on, but fully supplied with power from the = battery.
>
> On way would be treating the (internal) battery as separate = device.
> In this case: Can we map charging/discharging/full/empty to = off-sleep-
> on?
>
> Thanks,
>
>     Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce Nordman:
>
>
>       (all below as contributor)
>
>
>
>
>       For many decades, electrical products were = usually just on or off
> - a 2-state power model.  In the last several decades, we have = added
> many electronic products with a 3-state model - on, sleep, and = off.
> This is necessary and existing complexity.  Our discussions = around
> power states boil down to what complexity do we want to add to the = 3-
> state model, and why the burden is justified.
>
>
>
>
>
>       In discussions on this email list, in = I-drafts, and in person,
> the existing listings of power states from ACPI and DMTF are = often
> referenced as good candidates for eman to adopt in some way. =  ACPI is a
> hugely important technology, and it enables large amounts of = user
> functionality and energy savings.  I am less familiar with the = reach of
> DMTF in practice, but its depth and breadth of membership are
> compelling.  While I agree they both deserve close = examination, I think
> we can safely drop them from our discussions of what to define as = their
> complexity is more a distraction than an asset.
>
>
>
>
>       The basic ACPI list is of  "Global System = States" which "apply to
> the entire system".  There are four of these (G0-G3); G0 is = on
> ("working") and G1 is sleep ("sleeping").  G2 and G3 both = forms of off
> (only distinguished by whether a device is completely depowered = and
> whether it is safe to disassemble or not, and these distinctions = seems
> quite minor for eman purposes).  Thus, the ACPI Global states = are
> essentially on/sleep/off, the 3-state power model.
>
>                   ACPI = lists five "Sx" sleep states (S0 is on).  S5 is
> actually the G2 Off state (so not a sleep state at all), and = current
> implementations do not use S1 or S2, so in practice there are only = two
> ACPI sleep states: S3 and S4.  S3 is the ordinary system = sleep, with
> quick wakeup.  S4 is the hibernate state (with system memory = saved in
> non-volatile memory, possibly a hard disk) which typically has = long
> times to return to operation (often tens of seconds).   The = 1-2 second
> wake time from S3 for modern personal computers is compatible with = many
> IP protocol usages, e.g. initiating a TCP connection.  The = tens of
> seconds time for S4 on current systems is not.  So, the only = potential
> addition that the Sx states add to on/sleep/off is hibernate = (and
> reasonable people can differ on whether it is a fourth basic state, = a
> form of sleep, or a form of off).
>
>
>                   ACPI = does define processor states (Cx) and device
> states (Dx) (collectively Px), but these are the states of = particular
> components, not of the system as a whole.  It may be useful to = expose
> these through some mechanism, but they are distinct from the = power
> state.
>
>
>
>
>                   DMTF = essentially took the ACPI Gx states plus
> hibernate and added states that are commands and/or transitions. =  (Is
> "Master Bus Reset" a power state?  I think not).  If we = don't include
> commands or transitions (I think we should not), then these reduce = to
> the ACPI states.
>
>
>
>
>                   My = conclusion: ACPI and DMTF do not significantly
> change the 3-state power model.  If we want to talk about = states beyond
> the 3-state model, it is more clear to simply reference those
> extensions directly (e.g. how best to treat hibernate).  Note = that this
> discussion - and all others on the list - are grounded in = electronic
> devices.  Other devices generally have a 2-state model (e.g. a = light),
> or 3 states, but on, off, and "ready" (think a microwave oven).
>
>
>
>
>       --Bruce
>
>
>
>
>       --
>       Bruce Nordman
>       Lawrence Berkeley National Laboratory
>       eetd.lbl.gov/ea/nordman
>       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


= --Apple-Mail-22--372029679-- From chrisv@cyberswitching.com Sun Mar 13 16:34:41 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4383F3A6A4C for ; Sun, 13 Mar 2011 16:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwo5FYl6i1-B for ; Sun, 13 Mar 2011 16:34:24 -0700 (PDT) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) by core3.amsl.com (Postfix) with ESMTP id D0C5F3A6A46 for ; Sun, 13 Mar 2011 16:34:23 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o147.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 1d45d7d4.0.9985.00-379.17774.p01c11o147.mxlogic.net (envelope-from ); Sun, 13 Mar 2011 17:35:46 -0600 (MDT) X-MXL-Hash: 4d7d54d27a36b8ee-a8bdfa2dfbef4fe5c73cd3dee74711aeeed91f1f X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE1D7.3D3DD720" Date: Sun, 13 Mar 2011 16:34:39 -0700 Message-ID: <68FBE0F3CE97264395875AC1C468F22CF36854@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AcvhzWfPYTyR11HLT4qgTuvCu/bh2QACRqlw References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CF36845@mail03.cyberswitching.local> From: "Chris Verges" To: "Juergen Quittek" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=SbxTRnKmSzQA:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=wzgqfsuUAAAA:8 a=48vgC7mUAAAA:8 a=0-PB] X-AnalysisOut: [9bUlrFZ8MqLLCFkA:9 a=Y3EDu-1nQ49tFVMhRGcA:7 a=y2IYQlHuBUny] X-AnalysisOut: [CipExQ1mZkJZvYoA:4 a=wPNLvfGTeEIA:10 a=Y8rda4wpm8gA:10 a=F] X-AnalysisOut: [nBvD0j_UmcA:10 a=lr71C7C2fScA:10 a=lZB815dzVvQA:10 a=FQj98] X-AnalysisOut: [nZu5Y0ys_-O:21 a=A-B9USFTcS2rH46P:21 a=yMhMjlubAAAA:8 a=SS] X-AnalysisOut: [mOFEACAAAA:8 a=J35dNKfbAAAA:8 a=Nys2LJaC0NadDcbaFOcA:9 a=H] X-AnalysisOut: [hYwv5ZS-kdYICJPnWoA:7 a=dkYe03LqQGBdfSZboIMhH7K9qNEA:4 a=A] X-AnalysisOut: [vdbyHVHUK8wjLk9:21 a=NlaQ_uq7pAL2nIw1:21] Cc: eman mailing list , Rolf Winter , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 23:34:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE1D7.3D3DD720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An interface is an object as described in emanControlTable in = draft-verges. There are multiple objects contained in emanControlTable, = one for each type: emanAcpiControl, emanDmtfControl, etc. An entity can = implement one or more interfaces as is understood and supported by the = entity. =20 Proposed additional interfaces could be emanBatteryControl and = emanPduControl, for example. =20 An entity might implement multiple interfaces at the same time. How the = entity chooses to handle this is up to the entity and what makes sense = for the entity. In the case of ACPI and DMTF, the linkage between these = is defined by the DMTF standard and should be observed. =20 Thanks, Chris =20 --=20 Chris Verges 408-500-2377 http://www.cyberswitching.com =20 =20 From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Sunday, March 13, 2011 3:25 PM To: Chris Verges Cc: Bruce Nordman; Rolf Winter; eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Hi Chris, =20 I have just a question for clarification:=20 What do you call an 'interface'? Is it just a set of power states,=20 such as the set of DMTF power states=20 or the set of ACPI power states? Or is it more than this? =20 Thanks, =20 Juergen =20 =20 Am 12.03.2011 um 02:07 schrieb Chris Verges: Hi Bruce, =20 Please don't take silence as a form of acceptance. That's a dangerous = assumption. =20 My position is that a single state mechanism is not appropriate for EMAN = to consider. EMAN should support multiple state mechanisms, that = coexist with each other. =20 Consider the following scenario: =20 Three forms of state management: ACPI, DMTF, and PDU State Management. = (PDU states include on, off, reboot, tripped, and shed. Only for = example purposes, exact details to be worked out later.) =20 server-a - supports ACPI only server-b - supports ACPI and DMTF PDU - supports EMAN PDU State Management =20 I propose that we allow each device to support the modality that makes = sense for that device. The key is not in which modality is supported, = but rather how the user accesses the modality. Why would we try to = limit innovation by restricting what people can do? =20 Expose different hooks to allow a user to access ACPI, DMTF, and/or PDU = State Management through three different interfaces: =20 emanStateControlAcpi - implemented by entities which know how to respond = to ACPI states emanStateControlDmtf - implemented by entities which know how to respond = to DMTF states emanStateControlPdu - implemented by entities which know how to respond = to PDU State Management =20 This makes the EMAN schema more powerful and allows the market to adapt = easily as future changes in technologies and our understanding of how to = use those technologies improves. =20 Chris =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Bruce Nordman Sent: Friday, March 11, 2011 4:43 PM To: Rolf Winter Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Good discussion. Batteries are a specific example of a case in which a device has a = secondary function which can consume significant amounts of power, and the = secondary function is independent of the primary one. My computer is an iMac with = an integrated display, so the display is secondary to the primary function = of computation, but unlike the battery, its function is not independent (display always = powered down when the computational part is). Another example like the battery could be a TV with an integral video = recorder. The recorder can be active when the TV display is asleep or off. A = third example is an imaging MFD that does printing, copying, and scanning; it may have = the scanner active at relatively low power, but the heat-intensive toner = fusing unit powered down. Life would be simpler if devices were not = multi-functional. I think we should insist on devices having a primary function (that is = afterall how "identity" works), and the power state reflects that function. = Simple devices with internal batteries can consume a lot of power in sleep or off. = More sophisticated devices may choose to use the eman features for exposing the consumption = of the battery and balance of the system, and then have a state for the batter = exposed. We need to enable this but not require it. I am assuming that we will usually have both power state and current = power draw in watts, so the NMS will look at both (and the product's identity) = in deciding what is going on. (Perhaps part of identity is reporting if a = non-trivial battery is present (though this can be a dynamic characteristic).) So, one can look at power level, at power state, or both. I think = having both addresses Rolf's concerns. =20 For Juergen's note about the states of off-but charging (so high power), and on (and presumably AC-connected) but running only off of battery = power (so no AC draw), that confirms the need to have the actual mains power level. There have been notebook PCs designed to go off-grid in the = afternoon to avoid times of high electricity demand, so this is a very real = scenario. More important from my point of view, is that no one on this thread has = jumped to the defense of ACPI/DMTF. I am more convinced than ever that they = are a distraction for our purposes. --Bruce On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = wrote: Hi, just thinking out loud here. The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here = http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we = have battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the trade-offs: Option A) You can always tell from the device power state whether it is = drawing power or not ("off but charging" e.g.) and you might be able to = order them in a way that a higher state always translates to higher = power draw. It however seems to complicate power states. Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be really = "off but charging"). The device power states can be modelled cleaner = though and you'd need to look closer to see what the battery state is to = be sure there is no power draw. Is that the trade-off we're talking about or is there anything else that = needs to be considered? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Juergen Quittek > Sent: Freitag, 11. M=E4rz 2011 10:37 > To: Bruce Nordman > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > Hi Bruce, > > I understand your preference for a simple off-sleep-on model for power > states. > How would we model a device with a battery then > - it is off, but the empty battery is being charged > - it is on, but fully supplied with power from the battery. > > On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep- > on? > > Thanks, > > Juergen > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > (all below as contributor) > > > > > For many decades, electrical products were usually just on or = off > - a 2-state power model. In the last several decades, we have added > many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. Our discussions around > power states boil down to what complexity do we want to add to the 3- > state model, and why the burden is justified. > > > > > > In discussions on this email list, in I-drafts, and in person, > the existing listings of power states from ACPI and DMTF are often > referenced as good candidates for eman to adopt in some way. ACPI is = a > hugely important technology, and it enables large amounts of user > functionality and energy savings. I am less familiar with the reach = of > DMTF in practice, but its depth and breadth of membership are > compelling. While I agree they both deserve close examination, I = think > we can safely drop them from our discussions of what to define as = their > complexity is more a distraction than an asset. > > > > > The basic ACPI list is of "Global System States" which "apply = to > the entire system". There are four of these (G0-G3); G0 is on > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems > quite minor for eman purposes). Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model. > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > quick wakeup. S4 is the hibernate state (with system memory saved in > non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). The 1-2 second > wake time from S3 for modern personal computers is compatible with = many > IP protocol usages, e.g. initiating a TCP connection. The tens of > seconds time for S4 on current systems is not. So, the only potential > addition that the Sx states add to on/sleep/off is hibernate (and > reasonable people can differ on whether it is a fourth basic state, a > form of sleep, or a form of off). > > > ACPI does define processor states (Cx) and device > states (Dx) (collectively Px), but these are the states of particular > components, not of the system as a whole. It may be useful to expose > these through some mechanism, but they are distinct from the power > state. > > > > > DMTF essentially took the ACPI Gx states plus > hibernate and added states that are commands and/or transitions. (Is > "Master Bus Reset" a power state? I think not). If we don't include > commands or transitions (I think we should not), then these reduce to > the ACPI states. > > > > > My conclusion: ACPI and DMTF do not significantly > change the 3-state power model. If we want to talk about states = beyond > the 3-state model, it is more clear to simply reference those > extensions directly (e.g. how best to treat hibernate). Note that = this > discussion - and all others on the list - are grounded in electronic > devices. Other devices generally have a 2-state model (e.g. a light), > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > --Bruce > > > > > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman =20 ------_=_NextPart_001_01CBE1D7.3D3DD720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

An interface is an object as described in emanControlTable in = draft-verges.=A0 There are multiple objects contained in = emanControlTable, one for each type: emanAcpiControl, = emanDmtfControl, etc.=A0 An entity can implement one or more = interfaces as is understood and supported by the = entity.

 

Proposed additional interfaces could be emanBatteryControl and = emanPduControl, for example.

 

An entity might implement multiple interfaces at the same time.=A0 = How the entity chooses to handle this is up to the entity and what makes = sense for the entity.=A0 In the case of ACPI and DMTF, the linkage = between these is defined by the DMTF standard and should be = observed.

 

Thanks,

Chris

 

--

Chris Verges

408-500-2377

http://www.cyberswitching.com<= /span>

 

From:= = Juergen Quittek [mailto:ietf@quittek.at]
Sent: Sunday, March = 13, 2011 3:25 PM
To: Chris Verges
Cc: Bruce Nordman; = Rolf Winter; eman mailing list
Subject: Re: [eman] Power = states - time to dump ACPI and DMTF

 

Hi = Chris,

 

I = have just a question for = clarification: 

What = do you call an 'interface'?

Is it just a set of power = states, 

such as the = set of DMTF power states 

or the set of ACPI power = states?

Or is it more than = this?

 

Thanks,

 

    Juergen

 

 

Am = 12.03.2011 um 02:07 schrieb Chris Verges:



Hi Bruce,

 

Please don’t take silence as a form of acceptance.  = That’s a dangerous assumption.

 

My position is that a single state mechanism is not appropriate for = EMAN to consider.  EMAN should support multiple state mechanisms, = that coexist with each other.

 

Consider the following scenario:

 

Three forms of state management: ACPI, DMTF, and PDU State = Management.  (PDU states include on, off, reboot, = tripped, and shed.  Only for = example purposes, exact details to be worked out = later.)

 

server-a – supports ACPI only

server-b – supports ACPI and DMTF

PDU – supports EMAN PDU State = Management

 

I propose that we allow each device to support the modality that = makes sense for that device.  The key is not in which modality is = supported, but rather how the user accesses the modality.  Why = would we try to limit innovation by restricting what people can = do?

 

Expose different hooks to allow a user to access ACPI, DMTF, and/or = PDU State Management through three different = interfaces:

 

emanStateControlAcpi – implemented by entities which know how = to respond to ACPI states

emanStateControlDmtf – implemented by entities which know how = to respond to DMTF states

emanStateControlPdu – implemented by entities which know how to = respond to PDU State Management

 

This makes the EMAN schema more powerful and allows the market to = adapt easily as future changes in technologies and our understanding of = how to use those technologies = improves.

 

Chris

 

 

From:=  eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]=  On Behalf Of Bruce = Nordman
Sent: Friday, March 11, 2011 4:43 = PM
To: Rolf = Winter
Cc: eman mailing = list
Subject: Re: [eman] Power states - = time to dump ACPI and DMTF

 

Good discussion.

Batteries are a = specific example of a case in which a device has a secondary
function = which can consume significant amounts of power, and the = secondary
function is independent of the primary one.  My = computer is an iMac with an
integrated display, so the display is = secondary to the primary function of computation,
but unlike the = battery, its function is not independent (display always powered
down = when the computational part is).

Another example like the battery = could be a TV with an integral video recorder.
The recorder can be = active when the TV display is asleep or off.  A third example
is = an imaging MFD that does printing, copying, and scanning; it may have = the
scanner active at relatively low power, but the heat-intensive = toner fusing unit
powered down.  Life would be simpler if = devices were not multi-functional.

I think we should insist on = devices having a primary function (that is afterall
how = "identity" works), and the power state reflects that = function.  Simple devices
with internal batteries can consume a = lot of power in sleep or off.  More sophisticated
devices may = choose to use the eman features for exposing the consumption of = the
battery and balance of the system, and then have a state for the = batter exposed.
We need to enable this but not require it.

I = am assuming that we will usually have both power state and current = power
draw in watts, so the NMS will look at both (and the product's = identity) in
deciding what is going on.  (Perhaps part of = identity is reporting if a non-trivial
battery is present (though = this can be a dynamic characteristic).)
So, one can look at power = level, at power state, or both.  I think having
both addresses = Rolf's concerns.  

For Juergen's note = about the states of off-but charging (so high power),
and on (and = presumably AC-connected) but running only off of battery power
(so no = AC draw), that confirms the need to have the actual mains = power
level.  There have been notebook PCs designed to go = off-grid in the afternoon
to avoid times of high electricity demand, = so this is a very real scenario.


More important from my point = of view, is that no one on this thread has jumped
to the defense of = ACPI/DMTF.  I am more convinced than ever that they are
a = distraction for our purposes.

--Bruce

On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter <Rolf.Winter@neclab.eu> = wrote:

Hi,

just = thinking out loud here.

The thing which seems to complicate = matters here significantly is batteries. You either A) try to consider = battery state in the devices' power state or you B) leave it separate in = its own MIB module (as described e.g. here http://tools.ietf.org/html/draft-quittek-eman-battery-m= ib-00 where we have = battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the = trade-offs:

Option A) You can always tell from the device power = state whether it is drawing power or not ("off but charging" = e.g.) and you might be able to order them in a way that a higher state = always translates to higher power draw. It however seems to complicate = power states.

Option B) If a battery is present, you cannot tell = from the device's power state whether is it drawing power or not = ("off" could be really "off but charging"). The = device power states can be modelled cleaner though and you'd need to = look closer to see what the battery state is to be sure there is no = power draw.

Is that the trade-off we're talking about or is there = anything else that needs to be = considered?

Best,

Rolf

NEC Europe Limited | = Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014



> = -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On = Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 = 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> = Subject: Re: [eman] Power states - time to dump ACPI and = DMTF
>
> Hi Bruce,
>
> I understand your = preference for a simple off-sleep-on model for power
> = states.
> How would we model a device with a battery then
> =   - it is off, but the empty battery is being charged
> =   - it is on, but fully supplied with power from the = battery.
>
> On way would be treating the (internal) battery = as separate device.
> In this case: Can we map = charging/discharging/full/empty to off-sleep-
> = on?
>
> Thanks,
>
>     = Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce = Nordman:
>
>
>       (all below as = contributor)
>
>
>
>
>     =   For many decades, electrical products were usually just on or = off
> - a 2-state power model.  In the last several decades, = we have added
> many electronic products with a 3-state model - = on, sleep, and off.
> This is necessary and existing complexity. =  Our discussions around
> power states boil down to what = complexity do we want to add to the 3-
> state model, and why the = burden is justified.
>
>
>
>
>
> =       In discussions on this email list, in I-drafts, and = in person,
> the existing listings of power states from ACPI and = DMTF are often
> referenced as good candidates for eman to adopt = in some way.  ACPI is a
> hugely important technology, and it = enables large amounts of user
> functionality and energy savings. =  I am less familiar with the reach of
> DMTF in practice, but = its depth and breadth of membership are
> compelling.  While = I agree they both deserve close examination, I think
> we can = safely drop them from our discussions of what to define as their
> = complexity is more a distraction than an = asset.
>
>
>
>
>       The = basic ACPI list is of  "Global System States" which = "apply to
> the entire system".  There are four of = these (G0-G3); G0 is on
> ("working") and G1 is sleep = ("sleeping").  G2 and G3 both forms of off
> (only = distinguished by whether a device is completely depowered and
> = whether it is safe to disassemble or not, and these distinctions = seems
> quite minor for eman purposes).  Thus, the ACPI = Global states are
> essentially on/sleep/off, the 3-state power = model.
>
>               =     ACPI lists five "Sx" sleep states (S0 is on). =  S5 is
> actually the G2 Off state (so not a sleep state at = all), and current
> implementations do not use S1 or S2, so in = practice there are only two
> ACPI sleep states: S3 and S4. =  S3 is the ordinary system sleep, with
> quick wakeup. =  S4 is the hibernate state (with system memory saved in
> = non-volatile memory, possibly a hard disk) which typically has = long
> times to return to operation (often tens of seconds). =   The 1-2 second
> wake time from S3 for modern personal = computers is compatible with many
> IP protocol usages, e.g. = initiating a TCP connection.  The tens of
> seconds time for = S4 on current systems is not.  So, the only potential
> = addition that the Sx states add to on/sleep/off is hibernate = (and
> reasonable people can differ on whether it is a fourth = basic state, a
> form of sleep, or a form of = off).
>
>
>             =       ACPI does define processor states (Cx) and = device
> states (Dx) (collectively Px), but these are the states = of particular
> components, not of the system as a whole.  It = may be useful to expose
> these through some mechanism, but they = are distinct from the power
> = state.
>
>
>
>
>       =             DMTF essentially took the ACPI = Gx states plus
> hibernate and added states that are commands = and/or transitions.  (Is
> "Master Bus Reset" a = power state?  I think not).  If we don't include
> = commands or transitions (I think we should not), then these reduce = to
> the ACPI states.
>
>
>
>
> =                   My = conclusion: ACPI and DMTF do not significantly
> change the = 3-state power model.  If we want to talk about states = beyond
> the 3-state model, it is more clear to simply reference = those
> extensions directly (e.g. how best to treat hibernate). =  Note that this
> discussion - and all others on the list - = are grounded in electronic
> devices.  Other devices = generally have a 2-state model (e.g. a light),
> or 3 states, but = on, off, and "ready" (think a microwave = oven).
>
>
>
>
>       = --Bruce
>
>
>
>
>       = --
>       Bruce Nordman
>     =   Lawrence Berkeley National Laboratory
>     =   eetd.lbl.gov/ea/nordman
>     =   BNordman@LBL.gov
>   =     510-486-7089
>       = m: 510-501-7943
>
>     =   _______________________________________________
>   =     eman mailing list
>       eman@ietf.org
>     =   https://www.ietf.org/mailman/listinfo/eman
><= br>>




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

________________________= _______________________
eman mailing list
eman@ietf.org
https://www.ietf.org/= mailman/listinfo/eman

 

------_=_NextPart_001_01CBE1D7.3D3DD720-- From jparello@cisco.com Sun Mar 13 17:33:15 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738E23A6A46 for ; Sun, 13 Mar 2011 17:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywkqmIM8NB8W for ; Sun, 13 Mar 2011 17:33:11 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A2CBA3A6A34 for ; Sun, 13 Mar 2011 17:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=9707; q=dns/txt; s=iport; t=1300062874; x=1301272474; h=mime-version:subject:date:message-id:references:from:to: cc; bh=6kalIUOdwBqj2mo0qpP9UfbcbdIwNtoLYP5PSyrQPDo=; b=ObQg4m+ip0/18Zlp9qCN4SrSNKxYrnLUk3QCQmjEy6juJIttYE0BYDi6 Pd9QfqqbC+OhU9rMzpM0fz6iphQot9FzyAt2r998yZdEUHHiGlMD1kG/0 zVkTAN47s+bTulfSLGOOEKvPJ4H7LdiZYqpnIoFjnltZf2liXSo7gVI0N 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFb/fE2tJXG+/2dsb2JhbACmD3elEppvgnwZgk0EhSuKew X-IronPort-AV: E=Sophos;i="4.62,312,1297036800"; d="scan'208,217";a="277614428" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 14 Mar 2011 00:34:34 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2E0YHn0009955; Mon, 14 Mar 2011 00:34:33 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 17:34:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE1DF.92BC54B4" Date: Sun, 13 Mar 2011 17:33:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AcvhxIZTRicGwyBAQGG1B+MnonaLdQAGuwuA References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd><68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local><791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd><0851C4CF-D108-4BE9-AB17-A24F05FB72D4@quittek.at> From: "John Parello (jparello)" To: "Bruce Nordman" , "Juergen Quittek" X-OriginalArrivalTime: 14 Mar 2011 00:34:27.0393 (UTC) FILETIME=[9335E310:01CBE1DF] Cc: Rolf Winter , eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 00:33:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE1DF.92BC54B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruce, Agree our mandate is for monitoring. I've brought up the scenario a few = times about how state of a device is needed to monitor. How can that be addressed in your suggested model? Thanks Jp -----Original Message----- From: eman-bounces@ietf.org on behalf of Bruce Nordman Sent: Sun 3/13/2011 2:20 PM To: Juergen Quittek Cc: eman mailing list; Rolf Winter Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 I think we are making this more complicated than necessary. First, our mandate is for monitoring, not control. We should be thinking about control (as we are), but should not complicate the monitoring protocol for control reasons. I know that eman will in future be used by some devices for control (and I support their ability to do so in future), but the great majority I believe will only use its monitoring features. Second, the NMS will know the identity of the device being monitored, so can use that information in drawing conclusions. The power state does not need to be burdened with trying to be highly informative by itself. The device HAS a basic power state already - we are just trying to expose that which already exists. When devices have the ability and need to be more elaborate in what they communicate (e.g. exposing battery details), we can facilitate that, but for those that can't or don't need this, we should allow them to be simple. Batteries are not involved in the vast majority of electricity use, and the NMS will know if the device does (or could) have one and so can draw appropriate conclusions. To Juergen's question, the assumptions that can be made about a device's energy based solely on the power state depends on the device. We don't need to say more. --Bruce On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek = wrote: > Hi Rolf, > > One of the important questions to be answered is: > Do we want to be able to make assumptions on a device's energy = consumption > based on the power state? > If a devices's power state is off, what would it tell us, if not: The > devices does not need any power. > > If this is not the case, we are rather talking about functional states = with > some power-related properties, > But if these states do not serve as basis for power-related = assumptions on > the device, then the name > POWER state is misleading and not appropriate any more. > > Thanks, > > Juergen > > > Am 13.03.2011 um 14:34 schrieb Rolf Winter: > > > Chris, Ted, > > > > I wasn't really implying anything here. To me, it seemed that a lot = of > the discussion was triggered by the fact that it is difficult to = accommodate > batteries directly in a device's power state. So I was wondering why = one > would actually do that (instead of treating it as a completely = different > entity). My mail tried to summarize the differences and I was asking = whether > there is more. I believe this is something we want to figure out = quickly as > a bunch of things will rely on this decision. But it might be that a = simple > model would work here. E.g. you'd have the state sleep (which means = e.g. > that the functional components draw little power) and a sub-state that = says > batteries charging (or not, or which "type" of charging) which tells = you > that the device as a whole is drawing significant power. The same for = on and > off states of course. Or you can have all separate in a battery MIB. = In > either case, I think other battery related information should be in a > separate MIB. E.g. whether a battery is fully charged, empty, it's = age, > number of charging cycles and so forth. So which one should it be, = which of > the tradeoffs is most important to us? > > > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > ... > > --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 ------_=_NextPart_001_01CBE1DF.92BC54B4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] Power states - time to dump ACPI and DMTF

Hi Bruce,

Agree our mandate is for monitoring. I've brought up the scenario a few = times about how state of a device is needed to monitor.

How can that be addressed in your suggested model?

Thanks
Jp


-----Original Message-----
From: eman-bounces@ietf.org on behalf of Bruce Nordman
Sent: Sun 3/13/2011 2:20 PM
To: Juergen Quittek
Cc: eman mailing list; Rolf Winter
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

I think we are making this more complicated than necessary.
First, our mandate is for monitoring, not control.  We should = be
thinking about control (as we are), but should not complicate
the monitoring protocol for control reasons.  I know that eman
will in future be used by some devices for control (and I support
their ability to do so in future), but the great majority I believe = will
only use its monitoring features.

Second, the NMS will know the identity of the device being
monitored, so can use that information in drawing conclusions.
The power state does not need to be burdened with trying to
be highly informative by itself.  The device HAS a basic power
state already - we are just trying to expose that which already
exists.

When devices have the ability and need to be more elaborate
in what they communicate (e.g. exposing battery details), we
can facilitate that, but for those that can't or don't need this,
we should allow them to be simple.

Batteries are not involved in the vast majority of electricity
use, and the NMS will know if the device does (or could)
have one and so can draw appropriate conclusions.

To Juergen's question, the assumptions that can be made
about a device's energy based solely on the power state
depends on the device.  We don't need to say more.

--Bruce


On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek <ietf@quittek.at> = wrote:

> Hi Rolf,
>
> One of the important questions to be answered is:
> Do we want to be able to make assumptions on a device's energy = consumption
> based on the power state?
> If a devices's power state is off, what would it tell us, if not: = The
> devices does not need any power.
>
> If this is not the case, we are rather talking about functional = states with
> some power-related properties,
> But if these states do not serve as basis for power-related = assumptions on
> the device, then the name
> POWER state is misleading and not appropriate any more.
>
> Thanks,
>
>    Juergen
>
>
> Am 13.03.2011 um 14:34 schrieb Rolf Winter:
>
> > Chris, Ted,
> >
> > I wasn't really implying anything here. To me, it seemed that = a lot of
> the discussion was triggered by the fact that it is difficult to = accommodate
> batteries directly in a device's power state. So I was wondering = why one
> would actually do that (instead of treating it as a completely = different
> entity). My mail tried to summarize the differences and I was = asking whether
> there is more. I believe this is something we want to figure out = quickly as
> a bunch of things will rely on this decision. But it might be that = a simple
> model would work here. E.g. you'd have the state sleep (which means = e.g.
> that the functional components draw little power) and a sub-state = that says
> batteries charging (or not, or which "type" of charging) = which tells you
> that the device as a whole is drawing significant power. The same = for on and
> off states of course. Or you can have all separate in a battery = MIB. In
> either case, I think other battery related information should be in = a
> separate MIB. E.g. whether a battery is fully charged, empty, it's = age,
> number of charging cycles and so forth. So which one should it be, = which of
> the tradeoffs is most important to us?
> >
> >
> > Best,
> >
> > Rolf
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria = Road,
> London W3 6BL | Registered in England 2832014
> ...
>
>


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

------_=_NextPart_001_01CBE1DF.92BC54B4-- From tirth.ghose@gmail.com Mon Mar 14 00:01:53 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19F53A6C37 for ; Mon, 14 Mar 2011 00:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDAwN8MMkD-k for ; Mon, 14 Mar 2011 00:01:51 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5AFD33A67FF for ; Mon, 14 Mar 2011 00:01:51 -0700 (PDT) Received: by iwl42 with SMTP id 42so5771607iwl.31 for ; Mon, 14 Mar 2011 00:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YwHVVJc5pCGLQOx+zJ2tEb8keTA4nUyhgLq4GH4UsII=; b=h4QPcGOVEIviA8YLuhoQMYHOgBCM8j24NYkDeFa9BAU7foOeWhzeOshK8uD6FFlJrG 5bpj8OBk7r/qvAjthv9BL9d7ZzH+MEi0fKFQnYADXYGV3ffZgYN0LCWh/htq3XnOZkYO x/gWUNh6Qcgp2ARdE1PZpPmAnFzYGQZFAN2N8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=te2IpnoewUPkmIqTUlNcQzf4cGoKWcAKA7IPby3SfjQYwm1T3AH6bU9UwHrLGoX1wP UaJgGdhcPCb+ajaL4W3c9rbqssNgiTy5JLMbNSPxQSkyuYO7yHmi1r7GmabHbuaPr8pR er2ZhI77IvgUPI/4o1rtrLzuSd/UOIL2kpxYE= MIME-Version: 1.0 Received: by 10.43.54.210 with SMTP id vv18mr16017460icb.103.1300086194424; Mon, 14 Mar 2011 00:03:14 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Mon, 14 Mar 2011 00:03:14 -0700 (PDT) In-Reply-To: <865E90F5-30BD-40D5-8713-D5C222ECE359@quittek.at> References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <865E90F5-30BD-40D5-8713-D5C222ECE359@quittek.at> Date: Mon, 14 Mar 2011 00:03:14 -0700 X-Google-Sender-Auth: vBc8JHMjQLUdb7jII5nwpBymHfs Message-ID: From: Ted Ghose To: Juergen Quittek Content-Type: multipart/alternative; boundary=bcaec51dd719cbc9be049e6be7f8 Cc: eman mailing list , Rolf Winter , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 07:01:54 -0000 --bcaec51dd719cbc9be049e6be7f8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Juergen Yes, then I agree to what you are saying. Can we not just solve it by defining states like 0 - device off not charging 1 - device off charging ::::::: and we could exactly follow your method when and how to report thanks -tg- On Sun, Mar 13, 2011 at 4:08 PM, Juergen Quittek wrote: > Hi Ted, > > Am 11.03.2011 um 17:00 schrieb Ted Ghose: > > Hi Rolf, Juergen > > I like Rolf's idea very much. We should extend number of states > to accommodate other sub states. > > Here is one question I do have for Juergon, as handling the battery keeps > coming up in all the discussions. > > If the device is off, but battery is charging, who is reporting that and > how? Is battery itself has the intelligence to do so? In that case, can w= e > treat it as a separate device independent of the device it is connected t= o, > and then we could simplify the model. > > > Yes, Then we need power states for batteries, which may be different to > (off, sleep, on). > > In the other case, though, if device is turned off, there is no one to te= ll > what the battery is doing, unless an intelligent PDU or someone is aware = of > that device. Which comes to some source - sink model as well. > > > Devices have the capability to notify a management system when they switc= h > power states. > There is no need for continuous reporting once you reported you're off. A > PC may send a > notification before going to off or sleep mode. And of course it may send= a > wake-up notification > when waking up from sleep or when booting. > > It does not seem to be a smart idea to wake up the device just to report > that charging of > the battery is complete and thus common devices don't do so. But if you > measure power > with an external meter, a management system (or your "parent") might be > able to detect > this point in time. Alternatively, you could send a notification to your > management system > (or parent) indicating: I'm going to sleep mode an expect a charging time > of 75 minutes. > Then the management system (or parent) could assume (and report) for 75 > minutes > "device in state "sleep with charging batteries" and then switch to plain > "sleep". > > Thanks, > > Juergen > > Could you please clarify your thoughts? > > thanks > > -tg- > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > Save time... see it my way > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > > > On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter wrote= : > >> Hi, >> >> just thinking out loud here. >> >> The thing which seems to complicate matters here significantly is >> batteries. You either A) try to consider battery state in the devices' p= ower >> state or you B) leave it separate in its own MIB module (as described e.= g. >> here http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where >> we have battery states full(1), partiallyCharged(2), empty(3), charging(= 4), >> discharging(5), unknown(6)). I think these are the trade-offs: >> >> Option A) You can always tell from the device power state whether it is >> drawing power or not ("off but charging" e.g.) and you might be able to >> order them in a way that a higher state always translates to higher powe= r >> draw. It however seems to complicate power states. >> >> Option B) If a battery is present, you cannot tell from the device's pow= er >> state whether is it drawing power or not ("off" could be really "off but >> charging"). The device power states can be modelled cleaner though and y= ou'd >> need to look closer to see what the battery state is to be sure there is= no >> power draw. >> >> Is that the trade-off we're talking about or is there anything else that >> needs to be considered? >> >> Best, >> >> Rolf >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lond= on >> W3 6BL | Registered in England 2832014 >> >> >> > -----Original Message----- >> > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf O= f >> > Juergen Quittek >> > Sent: Freitag, 11. M=E4rz 2011 10:37 >> > To: Bruce Nordman >> > Cc: eman mailing list >> > Subject: Re: [eman] Power states - time to dump ACPI and DMTF >> > >> > Hi Bruce, >> > >> > I understand your preference for a simple off-sleep-on model for power >> > states. >> > How would we model a device with a battery then >> > - it is off, but the empty battery is being charged >> > - it is on, but fully supplied with power from the battery. >> > >> > On way would be treating the (internal) battery as separate device. >> > In this case: Can we map charging/discharging/full/empty to off-sleep- >> > on? >> > >> > Thanks, >> > >> > Juergen >> > >> > >> > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: >> > >> > >> > (all below as contributor) >> > >> > >> > >> > >> > For many decades, electrical products were usually just on or of= f >> > - a 2-state power model. In the last several decades, we have added >> > many electronic products with a 3-state model - on, sleep, and off. >> > This is necessary and existing complexity. Our discussions around >> > power states boil down to what complexity do we want to add to the 3- >> > state model, and why the burden is justified. >> > >> > >> > >> > >> > >> > In discussions on this email list, in I-drafts, and in person, >> > the existing listings of power states from ACPI and DMTF are often >> > referenced as good candidates for eman to adopt in some way. ACPI is = a >> > hugely important technology, and it enables large amounts of user >> > functionality and energy savings. I am less familiar with the reach o= f >> > DMTF in practice, but its depth and breadth of membership are >> > compelling. While I agree they both deserve close examination, I thin= k >> > we can safely drop them from our discussions of what to define as thei= r >> > complexity is more a distraction than an asset. >> > >> > >> > >> > >> > The basic ACPI list is of "Global System States" which "apply t= o >> > the entire system". There are four of these (G0-G3); G0 is on >> > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off >> > (only distinguished by whether a device is completely depowered and >> > whether it is safe to disassemble or not, and these distinctions seems >> > quite minor for eman purposes). Thus, the ACPI Global states are >> > essentially on/sleep/off, the 3-state power model. >> > >> > ACPI lists five "Sx" sleep states (S0 is on). S5 is >> > actually the G2 Off state (so not a sleep state at all), and current >> > implementations do not use S1 or S2, so in practice there are only two >> > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with >> > quick wakeup. S4 is the hibernate state (with system memory saved in >> > non-volatile memory, possibly a hard disk) which typically has long >> > times to return to operation (often tens of seconds). The 1-2 second >> > wake time from S3 for modern personal computers is compatible with man= y >> > IP protocol usages, e.g. initiating a TCP connection. The tens of >> > seconds time for S4 on current systems is not. So, the only potential >> > addition that the Sx states add to on/sleep/off is hibernate (and >> > reasonable people can differ on whether it is a fourth basic state, a >> > form of sleep, or a form of off). >> > >> > >> > ACPI does define processor states (Cx) and device >> > states (Dx) (collectively Px), but these are the states of particular >> > components, not of the system as a whole. It may be useful to expose >> > these through some mechanism, but they are distinct from the power >> > state. >> > >> > >> > >> > >> > DMTF essentially took the ACPI Gx states plus >> > hibernate and added states that are commands and/or transitions. (Is >> > "Master Bus Reset" a power state? I think not). If we don't include >> > commands or transitions (I think we should not), then these reduce to >> > the ACPI states. >> > >> > >> > >> > >> > My conclusion: ACPI and DMTF do not significantly >> > change the 3-state power model. If we want to talk about states beyon= d >> > the 3-state model, it is more clear to simply reference those >> > extensions directly (e.g. how best to treat hibernate). Note that thi= s >> > discussion - and all others on the list - are grounded in electronic >> > devices. Other devices generally have a 2-state model (e.g. a light), >> > or 3 states, but on, off, and "ready" (think a microwave oven). >> > >> > >> > >> > >> > --Bruce >> > >> > >> > >> > >> > -- >> > Bruce Nordman >> > Lawrence Berkeley National Laboratory >> > eetd.lbl.gov/ea/nordman >> > BNordman@LBL.gov >> > <510-486-7089>510-486-7089 >> > m: <510-501-7943>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 >> > > > --bcaec51dd719cbc9be049e6be7f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi=A0Juergen=A0

Yes, then I agree to what you are saying= . Can we not just solve it by defining states like


0 - device off not charging
1 - device off chargi= ng
:::::::

and we could exactly follow your meth= od when and how to report

thanks

-tg-



On Sun, Mar 13, 2011 at 4:08 PM, Juergen= Quittek <ietf@quit= tek.at> wrote:
Hi Ted,

Am 11.03.2011= um 17:00 schrieb Ted Ghose:

Hi Rolf, Juergen

I like Rolf's idea very much= . We should extend number of states to=A0accommodate=A0other sub states.=A0=

Here is one question I do have for Juergon, as handling= the battery keeps coming up in all the discussions.=A0

If the device is off, but battery is charging, who is r= eporting that and how? Is battery itself has the=A0intelligence to do so? I= n that case, can we treat it as a=A0separate=A0device=A0independent of the = device it is connected to, and then we could simplify the model.

Yes, Then we need power states for batter= ies, which may be different to (off, sleep, on).

In the other case, though, if device i= s turned off, there is no one to tell what the battery is doing, unless an= =A0intelligent=A0PDU or someone is aware of that device. Which comes to som= e source - sink model as well.

Devices have the capability to notify a m= anagement system when they switch power states.=A0
There is no ne= ed for continuous reporting once you reported you're off. A PC may send= a=A0
notification before going to off or sleep mode. And of course it may s= end a wake-up notification
when waking up from sleep or when boot= ing.

It does not seem to be a smart idea to wake u= p the device just to report that charging of=A0
the battery is complete and thus common devices don't do so. But i= f you measure power=A0
with an external meter, a management syste= m (or your "parent") =A0might be able to =A0detect=A0
t= his point in time. Alternatively, you could send a notification to your man= agement=A0system=A0
(or parent) indicating: I'm going to sleep mode an expect a chargi= ng time of 75=A0minutes.
Then the management system (or parent) c= ould assume (and report) for 75 minutes=A0
"device in state = "sleep with charging batteries" and then switch to plain "sl= eep".

Thanks,

=A0=A0 =A0Juergen

=
Could you please clarify your thoughts?

thanks

-tg-
*:-.,_,.-:= *'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:*= *:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time... see it my way
*:= -.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-= .,_,.-:**:-.,_,.


On Fri, Mar 11, 2011 at 5:36 AM, Rolf Wi= nter <Rolf.Winter@neclab.eu> wrote:
Hi,

just thinking out loud here.

The thing which seems to complicate matters here significantly is batteries= . You either A) try to consider battery state in the devices' power sta= te or you B) leave it separate in its own MIB module (as described e.g. her= e http://tools.ietf.org/html/draft-quittek-eman-battery-mib= -00 where we have battery states full(1), partiallyCharged(2), empty(3)= , charging(4), discharging(5), unknown(6)). I think these are the trade-off= s:

Option A) You can always tell from the device power state whether it is dra= wing power or not ("off but charging" e.g.) and you might be able= to order them in a way that a higher state always translates to higher pow= er draw. It however seems to complicate power states.

Option B) If a battery is present, you cannot tell from the device's po= wer state whether is it drawing power or not ("off" could be real= ly "off but charging"). The device power states can be modelled c= leaner though and you'd need to look closer to see what the battery sta= te is to be sure there is no power draw.

Is that the trade-off we're talking about or is there anything else tha= t needs to be considered?

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014


> -----Original Message-----
> From: eman-= bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [eman] Power states - time to dump ACPI and DMTF
>
> Hi Bruce,
>
> I understand your preference for a simple off-sleep-on model for power=
> states.
> How would we model a device with a battery then
> =A0 - it is off, but the empty battery is being charged
> =A0 - it is on, but fully supplied with power from the battery.
>
> On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep-=
> on?
>
> Thanks,
>
> =A0 =A0 Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce Nordman:
>
>
> =A0 =A0 =A0 (all below as contributor)
>
>
>
>
> =A0 =A0 =A0 For many decades, electrical products were usually just on= or off
> - a 2-state power model. =A0In the last several decades, we have added=
> many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. =A0Our discussions around > power states boil down to what complexity do we want to add to the 3-<= br> > state model, and why the burden is justified.
>
>
>
>
>
> =A0 =A0 =A0 In discussions on this email list, in I-drafts, and in per= son,
> the existing listings of power states from ACPI and DMTF are often
> referenced as good candidates for eman to adopt in some way. =A0ACPI i= s a
> hugely important technology, and it enables large amounts of user
> functionality and energy savings. =A0I am less familiar with the reach= of
> DMTF in practice, but its depth and breadth of membership are
> compelling. =A0While I agree they both deserve close examination, I th= ink
> we can safely drop them from our discussions of what to define as thei= r
> complexity is more a distraction than an asset.
>
>
>
>
> =A0 =A0 =A0 The basic ACPI list is of =A0"Global System States&qu= ot; which "apply to
> the entire system". =A0There are four of these (G0-G3); G0 is on<= br> > ("working") and G1 is sleep ("sleeping"). =A0G2 an= d G3 both forms of off
> (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems=
> quite minor for eman purposes). =A0Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ACPI lists five "Sx" sle= ep states (S0 is on). =A0S5 is
> actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two=
> ACPI sleep states: S3 and S4. =A0S3 is the ordinary system sleep, with=
> quick wakeup. =A0S4 is the hibernate state (with system memory saved i= n
> non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). =A0 The 1-2 seco= nd
> wake time from S3 for modern personal computers is compatible with man= y
> IP protocol usages, e.g. initiating a TCP connection. =A0The tens of > seconds time for S4 on current systems is not. =A0So, the only potenti= al
> addition that the Sx states add to on/sleep/off is hibernate (and
> reasonable people can differ on whether it is a fourth basic state, a<= br> > form of sleep, or a form of off).
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ACPI does define processor states = (Cx) and device
> states (Dx) (collectively Px), but these are the states of particular<= br> > components, not of the system as a whole. =A0It may be useful to expos= e
> these through some mechanism, but they are distinct from the power
> state.
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DMTF essentially took the ACPI Gx = states plus
> hibernate and added states that are commands and/or transitions. =A0(I= s
> "Master Bus Reset" a power state? =A0I think not). =A0If we = don't include
> commands or transitions (I think we should not), then these reduce to<= br> > the ACPI states.
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 My conclusion: ACPI and DMTF do no= t significantly
> change the 3-state power model. =A0If we want to talk about states bey= ond
> the 3-state model, it is more clear to simply reference those
> extensions directly (e.g. how best to treat hibernate). =A0Note that t= his
> discussion - and all others on the list - are grounded in electronic > devices. =A0Other devices generally have a 2-state model (e.g. a light= ),
> or 3 states, but on, off, and "ready" (think a microwave ove= n).
>
>
>
>
> =A0 =A0 =A0 --Bruce
>
>
>
>
> =A0 =A0 =A0 --
> =A0 =A0 =A0 Bruce Nordman
> =A0 =A0 =A0 Lawrence Berkeley National Laboratory
> =A0 =A0 =A0 eetd.lbl.gov/ea/nordman
> =A0 =A0 =A0 BNor= dman@LBL.gov
> =A0 =A0 =A0 510-486-7089
> =A0 =A0 =A0 m: 510-501-7943
>
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 eman mailing list
> =A0 =A0 =A0 eman@ie= tf.org
> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/eman
>
>

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



--bcaec51dd719cbc9be049e6be7f8-- From tirth.ghose@gmail.com Sat Mar 12 13:41:19 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0332D3A68DA for ; Sat, 12 Mar 2011 13:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaNmf1cXWyTl for ; Sat, 12 Mar 2011 13:41:10 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id AF1F43A68AB for ; Sat, 12 Mar 2011 13:41:10 -0800 (PST) Received: by iyi12 with SMTP id 12so723779iyi.31 for ; Sat, 12 Mar 2011 13:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=ttQEM3BLfB6mSq2k8dqgZeYNgfovU5E4jJuD3DCQHsk=; b=dPfRntv4xyK2jar3sA54hvHj0Nws1Y6fqyHxxT9wsK4HApYg0WzwJLyQMnVZ2+klOn eyTuuePqEFCXTSlWwb6hMk94OOfGuZbugp4gpd1BRuJMTtONl66yqZJe8yu7x/PCHHgv aN1FSFhPtGPAzaCogH1DhEd7rtUv+C8XdEZ9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=P4dI7GlvdT4q7WdVjPPYCNz0tjidhl/72f7nl+kKOiqoKiQulWLcmSrewEZ5mLCLvm FueaC4TQ1JvVfAUhAI2jPljKqeXHKz9/rYquHZ0CWRyh9X1EMUOZuJb47Hn4uhz321aw 4lcxTqLhoPtNUHnGH2g4xzUNormqczNcuX5NI= Received: by 10.43.61.202 with SMTP id wx10mr13596946icb.341.1299966151151; Sat, 12 Mar 2011 13:42:31 -0800 (PST) Received: from [10.29.253.104] ([166.205.138.143]) by mx.google.com with ESMTPS id c4sm4337569ict.19.2011.03.12.13.42.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2011 13:42:30 -0800 (PST) References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--463604104 Message-Id: X-Mailer: iPhone Mail (8C148a) From: Ted Ghose Date: Sat, 12 Mar 2011 13:42:14 -0800 To: Chris Verges X-Mailman-Approved-At: Mon, 14 Mar 2011 00:08:12 -0700 Cc: eman mailing list , Rolf Winter , Bruce Nordman Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 21:41:19 -0000 --Apple-Mail-1--463604104 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Servers have batteries?=20 -tg- Sent from my iPhone On Mar 11, 2011, at 8:04 AM, "Chris Verges" wrot= e: > Hi Ted, >=20 > =20 >=20 > I might be putting words into Rolf=E2=80=99s mouth, but here are my though= ts on this: >=20 > =20 >=20 > Certain devices, like servers, that contain a Lights Out Management (LOM) c= ard will be able to report the server=E2=80=99s power supply as =E2=80=9Coff= =E2=80=9D but the battery as =E2=80=9Ccharging=E2=80=9D. This combination f= or the server entity results in the desired effect. >=20 > =20 >=20 > Rolf, anywhere in the ballpark? >=20 > =20 >=20 > Chris >=20 > =20 >=20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Te= d Ghose > Sent: Friday, March 11, 2011 8:01 AM > To: Rolf Winter > Cc: Bruce Nordman; eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF >=20 > =20 >=20 > Hi Rolf, Juergen >=20 > =20 >=20 > I like Rolf's idea very much. We should extend number of states to accommo= date other sub states.=20 >=20 > =20 >=20 > Here is one question I do have for Juergon, as handling the battery keeps c= oming up in all the discussions.=20 >=20 > =20 >=20 > If the device is off, but battery is charging, who is reporting that and h= ow? Is battery itself has the intelligence to do so? In that case, can we tr= eat it as a separate device independent of the device it is connected to, an= d then we could simplify the model. >=20 > =20 >=20 > In the other case, though, if device is turned off, there is no one to tel= l what the battery is doing, unless an intelligent PDU or someone is aware o= f that device. Which comes to some source - sink model as well. >=20 > =20 >=20 > Could you please clarify your thoughts? >=20 > =20 >=20 > thanks >=20 > =20 >=20 > -tg- > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > Save time... see it my way > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. >=20 >=20 > On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter wrote= : >=20 > Hi, >=20 > just thinking out loud here. >=20 > The thing which seems to complicate matters here significantly is batterie= s. You either A) try to consider battery state in the devices' power state o= r you B) leave it separate in its own MIB module (as described e.g. here htt= p://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we have batt= ery states full(1), partiallyCharged(2), empty(3), charging(4), discharging(= 5), unknown(6)). I think these are the trade-offs: >=20 > Option A) You can always tell from the device power state whether it is dr= awing power or not ("off but charging" e.g.) and you might be able to order t= hem in a way that a higher state always translates to higher power draw. It h= owever seems to complicate power states. >=20 > Option B) If a battery is present, you cannot tell from the device's power= state whether is it drawing power or not ("off" could be really "off but ch= arging"). The device power states can be modelled cleaner though and you'd n= eed to look closer to see what the battery state is to be sure there is no p= ower draw. >=20 > Is that the trade-off we're talking about or is there anything else that n= eeds to be considered? >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London= W3 6BL | Registered in England 2832014 >=20 >=20 >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > > Juergen Quittek > > Sent: Freitag, 11. M=C3=A4rz 2011 10:37 > > To: Bruce Nordman > > Cc: eman mailing list > > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Bruce, > > > > I understand your preference for a simple off-sleep-on model for power > > states. > > How would we model a device with a battery then > > - it is off, but the empty battery is being charged > > - it is on, but fully supplied with power from the battery. > > > > On way would be treating the (internal) battery as separate device. > > In this case: Can we map charging/discharging/full/empty to off-sleep- > > on? > > > > Thanks, > > > > Juergen > > > > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > > > > (all below as contributor) > > > > > > > > > > For many decades, electrical products were usually just on or off > > - a 2-state power model. In the last several decades, we have added > > many electronic products with a 3-state model - on, sleep, and off. > > This is necessary and existing complexity. Our discussions around > > power states boil down to what complexity do we want to add to the 3- > > state model, and why the burden is justified. > > > > > > > > > > > > In discussions on this email list, in I-drafts, and in person, > > the existing listings of power states from ACPI and DMTF are often > > referenced as good candidates for eman to adopt in some way. ACPI is a > > hugely important technology, and it enables large amounts of user > > functionality and energy savings. I am less familiar with the reach of > > DMTF in practice, but its depth and breadth of membership are > > compelling. While I agree they both deserve close examination, I think > > we can safely drop them from our discussions of what to define as their > > complexity is more a distraction than an asset. > > > > > > > > > > The basic ACPI list is of "Global System States" which "apply to > > the entire system". There are four of these (G0-G3); G0 is on > > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > > (only distinguished by whether a device is completely depowered and > > whether it is safe to disassemble or not, and these distinctions seems > > quite minor for eman purposes). Thus, the ACPI Global states are > > essentially on/sleep/off, the 3-state power model. > > > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > > actually the G2 Off state (so not a sleep state at all), and current > > implementations do not use S1 or S2, so in practice there are only two > > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > > quick wakeup. S4 is the hibernate state (with system memory saved in > > non-volatile memory, possibly a hard disk) which typically has long > > times to return to operation (often tens of seconds). The 1-2 second > > wake time from S3 for modern personal computers is compatible with many > > IP protocol usages, e.g. initiating a TCP connection. The tens of > > seconds time for S4 on current systems is not. So, the only potential > > addition that the Sx states add to on/sleep/off is hibernate (and > > reasonable people can differ on whether it is a fourth basic state, a > > form of sleep, or a form of off). > > > > > > ACPI does define processor states (Cx) and device > > states (Dx) (collectively Px), but these are the states of particular > > components, not of the system as a whole. It may be useful to expose > > these through some mechanism, but they are distinct from the power > > state. > > > > > > > > > > DMTF essentially took the ACPI Gx states plus > > hibernate and added states that are commands and/or transitions. (Is > > "Master Bus Reset" a power state? I think not). If we don't include > > commands or transitions (I think we should not), then these reduce to > > the ACPI states. > > > > > > > > > > My conclusion: ACPI and DMTF do not significantly > > change the 3-state power model. If we want to talk about states beyond > > the 3-state model, it is more clear to simply reference those > > extensions directly (e.g. how best to treat hibernate). Note that this > > discussion - and all others on the list - are grounded in electronic > > devices. Other devices generally have a 2-state model (e.g. a light), > > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > > > > > > --Bruce > > > > > > > > > > -- > > Bruce Nordman > > Lawrence Berkeley National Laboratory > > eetd.lbl.gov/ea/nordman > > BNordman@LBL.gov > > 510-486-7089 > > m: 510-501-7943 > > > > _______________________________________________ > > 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 > =20 --Apple-Mail-1--463604104 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Servers have batteries? 

-tg-

Sent from my iPhone

On Mar 11, 201= 1, at 8:04 AM, "Chris Verges" <chrisv@cyberswitching.com> wrote:

Hi Ted,

 

I might be putting words into Rolf=E2=80=99s mouth, but here are my thou= ghts on this:

 

Certain devices, like servers, that contain a Lights Out Management= (LOM) card will be able to report the server=E2=80=99s power supply as =E2=80= =9Coff=E2=80=9D but the battery as =E2=80=9Ccharging=E2=80=9D.  This co= mbination for the server entity results in the desired effect.

 

Rolf, anywhere in t= he ballpark?

 

Chris

 

From:= eman-bounces= @ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Ted GhoseSent: Friday, March 11, 2011 8:01 AM
To: Rolf Winter
<= b>Cc: Bruce Nordman; eman mailing list
Subject: Re: [eman] Pow= er states - time to dump ACPI and DMTF

 

Hi Rolf, Juergen

 

I like Rolf's idea very much. We should extend number of states t= o accommodate other sub states. 

 

He= re is one question I do have for Juergon, as handling the battery keeps comi= ng up in all the discussions. 

 

If the device= is off, but battery is charging, who is reporting that and how? Is battery i= tself has the intelligence to do so? In that case, can we treat it as a=  separate device independent of the device it is connected to= , and then we could simplify the model.

 

In the ot= her case, though, if device is turned off, there is no one to tell what the b= attery is doing, unless an intelligent PDU or someone is aware of t= hat device. Which comes to some source - sink model as well.

<= /div>

 

Could you please clarify your thoughts?

 

thanks

 <= /p>

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:= -.,_,.
                  &nb= sp;  Save time... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_= ,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.

On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter <Rolf.Winter@n= eclab.eu> wrote:

Hi,

= just thinking out loud here.

The thing which seems to complicate matt= ers here significantly is batteries. You either A) try to consider battery s= tate in the devices' power state or you B) leave it separate in its own MIB m= odule (as described e.g. here http://tools.ietf.org/html/draft-q= uittek-eman-battery-mib-00 where we have battery states full(1), par= tiallyCharged(2), empty(3), charging(4), discharging(5), unknown(6)). I thin= k these are the trade-offs:

Option A) You can always tell from the de= vice power state whether it is drawing power or not ("off but charging" e.g.= ) and you might be able to order them in a way that a higher state always tr= anslates to higher power draw. It however seems to complicate power states.<= br>
Option B) If a battery is present, you cannot tell from the device's p= ower state whether is it drawing power or not ("off" could be really "off bu= t charging"). The device power states can be modelled cleaner though and you= 'd need to look closer to see what the battery state is to be sure there is n= o power draw.

Is that the trade-off we're talking about or is there a= nything else that needs to be considered?

Best,

Rolf

NE= C Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6= BL | Registered in England 2832014



> -----Original Message-----
> From: eman-bounc= es@ietf.org [mailto:eman-bounces@ietf.org] On Behalf O= f
> Juergen Quittek
> Sent: Freitag, 11. M=C3=A4rz 2011 10:37> To: Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [= eman] Power states - time to dump ACPI and DMTF
>
> Hi Bruce,>
> I understand your preference for a simple off-sleep-on model f= or power
> states.
> How would we model a device with a battery t= hen
>   - it is off, but the empty battery is being charged
&g= t;   - it is on, but fully supplied with power from the battery.
>= ;
> On way would be treating the (internal) battery as separate device= .
> In this case: Can we map charging/discharging/full/empty to off-sl= eep-
> on?
>
> Thanks,
>
>     Juerg= en
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce Nordman:
= >
>
>       (all below as contributor)
>=
>
>
>
>       For many decades, elec= trical products were usually just on or off
> - a 2-state power model.=  In the last several decades, we have added
> many electronic pr= oducts with a 3-state model - on, sleep, and off.
> This is necessary a= nd existing complexity.  Our discussions around
> power states bo= il down to what complexity do we want to add to the 3-
> state model, a= nd why the burden is justified.
>
>
>
>
>
&= gt;       In discussions on this email list, in I-drafts, and= in person,
> the existing listings of power states from ACPI and DMTF= are often
> referenced as good candidates for eman to adopt in some w= ay.  ACPI is a
> hugely important technology, and it enables larg= e amounts of user
> functionality and energy savings.  I am less f= amiliar with the reach of
> DMTF in practice, but its depth and breadt= h of membership are
> compelling.  While I agree they both deserv= e close examination, I think
> we can safely drop them from our discus= sions of what to define as their
> complexity is more a distraction th= an an asset.
>
>
>
>
>       Th= e basic ACPI list is of  "Global System States" which "apply to
>= the entire system".  There are four of these (G0-G3); G0 is on
>= ("working") and G1 is sleep ("sleeping").  G2 and G3 both forms of off=
> (only distinguished by whether a device is completely depowered and=
> whether it is safe to disassemble or not, and these distinctions se= ems
> quite minor for eman purposes).  Thus, the ACPI Global stat= es are
> essentially on/sleep/off, the 3-state power model.
>>                   ACPI li= sts five "Sx" sleep states (S0 is on).  S5 is
> actually the G2 O= ff state (so not a sleep state at all), and current
> implementations d= o not use S1 or S2, so in practice there are only two
> ACPI sleep sta= tes: S3 and S4.  S3 is the ordinary system sleep, with
> quick wa= keup.  S4 is the hibernate state (with system memory saved in
> n= on-volatile memory, possibly a hard disk) which typically has long
> t= imes to return to operation (often tens of seconds).   The 1-2 second> wake time from S3 for modern personal computers is compatible with ma= ny
> IP protocol usages, e.g. initiating a TCP connection.  The t= ens of
> seconds time for S4 on current systems is not.  So, the o= nly potential
> addition that the Sx states add to on/sleep/off is hib= ernate (and
> reasonable people can differ on whether it is a fourth b= asic state, a
> form of sleep, or a form of off).
>
>
&= gt;                   ACPI does= define processor states (Cx) and device
> states (Dx) (collectively P= x), but these are the states of particular
> components, not of the sy= stem as a whole.  It may be useful to expose
> these through some= mechanism, but they are distinct from the power
> state.
>
&= gt;
>
>
>              =     DMTF essentially took the ACPI Gx states plus
> hiberna= te and added states that are commands and/or transitions.  (Is
> "= Master Bus Reset" a power state?  I think not).  If we don't inclu= de
> commands or transitions (I think we should not), then these reduc= e to
> the ACPI states.
>
>
>
>
>  =                 My conclusion: ACPI= and DMTF do not significantly
> change the 3-state power model.  = ;If we want to talk about states beyond
> the 3-state model, it is mor= e clear to simply reference those
> extensions directly (e.g. how best= to treat hibernate).  Note that this
> discussion - and all othe= rs on the list - are grounded in electronic
> devices.  Other dev= ices generally have a 2-state model (e.g. a light),
> or 3 states, but= on, off, and "ready" (think a microwave oven).
>
>
>
&= gt;
>       --Bruce
>
>
>
>
= >       --
>       Bruce Nordman
&= gt;       Lawrence Berkeley National Laboratory
>  = ;     eetd.lbl.gov/ea/nordman<= br>>       BNordman@LBL.gov
>     &nbs= p; 510-486-7089
>      = ; m: 510-501-7943
>
>   &n= bsp;   _______________________________________________
>   &= nbsp;   eman mailing list
>       eman@ietf.org
&= gt;       https://www.ietf.org/mailman/listinfo/eman
>
>

_= ______________________________________________
eman mailing list
eman@ietf.org
https://www.ie= tf.org/mailman/listinfo/eman

 

<= /html>= --Apple-Mail-1--463604104-- From Rolf.Winter@neclab.eu Mon Mar 14 01:37:03 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E753A6AF4 for ; Mon, 14 Mar 2011 01:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.152 X-Spam-Level: X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXxb8Hecs5zW for ; Mon, 14 Mar 2011 01:37:01 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 1F3003A6ADD for ; Mon, 14 Mar 2011 01:37:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1FF262800018A; Mon, 14 Mar 2011 09:39:40 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX6nayl7qv1q; Mon, 14 Mar 2011 09:39:40 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 016672800017B; Mon, 14 Mar 2011 09:39:25 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 14 Mar 2011 09:38:08 +0100 From: Rolf Winter To: Juergen Quittek , Bruce Nordman Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AQHL37bMc1CHhWwxDEKYxTzj/hbcCgAAEYewlCtB3uCAAGGngIAAFKOAgAAOXgCAAAR/AIAABPUAgAC1XOA= Date: Mon, 14 Mar 2011 08:38:07 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DEA8AB@DAPHNIS.office.hd> References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at> <791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local> <791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd> <0851C4CF-D108-4BE9-AB17-A24F05FB72D4@quittek.at> <0E8D43D8-30EE-4483-ADC5-BEF9C210E62F@quittek.at> In-Reply-To: <0E8D43D8-30EE-4483-ADC5-BEF9C210E62F@quittek.at> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 08:37:03 -0000 Hi, not sure policy is the right word. The power state refers to the actual con= sumption for a device's primary function. Secondary functions could still c= onsume energy. E.g. battery charging or a fan still cooling down a device t= hat was just powered off and others. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Juergen Quittek [mailto:ietf@quittek.at] > Sent: Sonntag, 13. M=E4rz 2011 23:46 > To: Bruce Nordman > Cc: eman mailing list; Rolf Winter > Subject: Re: [eman] Power states - time to dump ACPI and DMTF >=20 > Hi Bruce, >=20 > I still would prefer having a definition. > The basic motivation is that "if you can't define it, you probably > don't know what it is". >=20 > Maybe we can say that a power state just indicates the current energy > consumption POLICY of a device and not necessary its actual consumption > rate. Then a sleep mode would be a mode in which a device saves > energy by not providing major parts of its core function. >=20 > But this would not necessarily imply that the devices consumes energy > at a low rate (low power) because the device may charge its batteries > or do something else that needs significant power. Still, the device > saves energy in sleep mode, because its main function is on sleep. > Analogous considerations would apply to the 'off' state. >=20 > Juergen >=20 >=20 > Am 13.03.2011 um 23:27 schrieb Bruce Nordman: >=20 >=20 > Good question. I would say we shouldn't try to define power > states, > as specific definitions inevitably collide with the wide variety > of products > in scope. Devices already have power states - we are not > creating them. > We are only providing a standard way to expose them to the > network > (or at least to the NMS). The distribution of time and energy > across > basic power states is always a topic of interest and discussion > in understanding > energy use, and reducing it, whether it is in the context of a > single building, of > technology, or energy policy. Exposing power state can be a > useful > piece of information in how devices interact with each other, in > what > this suggests for degrees of network connectivity (including > none), > and capability. Reporting basic power state enables the NMS to > use > this information in interpreting the power and energy data. >=20 > When specific meaning about a particular product type is intended, > then other mechanisms will usually be called for, whether they > are part > of eman or some other protocol. Creating one or more IANA > registries > for functional device states by product type does seem like > something > that we should explore. These would have no expectation of being > universal in the way that power states can be (though > harmonization > across product types is certainly to be strived for, particularly > for ones > that are more closely related). >=20 > --Bruce >=20 >=20 >=20 >=20 > On Sun, Mar 13, 2011 at 3:11 PM, Juergen Quittek > wrote: >=20 >=20 > Hi Bruce, >=20 > I still have the basic question: > What is the purpose of defining power states? > What do we need them for in addition to functional device > states? >=20 > We should have a clear answer in the eman WG. >=20 > Thanks, >=20 > Juergen >=20 >=20 > Am 13.03.2011 um 22:20 schrieb Bruce Nordman: >=20 >=20 > I think we are making this more complicated than > necessary. > First, our mandate is for monitoring, not control. > We should be > thinking about control (as we are), but should not > complicate > the monitoring protocol for control reasons. I know > that eman > will in future be used by some devices for control > (and I support > their ability to do so in future), but the great > majority I believe will > only use its monitoring features. >=20 > Second, the NMS will know the identity of the device > being > monitored, so can use that information in drawing > conclusions. > The power state does not need to be burdened with > trying to > be highly informative by itself. The device HAS a > basic power > state already - we are just trying to expose that > which already > exists. >=20 > When devices have the ability and need to be more > elaborate > in what they communicate (e.g. exposing battery > details), we > can facilitate that, but for those that can't or > don't need this, > we should allow them to be simple. >=20 > Batteries are not involved in the vast majority of > electricity > use, and the NMS will know if the device does (or > could) > have one and so can draw appropriate conclusions. >=20 > To Juergen's question, the assumptions that can be > made > about a device's energy based solely on the power > state > depends on the device. We don't need to say more. >=20 > --Bruce >=20 >=20 >=20 > On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek > wrote: >=20 >=20 > Hi Rolf, >=20 > One of the important questions to be answered > is: > Do we want to be able to make assumptions on a > device's energy consumption based on the power state? > If a devices's power state is off, what would > it tell us, if not: The devices does not need any power. >=20 > If this is not the case, we are rather talking > about functional states with some power-related properties, > But if these states do not serve as basis for > power-related assumptions on the device, then the name > POWER state is misleading and not appropriate > any more. >=20 > Thanks, >=20 > Juergen >=20 >=20 > Am 13.03.2011 um 14:34 schrieb Rolf Winter: >=20 >=20 > > Chris, Ted, > > > > I wasn't really implying anything here. To me, > it seemed that a lot of the discussion was triggered by the fact that > it is difficult to accommodate batteries directly in a device's power > state. So I was wondering why one would actually do that (instead of > treating it as a completely different entity). My mail tried to > summarize the differences and I was asking whether there is more. I > believe this is something we want to figure out quickly as a bunch of > things will rely on this decision. But it might be that a simple model > would work here. E.g. you'd have the state sleep (which means e.g. that > the functional components draw little power) and a sub-state that says > batteries charging (or not, or which "type" of charging) which tells > you that the device as a whole is drawing significant power. The same > for on and off states of course. Or you can have all separate in a > battery MIB. In either case, I think other battery related information > should be in a separate MIB. E.g. whether a battery is fully charged, > empty, it's age, number of charging cycles and so forth. So which one > should it be, which of the tradeoffs is most important to us? > > > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC > House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > ... >=20 >=20 >=20 >=20 >=20 >=20 > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 >=20 >=20 >=20 >=20 >=20 > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 >=20 >=20 From bclaise@cisco.com Mon Mar 14 03:11:43 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40273A6C7E for ; Mon, 14 Mar 2011 03:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f95idCAbASTX for ; Mon, 14 Mar 2011 03:11:41 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 3D09F3A6C71 for ; Mon, 14 Mar 2011 03:11:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2EACxUO016098; Mon, 14 Mar 2011 11:12:59 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2EACwMh028657; Mon, 14 Mar 2011 11:12:58 +0100 (CET) Message-ID: <4D7DEA2A.3050100@cisco.com> Date: Mon, 14 Mar 2011 11:12:58 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: chrisv@cyberswitching.com References: <20110304190215.GA5072@cslinux-build01.cyberswitching.local> In-Reply-To: <20110304190215.GA5072@cslinux-build01.cyberswitching.local> Content-Type: multipart/alternative; boundary="------------000009010209090509040508" Cc: eman@ietf.org Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 10:11:43 -0000 This is a multi-part message in MIME format. --------------000009010209090509040508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Chris, Thanks for your proposal. I also believe we should be solving the case of multiple power supplies However, we will have to pay attention that we don't double count the traffic in the Power Monitor Metering Domain. See http://tools.ietf.org/html/draft-ietf-eman-framework-00 -> Section 5.2. Power Monitor Topologies: Metering versus Control versus Power Distribution. So, even if there are two topologies for power distribution, we would need a single Power Monitor Parent. Regarding the gang, could we solve this one with the context information? For example, the pmKeywords in http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01 Regards, Benoit. > Hi Juergen, > > I wrote an additon to the various scenarios described in > draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario > found on Smart PDUs. Please let me know if you have any questions while > integrating it. > > $ diff draft-ietf-eman-requirements-00.txt draft-ietf-eman-requirements-01.txt > 416a417,449 >> 2.9. Scenario 9: Ganged outlets on a Smart Power Strip >> >> Some PDUs allow physical entities like outlets to be "ganged" together as a >> logical entity for simplified management purposes. This is particularly >> useful for servers with multiple power supplies, where each power supply is >> connected to a different physical outlet. Other implementations allow >> "gangs" to be created based on common ownership of outlets, such as >> business units or load shed priority or other non-physical relationships. >> >> Current implementations allow for an "M-to-N" mapping between outlet >> "gangs" and physical outlets. An example of this mapping includes the >> following: >> >> Outlet 1 (physical entity) >> Outlet 2 (physical entity) >> Outlet 3 (physical entity) >> Outlet 4 (physical entity) >> Outlet Gang A (virtual entity) >> Outlet Gang B (virtual entity) >> >> Gang A -> Outlets 1, 2 and 3 >> Gang B -> Outlets 3 and 4 >> >> Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both >> "gangs." >> >> Each "Outlet Gang" entity reports the aggregated data from the individual >> outlet entities that comprise it and enables a single point of control for >> all the individual outlet entities. For example, turning "Outlet Gang A" >> to the "off" state would turn outlets 1, 2, and 3 "off" in some >> implementations. (The impact of this action on "Outlet Gang B" is to be >> defined by the equipment manufacturer.) >> > Thanks, > Chris > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------000009010209090509040508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Chris,

Thanks for your proposal.
I also believe we should be solving the case of multiple power supplies
However, we will have to pay attention that we don't double count the traffic in the Power Monitor Metering Domain.
See http://tools.ietf.org/html/draft-ietf-eman-framework-00 ->   Section 5.2. Power Monitor Topologies: Metering versus Control versus Power Distribution. So, even if there are two topologies for power distribution, we would need a single Power Monitor Parent.

Regarding the gang, could we solve this one with the context information? For example, the pmKeywords in http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01

Regards, Benoit.
Hi Juergen,

I wrote an additon to the various scenarios described in
draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario
found on Smart PDUs.  Please let me know if you have any questions while
integrating it.

$ diff draft-ietf-eman-requirements-00.txt draft-ietf-eman-requirements-01.txt
416a417,449

2.9.  Scenario 9: Ganged outlets on a Smart Power Strip

   Some PDUs allow physical entities like outlets to be "ganged" together as a
   logical entity for simplified management purposes.  This is particularly
   useful for servers with multiple power supplies, where each power supply is
   connected to a different physical outlet.  Other implementations allow
   "gangs" to be created based on common ownership of outlets, such as
   business units or load shed priority or other non-physical relationships.

   Current implementations allow for an "M-to-N" mapping between outlet
   "gangs" and physical outlets.  An example of this mapping includes the
   following:

      Outlet 1             (physical entity)
      Outlet 2             (physical entity)
      Outlet 3             (physical entity)
      Outlet 4             (physical entity)
      Outlet Gang A        (virtual entity)
      Outlet Gang B        (virtual entity)

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

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

   Each "Outlet Gang" entity reports the aggregated data from the individual
   outlet entities that comprise it and enables a single point of control for
   all the individual outlet entities.  For example, turning "Outlet Gang A"
   to the "off" state would turn outlets 1, 2, and 3 "off" in some
   implementations.  (The impact of this action on "Outlet Gang B" is to be
   defined by the equipment manufacturer.)


Thanks,
Chris


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

--------------000009010209090509040508-- From jparello@cisco.com Mon Mar 14 07:37:45 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42BFA3A6D28 for ; Mon, 14 Mar 2011 07:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JweMOhISSoG2 for ; Mon, 14 Mar 2011 07:37:42 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A8B6D3A6D13 for ; Mon, 14 Mar 2011 07:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=27581; q=dns/txt; s=iport; t=1300113546; x=1301323146; h=mime-version:subject:date:message-id:references:from:to: cc; bh=1K22ARcUa8n+7wmeGk/6pLehtWq5nx3ps8yPiQXZ7RQ=; b=SaSF6muqTslUoUlL8ignViSqJY1KqZwG7yN/opwjnl6kARnknhpjxA8t bYx7RO+EGIi8AysuN1rf/qUVWYBbBwYYuSvE3DUKU8zGx5V7aiYJLclVE h7DWFz2yGDnVHiSu4be9YGjJcIN4vMsGqnsSXV+MbvHaPK8MdOaRCpM+m Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAACfFfU2tJV2a/2dsb2JhbACYQYZJhnx3pCabZYJ8GYJNBIUrins X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208,217";a="345955048" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2011 14:39:05 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2EEd5B3005978; Mon, 14 Mar 2011 14:39:05 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 07:39:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE255.90BF863B" Date: Mon, 14 Mar 2011 07:39:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AcvgTlH9Bg0OvbsTScGN5is2YGzi/gAAm0KQAID0xlE= References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CF36845@mail03.cyberswitching.local> From: "John Parello (jparello)" To: "Chris Verges" , "Bruce Nordman" , "Rolf Winter" X-OriginalArrivalTime: 14 Mar 2011 14:39:04.0987 (UTC) FILETIME=[91690EB0:01CBE255] Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 14:37:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE255.90BF863B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruce, "" More important from my point of view, is that no one on this thread has = jumped to the defense of ACPI/DMTF. I am more convinced than ever that they = are a distraction for our purposes. "" I don't think those models are a distraction. They represent states of = devices that humans are familiar with. Even down to consumers the = concept of sleep, hibernate etc are well known and in the vernacular of = human interaction with machines / things that use electrical power. I can't see how we can ignore the existence of these concepts or the = enumerations of them from those two bodies.=20 As part of our charter we have to work with other standards bodies and = this is the direct areas of intersection. I can't see dumping them. We = would have to address them and comment at the least - even if the group = said ignore them. IMO they are helpful just not sufficient. Jp -----Original Message----- From: eman-bounces@ietf.org on behalf of Chris Verges Sent: Fri 3/11/2011 5:07 PM To: Bruce Nordman; Rolf Winter Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Hi Bruce, =20 Please don't take silence as a form of acceptance. That's a dangerous = assumption. =20 My position is that a single state mechanism is not appropriate for EMAN = to consider. EMAN should support multiple state mechanisms, that = coexist with each other. =20 Consider the following scenario: =20 Three forms of state management: ACPI, DMTF, and PDU State Management. = (PDU states include on, off, reboot, tripped, and shed. Only for = example purposes, exact details to be worked out later.) =20 server-a - supports ACPI only server-b - supports ACPI and DMTF PDU - supports EMAN PDU State Management =20 I propose that we allow each device to support the modality that makes = sense for that device. The key is not in which modality is supported, = but rather how the user accesses the modality. Why would we try to = limit innovation by restricting what people can do? =20 Expose different hooks to allow a user to access ACPI, DMTF, and/or PDU = State Management through three different interfaces: =20 emanStateControlAcpi - implemented by entities which know how to respond = to ACPI states emanStateControlDmtf - implemented by entities which know how to respond = to DMTF states emanStateControlPdu - implemented by entities which know how to respond = to PDU State Management =20 This makes the EMAN schema more powerful and allows the market to adapt = easily as future changes in technologies and our understanding of how to = use those technologies improves. =20 Chris =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Bruce Nordman Sent: Friday, March 11, 2011 4:43 PM To: Rolf Winter Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Good discussion. Batteries are a specific example of a case in which a device has a = secondary function which can consume significant amounts of power, and the = secondary function is independent of the primary one. My computer is an iMac with = an integrated display, so the display is secondary to the primary function = of computation, but unlike the battery, its function is not independent (display always = powered down when the computational part is). Another example like the battery could be a TV with an integral video = recorder. The recorder can be active when the TV display is asleep or off. A = third example is an imaging MFD that does printing, copying, and scanning; it may have = the scanner active at relatively low power, but the heat-intensive toner = fusing unit powered down. Life would be simpler if devices were not = multi-functional. I think we should insist on devices having a primary function (that is = afterall how "identity" works), and the power state reflects that function. = Simple devices with internal batteries can consume a lot of power in sleep or off. = More sophisticated devices may choose to use the eman features for exposing the consumption = of the battery and balance of the system, and then have a state for the batter = exposed. We need to enable this but not require it. I am assuming that we will usually have both power state and current = power draw in watts, so the NMS will look at both (and the product's identity) = in deciding what is going on. (Perhaps part of identity is reporting if a = non-trivial battery is present (though this can be a dynamic characteristic).) So, one can look at power level, at power state, or both. I think = having both addresses Rolf's concerns. =20 For Juergen's note about the states of off-but charging (so high power), and on (and presumably AC-connected) but running only off of battery = power (so no AC draw), that confirms the need to have the actual mains power level. There have been notebook PCs designed to go off-grid in the = afternoon to avoid times of high electricity demand, so this is a very real = scenario. More important from my point of view, is that no one on this thread has = jumped to the defense of ACPI/DMTF. I am more convinced than ever that they = are a distraction for our purposes. --Bruce On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = wrote: Hi, just thinking out loud here. The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here = http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we = have battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the trade-offs: Option A) You can always tell from the device power state whether it is = drawing power or not ("off but charging" e.g.) and you might be able to = order them in a way that a higher state always translates to higher = power draw. It however seems to complicate power states. Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be really = "off but charging"). The device power states can be modelled cleaner = though and you'd need to look closer to see what the battery state is to = be sure there is no power draw. Is that the trade-off we're talking about or is there anything else that = needs to be considered? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Juergen Quittek > Sent: Freitag, 11. M=E4rz 2011 10:37 > To: Bruce Nordman > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > Hi Bruce, > > I understand your preference for a simple off-sleep-on model for power > states. > How would we model a device with a battery then > - it is off, but the empty battery is being charged > - it is on, but fully supplied with power from the battery. > > On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep- > on? > > Thanks, > > Juergen > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > (all below as contributor) > > > > > For many decades, electrical products were usually just on or = off > - a 2-state power model. In the last several decades, we have added > many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. Our discussions around > power states boil down to what complexity do we want to add to the 3- > state model, and why the burden is justified. > > > > > > In discussions on this email list, in I-drafts, and in person, > the existing listings of power states from ACPI and DMTF are often > referenced as good candidates for eman to adopt in some way. ACPI is = a > hugely important technology, and it enables large amounts of user > functionality and energy savings. I am less familiar with the reach = of > DMTF in practice, but its depth and breadth of membership are > compelling. While I agree they both deserve close examination, I = think > we can safely drop them from our discussions of what to define as = their > complexity is more a distraction than an asset. > > > > > The basic ACPI list is of "Global System States" which "apply = to > the entire system". There are four of these (G0-G3); G0 is on > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems > quite minor for eman purposes). Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model. > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > quick wakeup. S4 is the hibernate state (with system memory saved in > non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). The 1-2 second > wake time from S3 for modern personal computers is compatible with = many > IP protocol usages, e.g. initiating a TCP connection. The tens of > seconds time for S4 on current systems is not. So, the only potential > addition that the Sx states add to on/sleep/off is hibernate (and > reasonable people can differ on whether it is a fourth basic state, a > form of sleep, or a form of off). > > > ACPI does define processor states (Cx) and device > states (Dx) (collectively Px), but these are the states of particular > components, not of the system as a whole. It may be useful to expose > these through some mechanism, but they are distinct from the power > state. > > > > > DMTF essentially took the ACPI Gx states plus > hibernate and added states that are commands and/or transitions. (Is > "Master Bus Reset" a power state? I think not). If we don't include > commands or transitions (I think we should not), then these reduce to > the ACPI states. > > > > > My conclusion: ACPI and DMTF do not significantly > change the 3-state power model. If we want to talk about states = beyond > the 3-state model, it is more clear to simply reference those > extensions directly (e.g. how best to treat hibernate). Note that = this > discussion - and all others on the list - are grounded in electronic > devices. Other devices generally have a 2-state model (e.g. a light), > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > --Bruce > > > > > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 ------_=_NextPart_001_01CBE255.90BF863B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] Power states - time to dump ACPI and DMTF

Hi Bruce,

""
More important from my point of view, is that no one on this thread has = jumped
to the defense of ACPI/DMTF.  I am more convinced than ever that = they are
a distraction for our purposes.
""

I don't think those models are a distraction. They represent states of = devices that humans are familiar with. Even down to consumers the = concept of sleep, hibernate etc are well known and in the vernacular of = human interaction with machines / things that use electrical power.

I can't see how we can ignore the existence of these concepts or the = enumerations of them from those two bodies.

As part of our charter we have to work with other standards bodies and = this is the direct areas of intersection. I can't see dumping them. We = would have to address them and comment at the least - even if the group = said ignore them.

IMO they are helpful just not sufficient.

Jp



-----Original Message-----
From: eman-bounces@ietf.org on behalf of Chris Verges
Sent: Fri 3/11/2011 5:07 PM
To: Bruce Nordman; Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Hi Bruce,



Please don't take silence as a form of acceptance.  That's a = dangerous assumption.



My position is that a single state mechanism is not appropriate for EMAN = to consider.  EMAN should support multiple state mechanisms, that = coexist with each other.



Consider the following scenario:



Three forms of state management: ACPI, DMTF, and PDU State = Management.  (PDU states include on, off, reboot, tripped, and = shed.  Only for example purposes, exact details to be worked out = later.)



server-a - supports ACPI only

server-b - supports ACPI and DMTF

PDU - supports EMAN PDU State Management



I propose that we allow each device to support the modality that makes = sense for that device.  The key is not in which modality is = supported, but rather how the user accesses the modality.  Why = would we try to limit innovation by restricting what people can do?



Expose different hooks to allow a user to access ACPI, DMTF, and/or PDU = State Management through three different interfaces:



emanStateControlAcpi - implemented by entities which know how to respond = to ACPI states

emanStateControlDmtf - implemented by entities which know how to respond = to DMTF states

emanStateControlPdu - implemented by entities which know how to respond = to PDU State Management



This makes the EMAN schema more powerful and allows the market to adapt = easily as future changes in technologies and our understanding of how to = use those technologies improves.



Chris





From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] = On Behalf Of Bruce Nordman
Sent: Friday, March 11, 2011 4:43 PM
To: Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF



Good discussion.

Batteries are a specific example of a case in which a device has a = secondary
function which can consume significant amounts of power, and the = secondary
function is independent of the primary one.  My computer is an iMac = with an
integrated display, so the display is secondary to the primary function = of computation,
but unlike the battery, its function is not independent (display always = powered
down when the computational part is).

Another example like the battery could be a TV with an integral video = recorder.
The recorder can be active when the TV display is asleep or off.  A = third example
is an imaging MFD that does printing, copying, and scanning; it may have = the
scanner active at relatively low power, but the heat-intensive toner = fusing unit
powered down.  Life would be simpler if devices were not = multi-functional.

I think we should insist on devices having a primary function (that is = afterall
how "identity" works), and the power state reflects that = function.  Simple devices
with internal batteries can consume a lot of power in sleep or = off.  More sophisticated
devices may choose to use the eman features for exposing the consumption = of the
battery and balance of the system, and then have a state for the batter = exposed.
We need to enable this but not require it.

I am assuming that we will usually have both power state and current = power
draw in watts, so the NMS will look at both (and the product's identity) = in
deciding what is going on.  (Perhaps part of identity is reporting = if a non-trivial
battery is present (though this can be a dynamic characteristic).)
So, one can look at power level, at power state, or both.  I think = having
both addresses Rolf's concerns. 

For Juergen's note about the states of off-but charging (so high = power),
and on (and presumably AC-connected) but running only off of battery = power
(so no AC draw), that confirms the need to have the actual mains = power
level.  There have been notebook PCs designed to go off-grid in the = afternoon
to avoid times of high electricity demand, so this is a very real = scenario.


More important from my point of view, is that no one on this thread has = jumped
to the defense of ACPI/DMTF.  I am more convinced than ever that = they are
a distraction for our purposes.

--Bruce

On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = <Rolf.Winter@neclab.eu> wrote:

Hi,

just thinking out loud here.

The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here htt= p://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we = have battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the trade-offs:

Option A) You can always tell from the device power state whether it is = drawing power or not ("off but charging" e.g.) and you might = be able to order them in a way that a higher state always translates to = higher power draw. It however seems to complicate power states.

Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be = really "off but charging"). The device power states can be = modelled cleaner though and you'd need to look closer to see what the = battery state is to be sure there is no power draw.

Is that the trade-off we're talking about or is there anything else that = needs to be considered?

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014



> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] = On Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [eman] Power states - time to dump ACPI and DMTF
>
> Hi Bruce,
>
> I understand your preference for a simple off-sleep-on model for = power
> states.
> How would we model a device with a battery then
>   - it is off, but the empty battery is being charged
>   - it is on, but fully supplied with power from the = battery.
>
> On way would be treating the (internal) battery as separate = device.
> In this case: Can we map charging/discharging/full/empty to = off-sleep-
> on?
>
> Thanks,
>
>     Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce Nordman:
>
>
>       (all below as contributor)
>
>
>
>
>       For many decades, electrical = products were usually just on or off
> - a 2-state power model.  In the last several decades, we have = added
> many electronic products with a 3-state model - on, sleep, and = off.
> This is necessary and existing complexity.  Our discussions = around
> power states boil down to what complexity do we want to add to the = 3-
> state model, and why the burden is justified.
>
>
>
>
>
>       In discussions on this email = list, in I-drafts, and in person,
> the existing listings of power states from ACPI and DMTF are = often
> referenced as good candidates for eman to adopt in some way.  = ACPI is a
> hugely important technology, and it enables large amounts of = user
> functionality and energy savings.  I am less familiar with the = reach of
> DMTF in practice, but its depth and breadth of membership are
> compelling.  While I agree they both deserve close = examination, I think
> we can safely drop them from our discussions of what to define as = their
> complexity is more a distraction than an asset.
>
>
>
>
>       The basic ACPI list is of  = "Global System States" which "apply to
> the entire system".  There are four of these (G0-G3); G0 = is on
> ("working") and G1 is sleep ("sleeping").  = G2 and G3 both forms of off
> (only distinguished by whether a device is completely depowered = and
> whether it is safe to disassemble or not, and these distinctions = seems
> quite minor for eman purposes).  Thus, the ACPI Global states = are
> essentially on/sleep/off, the 3-state power model.
>
>           &nb= sp;       ACPI lists five "Sx" = sleep states (S0 is on).  S5 is
> actually the G2 Off state (so not a sleep state at all), and = current
> implementations do not use S1 or S2, so in practice there are only = two
> ACPI sleep states: S3 and S4.  S3 is the ordinary system = sleep, with
> quick wakeup.  S4 is the hibernate state (with system memory = saved in
> non-volatile memory, possibly a hard disk) which typically has = long
> times to return to operation (often tens of seconds).   = The 1-2 second
> wake time from S3 for modern personal computers is compatible with = many
> IP protocol usages, e.g. initiating a TCP connection.  The = tens of
> seconds time for S4 on current systems is not.  So, the only = potential
> addition that the Sx states add to on/sleep/off is hibernate = (and
> reasonable people can differ on whether it is a fourth basic state, = a
> form of sleep, or a form of off).
>
>
>           &nb= sp;       ACPI does define processor = states (Cx) and device
> states (Dx) (collectively Px), but these are the states of = particular
> components, not of the system as a whole.  It may be useful to = expose
> these through some mechanism, but they are distinct from the = power
> state.
>
>
>
>
>           &nb= sp;       DMTF essentially took the ACPI = Gx states plus
> hibernate and added states that are commands and/or = transitions.  (Is
> "Master Bus Reset" a power state?  I think = not).  If we don't include
> commands or transitions (I think we should not), then these reduce = to
> the ACPI states.
>
>
>
>
>           &nb= sp;       My conclusion: ACPI and DMTF do = not significantly
> change the 3-state power model.  If we want to talk about = states beyond
> the 3-state model, it is more clear to simply reference those
> extensions directly (e.g. how best to treat hibernate).  Note = that this
> discussion - and all others on the list - are grounded in = electronic
> devices.  Other devices generally have a 2-state model (e.g. a = light),
> or 3 states, but on, off, and "ready" (think a microwave = oven).
>
>
>
>
>       --Bruce
>
>
>
>
>       --
>       Bruce Nordman
>       Lawrence Berkeley National = Laboratory
>       eetd.lbl.gov/ea/nordman
>       BNordman@LBL.gov
>       510-486-7089
>       m: 510-501-7943
>
>       = _______________________________________________
>       eman mailing list
>       eman@ietf.org
>       https://www.ietf.org/= mailman/listinfo/eman
>
>




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

------_=_NextPart_001_01CBE255.90BF863B-- From Rolf.Winter@neclab.eu Mon Mar 14 07:55:49 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151EC3A6DA9 for ; Mon, 14 Mar 2011 07:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfMzK8qcl8ZC for ; Mon, 14 Mar 2011 07:55:47 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 7A6FE3A6D09 for ; Mon, 14 Mar 2011 07:55:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 33DAB2C00020B; Mon, 14 Mar 2011 15:58:57 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysdYwCVTRp+6; Mon, 14 Mar 2011 15:58:57 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 11B7C2C00020A; Mon, 14 Mar 2011 15:58:37 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 14 Mar 2011 15:56:47 +0100 From: Rolf Winter To: "John Parello (jparello)" , Chris Verges , Bruce Nordman Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AQHL37bMc1CHhWwxDEKYxTzj/hbcCgAAm0KQAID0xlGUKN95UA== Date: Mon, 14 Mar 2011 14:56:47 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DEAAC3@DAPHNIS.office.hd> References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd> <68FBE0F3CE97264395875AC1C468F22CF36845@mail03.cyberswitching.local> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 14:55:49 -0000 John, I agree with you that ACPI and DMTF shouldn't be ignored. I think it is a r= equirement that the EMAN product needs to accommodate these states. On the = other hand, I think they should not limit us either. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: John Parello (jparello) [mailto:jparello@cisco.com] > Sent: Montag, 14. M=E4rz 2011 15:39 > To: Chris Verges; Bruce Nordman; Rolf Winter > Cc: eman mailing list > Subject: RE: [eman] Power states - time to dump ACPI and DMTF >=20 > Hi Bruce, >=20 > "" > More important from my point of view, is that no one on this thread has > jumped > to the defense of ACPI/DMTF. I am more convinced than ever that they > are > a distraction for our purposes. > "" >=20 > I don't think those models are a distraction. They represent states of > devices that humans are familiar with. Even down to consumers the > concept of sleep, hibernate etc are well known and in the vernacular of > human interaction with machines / things that use electrical power. >=20 > I can't see how we can ignore the existence of these concepts or the > enumerations of them from those two bodies. >=20 > As part of our charter we have to work with other standards bodies and > this is the direct areas of intersection. I can't see dumping them. We > would have to address them and comment at the least - even if the group > said ignore them. >=20 > IMO they are helpful just not sufficient. >=20 > Jp >=20 >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org on behalf of Chris Verges > Sent: Fri 3/11/2011 5:07 PM > To: Bruce Nordman; Rolf Winter > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF >=20 > Hi Bruce, >=20 >=20 >=20 > Please don't take silence as a form of acceptance. That's a dangerous > assumption. >=20 >=20 >=20 > My position is that a single state mechanism is not appropriate for > EMAN to consider. EMAN should support multiple state mechanisms, that > coexist with each other. >=20 >=20 >=20 > Consider the following scenario: >=20 >=20 >=20 > Three forms of state management: ACPI, DMTF, and PDU State Management. > (PDU states include on, off, reboot, tripped, and shed. Only for > example purposes, exact details to be worked out later.) >=20 >=20 >=20 > server-a - supports ACPI only >=20 > server-b - supports ACPI and DMTF >=20 > PDU - supports EMAN PDU State Management >=20 >=20 >=20 > I propose that we allow each device to support the modality that makes > sense for that device. The key is not in which modality is supported, > but rather how the user accesses the modality. Why would we try to > limit innovation by restricting what people can do? >=20 >=20 >=20 > Expose different hooks to allow a user to access ACPI, DMTF, and/or PDU > State Management through three different interfaces: >=20 >=20 >=20 > emanStateControlAcpi - implemented by entities which know how to > respond to ACPI states >=20 > emanStateControlDmtf - implemented by entities which know how to > respond to DMTF states >=20 > emanStateControlPdu - implemented by entities which know how to respond > to PDU State Management >=20 >=20 >=20 > This makes the EMAN schema more powerful and allows the market to adapt > easily as future changes in technologies and our understanding of how > to use those technologies improves. >=20 >=20 >=20 > Chris >=20 >=20 >=20 >=20 >=20 > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Bruce Nordman > Sent: Friday, March 11, 2011 4:43 PM > To: Rolf Winter > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF >=20 >=20 >=20 > Good discussion. >=20 > Batteries are a specific example of a case in which a device has a > secondary > function which can consume significant amounts of power, and the > secondary > function is independent of the primary one. My computer is an iMac > with an > integrated display, so the display is secondary to the primary function > of computation, > but unlike the battery, its function is not independent (display always > powered > down when the computational part is). >=20 > Another example like the battery could be a TV with an integral video > recorder. > The recorder can be active when the TV display is asleep or off. A > third example > is an imaging MFD that does printing, copying, and scanning; it may > have the > scanner active at relatively low power, but the heat-intensive toner > fusing unit > powered down. Life would be simpler if devices were not multi- > functional. >=20 > I think we should insist on devices having a primary function (that is > afterall > how "identity" works), and the power state reflects that function. > Simple devices > with internal batteries can consume a lot of power in sleep or off. > More sophisticated > devices may choose to use the eman features for exposing the > consumption of the > battery and balance of the system, and then have a state for the batter > exposed. > We need to enable this but not require it. >=20 > I am assuming that we will usually have both power state and current > power > draw in watts, so the NMS will look at both (and the product's > identity) in > deciding what is going on. (Perhaps part of identity is reporting if a > non-trivial > battery is present (though this can be a dynamic characteristic).) > So, one can look at power level, at power state, or both. I think > having > both addresses Rolf's concerns. >=20 > For Juergen's note about the states of off-but charging (so high power), > and on (and presumably AC-connected) but running only off of battery > power > (so no AC draw), that confirms the need to have the actual mains power > level. There have been notebook PCs designed to go off-grid in the > afternoon > to avoid times of high electricity demand, so this is a very real > scenario. >=20 >=20 > More important from my point of view, is that no one on this thread has > jumped > to the defense of ACPI/DMTF. I am more convinced than ever that they > are > a distraction for our purposes. >=20 > --Bruce >=20 > On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter > wrote: >=20 > Hi, >=20 > just thinking out loud here. >=20 > The thing which seems to complicate matters here significantly is > batteries. You either A) try to consider battery state in the devices' > power state or you B) leave it separate in its own MIB module (as > described e.g. here http://tools.ietf.org/html/draft-quittek-eman- > battery-mib-00 where we have battery states full(1), > partiallyCharged(2), empty(3), charging(4), discharging(5), unknown(6)). > I think these are the trade-offs: >=20 > Option A) You can always tell from the device power state whether it is > drawing power or not ("off but charging" e.g.) and you might be able to > order them in a way that a higher state always translates to higher > power draw. It however seems to complicate power states. >=20 > Option B) If a battery is present, you cannot tell from the device's > power state whether is it drawing power or not ("off" could be really > "off but charging"). The device power states can be modelled cleaner > though and you'd need to look closer to see what the battery state is > to be sure there is no power draw. >=20 > Is that the trade-off we're talking about or is there anything else > that needs to be considered? >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of > > Juergen Quittek > > Sent: Freitag, 11. M=E4rz 2011 10:37 > > To: Bruce Nordman > > Cc: eman mailing list > > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > > > Hi Bruce, > > > > I understand your preference for a simple off-sleep-on model for > power > > states. > > How would we model a device with a battery then > > - it is off, but the empty battery is being charged > > - it is on, but fully supplied with power from the battery. > > > > On way would be treating the (internal) battery as separate device. > > In this case: Can we map charging/discharging/full/empty to off- > sleep- > > on? > > > > Thanks, > > > > Juergen > > > > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > > > > (all below as contributor) > > > > > > > > > > For many decades, electrical products were usually just on or > off > > - a 2-state power model. In the last several decades, we have added > > many electronic products with a 3-state model - on, sleep, and off. > > This is necessary and existing complexity. Our discussions around > > power states boil down to what complexity do we want to add to the 3- > > state model, and why the burden is justified. > > > > > > > > > > > > In discussions on this email list, in I-drafts, and in person, > > the existing listings of power states from ACPI and DMTF are often > > referenced as good candidates for eman to adopt in some way. ACPI is > a > > hugely important technology, and it enables large amounts of user > > functionality and energy savings. I am less familiar with the reach > of > > DMTF in practice, but its depth and breadth of membership are > > compelling. While I agree they both deserve close examination, I > think > > we can safely drop them from our discussions of what to define as > their > > complexity is more a distraction than an asset. > > > > > > > > > > The basic ACPI list is of "Global System States" which "apply > to > > the entire system". There are four of these (G0-G3); G0 is on > > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of > off > > (only distinguished by whether a device is completely depowered and > > whether it is safe to disassemble or not, and these distinctions > seems > > quite minor for eman purposes). Thus, the ACPI Global states are > > essentially on/sleep/off, the 3-state power model. > > > > ACPI lists five "Sx" sleep states (S0 is on). S5 > is > > actually the G2 Off state (so not a sleep state at all), and current > > implementations do not use S1 or S2, so in practice there are only > two > > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > > quick wakeup. S4 is the hibernate state (with system memory saved in > > non-volatile memory, possibly a hard disk) which typically has long > > times to return to operation (often tens of seconds). The 1-2 > second > > wake time from S3 for modern personal computers is compatible with > many > > IP protocol usages, e.g. initiating a TCP connection. The tens of > > seconds time for S4 on current systems is not. So, the only > potential > > addition that the Sx states add to on/sleep/off is hibernate (and > > reasonable people can differ on whether it is a fourth basic state, a > > form of sleep, or a form of off). > > > > > > ACPI does define processor states (Cx) and device > > states (Dx) (collectively Px), but these are the states of particular > > components, not of the system as a whole. It may be useful to expose > > these through some mechanism, but they are distinct from the power > > state. > > > > > > > > > > DMTF essentially took the ACPI Gx states plus > > hibernate and added states that are commands and/or transitions. (Is > > "Master Bus Reset" a power state? I think not). If we don't include > > commands or transitions (I think we should not), then these reduce to > > the ACPI states. > > > > > > > > > > My conclusion: ACPI and DMTF do not significantly > > change the 3-state power model. If we want to talk about states > beyond > > the 3-state model, it is more clear to simply reference those > > extensions directly (e.g. how best to treat hibernate). Note that > this > > discussion - and all others on the list - are grounded in electronic > > devices. Other devices generally have a 2-state model (e.g. a light), > > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > > > > > > --Bruce > > > > > > > > > > -- > > Bruce Nordman > > Lawrence Berkeley National Laboratory > > eetd.lbl.gov/ea/nordman > > BNordman@LBL.gov > > 510-486-7089 > > m: 510-501-7943 > > > > _______________________________________________ > > eman mailing list > > eman@ietf.org > > https://www.ietf.org/mailman/listinfo/eman > > > > >=20 >=20 >=20 >=20 > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 >=20 >=20 From chrisv@cyberswitching.com Mon Mar 14 09:16:02 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F043A6D54 for ; Mon, 14 Mar 2011 09:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMcX+SurSIWT for ; Mon, 14 Mar 2011 09:15:55 -0700 (PDT) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id 3EAED3A6957 for ; Mon, 14 Mar 2011 09:15:53 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o144.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id c8f3e7d4.0.312.00-355.737.p01c12o144.mxlogic.net (envelope-from ); Mon, 14 Mar 2011 10:17:19 -0600 (MDT) X-MXL-Hash: 4d7e3f8f298ba94c-dafa3d85928df2c6cadf1d8656d442cee61ce774 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE263.2358F30E" Date: Mon, 14 Mar 2011 09:16:11 -0700 Message-ID: <68FBE0F3CE97264395875AC1C468F22CF36864@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00 Thread-Index: AcviMEMh2ixzc6qRRM2lwVKjDUrNuQAMhcdg References: <20110304190215.GA5072@cslinux-build01.cyberswitching.local> <4D7DEA2A.3050100@cisco.com> From: "Chris Verges" To: "Benoit Claise" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=Vdpz72tn5H4A:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=5bjX] X-AnalysisOut: [hPQlcF1x13W4UrUA:9 a=tVb_FAtzMi7BAndJET08dXsjUBQA:4 a=CjuI] X-AnalysisOut: [K1q_8ugA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=MQsDQzRlkWy7kd0kNHoA:9 a=Hb6fety] X-AnalysisOut: [WaclvKhPGGvYA:7 a=lJPwyMApMuwuCZ75aUf_LbnbY7kA:4] Cc: eman@ietf.org Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:16:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE263.2358F30E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, =20 Could we solve it with a "keywords" style field? Perhaps. However, the relationship of an outlet gang to its physical outlets is more structural than that. It should be a separate field/mechanism so that modifying one does not inadvertently affect the other. Trying to combine the two is not the best solution and will bring up limitations of the schema later. =20 For example, why use pmParentId rather than including this information in pmKeywords? The pmParentId/pmIndex relationship is separate from the pmIndex/pmKeywords relationship in an object class diagram and for good reason. =20 =20 Chris =20 =20 From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Monday, March 14, 2011 3:13 AM To: Chris Verges Cc: eman@ietf.org Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00 =20 Hi Chris, Thanks for your proposal. I also believe we should be solving the case of multiple power supplies However, we will have to pay attention that we don't double count the traffic in the Power Monitor Metering Domain. See http://tools.ietf.org/html/draft-ietf-eman-framework-00 -> Section 5.2. Power Monitor Topologies: Metering versus Control versus Power Distribution. So, even if there are two topologies for power distribution, we would need a single Power Monitor Parent.=20 Regarding the gang, could we solve this one with the context information? For example, the pmKeywords in http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01 Regards, Benoit. Hi Juergen, =20 I wrote an additon to the various scenarios described in draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario found on Smart PDUs. Please let me know if you have any questions while integrating it. =20 $ diff draft-ietf-eman-requirements-00.txt draft-ietf-eman-requirements-01.txt 416a417,449 2.9. Scenario 9: Ganged outlets on a Smart Power Strip =20 Some PDUs allow physical entities like outlets to be "ganged" together as a logical entity for simplified management purposes. This is particularly useful for servers with multiple power supplies, where each power supply is connected to a different physical outlet. Other implementations allow "gangs" to be created based on common ownership of outlets, such as business units or load shed priority or other non-physical relationships. =20 Current implementations allow for an "M-to-N" mapping between outlet "gangs" and physical outlets. An example of this mapping includes the following: =20 Outlet 1 (physical entity) Outlet 2 (physical entity) Outlet 3 (physical entity) Outlet 4 (physical entity) Outlet Gang A (virtual entity) Outlet Gang B (virtual entity) =20 Gang A -> Outlets 1, 2 and 3 Gang B -> Outlets 3 and 4 =20 Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both "gangs." =20 Each "Outlet Gang" entity reports the aggregated data from the individual outlet entities that comprise it and enables a single point of control for all the individual outlet entities. For example, turning "Outlet Gang A" to the "off" state would turn outlets 1, 2, and 3 "off" in some implementations. (The impact of this action on "Outlet Gang B" is to be defined by the equipment manufacturer.) =20 =20 Thanks, Chris =20 =20 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman =20 ------_=_NextPart_001_01CBE263.2358F30E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benoit,

 

Could we solve it with a “keywords” style field?  = Perhaps.  However, the relationship of an outlet gang to its = physical outlets is more structural than that.  It should be a = separate field/mechanism so that modifying one does not inadvertently = affect the other.  Trying to combine the two is not the best = solution and will bring up limitations of the schema = later.

 

For example, why use pmParentId rather than including this = information in pmKeywords?  The pmParentId/pmIndex relationship is = separate from the pmIndex/pmKeywords relationship in an object class = diagram and for good reason. 

 

Chris

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, = March 14, 2011 3:13 AM
To: Chris Verges
Cc: = eman@ietf.org
Subject: Re: [eman] Outlet Gang addition to = draft-ietf-eman-requirements-00

 

Hi = Chris,

Thanks for your proposal.
I also believe we should be = solving the case of multiple power supplies
However, we will have to = pay attention that we don't double count the traffic in the Power = Monitor Metering Domain.
See http://t= ools.ietf.org/html/draft-ietf-eman-framework-00 ->   Section = 5.2. Power Monitor Topologies: Metering versus Control versus Power = Distribution. So, even if there are two topologies for power = distribution, we would need a single Power Monitor Parent. =

Regarding the gang, could we solve this one with the context = information? For example, the pmKeywords in h= ttp://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01

= Regards, Benoit.

Hi =
Juergen,
 
I wrote an =
additon to the various scenarios described =
in
draft-ietf-eman-requirements-00 to address the =
"Outlet Gang" scenario
found on Smart =
PDUs.  Please let me know if you have any questions =
while
integrating =
it.
 
$ diff =
draft-ietf-eman-requirements-00.txt =
draft-ietf-eman-requirements-01.txt
416a417,449=

2.9.  Scenario =
9: Ganged outlets on a Smart Power =
Strip
 
   Some =
PDUs allow physical entities like outlets to be "ganged" =
together as a
   logical entity for =
simplified management purposes.  This is =
particularly
   useful for servers with =
multiple power supplies, where each power supply =
is
   connected to a different physical =
outlet.  Other implementations =
allow
   "gangs" to be created =
based on common ownership of outlets, such =
as
   business units or load shed =
priority or other non-physical =
relationships.
 
 &nb=
sp; Current implementations allow for an "M-to-N" mapping =
between outlet
   "gangs" and =
physical outlets.  An example of this mapping includes =
the
   =
following:
 
  &=
nbsp;   Outlet =
1            =
 (physical entity)
      =
Outlet =
2            =
 (physical entity)
      =
Outlet =
3            =
 (physical entity)
      =
Outlet =
4            =
 (physical entity)
      =
Outlet Gang A        (virtual =
entity)
      Outlet Gang =
B        (virtual =
entity)
 
  &nbs=
p;   Gang A -> Outlets 1, 2 and =
3
      Gang B -> =
Outlets 3 and =
4
 
   Note the =
allowed overlap on Outlet 3, where Outlet 3 belongs to =
both
   =
"gangs."
 
 =
;  Each "Outlet Gang" entity reports the aggregated data =
from the individual
   outlet entities =
that comprise it and enables a single point of control =
for
   all the individual outlet =
entities.  For example, turning "Outlet Gang =
A"
   to the "off" state =
would turn outlets 1, 2, and 3 "off" in =
some
   implementations.  (The =
impact of this action on "Outlet Gang B" is to =
be
   defined by the equipment =
manufacturer.)
 
<= pre> 
Thanks,
Chris
 
 
__=
_____________________________________________
eman =
mailing list
eman@ietf.org
https://www.ietf.org/=
mailman/listinfo/eman

 

------_=_NextPart_001_01CBE263.2358F30E-- From Internet-Drafts@ietf.org Mon Mar 14 15:15:04 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348493A6BBA; Mon, 14 Mar 2011 15:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VddiD65KzxND; Mon, 14 Mar 2011 15:15:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3FF3A6D33; Mon, 14 Mar 2011 15:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314221502.9641.58112.idtracker@localhost> Date: Mon, 14 Mar 2011 15:15:02 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action:draft-ietf-eman-requirements-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 22:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Requirements for Energy Management Author(s) : J. Quittek, et al. Filename : draft-ietf-eman-requirements-01.txt Pages : 22 Date : 2011-03-14 This memo discusses requirements for energy management, particularly for monitoring energy consumption and controlling power states of managed devices. This memo further shows that existing IETF standards are not sufficient for energy management and that energy management requires architectural considerations that are different from common other management functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-requirements-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eman-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14150713.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 16:15:03 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C713A6BD7; Mon, 14 Mar 2011 16:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU8IrNciNSxT; Mon, 14 Mar 2011 16:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93053A6EE3; Mon, 14 Mar 2011 16:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314231501.3499.9241.idtracker@localhost> Date: Mon, 14 Mar 2011 16:15:01 -0700 Cc: eman@ietf.org Subject: [eman] I-D Action:draft-ietf-eman-framework-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Energy Management Framework Author(s) : B. Claise, et al. Filename : draft-ietf-eman-framework-01.txt Pages : 38 Date : 2011-03-14 This document defines an energy management framework. Expires September 14, 2011 [page 2] Internet-Draft March 2011 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-eman-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14160344.I-D@ietf.org> --NextPart-- From jparello@cisco.com Mon Mar 14 19:12:38 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAA43A6B1E for ; Mon, 14 Mar 2011 19:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGsLc6aDgQpT for ; Mon, 14 Mar 2011 19:12:37 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 707E83A697D for ; Mon, 14 Mar 2011 19:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=1085; q=dns/txt; s=iport; t=1300155242; x=1301364842; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=WTtjU5g4Y8D+kyYW9HiUq8E8weh8+AdmWIGJHHRuAeY=; b=mOiqIguUkh3ls5v0dczKIrX6MIj3OybIUsrNeCK+tdPguaEqu4zNeiMl Et6TcO/pDqPSXRgGr2Hxc2MjDqENRfo9vZMJs2OIc/waJ3uuAN7bB9FUa 3GzLDDrNUl53HLhtDIsZ3DHXp7SOok9W6HMh+5MYZ8eOsP+BoidCHDNrk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEZofk2tJV2a/2dsb2JhbACmDnelaZxPhWIEhSuHJ4NO X-IronPort-AV: E=Sophos;i="4.62,320,1297036800"; d="scan'208";a="225620169" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2011 02:14:01 +0000 Received: from [10.10.10.5] (sjc-vpn7-1046.cisco.com [10.21.148.22]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2F2E0e3009493 for ; Tue, 15 Mar 2011 02:14:00 GMT Message-ID: <4D7ECB68.3080001@cisco.com> Date: Mon, 14 Mar 2011 19:14:00 -0700 From: john parello User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "eman@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] New version of draft-ietf-eman-energy-aware-mib-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 02:12:38 -0000 Hi, We posted a new version of the energy aware mib and request time to review at IETF-80 The differences / modifications are: - Added UML to show base information model - Added identification objects and reference links which clear up references to other mibs, NMS' and persistence - Enumerated data specific to parent or child - Revised the capabilities to ProxyAbilities for clarity and format Open Issues we'd like to discuss: 1. Length and format of PowerMonitorId. The pmPowerMonitorID should be a unique id that identfies the device in the universe. A UUID using RFC 4122 seems to suffice. However an x.509 certificate conforming to RFC 5280 could also be appropriate. We have specified the field as variable 16 bytes but would like feedback and consensus on the format that is appropriate. 2. Do we want separate tables, as depicted in figure 1, as opposed to a single pmTable? 3. Should the pmMgmtMacAddress, pmMgmtAddress,pmMgmtAddressType, and pmMgmtDNSName also be implemented for Power Monitor Parent? Thanks (Authors) From j.schoenwaelder@jacobs-university.de Tue Mar 15 00:50:25 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1346C3A6A41 for ; Tue, 15 Mar 2011 00:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0VYKsOLDrcS for ; Tue, 15 Mar 2011 00:50:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D869B3A68C9 for ; Tue, 15 Mar 2011 00:50:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 025AAC0024; Tue, 15 Mar 2011 08:51:47 +0100 (CET) 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 BIG-cKDDIQw2; Tue, 15 Mar 2011 08:51:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D6AEC0006; Tue, 15 Mar 2011 08:51:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 127B716F5ACA; Tue, 15 Mar 2011 08:51:32 +0100 (CET) Date: Tue, 15 Mar 2011 08:51:32 +0100 From: Juergen Schoenwaelder To: john parello Message-ID: <20110315075132.GB27442@elstar.local> Mail-Followup-To: john parello , "eman@ietf.org" References: <4D7ECB68.3080001@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D7ECB68.3080001@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "eman@ietf.org" Subject: Re: [eman] New version of draft-ietf-eman-energy-aware-mib-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 07:50:25 -0000 On Mon, Mar 14, 2011 at 07:14:00PM -0700, john parello wrote: > Open Issues we'd like to discuss: > > 1. Length and format of PowerMonitorId. The pmPowerMonitorID > should be a unique id that identfies the device in the universe. A > UUID using RFC 4122 seems to suffice. However an x.509 certificate > conforming to RFC 5280 could also be appropriate. We have specified > the field as variable 16 bytes but would like feedback and consensus > on the format that is appropriate. Here is how the ENTITY-MIB does it: entPhysicalUris OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains URIs and, therefore, the syntax of this object must conform to RFC 3986, section 2. Multiple URIs may be present and are separated by white space characters. Leading and trailing white space characters are ignored. 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." REFERENCE "RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, section 2, August 1998." ::= { entPhysicalEntry 18 } > 2. Do we want separate tables, as depicted in figure 1, as opposed > to a single pmTable? > > 3. Should the pmMgmtMacAddress, pmMgmtAddress,pmMgmtAddressType, and > pmMgmtDNSName also be implemented for Power Monitor Parent? It is somewhat unclear to me what I am supposed to do with these addresses / names. If your intention is to point to other SNMP agents, then you should copy from the entLogicalTable. In general, this MIB module still looks largely like a reinvention of the ENTITY-MIB to me. /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 Tue Mar 15 06:15:52 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2CF3A6BCC for ; Tue, 15 Mar 2011 06:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcFBGCPFP7xL for ; Tue, 15 Mar 2011 06:15:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A63C03A6B5A for ; Tue, 15 Mar 2011 06:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=33164; q=dns/txt; s=iport; t=1300195023; x=1301404623; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=FzmMyDszfpLhmtX1wP10dbSVu9DoidCetc0zj8tADpg=; b=OrDa5gxMWFEAqBBpUyzv9whH9HygvQbllOt79H6wMan+J/O361RogLCU nTJAsdVz8KzXnDekKMvtUT4Hj0RTyfbz4Zl5g8Fz9k1xCRktOdY+xnfLU T+UPnDxiA5kmEeuaXjTJpJEYr+iZpbQergwffLAV091kgG94kCAmnlpFG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0CACMEf02tJV2a/2dsb2JhbAAXgkWVbo1Fd5dAjgqdA4J8GYJNBIUwiwI X-IronPort-AV: E=Sophos;i="4.62,322,1297036800"; d="scan'208,217";a="225758238" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2011 13:17:01 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2FDH1Ks009157; Tue, 15 Mar 2011 13:17:01 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 08:17:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE313.4501D649" Date: Tue, 15 Mar 2011 08:16:57 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: AcvgTlH9Bg0OvbsTScGN5is2YGzi/gAAm0KQAID0xlEALyaEQA== References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd><68FBE0F3CE97264395875AC1C468F22CF36845@mail03.cyberswitching.local> From: "Mouli Chandramouli (moulchan)" To: "John Parello (jparello)" , "Chris Verges" , "Bruce Nordman" , "Rolf Winter" X-OriginalArrivalTime: 15 Mar 2011 13:17:01.0310 (UTC) FILETIME=[451551E0:01CBE313] Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 13:15:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE313.4501D649 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I also concur that ACPI and DMTF are not distractions. ACPI has been = implemented has been across many computer vendors.=20 =20 If those ACPI compliant devices are energy aware devices, then the WG = framework should accommodate these power state models. =20 =20 The control framework seems to be different (or proprietary) from = vendor to vendor (IBM, HP, ...) but the power state knobs seem to be = common across set of homogenous devices.=20 =20 I shall address the other question on the value of power state for = monitoring or for control in another email.=20 =20 Thanks Mouli =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = John Parello (jparello) Sent: Monday, March 14, 2011 8:09 PM To: Chris Verges; Bruce Nordman; Rolf Winter Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Hi Bruce, "" More important from my point of view, is that no one on this thread has = jumped to the defense of ACPI/DMTF. I am more convinced than ever that they = are a distraction for our purposes. "" I don't think those models are a distraction. They represent states of = devices that humans are familiar with. Even down to consumers the = concept of sleep, hibernate etc are well known and in the vernacular of = human interaction with machines / things that use electrical power. I can't see how we can ignore the existence of these concepts or the = enumerations of them from those two bodies. As part of our charter we have to work with other standards bodies and = this is the direct areas of intersection. I can't see dumping them. We = would have to address them and comment at the least - even if the group = said ignore them. IMO they are helpful just not sufficient. Jp -----Original Message----- From: eman-bounces@ietf.org on behalf of Chris Verges Sent: Fri 3/11/2011 5:07 PM To: Bruce Nordman; Rolf Winter Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF Hi Bruce, Please don't take silence as a form of acceptance. That's a dangerous = assumption. My position is that a single state mechanism is not appropriate for EMAN = to consider. EMAN should support multiple state mechanisms, that = coexist with each other. Consider the following scenario: Three forms of state management: ACPI, DMTF, and PDU State Management. = (PDU states include on, off, reboot, tripped, and shed. Only for = example purposes, exact details to be worked out later.) server-a - supports ACPI only server-b - supports ACPI and DMTF PDU - supports EMAN PDU State Management I propose that we allow each device to support the modality that makes = sense for that device. The key is not in which modality is supported, = but rather how the user accesses the modality. Why would we try to = limit innovation by restricting what people can do? Expose different hooks to allow a user to access ACPI, DMTF, and/or PDU = State Management through three different interfaces: emanStateControlAcpi - implemented by entities which know how to respond = to ACPI states emanStateControlDmtf - implemented by entities which know how to respond = to DMTF states emanStateControlPdu - implemented by entities which know how to respond = to PDU State Management This makes the EMAN schema more powerful and allows the market to adapt = easily as future changes in technologies and our understanding of how to = use those technologies improves. Chris From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Bruce Nordman Sent: Friday, March 11, 2011 4:43 PM To: Rolf Winter Cc: eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF Good discussion. Batteries are a specific example of a case in which a device has a = secondary function which can consume significant amounts of power, and the = secondary function is independent of the primary one. My computer is an iMac with = an integrated display, so the display is secondary to the primary function = of computation, but unlike the battery, its function is not independent (display always = powered down when the computational part is). Another example like the battery could be a TV with an integral video = recorder. The recorder can be active when the TV display is asleep or off. A = third example is an imaging MFD that does printing, copying, and scanning; it may have = the scanner active at relatively low power, but the heat-intensive toner = fusing unit powered down. Life would be simpler if devices were not = multi-functional. I think we should insist on devices having a primary function (that is = afterall how "identity" works), and the power state reflects that function. = Simple devices with internal batteries can consume a lot of power in sleep or off. = More sophisticated devices may choose to use the eman features for exposing the consumption = of the battery and balance of the system, and then have a state for the batter = exposed. We need to enable this but not require it. I am assuming that we will usually have both power state and current = power draw in watts, so the NMS will look at both (and the product's identity) = in deciding what is going on. (Perhaps part of identity is reporting if a = non-trivial battery is present (though this can be a dynamic characteristic).) So, one can look at power level, at power state, or both. I think = having both addresses Rolf's concerns.=20 For Juergen's note about the states of off-but charging (so high power), and on (and presumably AC-connected) but running only off of battery = power (so no AC draw), that confirms the need to have the actual mains power level. There have been notebook PCs designed to go off-grid in the = afternoon to avoid times of high electricity demand, so this is a very real = scenario. More important from my point of view, is that no one on this thread has = jumped to the defense of ACPI/DMTF. I am more convinced than ever that they = are a distraction for our purposes. --Bruce On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = wrote: Hi, just thinking out loud here. The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' = power state or you B) leave it separate in its own MIB module (as = described e.g. here = http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we = have battery states full(1), partiallyCharged(2), empty(3), charging(4), = discharging(5), unknown(6)). I think these are the trade-offs: Option A) You can always tell from the device power state whether it is = drawing power or not ("off but charging" e.g.) and you might be able to = order them in a way that a higher state always translates to higher = power draw. It however seems to complicate power states. Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be really = "off but charging"). The device power states can be modelled cleaner = though and you'd need to look closer to see what the battery state is to = be sure there is no power draw. Is that the trade-off we're talking about or is there anything else that = needs to be considered? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf = Of > Juergen Quittek > Sent: Freitag, 11. M=E4rz 2011 10:37 > To: Bruce Nordman > Cc: eman mailing list > Subject: Re: [eman] Power states - time to dump ACPI and DMTF > > Hi Bruce, > > I understand your preference for a simple off-sleep-on model for power > states. > How would we model a device with a battery then > - it is off, but the empty battery is being charged > - it is on, but fully supplied with power from the battery. > > On way would be treating the (internal) battery as separate device. > In this case: Can we map charging/discharging/full/empty to off-sleep- > on? > > Thanks, > > Juergen > > > Am 11.03.2011 um 07:37 schrieb Bruce Nordman: > > > (all below as contributor) > > > > > For many decades, electrical products were usually just on or = off > - a 2-state power model. In the last several decades, we have added > many electronic products with a 3-state model - on, sleep, and off. > This is necessary and existing complexity. Our discussions around > power states boil down to what complexity do we want to add to the 3- > state model, and why the burden is justified. > > > > > > In discussions on this email list, in I-drafts, and in person, > the existing listings of power states from ACPI and DMTF are often > referenced as good candidates for eman to adopt in some way. ACPI is = a > hugely important technology, and it enables large amounts of user > functionality and energy savings. I am less familiar with the reach = of > DMTF in practice, but its depth and breadth of membership are > compelling. While I agree they both deserve close examination, I = think > we can safely drop them from our discussions of what to define as = their > complexity is more a distraction than an asset. > > > > > The basic ACPI list is of "Global System States" which "apply = to > the entire system". There are four of these (G0-G3); G0 is on > ("working") and G1 is sleep ("sleeping"). G2 and G3 both forms of off > (only distinguished by whether a device is completely depowered and > whether it is safe to disassemble or not, and these distinctions seems > quite minor for eman purposes). Thus, the ACPI Global states are > essentially on/sleep/off, the 3-state power model. > > ACPI lists five "Sx" sleep states (S0 is on). S5 is > actually the G2 Off state (so not a sleep state at all), and current > implementations do not use S1 or S2, so in practice there are only two > ACPI sleep states: S3 and S4. S3 is the ordinary system sleep, with > quick wakeup. S4 is the hibernate state (with system memory saved in > non-volatile memory, possibly a hard disk) which typically has long > times to return to operation (often tens of seconds). The 1-2 second > wake time from S3 for modern personal computers is compatible with = many > IP protocol usages, e.g. initiating a TCP connection. The tens of > seconds time for S4 on current systems is not. So, the only potential > addition that the Sx states add to on/sleep/off is hibernate (and > reasonable people can differ on whether it is a fourth basic state, a > form of sleep, or a form of off). > > > ACPI does define processor states (Cx) and device > states (Dx) (collectively Px), but these are the states of particular > components, not of the system as a whole. It may be useful to expose > these through some mechanism, but they are distinct from the power > state. > > > > > DMTF essentially took the ACPI Gx states plus > hibernate and added states that are commands and/or transitions. (Is > "Master Bus Reset" a power state? I think not). If we don't include > commands or transitions (I think we should not), then these reduce to > the ACPI states. > > > > > My conclusion: ACPI and DMTF do not significantly > change the 3-state power model. If we want to talk about states = beyond > the 3-state model, it is more clear to simply reference those > extensions directly (e.g. how best to treat hibernate). Note that = this > discussion - and all others on the list - are grounded in electronic > devices. Other devices generally have a 2-state model (e.g. a light), > or 3 states, but on, off, and "ready" (think a microwave oven). > > > > > --Bruce > > > > > -- > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > -- Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 ------_=_NextPart_001_01CBE313.4501D649 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] Power states - time to dump ACPI and DMTF

Hi,

 

I also concur that ACPI and DMTF are not distractions. = =A0ACPI has been implemented has been across many computer vendors. =

 

If those ACPI compliant devices are energy aware = devices,=A0 then the WG framework should accommodate these power state models. = =A0

 

The control framework seems to be different (or = proprietary) =A0from vendor to vendor (IBM, HP, …) but the power state knobs seem to be = common across set of homogenous devices.

 

I shall address the other question on the value of power = state for monitoring or for control in another email.

 

Thanks

Mouli

 

From:= eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = John Parello (jparello)
Sent: Monday, March 14, 2011 8:09 PM
To: Chris Verges; Bruce Nordman; Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and = DMTF

 

Hi = Bruce,

""
More important from my point of view, is that no one on this thread has = jumped
to the defense of ACPI/DMTF.  I am more convinced than ever that = they are
a distraction for our purposes.
""

I don't think those models are a distraction. They represent states of = devices that humans are familiar with. Even down to consumers the concept of = sleep, hibernate etc are well known and in the vernacular of human interaction = with machines / things that use electrical power.

I can't see how we can ignore the existence of these concepts or the enumerations of them from those two bodies.

As part of our charter we have to work with other standards bodies and = this is the direct areas of intersection. I can't see dumping them. We would = have to address them and comment at the least - even if the group said ignore = them.

IMO they are helpful just not sufficient.

Jp



-----Original Message-----
From: eman-bounces@ietf.org on behalf of Chris Verges
Sent: Fri 3/11/2011 5:07 PM
To: Bruce Nordman; Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Hi Bruce,



Please don't take silence as a form of acceptance.  That's a = dangerous assumption.



My position is that a single state mechanism is not appropriate for EMAN = to consider.  EMAN should support multiple state mechanisms, that = coexist with each other.



Consider the following scenario:



Three forms of state management: ACPI, DMTF, and PDU State = Management.  (PDU states include on, off, reboot, tripped, and shed.  Only for = example purposes, exact details to be worked out later.)



server-a - supports ACPI only

server-b - supports ACPI and DMTF

PDU - supports EMAN PDU State Management



I propose that we allow each device to support the modality that makes = sense for that device.  The key is not in which modality is supported, = but rather how the user accesses the modality.  Why would we try to = limit innovation by restricting what people can do?



Expose different hooks to allow a user to access ACPI, DMTF, and/or PDU = State Management through three different interfaces:



emanStateControlAcpi - implemented by entities which know how to respond = to ACPI states

emanStateControlDmtf - implemented by entities which know how to respond = to DMTF states

emanStateControlPdu - implemented by entities which know how to respond = to PDU State Management



This makes the EMAN schema more powerful and allows the market to adapt = easily as future changes in technologies and our understanding of how to use = those technologies improves.



Chris





From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Bruce Nordman
Sent: Friday, March 11, 2011 4:43 PM
To: Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF



Good discussion.

Batteries are a specific example of a case in which a device has a = secondary
function which can consume significant amounts of power, and the = secondary
function is independent of the primary one.  My computer is an iMac = with an
integrated display, so the display is secondary to the primary function = of computation,
but unlike the battery, its function is not independent (display always = powered
down when the computational part is).

Another example like the battery could be a TV with an integral video = recorder.
The recorder can be active when the TV display is asleep or off.  A = third example
is an imaging MFD that does printing, copying, and scanning; it may have = the
scanner active at relatively low power, but the heat-intensive toner = fusing unit
powered down.  Life would be simpler if devices were not = multi-functional.

I think we should insist on devices having a primary function (that is = afterall
how "identity" works), and the power state reflects that function.  Simple devices
with internal batteries can consume a lot of power in sleep or = off.  More sophisticated
devices may choose to use the eman features for exposing the consumption = of the
battery and balance of the system, and then have a state for the batter exposed.
We need to enable this but not require it.

I am assuming that we will usually have both power state and current = power
draw in watts, so the NMS will look at both (and the product's identity) = in
deciding what is going on.  (Perhaps part of identity is reporting = if a non-trivial
battery is present (though this can be a dynamic characteristic).)
So, one can look at power level, at power state, or both.  I think = having
both addresses Rolf's concerns. 

For Juergen's note about the states of off-but charging (so high = power),
and on (and presumably AC-connected) but running only off of battery = power
(so no AC draw), that confirms the need to have the actual mains = power
level.  There have been notebook PCs designed to go off-grid in the afternoon
to avoid times of high electricity demand, so this is a very real = scenario.


More important from my point of view, is that no one on this thread has = jumped
to the defense of ACPI/DMTF.  I am more convinced than ever that = they are
a distraction for our purposes.

--Bruce

On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter = <Rolf.Winter@neclab.eu> wrote:

Hi,

just thinking out loud here.

The thing which seems to complicate matters here significantly is = batteries. You either A) try to consider battery state in the devices' power state = or you B) leave it separate in its own MIB module (as described e.g. here htt= p://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we have battery states full(1), partiallyCharged(2), empty(3), charging(4), discharging(5), unknown(6)). I think these are the = trade-offs:

Option A) You can always tell from the device power state whether it is = drawing power or not ("off but charging" e.g.) and you might be able = to order them in a way that a higher state always translates to higher power = draw. It however seems to complicate power states.

Option B) If a battery is present, you cannot tell from the device's = power state whether is it drawing power or not ("off" could be = really "off but charging"). The device power states can be modelled = cleaner though and you'd need to look closer to see what the battery state is to = be sure there is no power draw.

Is that the trade-off we're talking about or is there anything else that = needs to be considered?

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014



> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. M=E4rz 2011 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [eman] Power states - time to dump ACPI and DMTF
>
> Hi Bruce,
>
> I understand your preference for a simple off-sleep-on model for = power
> states.
> How would we model a device with a battery then
>   - it is off, but the empty battery is being charged
>   - it is on, but fully supplied with power from the = battery.
>
> On way would be treating the (internal) battery as separate = device.
> In this case: Can we map charging/discharging/full/empty to = off-sleep-
> on?
>
> Thanks,
>
>     Juergen
>
>
> Am 11.03.2011 um 07:37 schrieb Bruce Nordman:
>
>
>       (all below as contributor)
>
>
>
>
>       For many decades, electrical = products were usually just on or off
> - a 2-state power model.  In the last several decades, we have = added
> many electronic products with a 3-state model - on, sleep, and = off.
> This is necessary and existing complexity.  Our discussions = around
> power states boil down to what complexity do we want to add to the = 3-
> state model, and why the burden is justified.
>
>
>
>
>
>       In discussions on this email = list, in I-drafts, and in person,
> the existing listings of power states from ACPI and DMTF are = often
> referenced as good candidates for eman to adopt in some way.  = ACPI is a
> hugely important technology, and it enables large amounts of = user
> functionality and energy savings.  I am less familiar with the = reach of
> DMTF in practice, but its depth and breadth of membership are
> compelling.  While I agree they both deserve close = examination, I think
> we can safely drop them from our discussions of what to define as = their
> complexity is more a distraction than an asset.
>
>
>
>
>       The basic ACPI list is of  "Global System States" which "apply to
> the entire system".  There are four of these (G0-G3); G0 = is on
> ("working") and G1 is sleep ("sleeping").  = G2 and G3 both forms of off
> (only distinguished by whether a device is completely depowered = and
> whether it is safe to disassemble or not, and these distinctions = seems
> quite minor for eman purposes).  Thus, the ACPI Global states = are
> essentially on/sleep/off, the 3-state power model.
>
>           &nb= sp;       ACPI lists five "Sx" sleep states (S0 is on).  S5 is
> actually the G2 Off state (so not a sleep state at all), and = current
> implementations do not use S1 or S2, so in practice there are only = two
> ACPI sleep states: S3 and S4.  S3 is the ordinary system = sleep, with
> quick wakeup.  S4 is the hibernate state (with system memory = saved in
> non-volatile memory, possibly a hard disk) which typically has = long
> times to return to operation (often tens of seconds).   = The 1-2 second
> wake time from S3 for modern personal computers is compatible with = many
> IP protocol usages, e.g. initiating a TCP connection.  The = tens of
> seconds time for S4 on current systems is not.  So, the only potential
> addition that the Sx states add to on/sleep/off is hibernate = (and
> reasonable people can differ on whether it is a fourth basic state, = a
> form of sleep, or a form of off).
>
>
>           &nb= sp;       ACPI does define processor states (Cx) and device
> states (Dx) (collectively Px), but these are the states of = particular
> components, not of the system as a whole.  It may be useful to = expose
> these through some mechanism, but they are distinct from the = power
> state.
>
>
>
>
>           &nb= sp;       DMTF essentially took the ACPI Gx states plus
> hibernate and added states that are commands and/or = transitions.  (Is
> "Master Bus Reset" a power state?  I think = not).  If we don't include
> commands or transitions (I think we should not), then these reduce = to
> the ACPI states.
>
>
>
>
>           &nb= sp;       My conclusion: ACPI and DMTF do not significantly
> change the 3-state power model.  If we want to talk about = states beyond
> the 3-state model, it is more clear to simply reference those
> extensions directly (e.g. how best to treat hibernate).  Note = that this
> discussion - and all others on the list - are grounded in = electronic
> devices.  Other devices generally have a 2-state model (e.g. a light),
> or 3 states, but on, off, and "ready" (think a microwave = oven).
>
>
>
>
>       --Bruce
>
>
>
>
>       --
>       Bruce Nordman
>       Lawrence Berkeley National = Laboratory
>       eetd.lbl.gov/ea/nordman
>       BNordman@LBL.gov
>       510-486-7089
>       m: 510-501-7943
>
>       _______________________________________________
>       eman mailing list
>       eman@ietf.org
>       https://www.ietf.org/= mailman/listinfo/eman
>
>




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

------_=_NextPart_001_01CBE313.4501D649-- From moulchan@cisco.com Tue Mar 15 06:46:19 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81803A6D2F for ; Tue, 15 Mar 2011 06:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCt+bIgJriYy for ; Tue, 15 Mar 2011 06:46:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BD34D3A6D17 for ; Tue, 15 Mar 2011 06:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=16870; q=dns/txt; s=iport; t=1300196856; x=1301406456; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ItJKxLAt7AnX4IzxRV80ZQ/viKvHLbpSikfvgMQsl6w=; b=hs/Hrgrzjxw5gwts1Dmhifn5kILCotz9E0xwFLQItV5O7takaG7DHVW8 ntPfqUK9Au8/OF50Bg/HR4aAmnZPNR8pnclBmbRH1whoOXlhvxCxEoHce IPcnOHsPtvZika6vB8U/eKMk/PnA71gholAaZBhcWfeYSHFj527JpqwDt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8AALIKf02tJV2Y/2dsb2JhbACCXJVuhkcBhn13pTicf4J8ARiCTQSFMIsCiTE X-IronPort-AV: E=Sophos;i="4.62,322,1297036800"; d="scan'208,217";a="667280307" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2011 13:47:35 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FDlZe6000994; Tue, 15 Mar 2011 13:47:35 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 08:47:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE317.8A22AD8F" Date: Tue, 15 Mar 2011 08:47:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Power states - time to dump ACPI and DMTF Thread-Index: Acvhy6rLjoifhQxvQwq8YD7CSSw9gABSQ1eg References: <8C1CB245-C579-4B66-A37E-8ADDF2E279FA@quittek.at><791AD3077F94194BB2BDD13565B6295D05DE8F03@DAPHNIS.office.hd><68FBE0F3CE97264395875AC1C468F22CECDD12@mail03.cyberswitching.local><791AD3077F94194BB2BDD13565B6295D05DEA518@DAPHNIS.office.hd><0851C4CF-D108-4BE9-AB17-A24F05FB72D4@quittek.at> From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" , "Bruce Nordman" X-OriginalArrivalTime: 15 Mar 2011 13:47:35.0527 (UTC) FILETIME=[8A5C9F70:01CBE317] Cc: Rolf Winter , eman mailing list Subject: Re: [eman] Power states - time to dump ACPI and DMTF X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 13:46:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE317.8A22AD8F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Juergen, =20 Excellent question to get to the root of the problem. =20 =20 If the focus is pure monitoring of energy-aware devices, then it is possible to collect the power meter reading (Watts, volts, ..) of the device.=20 However, much more information about the attributes of the measurement (the identity of the device, power source, power quality, measurement caliber, ...) is also provided in the MIB. modules. =20 =20 Power states functionality if available for the device is an additional attribute of the measurement of the device. for e.g. in addition to reporting 120 watts, the device is in power state 3. =20 =20 The transition to lower power states may occur in a distributed manner; analogous to the way my Laptop LCD screen shuts-off, during long periods of inactivity.=20 In addition to the power consumption, power state information is also an additional useful data point.=20 =20 Thanks Mouli =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Monday, March 14, 2011 3:42 AM To: Bruce Nordman Cc: eman mailing list; Rolf Winter Subject: Re: [eman] Power states - time to dump ACPI and DMTF =20 Hi Bruce, =20 I still have the basic question:=20 What is the purpose of defining power states? What do we need them for in addition to functional device states? =20 We should have a clear answer in the eman WG. =20 Thanks, =20 Juergen =20 =20 Am 13.03.2011 um 22:20 schrieb Bruce Nordman: I think we are making this more complicated than necessary. First, our mandate is for monitoring, not control. We should be thinking about control (as we are), but should not complicate the monitoring protocol for control reasons. I know that eman will in future be used by some devices for control (and I support their ability to do so in future), but the great majority I believe will only use its monitoring features. Second, the NMS will know the identity of the device being monitored, so can use that information in drawing conclusions. The power state does not need to be burdened with trying to be highly informative by itself. The device HAS a basic power state already - we are just trying to expose that which already exists. When devices have the ability and need to be more elaborate in what they communicate (e.g. exposing battery details), we can facilitate that, but for those that can't or don't need this, we should allow them to be simple. Batteries are not involved in the vast majority of electricity use, and the NMS will know if the device does (or could) have one and so can draw appropriate conclusions. To Juergen's question, the assumptions that can be made about a device's energy based solely on the power state depends on the device. We don't need to say more. --Bruce On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek wrote: Hi Rolf, One of the important questions to be answered is: Do we want to be able to make assumptions on a device's energy consumption based on the power state? If a devices's power state is off, what would it tell us, if not: The devices does not need any power. If this is not the case, we are rather talking about functional states with some power-related properties, But if these states do not serve as basis for power-related assumptions on the device, then the name POWER state is misleading and not appropriate any more. Thanks, Juergen Am 13.03.2011 um 14:34 schrieb Rolf Winter: > Chris, Ted, > > I wasn't really implying anything here. To me, it seemed that a lot of the discussion was triggered by the fact that it is difficult to accommodate batteries directly in a device's power state. So I was wondering why one would actually do that (instead of treating it as a completely different entity). My mail tried to summarize the differences and I was asking whether there is more. I believe this is something we want to figure out quickly as a bunch of things will rely on this decision. But it might be that a simple model would work here. E.g. you'd have the state sleep (which means e.g. that the functional components draw little power) and a sub-state that says batteries charging (or not, or which "type" of charging) which tells you that the device as a whole is drawing significant power. The same for on and off states of course. Or you can have all separate in a battery MIB. In either case, I think other battery related information should be in a separate MIB. E.g. whether a battery is fully charged, empty, it's age, number of charging cycles and so forth. So which one should it be, which of the tradeoffs is most important to us? > > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ... --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 =20 ------_=_NextPart_001_01CBE317.8A22AD8F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Juergen,

 

Excellent question to get to the root of the problem. =  

 

If the focus is pure monitoring of energy-aware devices, = then it is possible to collect the power meter reading (Watts, volts, ..) of the = device.

However, much more information about the attributes of = the measurement (the identity of the device, power source, power quality, measurement = caliber, …) is also provided in the MIB. modules.   

 

Power states functionality if available for the device is = an additional attribute of the measurement of the device. for e.g.  in addition to reporting  120 watts, the device is in power state 3. =   

 

The transition to lower power states may occur in a = distributed manner; analogous to the way my Laptop LCD screen shuts-off, during long periods of inactivity.

In addition to the power consumption, power state = information is also an additional useful data point.

 

Thanks

Mouli

 

 

From:= eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek
Sent: Monday, March 14, 2011 3:42 AM
To: Bruce Nordman
Cc: eman mailing list; Rolf Winter
Subject: Re: [eman] Power states - time to dump ACPI and = DMTF

 

Hi Bruce,

 

I still have the basic = question: 

What is the purpose of defining power = states?

What do we need them for in addition to functional = device states?

 

We should have a clear answer in the eman = WG.

 

Thanks,

 

    Juergen

 

 

Am 13.03.2011 um 22:20 schrieb Bruce = Nordman:



I think we are = making this more complicated than necessary.
First, our mandate is for monitoring, not control.  We should = be
thinking about control (as we are), but should not complicate
the monitoring protocol for control reasons.  I know that eman
will in future be used by some devices for control (and I support
their ability to do so in future), but the great majority I believe will =
only use its monitoring features.

Second, the NMS will know the identity of the device being
monitored, so can use that information in drawing conclusions.
The power state does not need to be burdened with trying to
be highly informative by itself.  The device HAS a basic power
state already - we are just trying to expose that which already
exists.

When devices have the ability and need to be more elaborate
in what they communicate (e.g. exposing battery details), we
can facilitate that, but for those that can't or don't need this,
we should allow them to be simple.

Batteries are not involved in the vast majority of electricity
use, and the NMS will know if the device does (or could)
have one and so can draw appropriate conclusions.

To Juergen's question, the assumptions that can be made
about a device's energy based solely on the power state
depends on the device.  We don't need to say more.

--Bruce

On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek = <ietf@quittek.at> = wrote:

Hi Rolf,

One of the important questions to be answered is:
Do we want to be able to make assumptions on a device's energy = consumption based on the power state?
If a devices's power state is off, what would it tell us, if not: The = devices does not need any power.

If this is not the case, we are rather talking about functional states = with some power-related properties,
But if these states do not serve as basis for power-related assumptions = on the device, then the name
POWER state is misleading and not appropriate any more.

Thanks,

   Juergen


Am 13.03.2011 um 14:34 schrieb Rolf Winter:


> Chris, Ted,
>
> I wasn't really implying anything here. To me, it seemed that a lot = of the discussion was triggered by the fact that it is difficult to accommodate batteries directly in a device's power state. So I was wondering why one = would actually do that (instead of treating it as a completely different = entity). My mail tried to summarize the differences and I was asking whether there = is more. I believe this is something we want to figure out quickly as a bunch of = things will rely on this decision. But it might be that a simple model would = work here. E.g. you'd have the state sleep (which means e.g. that the = functional components draw little power) and a sub-state that says batteries = charging (or not, or which "type" of charging) which tells you that the = device as a whole is drawing significant power. The same for on and off states of = course. Or you can have all separate in a battery MIB. In either case, I think = other battery related information should be in a separate MIB. E.g. whether a = battery is fully charged, empty, it's age, number of charging cycles and so = forth. So which one should it be, which of the tradeoffs is most important to = us?
>
>
> Best,
>
> Rolf
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014
...




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

 

------_=_NextPart_001_01CBE317.8A22AD8F-- From chrisv@cyberswitching.com Tue Mar 15 06:48:06 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779013A6D16 for ; Tue, 15 Mar 2011 06:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn+SMJvC7gpG for ; Tue, 15 Mar 2011 06:48:05 -0700 (PDT) Received: from p01c11o141.mxlogic.net (p01c11o141.mxlogic.net [208.65.144.64]) by core3.amsl.com (Postfix) with ESMTP id 0DAD43A6C08 for ; Tue, 15 Mar 2011 06:48:05 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o141.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 96e6f7d4.0.16638.00-393.38775.p01c11o141.mxlogic.net (envelope-from ); Tue, 15 Mar 2011 07:49:30 -0600 (MDT) X-MXL-Hash: 4d7f6e6a28cd1874-012cd55b268b0e619898aef7c4619c563670a63d X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 06:48:14 -0700 Message-ID: <68FBE0F3CE97264395875AC1C468F22CF368EB@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New version of draft-ietf-eman-energy-aware-mib-01 Thread-Index: Acvi5a9dNP0Mc2H6ToyiArbbQjfVAQAMaeIQ References: <4D7ECB68.3080001@cisco.com> <20110315075132.GB27442@elstar.local> From: "Chris Verges" To: "Juergen Schoenwaelder" , "john parello" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=OlVB1je1uv0A:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=48vgC7mUAAAA:8 a=j3Z] X-AnalysisOut: [76cjpAAAA:8 a=RnEe7sDueWB39pE8aOIA:9 a=URNkXaXN0hZVBFm6ku4] X-AnalysisOut: [A:7 a=H4NpFXuVpbFG-LtrXYPhOrF3JEgA:4 a=CjuIK1q_8ugA:10 a=F] X-AnalysisOut: [vgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=Dp0fh] X-AnalysisOut: [HmrmzHqp3fQ:21 a=09PLI1COCeytSR_f:21] Cc: eman@ietf.org Subject: Re: [eman] New version of draft-ietf-eman-energy-aware-mib-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 13:48:06 -0000 If we can use a format that is compatible with entPhysicalUris, it would be a great benefit as the UUID can be reused for both ENTITY-MIB and EMAN-MIB. John, is the PowerMonitorId proposal a super-set of entPhysicalUris? (That is, can PowerMonitorId represent a value stored in entPhysicalUris without requiring any changes to the format?) Thanks, Chris -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, March 15, 2011 12:52 AM To: john parello Cc: eman@ietf.org Subject: Re: [eman] New version of draft-ietf-eman-energy-aware-mib-01 On Mon, Mar 14, 2011 at 07:14:00PM -0700, john parello wrote: =20 > Open Issues we'd like to discuss: >=20 > 1. Length and format of PowerMonitorId. The pmPowerMonitorID > should be a unique id that identfies the device in the universe. A > UUID using RFC 4122 seems to suffice. However an x.509 certificate=20 > conforming to RFC 5280 could also be appropriate. We have specified=20 > the field as variable 16 bytes but would like feedback and consensus > on the format that is appropriate.=09 Here is how the ENTITY-MIB does it: entPhysicalUris OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains URIs and, therefore, the syntax of this object must conform to RFC 3986, section 2. Multiple URIs may be present and are separated by white space characters. Leading and trailing white space characters are ignored. 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." REFERENCE "RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, section 2, August 1998." ::=3D { entPhysicalEntry 18 } > 2. Do we want separate tables, as depicted in figure 1, as opposed > to a single pmTable?=09 >=20 > 3. Should the pmMgmtMacAddress, pmMgmtAddress,pmMgmtAddressType, and=20 > pmMgmtDNSName also be implemented for Power Monitor Parent? It is somewhat unclear to me what I am supposed to do with these addresses / names. If your intention is to point to other SNMP agents, then you should copy from the entLogicalTable. In general, this MIB module still looks largely like a reinvention of the ENTITY-MIB to me. /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 jparello@cisco.com Tue Mar 15 09:58:32 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE923A6C5B for ; Tue, 15 Mar 2011 09:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9mlqBFj9w6A for ; Tue, 15 Mar 2011 09:58:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BEC483A6E3A for ; Tue, 15 Mar 2011 09:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=9543; q=dns/txt; s=iport; t=1300208396; x=1301417996; h=mime-version:subject:date:message-id:references:from:to: cc; bh=gDJEKN/b/r0A38wtTZZZ0v5xAcrfTI0ADd8euhQEVG4=; b=mGLF3pqbTO+tKg8PUEPLtxE5DQZAa+y9C3YlN4YNYEBrFq4/Yd23/aPV Go/6tXy++IA26FKXPTO7BZroZM9bhKTa1WYksDsPucANFP5O+q1fSli6j 8gQulf98BwS0Ve/Xjl34JKvK2tiqa9VIF9+Fiytm7YCWp18zoVo3AA0y9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAHc3f02tJV2b/2dsb2JhbACYSo0+d6YQnQoCgxOCTQSFMIsC X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208,217";a="347145845" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 16:59:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2FGxmdk023512; Tue, 15 Mar 2011 16:59:55 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 09:59:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE332.6394D0CB" Date: Tue, 15 Mar 2011 09:58:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] New version of draft-ietf-eman-energy-aware-mib-01 Thread-Index: Acvi5a9dNP0Mc2H6ToyiArbbQjfVAQAMaeIQAAa4j1A= References: <4D7ECB68.3080001@cisco.com> <20110315075132.GB27442@elstar.local> <68FBE0F3CE97264395875AC1C468F22CF368EB@mail03.cyberswitching.local> From: "John Parello (jparello)" To: "Chris Verges" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 15 Mar 2011 16:59:48.0086 (UTC) FILETIME=[644D7960:01CBE332] Cc: eman@ietf.org Subject: Re: [eman] New version of draft-ietf-eman-energy-aware-mib-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 16:58:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE332.6394D0CB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Chris, The URI is more akin to the altKey that we defined (perhaps defer to = that for altKey) as it can be a list of identifiers. The MonitorID is = intended to be a single unique identifier. Jp -----Original Message----- From: Chris Verges [mailto:chrisv@cyberswitching.com] Sent: Tue 3/15/2011 6:48 AM To: Juergen Schoenwaelder; John Parello (jparello) Cc: eman@ietf.org Subject: RE: [eman] New version of draft-ietf-eman-energy-aware-mib-01 =20 If we can use a format that is compatible with entPhysicalUris, it would be a great benefit as the UUID can be reused for both ENTITY-MIB and EMAN-MIB. John, is the PowerMonitorId proposal a super-set of entPhysicalUris? (That is, can PowerMonitorId represent a value stored in entPhysicalUris without requiring any changes to the format?) Thanks, Chris -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, March 15, 2011 12:52 AM To: john parello Cc: eman@ietf.org Subject: Re: [eman] New version of draft-ietf-eman-energy-aware-mib-01 On Mon, Mar 14, 2011 at 07:14:00PM -0700, john parello wrote: =20 > Open Issues we'd like to discuss: >=20 > 1. Length and format of PowerMonitorId. The pmPowerMonitorID > should be a unique id that identfies the device in the universe. A > UUID using RFC 4122 seems to suffice. However an x.509 certificate=20 > conforming to RFC 5280 could also be appropriate. We have specified=20 > the field as variable 16 bytes but would like feedback and consensus > on the format that is appropriate.=09 Here is how the ENTITY-MIB does it: entPhysicalUris OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains URIs and, therefore, the syntax of this object must conform to RFC 3986, section 2. Multiple URIs may be present and are separated by white space characters. Leading and trailing white space characters are ignored. 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." REFERENCE "RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, section 2, August 1998." ::=3D { entPhysicalEntry 18 } > 2. Do we want separate tables, as depicted in figure 1, as opposed > to a single pmTable?=09 >=20 > 3. Should the pmMgmtMacAddress, pmMgmtAddress,pmMgmtAddressType, and=20 > pmMgmtDNSName also be implemented for Power Monitor Parent? It is somewhat unclear to me what I am supposed to do with these addresses / names. If your intention is to point to other SNMP agents, then you should copy from the entLogicalTable. In general, this MIB module still looks largely like a reinvention of the ENTITY-MIB to me. /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 ------_=_NextPart_001_01CBE332.6394D0CB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] New version of = draft-ietf-eman-energy-aware-mib-01

HI Chris,

The URI is more akin to the altKey that we defined (perhaps defer to = that for altKey) as it can be a list of identifiers. The MonitorID is = intended to be a single unique identifier.

Jp



-----Original Message-----
From: Chris Verges [mailto:chrisv@cyberswitching.co= m]
Sent: Tue 3/15/2011 6:48 AM
To: Juergen Schoenwaelder; John Parello (jparello)
Cc: eman@ietf.org
Subject: RE: [eman] New version of = draft-ietf-eman-energy-aware-mib-01

If we can use a format that is compatible with entPhysicalUris, it = would
be a great benefit as the UUID can be reused for both ENTITY-MIB and
EMAN-MIB.  John, is the PowerMonitorId proposal a super-set of
entPhysicalUris?  (That is, can PowerMonitorId represent a value = stored
in entPhysicalUris without requiring any changes to the format?)

Thanks,
Chris


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] = On Behalf Of
Juergen Schoenwaelder
Sent: Tuesday, March 15, 2011 12:52 AM
To: john parello
Cc: eman@ietf.org
Subject: Re: [eman] New version of = draft-ietf-eman-energy-aware-mib-01

On Mon, Mar 14, 2011 at 07:14:00PM -0700, john parello wrote:

> Open Issues we'd like to discuss:
>
> 1. Length and format of PowerMonitorId. The pmPowerMonitorID
> should be a unique id that identfies the device in the
universe. A
> UUID using RFC 4122 seems to suffice. However an x.509 = certificate
> conforming to RFC 5280 could also be appropriate. We have = specified
> the field as variable 16 bytes but would like feedback and = consensus
> on the format that is appropriate.   

Here is how the ENTITY-MIB does it:

entPhysicalUris OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
            = "This object contains additional identification information
            about = the physical entity.  The object contains URIs and,
            = therefore, the syntax of this object must conform to RFC
            3986, = section 2.

            = Multiple URIs may be present and are separated by white
            space = characters.  Leading and trailing white space
            = characters are ignored.

            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."
    REFERENCE
            = "RFC 3986, Uniform Resource Identifiers (URI): Generic
            = Syntax, section 2, August 1998."
    ::=3D { entPhysicalEntry 18 }

> 2. Do we want separate tables, as depicted in figure 1, as = opposed
> to a single pmTable? 
>
> 3. Should the pmMgmtMacAddress, pmMgmtAddress,pmMgmtAddressType, = and
> pmMgmtDNSName also be implemented for Power Monitor Parent?

It is somewhat unclear to me what I am supposed to do with these
addresses / names. If your intention is to point to other SNMP = agents,
then you should copy from the entLogicalTable. In general, this MIB
module still looks largely like a reinvention of the ENTITY-MIB to = me.

/js

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

------_=_NextPart_001_01CBE332.6394D0CB-- From ietf@quittek.at Tue Mar 15 16:16:53 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0523A6ECA for ; Tue, 15 Mar 2011 16:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htSm7yOKDu4d for ; Tue, 15 Mar 2011 16:16:52 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 5CC863A6D74 for ; Tue, 15 Mar 2011 16:16:52 -0700 (PDT) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LobIQ-1QRXGM31NS-00gbzL; Wed, 16 Mar 2011 00:18:16 +0100 From: Juergen Quittek Content-Type: text/plain; charset=us-ascii Message-Id: Date: Wed, 16 Mar 2011 00:18:16 +0100 To: eman mailing list Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:Q6bev8sHXLtLrr1cUFcah+WVI6FIjw3wgki+7I61tcY 1MptS852rmTMDdMEADjRTB5Lj0QeowLI75om81e9qibnvRa4xd 9t7EVA1CmR2C1O7ZasbqQSX/wDv+4WtP7mfFmRoN9NlkNcVUqL 0UpxPABbJ5r36UtBna2XB8gZCss7Z4zp61SOQqD9y0sICTLE8T wuWazCkq/VS7NpTzjZD+g== Subject: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:16:53 -0000 Hi all, in some recent emails on this list I read "If the device is energy-aware" Also we have a draft called draft-ietf-eman-energy-aware-mib containing a MIB module called ENERGY-AWARE-MIB. My question is: What do we mean when we say "aware"? Is it a term to which we give a clear technical meaning or does it just sound sexy and is good for marketing? According to Merriam-Webster aware means "having or showing realization, perception, or knowledge" This rather sounds like a cognitive performance that most of the devices we are talking about will never be able to show. So what else would "aware" mean for us? And is it OK to re-define it? Is a switch that measures its own energy consumption "energy-aware"? Then it would be as well packet-aware if it has a counter for packets. It would be flow-aware if it supports NetFlow, and of course it would be TCP-aware if it implements the TCP-MIB and IP aware with the IF-MIB. According to draft-ietf-eman-energy-aware-mib a device can even become energy-aware if an external meter measures its power and reports it to a management station. In this case, the "energy-aware" device does never get any access to its power and energy values. This is terribly misleading. Let's please stop such nonsense. Considering that the IETF creates technical specifications and not marketing brochures, I suggest replacing this term in all our documents with other terms that are technically accurate. Which term to be used depends on the context. In many cases, just calling them "monitored" devices or entities is fine. But in other cases the replacement is more difficult. For example, MIB module ENERGY-AWARE-MIB could more appropriately be called EMAN-ENTITY-ID-MIB or EMAN-RELATIONSHIP-MIB, etc., depending on which feature of the module we consider most important. Thanks, Juergen From ietf@quittek.at Tue Mar 15 16:55:32 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C30D3A6E48 for ; Tue, 15 Mar 2011 16:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMh9hwkFp0cJ for ; Tue, 15 Mar 2011 16:55:31 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 9CAC83A6BE6 for ; Tue, 15 Mar 2011 16:55:31 -0700 (PDT) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MWxmu-1PTcho2Qs8-00W8dy; Wed, 16 Mar 2011 00:56:56 +0100 From: Juergen Quittek Content-Type: text/plain; charset=us-ascii Message-Id: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> Date: Wed, 16 Mar 2011 00:56:55 +0100 To: eman mailing list Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:6udbQYAb+hZoC2LomURpsvTU7FKKpkXQsWqrnvAGmSK ouYuLyS30ZQpty0+8XZpXvS9nNyxSd7IT9WXAfUyOQbUFNyiRn WuSkTXziSh56bFtW/98dVaJJKpYCHRuHTslHmSZKMeOh7llROl AH8AMHZrkHvM4g1Kh6lhmOQjdzmdvCqtOTGTN0RisG1whtqXR9 oQ6KUu8HheH+QmIT+9Slw== Subject: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:55:32 -0000 Dear all, here is a proposal for our power state discussion. It is not new and has been discussed in different flavors already. I just try to promote it by showing that it is flexible and=20 at the same time simple concerning its definition in a MIB module. It looks like people on this list want to be able to use different=20 sets of power states in order to support different energy management interfaces. An example for a set would be the set of DMTF power states. A way to support this and still allowing very simple implementations would be the following: We can be open to any set of power states by having them registered=20 at IANA. For each set we would register - an ID (number) for identifying the set - a number for each power state in this set For example: EMAN: set ID: 0 states IDs: off(0). sleep(1). on(2) DMTF:=20 set ID: 1 states: powerOn(2), sleepLight(3), sleepDeep(4), etc. ACPI: setID: 2 states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. Then we can define power state tables such that they have two indices: First the setID and then the stateID.=20 In such a table you could implement several sets (interfaces) at the = same time. a device can support three basic power states with setID 0 as first = index, but as well show all DMTF power states with setID 1 as first index. And = another index could be used for ACPI and other power state sets. Simple = implementations would just implement a single (simple) set, but device makers would have = the=20 chance to provide support for multiple interfaces (sets). A small disadvantage is that for identifying a power state we need two = numbers. We can solve this at MIB level by a textual convention for power state = index objects that defines the index as a string consisting of two numbers separated = by a dot, for example, "0.2" or "4.12". The first number would identify the set = and the second one the state within the set. Any organization that specifies or builds devices can then define sets = of power=20 states, for example, for light bulbs or for UPS systems, and register = them at IANA. This mechanism is still simple but provides openness to future = developments without need to modify or extend the MIB module. Juergen From jparello@cisco.com Tue Mar 15 17:03:57 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972833A6E48 for ; Tue, 15 Mar 2011 17:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI4g4ttlMXj4 for ; Tue, 15 Mar 2011 17:03:55 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 14F843A6A4E for ; Tue, 15 Mar 2011 17:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=8969; q=dns/txt; s=iport; t=1300233921; x=1301443521; h=mime-version:subject:date:message-id:references:from:to; bh=Jto960EcmLl+BfH+s4zwiPZ0cN/He4LN4TFQa3W/KIQ=; b=jym+4XZ/b9NIvE8tlWwsyJcVqV+/sI253oWkguW5wb1bdiiOWRd1G7O0 6QhqHJQlPywCDdL6J4GCqN8oj0oUCsCETc16WwP5kuYPBOm0iWNU8CSzm xFnIw2LJ6LfiB0tkwmZzij/2uLsCsgdo5bQ0KU9IWDimUYsTXvQ/Dapwc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMabf02tJXHA/2dsb2JhbACmDnekW5xrhWIEgXWDO4sC X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208,217";a="320708608" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2011 00:05:20 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2G05Kml028097; Wed, 16 Mar 2011 00:05:20 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 17:05:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE36D.D5F90C0F" Date: Tue, 15 Mar 2011 17:05:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: Awareness Thread-Index: AcvjZ0wmz9/TSmofRxW8xGZrGMnlJwAA7+XF References: From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 16 Mar 2011 00:05:19.0917 (UTC) FILETIME=[D675B5D0:01CBE36D] Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 00:03:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE36D.D5F90C0F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeurgen, The idea for energy aware was to distinguish between a device that is = capable of reporting it's power consumption, or has delagated that to = something that can, versus one without. So if you are metered by a device and not aware that that meter is = reporting your power (you don't defer or aggregate to it) then it = doesn't fit the definition. It has technical merit IMO because it covers = both those cases. That's a term that other standards groups are using as well see: http://odva.org/Portals/0/Library/Publications_Numbered/PUB00246_ODVA_Opt= imization_of_Energy_Usage_R0.pdf Energy Aware packet routing is a term and field of cs research as is = thermal aware scheduling for data centers and routing. So I don't see = this as a stretch at all. As for packet aware sounding ridiculous etc one can pair any two terms = out of context like that and sound ridiculous - like capable or secure - = and say a device is packet capbable or packet secure etc. So that's a = bit specious IMO. The point for us is to have a distinction between something that can = report it's power and cannot/did not delegate it. Before we partitioned the mib into two portions aware meant power = reporting but since the usage object got factored into the monitor at = the split it's probably not the best name for the draft anymore = (although it applies for context). That's a relic of this process not = modeling. As a meta item a call for a WG glossary does sound in order though. Jp -----Original Message----- From: eman-bounces@ietf.org on behalf of Juergen Quittek Sent: Tue 3/15/2011 4:18 PM To: eman mailing list Subject: [eman] Terminology: Awareness =20 Hi all, in some recent emails on this list I read "If the device is = energy-aware" Also we have a draft called draft-ietf-eman-energy-aware-mib containing a MIB module called ENERGY-AWARE-MIB. My question is: What do we mean when we say "aware"? Is it a term to which we give a clear technical meaning=20 or does it just sound sexy and is good for marketing? According to Merriam-Webster aware means "having or showing realization, perception, or knowledge" This rather sounds like a cognitive performance that most of the=20 devices we are talking about will never be able to show.=20 So what else would "aware" mean for us?=20 And is it OK to re-define it? Is a switch that measures its own energy consumption "energy-aware"? Then it would be as well packet-aware if it has a counter for packets. It would be flow-aware if it supports NetFlow, and of course it would be TCP-aware if it implements the TCP-MIB and IP aware with the IF-MIB. According to draft-ietf-eman-energy-aware-mib a device can even become energy-aware if an external meter measures its power and reports it to=20 a management station. In this case, the "energy-aware" device does never get any access to its power and energy values. This is terribly = misleading. Let's please stop such nonsense. Considering that the IETF creates technical specifications and not marketing brochures, I suggest replacing this term=20 in all our documents with other terms that are technically accurate. Which term to be used depends on the context. In many cases, just calling them "monitored" devices or entities is fine. But in other cases = the replacement is more difficult. For example, MIB module ENERGY-AWARE-MIB could more appropriately be called=20 EMAN-ENTITY-ID-MIB or EMAN-RELATIONSHIP-MIB, etc.,=20 depending on which feature of the module we consider most=20 important. Thanks, Juergen _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman ------_=_NextPart_001_01CBE36D.D5F90C0F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] Terminology: Awareness

Hi Jeurgen,

The idea for energy aware was to distinguish between a device that is = capable of reporting it's power consumption, or has delagated that to = something that can, versus one without.

So if you are metered by a device and not aware that that meter is = reporting your power (you don't defer or aggregate to it) then it = doesn't fit the definition. It has technical merit IMO because it covers = both those cases.

That's a term that other standards groups are using as well see:
http://odva.org/Portals/0/Libra= ry/Publications_Numbered/PUB00246_ODVA_Optimization_of_Energy_Usage_R0.pd= f

Energy Aware packet routing is a term and field of cs research as is = thermal aware scheduling for data centers and routing. So I don't see = this as a stretch at all.

As for packet aware sounding ridiculous etc one can pair any two terms = out of context like that and sound ridiculous - like capable or secure - = and say a device is packet capbable or packet secure etc. So that's a = bit specious IMO.

The point for us is to have a distinction between something that can = report it's power and cannot/did not delegate it.

Before we partitioned the mib into two portions aware meant power = reporting but since the usage object got factored into the monitor at = the split it's probably not the best name for the draft anymore = (although it applies for context). That's a relic of this process not = modeling.

As a meta item a call for a WG glossary does sound in order though.
Jp





-----Original Message-----
From: eman-bounces@ietf.org on behalf of Juergen Quittek
Sent: Tue 3/15/2011 4:18 PM
To: eman mailing list
Subject: [eman] Terminology: Awareness

Hi all,

in some recent emails on this list I read "If the device is = energy-aware"
Also we have a draft called draft-ietf-eman-energy-aware-mib = containing
a MIB module called ENERGY-AWARE-MIB.

My question is: What do we mean when we say "aware"?

Is it a term to which we give a clear technical meaning
or does it just sound sexy and is good for marketing?

According to Merriam-Webster aware means

    "having or showing realization, perception, or = knowledge"

This rather sounds like a cognitive performance that most of the
devices we are talking about will never be able to show.

So what else would "aware" mean for us?
And is it OK to re-define it?

Is a switch that measures its own energy consumption = "energy-aware"?
Then it would be as well packet-aware if it has a counter for = packets.
It would be flow-aware if it supports NetFlow, and of course it = would
be TCP-aware if it implements the TCP-MIB and IP aware with the = IF-MIB.

According to draft-ietf-eman-energy-aware-mib a device can even = become
energy-aware if an external meter measures its power and reports it = to
a management station. In this case, the "energy-aware" device = does never
get any access to its power and energy values. This is terribly = misleading.
Let's please stop such nonsense.

Considering that the IETF creates technical specifications
and not marketing brochures, I suggest replacing this term
in all our documents with other terms that are technically accurate.

Which term to be used depends on the context. In many cases, just
calling them "monitored" devices or entities is fine. But in = other cases
the replacement is more difficult. For example, MIB module
ENERGY-AWARE-MIB could more appropriately be called
EMAN-ENTITY-ID-MIB or  EMAN-RELATIONSHIP-MIB, etc.,
depending on which feature of the module we consider most
important.

Thanks,

    Juergen


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

------_=_NextPart_001_01CBE36D.D5F90C0F-- From jparello@cisco.com Tue Mar 15 17:08:23 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6043A6BA1 for ; Tue, 15 Mar 2011 17:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HQFAGOAjDtG for ; Tue, 15 Mar 2011 17:08:22 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6392B3A6A4E for ; Tue, 15 Mar 2011 17:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=6533; q=dns/txt; s=iport; t=1300234188; x=1301443788; h=mime-version:subject:date:message-id:references:from:to; bh=xV8riCAzEglhroVasb1WWlqh4+Cte52KvJA5qia4r1g=; b=mTSWB1wRLVB/7Mu4SQGu8fz+B4m4hPKl6T3Vv+eMHsF29q3tMvQY8/gS unjXmuurW73n7s18mu/PXFl95NHkD7+WNjwM8sQ2Bs2Qh4oNvPFg/SWMW Cn6cDaP3YsgNdzS93i/xCV4AqVKn6wa6bH98KdCKnnWMhDLep6h3r23jG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC+df02tJXG9/2dsb2JhbACmDnekXpxngnuCZwSFMIsC X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208,217";a="320709826" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2011 00:09:47 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2G09R8H010437; Wed, 16 Mar 2011 00:09:46 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 17:08:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE36E.554DD807" Date: Tue, 15 Mar 2011 17:07:18 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvjbLAeQH3aB/SZR7qirkAVoS47OwAAW05k References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 16 Mar 2011 00:08:52.0990 (UTC) FILETIME=[557611E0:01CBE36E] Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 00:08:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE36E.554DD807 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 on this!=20 =20 -----Original Message----- From: eman-bounces@ietf.org on behalf of Juergen Quittek Sent: Tue 3/15/2011 4:56 PM To: eman mailing list Subject: [eman] MIB-friendly proposal for flexible power states =20 Dear all, here is a proposal for our power state discussion. It is not new and has been discussed in different flavors already. I just try to promote it by showing that it is flexible and=20 at the same time simple concerning its definition in a MIB module. It looks like people on this list want to be able to use different=20 sets of power states in order to support different energy management interfaces. An example for a set would be the set of DMTF power states. A way to support this and still allowing very simple implementations would be the following: We can be open to any set of power states by having them registered=20 at IANA. For each set we would register - an ID (number) for identifying the set - a number for each power state in this set For example: EMAN: set ID: 0 states IDs: off(0). sleep(1). on(2) DMTF:=20 set ID: 1 states: powerOn(2), sleepLight(3), sleepDeep(4), etc. ACPI: setID: 2 states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. Then we can define power state tables such that they have two indices: First the setID and then the stateID.=20 In such a table you could implement several sets (interfaces) at the = same time. a device can support three basic power states with setID 0 as first = index, but as well show all DMTF power states with setID 1 as first index. And = another index could be used for ACPI and other power state sets. Simple = implementations would just implement a single (simple) set, but device makers would have = the=20 chance to provide support for multiple interfaces (sets). A small disadvantage is that for identifying a power state we need two = numbers. We can solve this at MIB level by a textual convention for power state = index objects that defines the index as a string consisting of two numbers separated = by a dot, for example, "0.2" or "4.12". The first number would identify the set = and the second one the state within the set. Any organization that specifies or builds devices can then define sets = of power=20 states, for example, for light bulbs or for UPS systems, and register = them at IANA. This mechanism is still simple but provides openness to future = developments without need to modify or extend the MIB module. Juergen _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman ------_=_NextPart_001_01CBE36E.554DD807 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] MIB-friendly proposal for flexible power = states

+1 on this!



-----Original Message-----
From: eman-bounces@ietf.org on behalf of Juergen Quittek
Sent: Tue 3/15/2011 4:56 PM
To: eman mailing list
Subject: [eman] MIB-friendly proposal for flexible power states

Dear all,

here is a proposal for our power state discussion.
It is not new and has been discussed in different flavors already.
I just try to promote it by showing that it is flexible and
at the same time simple concerning its definition in a MIB module.

It looks like people on this list want to be able to use different
sets of power states in order to support different energy management
interfaces. An example for a set would be the set of DMTF power = states.

A way to support this and still allowing very simple implementations
would be the following:

We can be open to any set of power states by having them registered
at IANA. For each set we would register
  - an ID (number) for identifying the set
  - a number for each power state in this set

For example:
EMAN:
set ID: 0
states IDs: off(0). sleep(1). on(2)

DMTF:
set ID: 1
states:  powerOn(2), sleepLight(3), sleepDeep(4), etc.

ACPI:
setID: 2
states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc.

Then we can define power state tables such that they have two = indices:
First the setID and then the stateID.

In such a table you could implement several sets (interfaces) at the = same time.
a device can support three basic power states with setID 0 as first = index,
but as well show all DMTF power states with setID 1 as first index. And = another
index could be used for ACPI and other power state sets. Simple = implementations
would just implement a single (simple) set, but device makers would have = the
chance to provide support for multiple interfaces (sets).

A small disadvantage is that for identifying a power state we need two = numbers.
We can solve this at MIB level by a textual convention for power state = index objects
that defines the index as a string consisting of two numbers separated = by a dot,
for example, "0.2" or "4.12". The first number would = identify the set and the second
one the state within the set.

Any organization that specifies or builds devices can then define sets = of power
states, for example, for light bulbs or for UPS systems, and register = them at IANA.
This mechanism is still simple but provides openness to future = developments
without need to modify or extend the MIB module.

    Juergen

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

------_=_NextPart_001_01CBE36E.554DD807-- From ietf@quittek.at Tue Mar 15 18:12:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3F293A6DBE for ; Tue, 15 Mar 2011 18:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae+lnDUlKMDS for ; Tue, 15 Mar 2011 18:12:26 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id C57793A6BA1 for ; Tue, 15 Mar 2011 18:12:25 -0700 (PDT) Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MRhPx-1QSdMK0WnB-00Svni; Wed, 16 Mar 2011 02:13:50 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2--191718989 Message-Id: From: Juergen Quittek Date: Wed, 16 Mar 2011 02:13:48 +0100 To: John Parello (jparello) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:XjCsDDci31nocTowULXk6DivliudrIfPwYxAr+YhDxC ipimzg3RYk5+LQbwYDXuXgihnDArEu42QhF7T8+dKwui/NQDEW GaC2e3nJFWmfnWujcW7Ox1P+BZ0hM1obQZtomBNyrlwJrdCa+n vq/IE1e1/Gp1+sRHCrEgB6h2ZQ2vZL4MyUkCNGQ3OOZIdwSf57 3dnCQXi7u+7hqxuqMlJxA== Cc: eman mailing list Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 01:12:27 -0000 --Apple-Mail-2--191718989 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi John, Am 16.03.2011 um 01:05 schrieb John Parello (jparello): > Hi Jeurgen, >=20 > The idea for energy aware was to distinguish between a device that is = capable of reporting it's power consumption, or has delagated that to = something that can, versus one without. >=20 OK. Then let's call it "monitored" device instead of "aware" device.=20 > So if you are metered by a device and not aware that that meter is = reporting your power (you don't defer or aggregate to it) then it = doesn't fit the definition. It has technical merit IMO because it covers = both those cases. >=20 > That's a term that other standards groups are using as well see: > = http://odva.org/Portals/0/Library/Publications_Numbered/PUB00246_ODVA_Opti= mization_of_Energy_Usage_R0.pdf >=20 As I said in my previous email: The IETF produces technical = specifications and not marketing brochures. > Energy Aware packet routing is a term and field of cs research as is = thermal aware scheduling for data centers and routing. So I don't see = this as a stretch at all. >=20 I have no problem with the term energy aware packet routing. This is a = reasonable use of the term "aware" (in contrast to how we have been = using it so far in the EMAN WG). > As for packet aware sounding ridiculous etc one can pair any two terms = out of context like that and sound ridiculous - like capable or secure - = and say a device is packet capbable or packet secure etc. So that's a = bit specious IMO. >=20 > The point for us is to have a distinction between something that can = report it's power and cannot/did not delegate it. >=20 I don't think that these devices "delegate" anything. The desktop phone = does not delegate power metering to the PoE switch. Typically, the PoE = switch measures without any delegation request from the phone.=20 The device is either monitored or it is not monitored. the term = "awareness" is terribly misleading. > Before we partitioned the mib into two portions aware meant power = reporting but since the usage object got factored into the monitor at = the split it's probably not the best name for the draft anymore = (although it applies for context). That's a relic of this process not = modeling. >=20 I don't care about draft names. They are ephemeral. But their technical = content is not when turned into an RFC. > As a meta item a call for a WG glossary does sound in order though. >=20 Great, let's start working on it. Thanks, Juergen > Jp >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org on behalf of Juergen Quittek > Sent: Tue 3/15/2011 4:18 PM > To: eman mailing list > Subject: [eman] Terminology: Awareness >=20 > Hi all, >=20 > in some recent emails on this list I read "If the device is = energy-aware" > Also we have a draft called draft-ietf-eman-energy-aware-mib = containing > a MIB module called ENERGY-AWARE-MIB. >=20 > My question is: What do we mean when we say "aware"? >=20 > Is it a term to which we give a clear technical meaning > or does it just sound sexy and is good for marketing? >=20 > According to Merriam-Webster aware means >=20 > "having or showing realization, perception, or knowledge" >=20 > This rather sounds like a cognitive performance that most of the > devices we are talking about will never be able to show. >=20 > So what else would "aware" mean for us? > And is it OK to re-define it? >=20 > Is a switch that measures its own energy consumption "energy-aware"? > Then it would be as well packet-aware if it has a counter for packets. > It would be flow-aware if it supports NetFlow, and of course it would > be TCP-aware if it implements the TCP-MIB and IP aware with the = IF-MIB. >=20 > According to draft-ietf-eman-energy-aware-mib a device can even become > energy-aware if an external meter measures its power and reports it to > a management station. In this case, the "energy-aware" device does = never > get any access to its power and energy values. This is terribly = misleading. > Let's please stop such nonsense. >=20 > Considering that the IETF creates technical specifications > and not marketing brochures, I suggest replacing this term > in all our documents with other terms that are technically accurate. >=20 > Which term to be used depends on the context. In many cases, just > calling them "monitored" devices or entities is fine. But in other = cases > the replacement is more difficult. For example, MIB module > ENERGY-AWARE-MIB could more appropriately be called > EMAN-ENTITY-ID-MIB or EMAN-RELATIONSHIP-MIB, etc., > depending on which feature of the module we consider most > important. >=20 > Thanks, >=20 > Juergen >=20 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 >=20 --Apple-Mail-2--191718989 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi John,

Am 16.03.2011 um 01:05 schrieb John Parello (jparello):

Hi Jeurgen,

The idea for energy aware was to distinguish between a device that is capable of reporting it's power consumption, or has delagated that to something that can, versus one without.

OK. Then let's call it "monitored" device instead of "aware" device. 

So if you are metered by a device and not aware that that meter is reporting your power (you don't defer or aggregate to it) then it doesn't fit the definition. It has technical merit IMO because it covers both those cases.

That's a term that other standards groups are using as well see:
http://odva.org/Portals/0/Library/Publications_Numbered/PUB00246_ODVA_Optimization_of_Energy_Usage_R0.pdf

As I said in my previous email: The IETF produces technical specifications and not marketing brochures.

Energy Aware packet routing is a term and field of cs research as is thermal aware scheduling for data centers and routing. So I don't see this as a stretch at all.

I have no problem with the term energy aware packet routing. This is a reasonable use of the term "aware" (in contrast to how we have been using it so far in the EMAN WG).

As for packet aware sounding ridiculous etc one can pair any two terms out of context like that and sound ridiculous - like capable or secure - and say a device is packet capbable or packet secure etc. So that's a bit specious IMO.

The point for us is to have a distinction between something that can report it's power and cannot/did not delegate it.

I don't think that these devices "delegate" anything. The desktop phone does not delegate power metering to the PoE switch. Typically, the PoE switch measures without any delegation request from the phone. 

The device is either monitored or it is not monitored. the term "awareness" is terribly misleading.

Before we partitioned the mib into two portions aware meant power reporting but since the usage object got factored into the monitor at the split it's probably not the best name for the draft anymore (although it applies for context). That's a relic of this process not modeling.

I don't care about draft names. They are ephemeral. But their technical content is not when turned into an RFC.

As a meta item a call for a WG glossary does sound in order though.

Great, let's start working on it.

Thanks,

    Juergen

Jp





-----Original Message-----
From: eman-bounces@ietf.org on behalf of Juergen Quittek
Sent: Tue 3/15/2011 4:18 PM
To: eman mailing list
Subject: [eman] Terminology: Awareness

Hi all,

in some recent emails on this list I read "If the device is energy-aware"
Also we have a draft called draft-ietf-eman-energy-aware-mib containing
a MIB module called ENERGY-AWARE-MIB.

My question is: What do we mean when we say "aware"?

Is it a term to which we give a clear technical meaning
or does it just sound sexy and is good for marketing?

According to Merriam-Webster aware means

    "having or showing realization, perception, or knowledge"

This rather sounds like a cognitive performance that most of the
devices we are talking about will never be able to show.

So what else would "aware" mean for us?
And is it OK to re-define it?

Is a switch that measures its own energy consumption "energy-aware"?
Then it would be as well packet-aware if it has a counter for packets.
It would be flow-aware if it supports NetFlow, and of course it would
be TCP-aware if it implements the TCP-MIB and IP aware with the IF-MIB.

According to draft-ietf-eman-energy-aware-mib a device can even become
energy-aware if an external meter measures its power and reports it to
a management station. In this case, the "energy-aware" device does never
get any access to its power and energy values. This is terribly misleading.
Let's please stop such nonsense.

Considering that the IETF creates technical specifications
and not marketing brochures, I suggest replacing this term
in all our documents with other terms that are technically accurate.

Which term to be used depends on the context. In many cases, just
calling them "monitored" devices or entities is fine. But in other cases
the replacement is more difficult. For example, MIB module
ENERGY-AWARE-MIB could more appropriately be called
EMAN-ENTITY-ID-MIB or  EMAN-RELATIONSHIP-MIB, etc.,
depending on which feature of the module we consider most
important.

Thanks,

    Juergen


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


--Apple-Mail-2--191718989-- From jparello@cisco.com Tue Mar 15 19:08:34 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A169E3A6B25 for ; Tue, 15 Mar 2011 19:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtkBC7eu1kqQ for ; Tue, 15 Mar 2011 19:08:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 40ED23A696C for ; Tue, 15 Mar 2011 19:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=8796; q=dns/txt; s=iport; t=1300241399; x=1301450999; h=mime-version:subject:date:message-id:references:from:to: cc; bh=R8ISq8mPif1KQnvwTdrfLLlVHZyVcftMe8Cq+wE/1iQ=; b=cd8ZZxnOucUDreNYYBLlvtuNPlewmoBpH1QSBLMfY6kQOHKeGL1hwYKc KSR91XQyUkjVrnz58Nk8+Z0yUFgpxYPXV+Y6I3Yi5Qg/Nw8xjRhKyjydO QrCE+X1FSnW9HLCAQ5u2xvE0ofMqkOY3m0HtciK4jBjiPCpd5NFGRO1PE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJq4f02tJV2Y/2dsb2JhbACmDnekR5xjhWIEgXWDO4sC X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208,217";a="414793421" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-1.cisco.com with ESMTP; 16 Mar 2011 02:09:58 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2G29wBs031956; Wed, 16 Mar 2011 02:09:58 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 19:09:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE37F.3F7CF828" Date: Tue, 15 Mar 2011 19:09:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: Awareness Thread-Index: Acvjd2v6rTBwbVKkQeiRhw5olJMdiQABmxIE References: From: "John Parello (jparello)" To: "Juergen Quittek" X-OriginalArrivalTime: 16 Mar 2011 02:09:58.0212 (UTC) FILETIME=[3FDEF840:01CBE37F] Cc: eman mailing list Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 02:08:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE37F.3F7CF828 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeurgen, inline... -----Original Message----- From: Juergen Quittek [mailto:ietf@quittek.at] Sent: Tue 3/15/2011 6:13 PM To: John Parello (jparello) Cc: eman mailing list Subject: Re: [eman] Terminology: Awareness =20 Hi John, Am 16.03.2011 um 01:05 schrieb John Parello (jparello): > Hi Jeurgen, >=20 > The idea for energy aware was to distinguish between a device that is = capable of reporting it's power consumption, or has delagated that to = something that can, versus one without. >=20 OK. Then let's call it "monitored" device instead of "aware" device.=20 [jp] I think the concept of aware covers the fact that a device knows = it's being metered versus metered without it. If I were to monitor you = there's then a later distinction of whether you know about it or not. So = there's a clear difference between the two. > So if you are metered by a device and not aware that that meter is = reporting your power (you don't defer or aggregate to it) then it = doesn't fit the definition. It has technical merit IMO because it covers = both those cases. >=20 > That's a term that other standards groups are using as well see: > = http://odva.org/Portals/0/Library/Publications_Numbered/PUB00246_ODVA_Opt= imization_of_Energy_Usage_R0.pdf >=20 As I said in my previous email: The IETF produces technical = specifications and not marketing brochures. [jp] Neither do I and this as a pure modeling distinction. The ODVA = produces the CIP specification which produces an energy aware object = with data and services. I can point to other where this is a clear = technical term. There's a very big difference between monitored and = aware of the monitoring. > Energy Aware packet routing is a term and field of cs research as is = thermal aware scheduling for data centers and routing. So I don't see = this as a stretch at all. >=20 I have no problem with the term energy aware packet routing. This is a = reasonable use of the term "aware" (in contrast to how we have been = using it so far in the EMAN WG). [jp] See above I've sited a clear difference for the term. > As for packet aware sounding ridiculous etc one can pair any two terms = out of context like that and sound ridiculous - like capable or secure - = and say a device is packet capbable or packet secure etc. So that's a = bit specious IMO. >=20 > The point for us is to have a distinction between something that can = report it's power and cannot/did not delegate it. >=20 I don't think that these devices "delegate" anything. The desktop phone = does not delegate power metering to the PoE switch. Typically, the PoE = switch measures without any delegation request from the phone.=20 The device is either monitored or it is not monitored. the term = "awareness" is terribly misleading. [jp] They do in fact delegate to the switch through PoE negotiation, = time of day control and metering. They are distinct and we find the = distinction needed in lines of devices we ship. I can send you details = off thread if needed. Monitored versus monitored and aware of the = monitoring is clearly different. > Before we partitioned the mib into two portions aware meant power = reporting but since the usage object got factored into the monitor at = the split it's probably not the best name for the draft anymore = (although it applies for context). That's a relic of this process not = modeling. >=20 I don't care about draft names. They are ephemeral. But their technical = content is not when turned into an RFC. [jp] ACK on that > As a meta item a call for a WG glossary does sound in order though. >=20 Great, let's start working on it. [jp] ACK on that as well. Jp ------_=_NextPart_001_01CBE37F.3F7CF828 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] Terminology: Awareness

Hi Jeurgen,

inline...

-----Original Message-----
From: Juergen Quittek [mailto:ietf@quittek.at]
Sent: Tue 3/15/2011 6:13 PM
To: John Parello (jparello)
Cc: eman mailing list
Subject: Re: [eman] Terminology: Awareness

Hi John,

Am 16.03.2011 um 01:05 schrieb John Parello (jparello):

> Hi Jeurgen,
>
> The idea for energy aware was to distinguish between a device that = is capable of reporting it's power consumption, or has delagated that to = something that can, versus one without.
>
OK. Then let's call it "monitored" device instead of = "aware" device.

[jp] I think the concept of aware covers the fact that a device knows = it's being metered versus metered without it. If I were to monitor you = there's then a later distinction of whether you know about it or not. So = there's a clear difference between the two.


> So if you are metered by a device and not aware that that meter is = reporting your power (you don't defer or aggregate to it) then it = doesn't fit the definition. It has technical merit IMO because it covers = both those cases.
>
> That's a term that other standards groups are using as well = see:
> http://odva.org/Portals/0/Libra= ry/Publications_Numbered/PUB00246_ODVA_Optimization_of_Energy_Usage_R0.pd= f
>
As I said in my previous email: The IETF produces technical = specifications and not marketing brochures.

[jp] Neither do I and this as a pure modeling distinction. The ODVA = produces the CIP specification which produces an energy aware object = with data and services. I can point to other where this is a clear = technical term. There's a very big difference between monitored and = aware of the monitoring.

> Energy Aware packet routing is a term and field of cs research as = is thermal aware scheduling for data centers and routing. So I don't see = this as a stretch at all.
>
I have no problem with the term energy aware packet routing. This is a = reasonable use of the term "aware" (in contrast to how we have = been using it so far in the EMAN WG).

[jp] See above I've sited a clear difference for the term.

> As for packet aware sounding ridiculous etc one can pair any two = terms out of context like that and sound ridiculous - like capable or = secure - and say a device is packet capbable or packet secure etc. So = that's a bit specious IMO.
>
> The point for us is to have a distinction between something that = can report it's power and cannot/did not delegate it.
>
I don't think that these devices "delegate" anything. The = desktop phone does not delegate power metering to the PoE switch. = Typically, the PoE switch measures without any delegation request from = the phone.

The device is either monitored or it is not monitored. the term = "awareness" is terribly misleading.

[jp] They do in fact delegate to the switch through PoE negotiation, = time of day control and metering. They are distinct and we find the = distinction needed in lines of devices we ship. I can send you details = off thread if needed. Monitored versus monitored and aware of the = monitoring is clearly different.

> Before we partitioned the mib into two portions aware meant power = reporting but since the usage object got factored into the monitor at = the split it's probably not the best name for the draft anymore = (although it applies for context). That's a relic of this process not = modeling.
>
I don't care about draft names. They are ephemeral. But their technical = content is not when turned into an RFC.

[jp] ACK  on that

> As a meta item a call for a WG glossary does sound in order = though.
>
Great, let's start working on it.

[jp] ACK on that as well.


Jp

------_=_NextPart_001_01CBE37F.3F7CF828-- From ietf@quittek.at Tue Mar 15 19:47:13 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2615B3A6CA4 for ; Tue, 15 Mar 2011 19:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRXZdMEGoOsH for ; Tue, 15 Mar 2011 19:47:11 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 135DF3A6C18 for ; Tue, 15 Mar 2011 19:46:40 -0700 (PDT) Received: from [192.168.1.138] (HSI-KBW-109-193-075-248.hsi7.kabel-badenwuerttemberg.de [109.193.75.248]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MRyX8-1QSsjh2yIk-00TCf8; Wed, 16 Mar 2011 03:48:03 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-3--186063783 Message-Id: From: Juergen Quittek Date: Wed, 16 Mar 2011 03:48:03 +0100 To: John Parello (jparello) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:l5/zaTTNuJ4cQby6X6sdk3Yp8iTe3WwdvJrDA3sc8ec pZWTUo+kMXmR4Z219H6MKz5YFhkumt+w0pH8K1hMKmAcPIgt15 hntf2Q8GLywPsxwiJeHOVC3aU0j8eZ/5w43m300UL/shsMAmDg jsavxyf9oyLCOqsvpKVoqJwjrqQkxNvABnqmLVRu7yff7R+Sly aQLR7ETL/FjEcgtb8/X3g== Cc: eman mailing list Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 02:47:13 -0000 --Apple-Mail-3--186063783 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi John, Again inline ... Am 16.03.2011 um 03:09 schrieb John Parello (jparello): >=20 > Hi Jeurgen, >=20 > inline... >=20 > -----Original Message----- > From: Juergen Quittek [mailto:ietf@quittek.at] > Sent: Tue 3/15/2011 6:13 PM > To: John Parello (jparello) > Cc: eman mailing list > Subject: Re: [eman] Terminology: Awareness >=20 > Hi John, >=20 > Am 16.03.2011 um 01:05 schrieb John Parello (jparello): >=20 > > Hi Jeurgen, > > > > The idea for energy aware was to distinguish between a device that = is capable of reporting it's power consumption, or has delagated that to = something that can, versus one without. > > > OK. Then let's call it "monitored" device instead of "aware" device. >=20 > [jp] I think the concept of aware covers the fact that a device knows = it's being metered versus metered without it. If I were to monitor you = there's then a later distinction of whether you know about it or not. So = there's a clear difference between the two. >=20 So you define a device to be "energy-aware", if there is the information = that it is being metered available to it. Hence, devices that are being metered, but do not have this information = are not energy-aware. What is this distinction useful for? I just think about a device that knows its traffic is being monitored by = a probe attached to one of its links and another device that does not = know it. What makes the difference. I think it is important that the management = system knows which device is monitored. Why would we tell this all = devices? According to this definition, IP phones attached to a PoE switched and = metered by it are not energy-aware, if not the PoE switch tells them. = Why should the switch do so? What would be different if it did so? > > So if you are metered by a device and not aware that that meter is = reporting your power (you don't defer or aggregate to it) then it = doesn't fit the definition. It has technical merit IMO because it covers = both those cases. > > > > That's a term that other standards groups are using as well see: > > = http://odva.org/Portals/0/Library/Publications_Numbered/PUB00246_ODVA_Opti= mization_of_Energy_Usage_R0.pdf > > > As I said in my previous email: The IETF produces technical = specifications and not marketing brochures. >=20 > [jp] Neither do I and this as a pure modeling distinction. The ODVA = produces the CIP specification which produces an energy aware object = with data and services. I can point to other where this is a clear = technical term. There's a very big difference between monitored and = aware of the monitoring. >=20 OK. What is the big difference. I am curious to understand it. I have = not found it explained in any of our drafts. > > Energy Aware packet routing is a term and field of cs research as is = thermal aware scheduling for data centers and routing. So I don't see = this as a stretch at all. > > > I have no problem with the term energy aware packet routing. This is a = reasonable use of the term "aware" (in contrast to how we have been = using it so far in the EMAN WG). >=20 > [jp] See above I've sited a clear difference for the term. >=20 See above. What makes the difference? What use makes a device of the = knowledge that it is being metered? > > As for packet aware sounding ridiculous etc one can pair any two = terms out of context like that and sound ridiculous - like capable or = secure - and say a device is packet capbable or packet secure etc. So = that's a bit specious IMO. > > > > The point for us is to have a distinction between something that can = report it's power and cannot/did not delegate it. > > > I don't think that these devices "delegate" anything. The desktop = phone does not delegate power metering to the PoE switch. Typically, the = PoE switch measures without any delegation request from the phone. >=20 > The device is either monitored or it is not monitored. the term = "awareness" is terribly misleading. >=20 > [jp] They do in fact delegate to the switch through PoE negotiation, = time of day control and metering. They are distinct and we find the = distinction needed in lines of devices we ship. I can send you details = off thread if needed. Monitored versus monitored and aware of the = monitoring is clearly different. >=20 Is this part of the PoE standard or a proprietary extension?=20 I don't remember reading anything about a metering delegation request in = the PoE specification.=20 Thanks, Juergen > > Before we partitioned the mib into two portions aware meant power = reporting but since the usage object got factored into the monitor at = the split it's probably not the best name for the draft anymore = (although it applies for context). That's a relic of this process not = modeling. > > > I don't care about draft names. They are ephemeral. But their = technical content is not when turned into an RFC. >=20 > [jp] ACK on that >=20 > > As a meta item a call for a WG glossary does sound in order though. > > > Great, let's start working on it. >=20 > [jp] ACK on that as well. >=20 >=20 > Jp >=20 --Apple-Mail-3--186063783 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = John,

Again inline ...

Am = 16.03.2011 um 03:09 schrieb John Parello (jparello):


Hi Jeurgen,

inline...

-----Original Message-----
From: Juergen Quittek [mailto:ietf@quittek.at]
Sent: Tue 3/15/2011 6:13 PM
To: John Parello (jparello)
Cc: eman mailing list
Subject: Re: [eman] Terminology: Awareness

Hi John,

Am 16.03.2011 um 01:05 schrieb John Parello (jparello):

> Hi Jeurgen,
>
> The idea for energy aware was to distinguish between a device that = is capable of reporting it's power consumption, or has delagated that to = something that can, versus one without.
>
OK. Then let's call it "monitored" device instead of "aware" device.

[jp] I think the concept of aware covers the fact that a device knows = it's being metered versus metered without it. If I were to monitor you = there's then a later distinction of whether you know about it or not. So = there's a clear difference between the = two.

So you define a device to be = "energy-aware", if there is the information that it is being metered = available to it.
Hence, devices that are being metered, but do = not have this information are not energy-aware.
What is this = distinction useful for?

I just think about a = device that knows its traffic is being monitored by a probe attached to = one of its links and another device that does not know = it.
What makes the difference. I think it is important that = the management system knows which device is monitored. Why would we tell = this all devices?

According to this definition, = IP phones attached to a PoE switched and metered by it are not = energy-aware, if not the PoE switch tells them. Why should the switch do = so?
What would be different if it did so?

> So if you are metered by a device and not aware that that meter is = reporting your power (you don't defer or aggregate to it) then it = doesn't fit the definition. It has technical merit IMO because it covers = both those cases.
>
> That's a term that other standards groups are using as well = see:
> http://odva.org/Portals/0/Library= /Publications_Numbered/PUB00246_ODVA_Optimization_of_Energy_Usage_R0.pdf
>
As I said in my previous email: The IETF produces technical = specifications and not marketing brochures.

[jp] Neither do I and this as a pure modeling distinction. The ODVA = produces the CIP specification which produces an energy aware object = with data and services. I can point to other where this is a clear = technical term. There's a very big difference between monitored and = aware of the monitoring.

OK. What is = the big difference. I am curious to understand it. I have not found it = explained in any of our drafts.

> Energy Aware packet routing is a term and field of cs research as = is thermal aware scheduling for data centers and routing. So I don't see = this as a stretch at all.
>
I have no problem with the term energy aware packet routing. This is a = reasonable use of the term "aware" (in contrast to how we have been = using it so far in the EMAN WG).

[jp] See above I've sited a clear difference for the = term.

See above. What makes the = difference? What use makes a device of the knowledge that it is being = metered?

> As for packet aware sounding ridiculous etc one can pair any two = terms out of context like that and sound ridiculous - like capable or = secure - and say a device is packet capbable or packet secure etc. So = that's a bit specious IMO.
>
> The point for us is to have a distinction between something that = can report it's power and cannot/did not delegate it.
>
I don't think that these devices "delegate" anything. The desktop phone = does not delegate power metering to the PoE switch. Typically, the PoE = switch measures without any delegation request from the phone.

The device is either monitored or it is not monitored. the term = "awareness" is terribly misleading.

[jp] They do in fact delegate to the switch through PoE negotiation, = time of day control and metering. They are distinct and we find the = distinction needed in lines of devices we ship. I can send you details = off thread if needed. Monitored versus monitored and aware of the = monitoring is clearly different.

Is = this part of the PoE standard or a proprietary = extension? 


=
   =  Juergen



> Before we partitioned the mib into two portions aware meant power = reporting but since the usage object got factored into the monitor at = the split it's probably not the best name for the draft anymore = (although it applies for context). That's a relic of this process not = modeling.
>
I don't care about draft names. They are ephemeral. But their technical = content is not when turned into an RFC.

[jp] ACK  on that

> As a meta item a call for a WG glossary does sound in order = though.
>
Great, let's start working on it.

[jp] ACK on that as well.


Jp


= --Apple-Mail-3--186063783-- From tirth.ghose@gmail.com Tue Mar 15 20:21:13 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7DD3A6A7E for ; Tue, 15 Mar 2011 20:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQwDQqIQRZ49 for ; Tue, 15 Mar 2011 20:21:12 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id A94743A6BD3 for ; Tue, 15 Mar 2011 20:21:11 -0700 (PDT) Received: by iyi12 with SMTP id 12so1465983iyi.31 for ; Tue, 15 Mar 2011 20:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GfDBCEfq9ZCJQntUP78rdxpoGoE9KQLakxuMCF5u3D8=; b=F4wlQlVwIoRh2HITPpSOUjVsRPCDhJ5C4QDsk5PGy/k53y225hyZn+jKRym3aQ5sWR +sNWg1QXeXPLKj5UMop0vCUETlanPpymMDTzJ4epMXkrEiw3ZlxqmZLNYdW5PB7IyIbw NtlipRJm1AwKw/+2FOCuoP4wpHSI8E3Z6NqIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ZotlHDHjLiCZcyFaobvjSYST0CZ4AZw4lvukQDMKVyD+ubH/Ag70aWh2FgILzbKt/i ZnLaH7oWLmdM4hO05BQo9F6J9mKTVR0OQ/kI1SwhcrfRwpyR9Pg6ku3sJgf5zFtoqN3r AK3B/CfaNbJ1BgcyshmPoSNNkv67NJ2LEPTJo= MIME-Version: 1.0 Received: by 10.43.54.210 with SMTP id vv18mr252173icb.103.1300245756654; Tue, 15 Mar 2011 20:22:36 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Tue, 15 Mar 2011 20:22:36 -0700 (PDT) In-Reply-To: References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> Date: Tue, 15 Mar 2011 20:22:36 -0700 X-Google-Sender-Auth: bBri1Ul0WXGUgxZ-pZZDoxRigFs Message-ID: From: Ted Ghose To: Juergen Quittek , "John Parello (jparello)" Content-Type: multipart/alternative; boundary=bcaec51dd7197234d0049e910eed Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 03:21:13 -0000 --bcaec51dd7197234d0049e910eed Content-Type: text/plain; charset=ISO-8859-1 Hi Juergen This is a great start, why can't we take all and have one unified standard this is the standard body, isn't it? If you lead to one unified standard, like SI and we publish a conversation, everyone across the world will have one thing to refer to. thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Tue, Mar 15, 2011 at 5:07 PM, John Parello (jparello) wrote: > > +1 on this! > > > > > -----Original Message----- > From: eman-bounces@ietf.org on behalf of Juergen Quittek > Sent: Tue 3/15/2011 4:56 PM > To: eman mailing list > Subject: [eman] MIB-friendly proposal for flexible power states > > Dear all, > > here is a proposal for our power state discussion. > It is not new and has been discussed in different flavors already. > I just try to promote it by showing that it is flexible and > at the same time simple concerning its definition in a MIB module. > > It looks like people on this list want to be able to use different > sets of power states in order to support different energy management > interfaces. An example for a set would be the set of DMTF power states. > > A way to support this and still allowing very simple implementations > would be the following: > > We can be open to any set of power states by having them registered > at IANA. For each set we would register > - an ID (number) for identifying the set > - a number for each power state in this set > > For example: > EMAN: > set ID: 0 > states IDs: off(0). sleep(1). on(2) > > DMTF: > set ID: 1 > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. > > ACPI: > setID: 2 > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. > > Then we can define power state tables such that they have two indices: > First the setID and then the stateID. > > In such a table you could implement several sets (interfaces) at the same > time. > a device can support three basic power states with setID 0 as first index, > but as well show all DMTF power states with setID 1 as first index. And > another > index could be used for ACPI and other power state sets. Simple > implementations > would just implement a single (simple) set, but device makers would have > the > chance to provide support for multiple interfaces (sets). > > A small disadvantage is that for identifying a power state we need two > numbers. > We can solve this at MIB level by a textual convention for power state > index objects > that defines the index as a string consisting of two numbers separated by a > dot, > for example, "0.2" or "4.12". The first number would identify the set and > the second > one the state within the set. > > Any organization that specifies or builds devices can then define sets of > power > states, for example, for light bulbs or for UPS systems, and register them > at IANA. > This mechanism is still simple but provides openness to future developments > without need to modify or extend the MIB module. > > 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 > > --bcaec51dd7197234d0049e910eed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi=A0Juergen

This is a great start, why can't = we take all and have one unified standard

this is the st= andard body, isn't it?

If you lead to one unif= ied standard, like SI and we publish a conversation,=A0everyone=A0across th= e world will have one thing to refer to.=A0

thanks

-tg-
=A0
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'= ``'*:-.,_:-.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 Save time... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_= :-.,_,.-:**:-.,_,.


On Tue, Mar 15, 2011 at 5:07 PM, John Pa= rello (jparello) <jparello@cisco.com> wrote:

+1 on this!





-----Original Message-----
From: eman-bounc= es@ietf.org on behalf of Juergen Quittek
Sent: Tue 3/15/2011 4:56 PM
To: eman mailing list
Subject: [eman] MIB-friendly proposal for flexible power states

Dear all,

here is a proposal for our power state discussion.
It is not new and has been discussed in different flavors already.
I just try to promote it by showing that it is flexible and
at the same time simple concerning its definition in a MIB module.

It looks like people on this list want to be able to use different
sets of power states in order to support different energy management
interfaces. An example for a set would be the set of DMTF power states.

A way to support this and still allowing very simple implementations
would be the following:

We can be open to any set of power states by having them registered
at IANA. For each set we would register
=A0 - an ID (number) for identifying the set
=A0 - a number for each power state in this set

For example:
EMAN:
set ID: 0
states IDs: off(0). sleep(1). on(2)

DMTF:
set ID: 1
states:=A0 powerOn(2), sleepLight(3), sleepDeep(4), etc.

ACPI:
setID: 2
states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc.

Then we can define power state tables such that they have two indices:
First the setID and then the stateID.

In such a table you could implement several sets (interfaces) at the same t= ime.
a device can support three basic power states with setID 0 as first index,<= br> but as well show all DMTF power states with setID 1 as first index. And ano= ther
index could be used for ACPI and other power state sets. Simple implementat= ions
would just implement a single (simple) set, but device makers would have th= e
chance to provide support for multiple interfaces (sets).

A small disadvantage is that for identifying a power state we need two numb= ers.
We can solve this at MIB level by a textual convention for power state inde= x objects
that defines the index as a string consisting of two numbers separated by a= dot,
for example, "0.2" or "4.12". The first number would id= entify the set and the second
one the state within the set.

Any organization that specifies or builds devices can then define sets of p= ower
states, for example, for light bulbs or for UPS systems, and register them = at IANA.
This mechanism is still simple but provides openness to future developments=
without need to modify or extend the MIB module.

=A0=A0=A0 Juergen

_______________________________________________
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


--bcaec51dd7197234d0049e910eed-- From jparello@cisco.com Tue Mar 15 20:23:05 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765DB3A6B65 for ; Tue, 15 Mar 2011 20:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8gu54Yx8UfV for ; Tue, 15 Mar 2011 20:23:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8FCCF3A6AC9 for ; Tue, 15 Mar 2011 20:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=8613; q=dns/txt; s=iport; t=1300245869; x=1301455469; h=mime-version:subject:date:message-id:references:from:to: cc; bh=pem9b5J9pxSIWygcKlQyo3MJ9i7ajB6oYyC3LA/Uxao=; b=SAXYtlzm0ltYQ53YErvbk+au+ij38C29hIniR2uapf0q44zVHV2fh3ii T8/WlSZuhyivMtT5sVqaFKsNKbpNidEBsW70rsGYhMtqe5vG+hM1Y35ci Fb6GvJ4CX+krwppa5FQCu8tkL8wfBJNiOUQR31QCyANNdkxSyMMax8+Xg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC7Kf02tJV2Z/2dsb2JhbACmDnejcZxihWIEhTCLAw X-IronPort-AV: E=Sophos;i="4.63,192,1299456000"; d="scan'208,217";a="414806910" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 16 Mar 2011 03:24:29 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2G3OSBj001249; Wed, 16 Mar 2011 03:24:28 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 20:24:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE389.A81CBB52" Date: Tue, 15 Mar 2011 20:24:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: Awareness Thread-Index: AcvjhJT5yGw36S5WRJqavVna1NJMBwAARakb References: From: "John Parello (jparello)" To: "Juergen Quittek" X-OriginalArrivalTime: 16 Mar 2011 03:24:28.0467 (UTC) FILETIME=[A859C030:01CBE389] Cc: eman mailing list Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 03:23:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE389.A81CBB52 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jeurgen, trimmed see inline... -----Original Message----- From: Juergen Quittek [mailto:ietf@quittek.at] Sent: Tue 3/15/2011 7:48 PM To: John Parello (jparello) Cc: eman mailing list Subject: Re: [eman] Terminology: Awareness =20 > [jp] I think the concept of aware covers the fact that a device knows = it's being metered versus metered without it. If I were to monitor you = there's then a later distinction of whether you know about it or not. So = there's a clear difference between the two. >=20 So you define a device to be "energy-aware", if there is the information = that it is being metered available to it. Hence, devices that are being metered, but do not have this information = are not energy-aware. What is this distinction useful for? I just think about a device that knows its traffic is being monitored by = a probe attached to one of its links and another device that does not = know it. What makes the difference. I think it is important that the management = system knows which device is monitored. Why would we tell this all = devices? According to this definition, IP phones attached to a PoE switched and = metered by it are not energy-aware, if not the PoE switch tells them. = Why should the switch do so? What would be different if it did so? [jp] Yes that's right. If a PoE is not capable of reporting its usage = and is metered by the switch and doesn't know about it - it is not = aware. Let's look at that same device if it is aware but can't report = it's own usage. If the PoE phone is aware that the switch can report = it's usage when asked it can defer the question to its switch versus = saying I don't know. That's a very useful pattern of precessing. I don't = know, versus hold on I'll find out, or ask this person - very distinct = processing from indicating aware versus monitored. You use the = difference yourself "probe". There is no difference in probing and = monitoring (observer) but there is very much a difference if the device = itself is capable of reporting a value or knowing where to direct you = (observed).=20 Management of devices in this space reply on making the distinction of = what is probed and what is capable of reporting itself or via a proxy. = It's the nature of the problem domain. Now let's shift to correlation of data from sets of devices. When an NMS = is processing data there is quite an advantage in the correlation of the = data. Example in an enterprise or data center deployment you have = setups where meters (ok probes) are set up for sections of distribution = (panels, racks, plugs, device) and may or may not be redundant. These = monitored/probed values all have difference accuracy and capabilities. A = device that reports it's consumption and is aware of the device(s) = metering it can indicate as such and the data can be correlated to = resolve (in)accuracies and accounted. Monitoring is not sufficient alone as that is an attribute based upon = the observer not the observed. =20 >=20 > [jp] They do in fact delegate to the switch through PoE negotiation, = time of day control and metering. They are distinct and we find the = distinction needed in lines of devices we ship. I can send you details = off thread if needed. Monitored versus monitored and aware of the = monitoring is clearly different. >=20 Is this part of the PoE standard or a proprietary extension?=20 I don't remember reading anything about a metering delegation request in = the PoE specification.=20 [jp] Sorry if I wasn't clear, yes proprietary, and they exist as I = stated that. "we find the distinctions in lines of devices we ship". = This pattern of processing does exist in other lines of devices and not = a standard. Jp ------_=_NextPart_001_01CBE389.A81CBB52 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eman] Terminology: Awareness

Hi Jeurgen,

trimmed see inline...


-----Original Message-----
From: Juergen Quittek [mailto:ietf@quittek.at]
Sent: Tue 3/15/2011 7:48 PM
To: John Parello (jparello)
Cc: eman mailing list
Subject: Re: [eman] Terminology: Awareness

> [jp] I think the concept of aware covers the fact that a device = knows it's being metered versus metered without it. If I were to monitor = you there's then a later distinction of whether you know about it or = not. So there's a clear difference between the two.
>
So you define a device to be "energy-aware", if there is the = information that it is being metered available to it.
Hence, devices that are being metered, but do not have this information = are not energy-aware.
What is this distinction useful for?

I just think about a device that knows its traffic is being monitored by = a probe attached to one of its links and another device that does not = know it.
What makes the difference. I think it is important that the management = system knows which device is monitored. Why would we tell this all = devices?

According to this definition, IP phones attached to a PoE switched and = metered by it are not energy-aware, if not the PoE switch tells them. = Why should the switch do so?
What would be different if it did so?


[jp] Yes that's right. If a PoE is not capable of reporting its usage = and is metered by the switch and doesn't know about it - it is not = aware. Let's look at that same device if it is aware but can't report = it's own usage. If the PoE phone is aware that the switch can report = it's usage when asked it can defer the question to its switch versus = saying I don't know. That's a very useful pattern of precessing. I don't = know, versus hold on I'll find out, or ask this person - very distinct = processing from indicating aware versus monitored. You use the = difference yourself "probe". There is no difference in probing = and monitoring (observer) but there is very much a difference if the = device itself is capable of reporting a value or knowing where to direct = you (observed).

Management of devices in this space reply on making the distinction of = what is probed and what is capable of reporting itself or via a proxy. = It's the nature of the problem domain.

Now let's shift to correlation of data from sets of devices. When an NMS = is processing data there is quite an advantage in the correlation of the = data.  Example in an enterprise or data center deployment you have = setups where meters (ok probes) are set up for sections of distribution = (panels, racks, plugs, device) and may or may not be redundant. These = monitored/probed values all have difference accuracy and capabilities. A = device that reports it's consumption and is aware of the device(s) = metering it can indicate as such and the data can be correlated to = resolve (in)accuracies and accounted.

Monitoring is not sufficient alone as that is an attribute based upon = the observer not the observed. 


>
> [jp] They do in fact delegate to the switch through PoE = negotiation, time of day control and metering. They are distinct and we = find the distinction needed in lines of devices we ship. I can send you = details off thread if needed. Monitored versus monitored and aware of = the monitoring is clearly different.
>

Is this part of the PoE standard or a proprietary extension?
I don't remember reading anything about a metering delegation request in = the PoE specification.

[jp] Sorry if I wasn't clear, yes proprietary, and they exist as I = stated that. "we find the distinctions in lines of devices we = ship". This pattern of processing does exist in other lines of = devices and not a standard.

Jp

------_=_NextPart_001_01CBE389.A81CBB52-- From j.schoenwaelder@jacobs-university.de Tue Mar 15 22:27:50 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A693A677E for ; Tue, 15 Mar 2011 22:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.182 X-Spam-Level: X-Spam-Status: No, score=-103.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cqKKOZCIhR8 for ; Tue, 15 Mar 2011 22:27:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E17B03A67A4 for ; Tue, 15 Mar 2011 22:27:46 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92DE2C0023; Wed, 16 Mar 2011 06:29:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Iiunlutqpg2t; Wed, 16 Mar 2011 06:29:08 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 616D5C001E; Wed, 16 Mar 2011 06:29:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7F4B016FBB2A; Wed, 16 Mar 2011 06:28:54 +0100 (CET) Date: Wed, 16 Mar 2011 06:28:54 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20110316052854.GA2249@elstar.local> Mail-Followup-To: Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 05:27:50 -0000 On Wed, Mar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote: > Dear all, > > here is a proposal for our power state discussion. > It is not new and has been discussed in different flavors already. > I just try to promote it by showing that it is flexible and > at the same time simple concerning its definition in a MIB module. > > It looks like people on this list want to be able to use different > sets of power states in order to support different energy management > interfaces. An example for a set would be the set of DMTF power states. > > A way to support this and still allowing very simple implementations > would be the following: > > We can be open to any set of power states by having them registered > at IANA. For each set we would register > - an ID (number) for identifying the set > - a number for each power state in this set > > For example: > EMAN: > set ID: 0 > states IDs: off(0). sleep(1). on(2) > > DMTF: > set ID: 1 > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. > > ACPI: > setID: 2 > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. > > Then we can define power state tables such that they have two indices: > First the setID and then the stateID. > > In such a table you could implement several sets (interfaces) at the same time. > a device can support three basic power states with setID 0 as first index, > but as well show all DMTF power states with setID 1 as first index. And another > index could be used for ACPI and other power state sets. Simple implementations > would just implement a single (simple) set, but device makers would have the > chance to provide support for multiple interfaces (sets). > > A small disadvantage is that for identifying a power state we need two numbers. > We can solve this at MIB level by a textual convention for power state index objects > that defines the index as a string consisting of two numbers separated by a dot, > for example, "0.2" or "4.12". The first number would identify the set and the second > one the state within the set. > > Any organization that specifies or builds devices can then define sets of power > states, for example, for light bulbs or for UPS systems, and register them at IANA. > This mechanism is still simple but provides openness to future developments > without need to modify or extend the MIB module. I am likely confused what the goal is. If every power state set needs to be registered with IANA, then why not simply use an enumeration? simple-off(0), simple-sleep(1), simple-on(2), dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203), ... You can add whatever text is needed to tell implementors they should just use the values of one set only. If you want to support non-IANA registered power states, the normal thing to do in MIB land is to use OBJECT-IDENTITIES, that is defined object identifier constants. This is how we identify say crypto-algorithms. We also have numeric TCs that define a set of well known values and that partition some of the integer number space for private use, in case a small number of well known power states with vendor extensibility is the way to go. I think it is crucial to figure out how much flexibility is needed and desirable and once that question has been answered, I think we should talk about the encoding (and I prefer encodings that are already known in MIB land over new creations). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bnordman@lbl.gov Tue Mar 15 23:27:24 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD533A67DB for ; Tue, 15 Mar 2011 23:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKzgbSoQJJNP for ; Tue, 15 Mar 2011 23:27:23 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by core3.amsl.com (Postfix) with ESMTP id 1E4CA3A67F1 for ; Tue, 15 Mar 2011 23:27:23 -0700 (PDT) X-Ironport-SBRS: 5.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcBAE/1f03RVdy0mGdsb2JhbACCW5w8AYZtCBQBAQEBAQgJDQcUJaVjmyqCfBmCTQSFMIcviHo6 X-IronPort-AV: E=Sophos;i="4.63,193,1299484800"; d="scan'208";a="36429158" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 15 Mar 2011 23:28:47 -0700 Received: by vxk12 with SMTP id 12so1755321vxk.39 for ; Tue, 15 Mar 2011 23:28:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.231 with SMTP id cl7mr485402vdc.45.1300256927291; Tue, 15 Mar 2011 23:28:47 -0700 (PDT) Received: by 10.52.155.40 with HTTP; Tue, 15 Mar 2011 23:28:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Mar 2011 23:28:47 -0700 Message-ID: From: Bruce Nordman To: Juergen Quittek Content-Type: multipart/alternative; boundary=bcaec5015d31449ad7049e93a8f4 Cc: eman mailing list Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 06:27:24 -0000 --bcaec5015d31449ad7049e93a8f4 Content-Type: text/plain; charset=ISO-8859-1 I'll not try to insert myself into the exact back/forth of this, but the "aware" term has also puzzled me from the start. >From the perspective of the NMS, I would think that the level of self-awareness of the device being monitored might be unimportant, or at best a detail that could be noted (a flag). The reference model document notes that the functionality of reporting is divided into three parts: power supply, power metering, and power status. A device may report some or all of these itself, and a separate device may report some or all. Thus, "awareness" would seem to be disaggregated, not unitary. I have wondered if this disaggregation suggests that the MIBs should be divided up along these lines, since initially at least, different devices (in principle three) might be reporting the different types of information. In addition, control signals (not my usual concern) will then also travel to different entities, depending on whether it is supply, meter, or status that is in question. Finally, I think that data about identity and context are distinct from the above three types of energy-specific data, so may suggest one or two additional MIBs (otherwise, they are most closely related to status). --Bruce .. > > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec5015d31449ad7049e93a8f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll not try to insert myself into the exact back/forth of this, butthe "aware" term has also puzzled me from the start.

From= the perspective of the NMS, I would think that the level
of self-awaren= ess of the device being monitored might be
unimportant, or at best a detail that could be noted (a flag).

The r= eference model document notes that the functionality of
reporting is div= ided into three parts: power supply, power
metering, and power status.= =A0 A device may report some or
all of these itself, and a separate device may report some or
all.=A0 Th= us, "awareness" would seem to be disaggregated,
not unitary.
I have wondered if this disaggregation suggests that the
MIBs shou= ld be divided up along these lines, since initially
at least, different devices (in principle three) might be
reporting the = different types of information.=A0 In addition,
control signals (not my = usual concern) will then also travel
to different entities, depending on= whether it is supply,
meter, or status that is in question.

Finally, I think that data abo= ut identity and context are
distinct from the above three types of energ= y-specific
data, so may suggest one or two additional MIBs
(otherwise= , they are most closely related to status).

--Bruce

..




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

--bcaec5015d31449ad7049e93a8f4-- From dromasca@avaya.com Wed Mar 16 03:21:23 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B753A68EE for ; Wed, 16 Mar 2011 03:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRBDNEuFU3w6 for ; Wed, 16 Mar 2011 03:21:21 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 179A63A68EC for ; Wed, 16 Mar 2011 03:21:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU2HCzI1/2dsb2JhbACYKo47dKR5ApkWAoJ8GoJJBJAM X-IronPort-AV: E=Sophos;i="4.63,193,1299474000"; d="scan'208";a="269705185" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Mar 2011 06:22:46 -0400 X-IronPort-AV: E=Sophos;i="4.63,193,1299474000"; d="scan'208";a="622197550" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Mar 2011 06:22:45 -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, 16 Mar 2011 11:22:37 +0100 Message-ID: In-Reply-To: <20110316052854.GA2249@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: Acvjmx4BvTi259oSSea7SF2y2hnysQAKNw1w References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Juergen Quittek" Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 10:21:23 -0000 Hi,=20 +1 to what JuergenS said.=20 Thanks and Regards, Dan=20 (speaking as contributor)=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, March 16, 2011 7:29 AM > To: Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] MIB-friendly proposal for flexible power states >=20 > On Wed, Mar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote: > > Dear all, > >=20 > > here is a proposal for our power state discussion. > > It is not new and has been discussed in different flavors already. > > I just try to promote it by showing that it is flexible and at the=20 > > same time simple concerning its definition in a MIB module. > >=20 > > It looks like people on this list want to be able to use different=20 > > sets of power states in order to support different energy=20 > management=20 > > interfaces. An example for a set would be the set of DMTF=20 > power states. > >=20 > > A way to support this and still allowing very simple=20 > implementations=20 > > would be the following: > >=20 > > We can be open to any set of power states by having them=20 > registered at=20 > > IANA. For each set we would register > > - an ID (number) for identifying the set > > - a number for each power state in this set > >=20 > > For example: > > EMAN: > > set ID: 0 > > states IDs: off(0). sleep(1). on(2) > >=20 > > DMTF:=20 > > set ID: 1 > > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. > >=20 > > ACPI: > > setID: 2 > > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. > >=20 > > Then we can define power state tables such that they have=20 > two indices: > > First the setID and then the stateID.=20 > >=20 > > In such a table you could implement several sets=20 > (interfaces) at the same time. > > a device can support three basic power states with setID 0 as first=20 > > index, but as well show all DMTF power states with setID 1 as first=20 > > index. And another index could be used for ACPI and other=20 > power state=20 > > sets. Simple implementations would just implement a single (simple)=20 > > set, but device makers would have the chance to provide=20 > support for multiple interfaces (sets). > >=20 > > A small disadvantage is that for identifying a power state=20 > we need two numbers. > > We can solve this at MIB level by a textual convention for=20 > power state=20 > > index objects that defines the index as a string consisting of two=20 > > numbers separated by a dot, for example, "0.2" or "4.12". The first=20 > > number would identify the set and the second one the state=20 > within the set. > >=20 > > Any organization that specifies or builds devices can then=20 > define sets=20 > > of power states, for example, for light bulbs or for UPS=20 > systems, and register them at IANA. > > This mechanism is still simple but provides openness to future=20 > > developments without need to modify or extend the MIB module. >=20 > I am likely confused what the goal is. If every power state=20 > set needs to be registered with IANA, then why not simply use=20 > an enumeration? >=20 > simple-off(0), simple-sleep(1), simple-on(2),=20 > dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... > acpi-offHard(200), acpi-offSoft(201), hibernate(202),=20 > sleepDeep(203), ... >=20 > You can add whatever text is needed to tell implementors they=20 > should just use the values of one set only. If you want to=20 > support non-IANA registered power states, the normal thing to=20 > do in MIB land is to use OBJECT-IDENTITIES, that is defined=20 > object identifier constants. This is how we identify say=20 > crypto-algorithms. We also have numeric TCs that define a set=20 > of well known values and that partition some of the integer=20 > number space for private use, in case a small number of well=20 > known power states with vendor extensibility is the way to go. >=20 > I think it is crucial to figure out how much flexibility is=20 > needed and desirable and once that question has been=20 > answered, I think we should talk about the encoding (and I=20 > prefer encodings that are already known in MIB land over new=20 > creations). >=20 > /js >=20 > --=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 >=20 From Rolf.Winter@neclab.eu Wed Mar 16 03:32:46 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E443A68E3 for ; Wed, 16 Mar 2011 03:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9YkHYhCpLyI for ; Wed, 16 Mar 2011 03:32:45 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 346793A68E1 for ; Wed, 16 Mar 2011 03:32:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 9EAE82C0002E7; Wed, 16 Mar 2011 11:36:06 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FpJpq3vh2Qb; Wed, 16 Mar 2011 11:36:06 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 800412C000203; Wed, 16 Mar 2011 11:35:56 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Wed, 16 Mar 2011 11:34:00 +0100 From: Rolf Winter To: Juergen Quittek , eman mailing list Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AQHL42y6THdhrIafvU+yzPT5yM5IhpQvxFrA Date: Wed, 16 Mar 2011 10:34:00 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DEB5CA@DAPHNIS.office.hd> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> In-Reply-To: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 10:32:46 -0000 This looks very good to me. +1 NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Quittek > Sent: Mittwoch, 16. M=E4rz 2011 00:57 > To: eman mailing list > Subject: [eman] MIB-friendly proposal for flexible power states >=20 > Dear all, >=20 > here is a proposal for our power state discussion. > It is not new and has been discussed in different flavors already. > I just try to promote it by showing that it is flexible and > at the same time simple concerning its definition in a MIB module. >=20 > It looks like people on this list want to be able to use different > sets of power states in order to support different energy management > interfaces. An example for a set would be the set of DMTF power states. >=20 > A way to support this and still allowing very simple implementations > would be the following: >=20 > We can be open to any set of power states by having them registered > at IANA. For each set we would register > - an ID (number) for identifying the set > - a number for each power state in this set >=20 > For example: > EMAN: > set ID: 0 > states IDs: off(0). sleep(1). on(2) >=20 > DMTF: > set ID: 1 > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. >=20 > ACPI: > setID: 2 > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. >=20 > Then we can define power state tables such that they have two indices: > First the setID and then the stateID. >=20 > In such a table you could implement several sets (interfaces) at the > same time. > a device can support three basic power states with setID 0 as first > index, > but as well show all DMTF power states with setID 1 as first index. And > another > index could be used for ACPI and other power state sets. Simple > implementations > would just implement a single (simple) set, but device makers would > have the > chance to provide support for multiple interfaces (sets). >=20 > A small disadvantage is that for identifying a power state we need two > numbers. > We can solve this at MIB level by a textual convention for power state > index objects > that defines the index as a string consisting of two numbers separated > by a dot, > for example, "0.2" or "4.12". The first number would identify the set > and the second > one the state within the set. >=20 > Any organization that specifies or builds devices can then define sets > of power > states, for example, for light bulbs or for UPS systems, and register > them at IANA. > This mechanism is still simple but provides openness to future > developments > without need to modify or extend the MIB module. >=20 > Juergen >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From moulchan@cisco.com Wed Mar 16 05:02:32 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C533A6959 for ; Wed, 16 Mar 2011 05:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxS3Jp+c0Kia for ; Wed, 16 Mar 2011 05:02:31 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 29E523A6958 for ; Wed, 16 Mar 2011 05:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=14150; q=dns/txt; s=iport; t=1300277037; x=1301486637; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=QBwot1UyR3hJJ9bpAGrgNFgA4eDX2zqX9yz/JYWVj84=; b=AtEMWdBDhOzgGOIAOrYxM9MoyLuKoR7sdUKfVK3TXWp1hUZWTNA69WTH ILVLunXbNiLUkYxbwsDc8N47j7j3rnBteXpGkQoapn7t66haLv8vwUPIe 7O86mOSVgCvHQWB91+1yPbCJLTXp4mKxsjsmUUqpFIKh8JbNuPKQefcpG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBANNDgE2tJXHB/2dsb2JhbACYUY03d6RynFiFYgSFL4sC X-IronPort-AV: E=Sophos;i="4.63,193,1299456000"; d="scan'208,217";a="347656827" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 16 Mar 2011 12:03:56 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2GC3ujV006416; Wed, 16 Mar 2011 12:03:56 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 07:03:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE3D2.399D25B9" Date: Wed, 16 Mar 2011 07:03:52 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: Awareness Thread-Index: AcvjZ0mjmtU7E2+iRwyc9p2Kq16TCAAVchJg References: From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" , "eman mailing list" X-OriginalArrivalTime: 16 Mar 2011 12:03:56.0104 (UTC) FILETIME=[39B5BC80:01CBE3D2] Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 12:02:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE3D2.399D25B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Juergen, It is possible to argue, Awareness of Energy Usage (being conscious of energy usage) can possibly lead to conservation of energy.=20 One is conscious ( or aware) of the energy usage only when they get the electricity bill. The bill is generated based on energy measurement. In a sense, awareness is a result of measurement. Energy measurement/monitoring is the focus of the WG.=20 Energy-aware device is probably is a acronym for a energy measurement capable device (measurement obtained directly or indirectly). Perhaps it may be useful to define the concept what is an energy-aware device in some draft.=20 Regarding the particular question, the name of MIB module you have referenced focuses on identification, context of the device that is monitoring its own energy usage or reporting energy usage on behalf of other device devices.=20 If other names are better suited for the MIB module such as EMAN-ENTITY-MIB, that is a good discussion point for the WG.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Wednesday, March 16, 2011 4:48 AM To: eman mailing list Subject: [eman] Terminology: Awareness Hi all, in some recent emails on this list I read "If the device is energy-aware" Also we have a draft called draft-ietf-eman-energy-aware-mib containing a MIB module called ENERGY-AWARE-MIB. My question is: What do we mean when we say "aware"? Is it a term to which we give a clear technical meaning=20 or does it just sound sexy and is good for marketing? According to Merriam-Webster aware means "having or showing realization, perception, or knowledge" This rather sounds like a cognitive performance that most of the=20 devices we are talking about will never be able to show.=20 So what else would "aware" mean for us?=20 And is it OK to re-define it? Is a switch that measures its own energy consumption "energy-aware"? Then it would be as well packet-aware if it has a counter for packets. It would be flow-aware if it supports NetFlow, and of course it would be TCP-aware if it implements the TCP-MIB and IP aware with the IF-MIB. According to draft-ietf-eman-energy-aware-mib a device can even become energy-aware if an external meter measures its power and reports it to=20 a management station. In this case, the "energy-aware" device does never get any access to its power and energy values. This is terribly misleading. Let's please stop such nonsense. Considering that the IETF creates technical specifications and not marketing brochures, I suggest replacing this term=20 in all our documents with other terms that are technically accurate. Which term to be used depends on the context. In many cases, just calling them "monitored" devices or entities is fine. But in other cases the replacement is more difficult. For example, MIB module ENERGY-AWARE-MIB could more appropriately be called=20 EMAN-ENTITY-ID-MIB or EMAN-RELATIONSHIP-MIB, etc.,=20 depending on which feature of the module we consider most=20 important. Thanks, Juergen _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman ------_=_NextPart_001_01CBE3D2.399D25B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [eman] Terminology: Awareness

Hi = Juergen,

It is possible = to argue, Awareness of Energy Usage (being conscious of energy = usage) can possibly lead to conservation of energy.

One is = conscious ( or aware) of the energy usage only when they get the = electricity bill. The bill is generated based on energy = measurement.

In a sense, = awareness is a result of measurement. = Energy measurement/monitoring is the focus of the = WG.

Energy-aware = device is probably is a acronym for a energy measurement capable device (measurement = obtained directly or indirectly).

Perhaps it may = be useful to define the concept what is an energy-aware device in some draft.

Regarding the = particular question, the name of MIB module you have referenced focuses = on identification, context of the device that is monitoring its own energy usage = or reporting = energy usage = on behalf of other device devices. =

If other names = are better suited for the MIB module such as EMAN-ENTITY-MIB, that is a = good discussion point for the WG. =


Thanks

Mouli

-----Original = Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] = On Behalf Of Juergen Quittek
Sent: Wednesday, March 16, 2011 4:48 AM
To: eman mailing list
Subject: [eman] Terminology: Awareness

Hi = all,

in some recent = emails on this list I read "If the device is = energy-aware"

Also we have a = draft called draft-ietf-eman-energy-aware-mib = containing

a MIB module = called ENERGY-AWARE-MIB.

My question = is: What do we mean when we say "aware"?

Is it a term = to which we give a clear technical meaning

or does it = just sound sexy and is good for marketing?

According to = Merriam-Webster aware means

    "having or showing = realization, perception, or knowledge"

This rather = sounds like a cognitive performance that most of the

devices we are = talking about will never be able to show.

So what else = would "aware" mean for us?

And is it OK = to re-define it?

Is a switch = that measures its own energy consumption = "energy-aware"?

Then it would = be as well packet-aware if it has a counter for = packets.

It would be = flow-aware if it supports NetFlow, and of course it = would

be TCP-aware = if it implements the TCP-MIB and IP aware with the = IF-MIB.

According to = draft-ietf-eman-energy-aware-mib a device can even = become

energy-aware = if an external meter measures its power and reports it to =

a management = station. In this case, the "energy-aware" device does = never

get any access = to its power and energy values. This is terribly = misleading.

Let's please = stop such nonsense.

Considering = that the IETF creates technical specifications

and not = marketing brochures, I suggest replacing this term

in all our = documents with other terms that are technically = accurate.

Which term to = be used depends on the context. In many cases, just

calling them = "monitored" devices or entities is fine. But in other cases =

the = replacement is more difficult. For example, MIB module

ENERGY-AWARE-MIB could more appropriately be called =

EMAN-ENTITY-ID-MIB or  EMAN-RELATIONSHIP-MIB, = etc.,

depending on = which feature of the module we consider most

important.

Thanks,

    Juergen


_______________________________________________<= /SPAN>

eman mailing = list

eman@ietf.org

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

------_=_NextPart_001_01CBE3D2.399D25B9-- From moulchan@cisco.com Wed Mar 16 06:24:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4803A698E for ; Wed, 16 Mar 2011 06:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x-WrtX3PNKG for ; Wed, 16 Mar 2011 06:24:21 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id ED6373A6954 for ; Wed, 16 Mar 2011 06:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=4644; q=dns/txt; s=iport; t=1300281947; x=1301491547; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nC1tdmPt2csz18pgPlepJtP2t5c+xI9Ked0BTbo0RMI=; b=G2AWDUwnl9Ze2O2SspUFwr/la2Vyk7lGlPg2FMpqR+yao7SGGfFhtQIg csfSiTNJc8njmsyVssUAV3Y5evmyWx5stYfH05CXtDfAIAogtstEy+Z3I P5T/XnkZ2purfa3cItnYfGsvsADm+RDRWlBiyCqn1TD7Xw/OsyslmMCxD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBAEZXgE2tJV2Y/2dsb2JhbACYUY03d6VDnFECgnkagk0EhS+LAg X-IronPort-AV: E=Sophos;i="4.63,194,1299456000"; d="scan'208";a="414944317" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-1.cisco.com with ESMTP; 16 Mar 2011 13:25:47 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2GDPluc021513; Wed, 16 Mar 2011 13:25:47 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 08:25:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 08:25:44 -0500 Message-ID: In-Reply-To: <20110316052854.GA2249@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvjmyID5bvpgojCRg+7Im2Lg5bU3wAQCWBQ References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> From: "Mouli Chandramouli (moulchan)" To: "Juergen Schoenwaelder" , "Juergen Quittek" X-OriginalArrivalTime: 16 Mar 2011 13:25:47.0240 (UTC) FILETIME=[A8F99E80:01CBE3DD] Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 13:24:22 -0000 Juergen S, Would it be useful to know the capability of the device on which power state model is supported by the device - ENTITY-STATE, DMTF, ACPI or ...?=20 A device can also support multiple power state models.=20 In that sense, the model Juergen Q proposed - the vector model (x1, x2) - where x1 - is the power state type and x2 is the power state seems more natural ? Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, March 16, 2011 10:59 AM To: Juergen Quittek Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states On Wed, Mar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote: > Dear all, >=20 > here is a proposal for our power state discussion. > It is not new and has been discussed in different flavors already. > I just try to promote it by showing that it is flexible and=20 > at the same time simple concerning its definition in a MIB module. >=20 > It looks like people on this list want to be able to use different=20 > sets of power states in order to support different energy management > interfaces. An example for a set would be the set of DMTF power states. >=20 > A way to support this and still allowing very simple implementations > would be the following: >=20 > We can be open to any set of power states by having them registered=20 > at IANA. For each set we would register > - an ID (number) for identifying the set > - a number for each power state in this set >=20 > For example: > EMAN: > set ID: 0 > states IDs: off(0). sleep(1). on(2) >=20 > DMTF:=20 > set ID: 1 > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. >=20 > ACPI: > setID: 2 > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. >=20 > Then we can define power state tables such that they have two indices: > First the setID and then the stateID.=20 >=20 > In such a table you could implement several sets (interfaces) at the same time. > a device can support three basic power states with setID 0 as first index, > but as well show all DMTF power states with setID 1 as first index. And another > index could be used for ACPI and other power state sets. Simple implementations > would just implement a single (simple) set, but device makers would have the=20 > chance to provide support for multiple interfaces (sets). >=20 > A small disadvantage is that for identifying a power state we need two numbers. > We can solve this at MIB level by a textual convention for power state index objects > that defines the index as a string consisting of two numbers separated by a dot, > for example, "0.2" or "4.12". The first number would identify the set and the second > one the state within the set. >=20 > Any organization that specifies or builds devices can then define sets of power=20 > states, for example, for light bulbs or for UPS systems, and register them at IANA. > This mechanism is still simple but provides openness to future developments > without need to modify or extend the MIB module. I am likely confused what the goal is. If every power state set needs to be registered with IANA, then why not simply use an enumeration? simple-off(0), simple-sleep(1), simple-on(2), dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203), ... You can add whatever text is needed to tell implementors they should just use the values of one set only. If you want to support non-IANA registered power states, the normal thing to do in MIB land is to use OBJECT-IDENTITIES, that is defined object identifier constants. This is how we identify say crypto-algorithms. We also have numeric TCs that define a set of well known values and that partition some of the integer number space for private use, in case a small number of well known power states with vendor extensibility is the way to go. I think it is crucial to figure out how much flexibility is needed and desirable and once that question has been answered, I think we should talk about the encoding (and I prefer encodings that are already known in MIB land over new creations). /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 Mar 16 06:52:36 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8363A6827 for ; Wed, 16 Mar 2011 06:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.183 X-Spam-Level: X-Spam-Status: No, score=-103.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W0IPDio83Ku for ; Wed, 16 Mar 2011 06:52:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AE8353A6999 for ; Wed, 16 Mar 2011 06:52:35 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80E1CC002B; Wed, 16 Mar 2011 14:54:01 +0100 (CET) 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 VtsBoEaKeZuC; Wed, 16 Mar 2011 14:54:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6470C0023; Wed, 16 Mar 2011 14:54:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CA49D16FCA62; Wed, 16 Mar 2011 14:54:00 +0100 (CET) Date: Wed, 16 Mar 2011 14:54:00 +0100 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20110316135400.GD239@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@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 mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 13:52:36 -0000 On Wed, Mar 16, 2011 at 08:25:44AM -0500, Mouli Chandramouli (moulchan) wrote: > Juergen S, > > Would it be useful to know the capability of the device on which power > state model is supported by the device - ENTITY-STATE, DMTF, ACPI or > ...? > A device can also support multiple power state models. > > In that sense, the model Juergen Q proposed - the vector model (x1, x2) > - where x1 - is the power state type and x2 is the power state seems > more natural ? I do not think Juergen Q proposed a vector. Juergen, correct me if I am wrong. This is actually different design issue, independent of the encoding. I was commenting on the encoding only. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From russ@cisco.com Wed Mar 16 09:52:41 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C802E3A69DE for ; Wed, 16 Mar 2011 09:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k43EEJzqXSxp for ; Wed, 16 Mar 2011 09:52:40 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A774C3A69D8 for ; Wed, 16 Mar 2011 09:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1418; q=dns/txt; s=iport; t=1300294447; x=1301504047; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=hLDuKxoCCnhnihyBC3FDG4duHJNpSv7gLh3nHz1VVKw=; b=WpximGoyJsxnVvHdD8aWYgdJYwmc9vPHnyg/L5hsToaAmeFhLKOw0JN9 km0aMMBjpo5FuKcY16bvdE8K/sckmoBfxK54gz3WSRsQexXlfcsR+oqIa xWWTHVlDsmnfxli4eUYUqCLuoaeEto83GEUIq/1k6Ga7FQD/WHF9sODFi o=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMuHgE2tJV2b/2dsb2JhbACmD3ekU5xRhWMEjF6DTQ X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="asc'?scan'208";a="347789742" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-5.cisco.com with ESMTP; 16 Mar 2011 16:54:06 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2GGs5u2005251; Wed, 16 Mar 2011 16:54:05 GMT Message-ID: <4D80EB27.4080900@cisco.com> Date: Wed, 16 Mar 2011 12:53:59 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> In-Reply-To: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig08A7D84B4DE53A127343EBD9" Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 16:52:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig08A7D84B4DE53A127343EBD9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > We can be open to any set of power states by having them registered=20 > at IANA. For each set we would register > - an ID (number) for identifying the set > - a number for each power state in this set I really like this idea... The only thing I would do is have it split into two "spaces," perhaps. All devices should support "on" and "off," so those should be in the "primary space." Then you could have an "extended state" that is defined as below. You could also actually support multiple "extended spaces." For instance, you could have one space for batteries, and another for various ranges of device states. I would support this idea. :-) Russ --------------enig08A7D84B4DE53A127343EBD9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2A6ycACgkQER27sUhU9OQ/FQCeNL6V1usOTqGHXhgsO3gtbVDh rQkAn1gjVPvGMUEMwtmTvZ8oRjvn3iur =LGkl -----END PGP SIGNATURE----- --------------enig08A7D84B4DE53A127343EBD9-- From j.schoenwaelder@jacobs-university.de Wed Mar 16 10:41:21 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A6E3A6A07 for ; Wed, 16 Mar 2011 10:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.18 X-Spam-Level: X-Spam-Status: No, score=-103.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPgsL4idJmYE for ; Wed, 16 Mar 2011 10:41:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B8A903A69F2 for ; Wed, 16 Mar 2011 10:41:20 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24209C001E; Wed, 16 Mar 2011 18:42:47 +0100 (CET) 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 MfN+GisXLEa8; Wed, 16 Mar 2011 18:42:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87A80C000F; Wed, 16 Mar 2011 18:42:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7B97C16FD122; Wed, 16 Mar 2011 18:42:46 +0100 (CET) Date: Wed, 16 Mar 2011 18:42:46 +0100 From: Juergen Schoenwaelder To: Russ White Message-ID: <20110316174246.GB1468@elstar.local> Mail-Followup-To: Russ White , Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <4D80EB27.4080900@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D80EB27.4080900@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 17:41:22 -0000 On Wed, Mar 16, 2011 at 12:53:59PM -0400, Russ White wrote: > > We can be open to any set of power states by having them registered > > at IANA. For each set we would register > > - an ID (number) for identifying the set > > - a number for each power state in this set > > I really like this idea... The only thing I would do is have it split > into two "spaces," perhaps. All devices should support "on" and "off," > so those should be in the "primary space." Then you could have an > "extended state" that is defined as below. You could also actually > support multiple "extended spaces." For instance, you could have one > space for batteries, and another for various ranges of device states. What is a management application going to do with "multiple extended spaces"? What is going to happen if the "multiple extended spaces" turn out to be inconsistent? The more bloat people want to add, the more I start liking a minimal three state model. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From russ@cisco.com Wed Mar 16 10:46:47 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4141D3A6A1D for ; Wed, 16 Mar 2011 10:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRu8paJaxje9 for ; Wed, 16 Mar 2011 10:46:46 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 254D93A6A14 for ; Wed, 16 Mar 2011 10:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=2796; q=dns/txt; s=iport; t=1300297693; x=1301507293; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=d1KxB7rBp9tB/idnTsSpSiAkH+iHDWoOnQjFEBmC1a0=; b=MuV7ghuSV49nNVrB4idgwR+FC9wq9WyH5ZlisGYwAe4s6cVSerXg9n44 oTUOAerBTo5RTzu2s4JignK4ksh3r/9u8KA1iGz1Mk3T6JlvvJ+12wI8R IVf8oXogtBkkn4xDuAaYy7zEhE9G+HNJlq0aeHTk5bgpy6PSMZSTdqF1K c=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHKUgE2tJV2d/2dsb2JhbACmEHekZJxRhWMEjF6DTQ X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="asc'?scan'208";a="225857632" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2011 17:48:12 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2GHmBjo010680; Wed, 16 Mar 2011 17:48:12 GMT Message-ID: <4D80F7D2.1040200@cisco.com> Date: Wed, 16 Mar 2011 13:48:02 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local> In-Reply-To: <20110316174246.GB1468@elstar.local> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig66A7882CD8B85ADD8C8A5DA9" Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 17:46:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig66A7882CD8B85ADD8C8A5DA9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> I really like this idea... The only thing I would do is have it split >> into two "spaces," perhaps. All devices should support "on" and "off,"= >> so those should be in the "primary space." Then you could have an >> "extended state" that is defined as below. You could also actually >> support multiple "extended spaces." For instance, you could have one >> space for batteries, and another for various ranges of device states. >=20 > What is a management application going to do with "multiple extended > spaces"? What is going to happen if the "multiple extended spaces" > turn out to be inconsistent? The more bloat people want to add, the > more I start liking a minimal three state model. ;-) Don't most management applications already support a "plug in" architecture for various devices? IE, if I buy a switch from some vendor, don't I have the option of downloading the MIB for the switch and putting it into the management application so I get finer grained control/understanding of what the switch supports? In this case, you'd have one space for the power state, depending on the sort of power state the device supports, like DMTP, an EMAN standard, or something else. And if the device has a battery, you could pull in the battery state as well. This makes more sense than having power states tied to battery states. You could have a laptop that provides some set of standard PC power states, and then some set of standard battery power states. A desktop would provide the PC levels, while not the battery ones. A wired video camera might provide the right power states for that sort of device, and add on some standard set of states for batteries if it happens to be battery powered. This allows the flexibility of different sets of states for devices that would fall under different standards, and additional power states where that information might be useful. Flexibility seems like it would be a good thing, given the past conversations on what to support and how to support it. :-) Russ --------------enig66A7882CD8B85ADD8C8A5DA9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2A99UACgkQER27sUhU9OSwTACdHeJWwlRSgStIGvp7kzor3iUt 3+MAnjcS1PTwwlha1LG9PnB2aLd3eZzc =5QjD -----END PGP SIGNATURE----- --------------enig66A7882CD8B85ADD8C8A5DA9-- From jparello@cisco.com Wed Mar 16 11:18:15 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A85C3A6A2A for ; Wed, 16 Mar 2011 11:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45Nby9fkqFpY for ; Wed, 16 Mar 2011 11:18:08 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 55FE43A6A21 for ; Wed, 16 Mar 2011 11:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=14657; q=dns/txt; s=iport; t=1300299575; x=1301509175; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=SaDa7FZPWS2BI8RJ/0KgXWbt1nCYfajcwUxRdTW4Kgk=; b=A01CSrZ011B6JV6OdQLK/OIhLyrH8ZjCb5XqjOfJSP6HBPzUVvkRAITz sOj4aFqaM98F+TZ6X1BVqYQBCUHjO9P91uMlzrO23z94Vq42raV41Fpmr uSGWpDP18Or0quTryfeS9QaVhRI7rZCA5uvxmZ/XObAWnwyt8NpyEB5s7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcBAPKbgE2tJV2c/2dsb2JhbACCW5V8hkcBhnF3pGGcU4J8GYJOBIUviwI X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208,217";a="226260060" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2011 18:19:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2GIJMmi021598; Wed, 16 Mar 2011 18:19:34 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 11:19:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE406.AE6322E9" Date: Wed, 16 Mar 2011 11:14:41 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: Awareness Thread-Index: Acvjo2qhmvwbVsOeR9iOhuvmG1GPagAYI3mA References: From: "John Parello (jparello)" To: "Bruce Nordman" , "Juergen Quittek" X-OriginalArrivalTime: 16 Mar 2011 18:19:26.0650 (UTC) FILETIME=[AEF639A0:01CBE406] Cc: eman mailing list Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 18:18:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE406.AE6322E9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Bruce, =20 I'll sum up my thinking here on aware versus monitored. =20 I think the term aware is more precise than monitor for the work of this group but both are necessary. It's unfortunate monitor was used from the start when the requirements were specified.=20 =20 If a device implements the objects we are defining here we can say the device is aware of its power and energy. Whether it is monitored or not is a different attribute. Monitored assumes the existence of an observer. Let's anthropomorphize this as an example. =20 Device =3D Person Energy =3D spending =20 If your spending is monitored you would assume from that there exists some external observer. If you are aware of your spending you are tracking your spending with or without an observer. =20 Back to our work. =20 IF you implement a set of objects we define in this WG you are aware of your energy. You may or may not be monitored by someone accessing the object. You can't assume just because you implement the objects there's some miraculous observer making SNMP request to you or monitoring you. You may never be contacted but you are still aware. =20 They are distinct terms. =20 In this space where there are non telecommunications devices the term monitoring with an implied observer would be perceived as a setup where some external metering device or physical probe was attached to a device. This is ambiguous and misleading. =20 Juergen proposes swapping out the term aware for monitored . I completely disagree with that as they are not synonyms and describe two very different use. =20 AS for the idea this was marketing driven or that the use cases I proposed were proprietary (I'd say running code looking for consensus) those are arguments to the messenger not the message so I don't see how that even needs consideration. =20 This distinction has been adopted by another standards body so it merits consideration in this WG. =20 Jp =20 =20 =20 From: Bruce Nordman [mailto:bnordman@lbl.gov]=20 Sent: Tuesday, March 15, 2011 11:29 PM To: Juergen Quittek Cc: John Parello (jparello); eman mailing list Subject: Re: [eman] Terminology: Awareness =20 I'll not try to insert myself into the exact back/forth of this, but the "aware" term has also puzzled me from the start. >From the perspective of the NMS, I would think that the level of self-awareness of the device being monitored might be unimportant, or at best a detail that could be noted (a flag). The reference model document notes that the functionality of reporting is divided into three parts: power supply, power metering, and power status. A device may report some or all of these itself, and a separate device may report some or all. Thus, "awareness" would seem to be disaggregated, not unitary. I have wondered if this disaggregation suggests that the MIBs should be divided up along these lines, since initially at least, different devices (in principle three) might be reporting the different types of information. In addition, control signals (not my usual concern) will then also travel to different entities, depending on whether it is supply, meter, or status that is in question. Finally, I think that data about identity and context are distinct from the above three types of energy-specific data, so may suggest one or two additional MIBs (otherwise, they are most closely related to status). --Bruce .. =20 --=20 Bruce Nordman Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 ------_=_NextPart_001_01CBE406.AE6322E9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Bruce,

 

I’ll sum up my thinking here on aware versus = monitored.

 

I think the term aware is more precise than monitor for = the work of this group but both are necessary. It’s unfortunate monitor =  was used from the start when the requirements were specified. =

 

 If a device implements the objects we are defining = here we can say the device is aware of its power and energy. Whether it is = monitored or not is a different attribute.  Monitored assumes the existence of = an observer. Let’s anthropomorphize this as an = example.

 

Device  =3D Person

Energy =3D spending

 

If your spending is monitored you would assume from that = there exists some external observer.

If you are aware of your spending you are tracking your = spending with or without an observer.

 

Back to our work.

 

IF you implement a set of objects we define in this WG = you are aware of your energy. You may or may not be monitored by someone = accessing the object. You can’t assume just because you implement the objects = there’s some miraculous observer making SNMP request to you or monitoring you. = You may never be contacted but you are still aware.

 

They are distinct terms.

 

In this space where there are non telecommunications = devices the term monitoring with an implied observer would be perceived as a setup = where some external metering device or physical probe was attached to a = device. This is ambiguous and misleading.

 

Juergen proposes swapping out the term aware for = monitored . I completely disagree with that as they are not synonyms and describe two = very different use.

 

AS for the idea this was marketing driven or that the use = cases I proposed were proprietary (I’d say running code looking for = consensus) those are arguments to the messenger not the message so I don’t = see how that even needs consideration.

 

This distinction has been adopted by another standards = body so it merits consideration in this WG.

 

Jp

 

 

 

From:= Bruce = Nordman [mailto:bnordman@lbl.gov]
Sent: Tuesday, March 15, 2011 11:29 PM
To: Juergen Quittek
Cc: John Parello (jparello); eman mailing list
Subject: Re: [eman] Terminology: Awareness

 

I'll not try to = insert myself into the exact back/forth of this, but
the "aware" term has also puzzled me from the start.

>From the perspective of the NMS, I would think that the level
of self-awareness of the device being monitored might be
unimportant, or at best a detail that could be noted (a flag).

The reference model document notes that the functionality of
reporting is divided into three parts: power supply, power
metering, and power status.  A device may report some or
all of these itself, and a separate device may report some or
all.  Thus, "awareness" would seem to be = disaggregated,
not unitary.

I have wondered if this disaggregation suggests that the
MIBs should be divided up along these lines, since initially
at least, different devices (in principle three) might be
reporting the different types of information.  In addition,
control signals (not my usual concern) will then also travel
to different entities, depending on whether it is supply,
meter, or status that is in question.

Finally, I think that data about identity and context are
distinct from the above three types of energy-specific
data, so may suggest one or two additional MIBs
(otherwise, they are most closely related to status).

--Bruce

..

 




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

------_=_NextPart_001_01CBE406.AE6322E9-- From jparello@cisco.com Wed Mar 16 11:27:04 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43CA13A6947 for ; Wed, 16 Mar 2011 11:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfjfnhPm2Hpx for ; Wed, 16 Mar 2011 11:27:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E222D3A6918 for ; Wed, 16 Mar 2011 11:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=4755; q=dns/txt; s=iport; t=1300300110; x=1301509710; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Ifyl5VUrH+Khd25DbmQmS2SfzFm2l5W1ZeZpfU46ZUg=; b=dUqKBnKkDw9yk85wthgoS7ozbgn+RbYY5tmcwCi2sHJSpzI1qhih5XF+ 6oHpZOs3ze140/XU8/gKWNyylQz5fXtL6T5MCDi6dNBrSgLrdQqBy+x73 dlBy8tZHYSavCTYs3bhIyORjEsbbciPu2u02CyktAHfTOZwcX8WQBZLSY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAAMOegE2tJV2Z/2dsb2JhbACYV402d6R1nFUCgnkagk4EhS+LAg X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="415067383" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 16 Mar 2011 18:28:11 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2GISAar031113; Wed, 16 Mar 2011 18:28:10 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 11:28:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 11:23:13 -0700 Message-ID: In-Reply-To: <20110316052854.GA2249@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvjmygyVgXEmDSxTpC9Rv2sJDYOlAAa5ZVw References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> From: "John Parello (jparello)" To: "Juergen Schoenwaelder" , "Juergen Quittek" X-OriginalArrivalTime: 16 Mar 2011 18:28:04.0543 (UTC) FILETIME=[E3A66CF0:01CBE407] Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 18:27:04 -0000 Hi Juergen, You could have one long list as you suggest but then if someone added a state they are not grouped. So in your example if the dmtf adds a state foo you would have to add dmtf-foo to the end? It seems clearer to have these groups in sets and those sets are interfaces. Also there will be a question of parity on states. If I set to EMAN-OFF does that imply I am in DMTF-OFF and HAL-HARD-OFF as well? >From a strict interface implementation split such a distinction would make sense. Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, March 15, 2011 10:29 PM To: Juergen Quittek Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states On Wed, Mar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote: > Dear all, >=20 > here is a proposal for our power state discussion. > It is not new and has been discussed in different flavors already. > I just try to promote it by showing that it is flexible and=20 > at the same time simple concerning its definition in a MIB module. >=20 > It looks like people on this list want to be able to use different=20 > sets of power states in order to support different energy management > interfaces. An example for a set would be the set of DMTF power states. >=20 > A way to support this and still allowing very simple implementations > would be the following: >=20 > We can be open to any set of power states by having them registered=20 > at IANA. For each set we would register > - an ID (number) for identifying the set > - a number for each power state in this set >=20 > For example: > EMAN: > set ID: 0 > states IDs: off(0). sleep(1). on(2) >=20 > DMTF:=20 > set ID: 1 > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. >=20 > ACPI: > setID: 2 > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. >=20 > Then we can define power state tables such that they have two indices: > First the setID and then the stateID.=20 >=20 > In such a table you could implement several sets (interfaces) at the same time. > a device can support three basic power states with setID 0 as first index, > but as well show all DMTF power states with setID 1 as first index. And another > index could be used for ACPI and other power state sets. Simple implementations > would just implement a single (simple) set, but device makers would have the=20 > chance to provide support for multiple interfaces (sets). >=20 > A small disadvantage is that for identifying a power state we need two numbers. > We can solve this at MIB level by a textual convention for power state index objects > that defines the index as a string consisting of two numbers separated by a dot, > for example, "0.2" or "4.12". The first number would identify the set and the second > one the state within the set. >=20 > Any organization that specifies or builds devices can then define sets of power=20 > states, for example, for light bulbs or for UPS systems, and register them at IANA. > This mechanism is still simple but provides openness to future developments > without need to modify or extend the MIB module. I am likely confused what the goal is. If every power state set needs to be registered with IANA, then why not simply use an enumeration? simple-off(0), simple-sleep(1), simple-on(2), dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203), ... You can add whatever text is needed to tell implementors they should just use the values of one set only. If you want to support non-IANA registered power states, the normal thing to do in MIB land is to use OBJECT-IDENTITIES, that is defined object identifier constants. This is how we identify say crypto-algorithms. We also have numeric TCs that define a set of well known values and that partition some of the integer number space for private use, in case a small number of well known power states with vendor extensibility is the way to go. I think it is crucial to figure out how much flexibility is needed and desirable and once that question has been answered, I think we should talk about the encoding (and I prefer encodings that are already known in MIB land over new creations). /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 Mar 17 00:17:05 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B104F3A67F7 for ; Thu, 17 Mar 2011 00:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zzE1BPGXgmk for ; Thu, 17 Mar 2011 00:17:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 203163A67AE for ; Thu, 17 Mar 2011 00:17:04 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1B8DC0014; Thu, 17 Mar 2011 08:18:30 +0100 (CET) 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 Cfw8+I+hzOxB; Thu, 17 Mar 2011 08:18:29 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1197FC000F; Thu, 17 Mar 2011 08:18:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 86FAA16FD90A; Thu, 17 Mar 2011 08:18:28 +0100 (CET) Date: Thu, 17 Mar 2011 08:18:28 +0100 From: Juergen Schoenwaelder To: Russ White Message-ID: <20110317071828.GA2375@elstar.local> Mail-Followup-To: Russ White , Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local> <4D80F7D2.1040200@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D80F7D2.1040200@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 07:17:05 -0000 On Wed, Mar 16, 2011 at 01:48:02PM -0400, Russ White wrote: > > >> I really like this idea... The only thing I would do is have it split > >> into two "spaces," perhaps. All devices should support "on" and "off," > >> so those should be in the "primary space." Then you could have an > >> "extended state" that is defined as below. You could also actually > >> support multiple "extended spaces." For instance, you could have one > >> space for batteries, and another for various ranges of device states. > > > > What is a management application going to do with "multiple extended > > spaces"? What is going to happen if the "multiple extended spaces" > > turn out to be inconsistent? The more bloat people want to add, the > > more I start liking a minimal three state model. ;-) > > Don't most management applications already support a "plug in" > architecture for various devices? IE, if I buy a switch from some > vendor, don't I have the option of downloading the MIB for the switch > and putting it into the management application so I get finer grained > control/understanding of what the switch supports? > > In this case, you'd have one space for the power state, depending on the > sort of power state the device supports, like DMTP, an EMAN standard, or > something else. > > And if the device has a battery, you could pull in the battery state as > well. > > This makes more sense than having power states tied to battery states. > You could have a laptop that provides some set of standard PC power > states, and then some set of standard battery power states. A desktop > would provide the PC levels, while not the battery ones. A wired video > camera might provide the right power states for that sort of device, and > add on some standard set of states for batteries if it happens to be > battery powered. > > This allows the flexibility of different sets of states for devices that > would fall under different standards, and additional power states where > that information might be useful. > > Flexibility seems like it would be a good thing, given the past > conversations on what to support and how to support it. Reporting different states for different components of the system makes sense to me. Reporting a vector of states for a single component does not make much sense to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 17 00:21:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A813A6A59 for ; Thu, 17 Mar 2011 00:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.182 X-Spam-Level: X-Spam-Status: No, score=-103.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4JYYdr4Fufx for ; Thu, 17 Mar 2011 00:21:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 951343A6A55 for ; Thu, 17 Mar 2011 00:21:21 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7048C0014; Thu, 17 Mar 2011 08:22:48 +0100 (CET) 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 0rUucP2Ou-eq; Thu, 17 Mar 2011 08:22:48 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F4049C000F; Thu, 17 Mar 2011 08:22:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ECEC816FD950; Thu, 17 Mar 2011 08:22:47 +0100 (CET) Date: Thu, 17 Mar 2011 08:22:47 +0100 From: Juergen Schoenwaelder To: "John Parello (jparello)" Message-ID: <20110317072247.GB2375@elstar.local> Mail-Followup-To: "John Parello (jparello)" , Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@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 mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 07:21:30 -0000 On Wed, Mar 16, 2011 at 11:23:13AM -0700, John Parello (jparello) wrote: > You could have one long list as you suggest but then if someone added a > state they are not grouped. So in your example if the dmtf adds a state > foo you would have to add dmtf-foo to the end? I tried to group the numbers but screwd up at the end. But at the end, it does not matter. A management system either understands what a particular number _means_ so that it can do something meaningful with the information or all it can do is just displaying the label. In both cases, what the number is is not really of importance. > It seems clearer to have these groups in sets and those sets are > interfaces. Explain "interfaces". > Also there will be a question of parity on states. If I set to EMAN-OFF > does that imply I am in DMTF-OFF and HAL-HARD-OFF as well? This is what I was pointing to. I heard some people arguing for a small and simple set of states. Others were arguing for exporting the component's native state. I can see value in both and have no clear opinion. However, the direction of reporting a vector of states for a component seems to be wrong and not at all helpful to me. > From a strict interface implementation split such a distinction would > make sense. Please explain "interface". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@quittek.at Thu Mar 17 01:51:17 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239F83A6806 for ; Thu, 17 Mar 2011 01:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iY5yHClvCSCC for ; Thu, 17 Mar 2011 01:51:15 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 43DE03A6842 for ; Thu, 17 Mar 2011 01:51:15 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MZOd3-1QKh0C0x1Z-00LPeA; Thu, 17 Mar 2011 09:52:37 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4--77790132 Message-Id: From: Juergen Quittek Date: Thu, 17 Mar 2011 09:52:36 +0100 To: "John Parello (jparello)" X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:rk3uiQxqPNmGTPxAF4qxTdwAS/t7QC4NJ6bSi4um81g 91zkabY9lyAsKKrr4GNjvkRcbiSxQdp2CV1Q+rsGPdOHkWkLAL TP8PrpShP41UEwXCg3TTSlQS/j0m0RI60snGqM6S+YWqyNn4SW v7TSDN222C+xVpV3xfqk3XDsY+YJrl//4DpSBk3z0ZVLXkrozV srf1u12tMAuY4nAx9kvqg== Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 08:51:17 -0000 --Apple-Mail-4--77790132 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi John, Let's start defining terms. According you your email below and our discussions before I assume the = following: "energy-metered"=20 A device is energy-metered if some entity measures the energy = consumption of the device. This may happen internally or externally of = the device.=20 "energy-aware"=20 A device is enerhy-aware if the information that the devices is metered = is available at the device even if metering is conducted externally. "energy-monitored" A device is energy-monitored if some energy monitoring system observes = metered energy values of a device. For self-managed devices, it may be = the device itself that monitors it. Would you agree on these definitions or do you have other ones? If yes, I am still waiting for someone explaining me what we need the = concept of "energy-awareness" for if we have "metered" and "monitored". Thanks, Juergen Am 16.03.2011 um 19:14 schrieb John Parello (jparello): > Hi Bruce, > =20 > I=92ll sum up my thinking here on aware versus monitored. > =20 > I think the term aware is more precise than monitor for the work of = this group but both are necessary. It=92s unfortunate monitor was used = from the start when the requirements were specified. > =20 > If a device implements the objects we are defining here we can say = the device is aware of its power and energy. Whether it is monitored or = not is a different attribute. Monitored assumes the existence of an = observer. Let=92s anthropomorphize this as an example. > =20 > Device =3D Person > Energy =3D spending > =20 > If your spending is monitored you would assume from that there exists = some external observer. > If you are aware of your spending you are tracking your spending with = or without an observer. > =20 > Back to our work. > =20 > IF you implement a set of objects we define in this WG you are aware = of your energy. You may or may not be monitored by someone accessing the = object. You can=92t assume just because you implement the objects = there=92s some miraculous observer making SNMP request to you or = monitoring you. You may never be contacted but you are still aware. > =20 > They are distinct terms. > =20 > In this space where there are non telecommunications devices the term = monitoring with an implied observer would be perceived as a setup where = some external metering device or physical probe was attached to a = device. This is ambiguous and misleading. > =20 > Juergen proposes swapping out the term aware for monitored . I = completely disagree with that as they are not synonyms and describe two = very different use. > =20 > AS for the idea this was marketing driven or that the use cases I = proposed were proprietary (I=92d say running code looking for consensus) = those are arguments to the messenger not the message so I don=92t see = how that even needs consideration. > =20 > This distinction has been adopted by another standards body so it = merits consideration in this WG. > =20 > Jp > =20 > =20 > =20 > From: Bruce Nordman [mailto:bnordman@lbl.gov]=20 > Sent: Tuesday, March 15, 2011 11:29 PM > To: Juergen Quittek > Cc: John Parello (jparello); eman mailing list > Subject: Re: [eman] Terminology: Awareness > =20 > I'll not try to insert myself into the exact back/forth of this, but > the "aware" term has also puzzled me from the start. >=20 > =46rom the perspective of the NMS, I would think that the level > of self-awareness of the device being monitored might be > unimportant, or at best a detail that could be noted (a flag). >=20 > The reference model document notes that the functionality of > reporting is divided into three parts: power supply, power > metering, and power status. A device may report some or > all of these itself, and a separate device may report some or > all. Thus, "awareness" would seem to be disaggregated, > not unitary. >=20 > I have wondered if this disaggregation suggests that the > MIBs should be divided up along these lines, since initially > at least, different devices (in principle three) might be > reporting the different types of information. In addition, > control signals (not my usual concern) will then also travel > to different entities, depending on whether it is supply, > meter, or status that is in question. >=20 > Finally, I think that data about identity and context are > distinct from the above three types of energy-specific > data, so may suggest one or two additional MIBs > (otherwise, they are most closely related to status). >=20 > --Bruce >=20 > .. > =20 >=20 >=20 >=20 > --=20 > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 --Apple-Mail-4--77790132 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi John,

Let's start defining = terms.
According you your email below and our discussions = before I assume the = following:

"energy-metered" 
A = device is energy-metered if some entity measures the energy consumption = of the device. This may happen internally or externally of the = device. 

"energy-aware" 
A = device is enerhy-aware if the information that the devices is metered is = available at the device even if metering is conducted = externally.

"energy-monitored"
A = device is energy-monitored if some energy monitoring system observes = metered energy values of a device. For self-managed devices, it may be = the device itself that monitors it.

Would you = agree on these definitions or do you have other = ones?

If yes, I am still waiting for someone = explaining me what we need the concept of "energy-awareness" for if we = have "metered" and = "monitored".

Thanks,

&nb= sp;   Juergen


Am = 16.03.2011 um 19:14 schrieb John Parello (jparello):

Hi = Bruce,
I=92ll = sum up my thinking here on aware versus = monitored.
I = think the term aware is more precise than monitor for the work of this = group but both are necessary. It=92s unfortunate monitor  was used = from the start when the requirements were = specified.
Energy =3D spending
If = your spending is monitored you would assume from that there exists some = external observer.
If = you are aware of your spending you are tracking your spending with or = without an observer.
 
Back to our = work.
IF = you implement a set of objects we define in this WG you are aware of = your energy. You may or may not be monitored by someone accessing the = object. You can=92t assume just because you implement the objects = there=92s some miraculous observer making SNMP request to you or = monitoring you. You may never be contacted but you are still = aware.
They = are distinct terms.
 
In this space where there are non = telecommunications devices the term monitoring with an implied observer = would be perceived as a setup where some external metering device or = physical probe was attached to a device. This is ambiguous and = misleading.
 
AS for the idea this was = marketing driven or that the use cases I proposed were proprietary (I=92d = say running code looking for consensus) those are arguments to the = messenger not the message so I don=92t see how that even needs = consideration.
This = distinction has been adopted by another standards body so it merits = consideration in this WG.
 
Jp
From: Bruce Nordman = [mailto:bnordman@lbl.gov] 
Sent: Tuesday, March 15, 2011 = 11:29 PM
To: Juergen = Quittek
Cc: John Parello (jparello); = eman mailing list
Subject: Re: [eman] Terminology: = Awareness
 

I'll not try to insert myself into the exact = back/forth of this, but
the "aware" term has also puzzled me from the = start.

=46rom the perspective of the NMS, I would think that the = level
of self-awareness of the device being monitored might = be
unimportant, or at best a detail that could be noted (a = flag).

The reference model document notes that the functionality = of
reporting is divided into three parts: power supply, = power
metering, and power status.  A device may report some = or
all of these itself, and a separate device may report some = or
all.  Thus, "awareness" would seem to be = disaggregated,
not unitary.

I have wondered if this = disaggregation suggests that the
MIBs should be divided up along = these lines, since initially
at least, different devices (in = principle three) might be
reporting the different types of = information.  In addition,
control signals (not my usual = concern) will then also travel
to different entities, depending on = whether it is supply,
meter, or status that is in = question.

Finally, I think that data about identity and context = are
distinct from the above three types of energy-specific
data, = so may suggest one or two additional MIBs
(otherwise, they are most = closely related to status).

--Bruce

..
 




-- 
Bruce Nordman
Lawrence Berkeley National = Laboratory
In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvjmygyVgXEmDSxTpC9Rv2sJDYOlAAa5ZVwACJM09A= References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at><20110316052854.GA2249@elstar.local> From: "Romascanu, Dan (Dan)" To: "John Parello (jparello)" , "Juergen Schoenwaelder" , "Juergen Quittek" Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 10:44:29 -0000 Hi John,=20 This grouping that you are talking about seems to me to be a matter of document readability by humans. It does not have any application significance, as the management application just gets an integer value. Am I wrong?=20 We can do a few things to improve human readability - for example similar prefixing of enumerated value names that belong to the same group, or sparse grouping that leaves room for definition of new enumerated values in the same group for the foreseeing future.=20 Regards, Dan=20 (speaking as contributor) =20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of John Parello (jparello) > Sent: Wednesday, March 16, 2011 8:23 PM > To: Juergen Schoenwaelder; Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] MIB-friendly proposal for flexible power states >=20 > Hi Juergen, >=20 > You could have one long list as you suggest but then if=20 > someone added a state they are not grouped. So in your=20 > example if the dmtf adds a state foo you would have to add=20 > dmtf-foo to the end? >=20 > It seems clearer to have these groups in sets and those sets=20 > are interfaces. >=20 > Also there will be a question of parity on states. If I set=20 > to EMAN-OFF does that imply I am in DMTF-OFF and HAL-HARD-OFF as well? >=20 > From a strict interface implementation split such a=20 > distinction would make sense. >=20 > Jp >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, March 15, 2011 10:29 PM > To: Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] MIB-friendly proposal for flexible power states >=20 > On Wed, Mar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote: > > Dear all, > >=20 > > here is a proposal for our power state discussion. > > It is not new and has been discussed in different flavors already. > > I just try to promote it by showing that it is flexible and at the=20 > > same time simple concerning its definition in a MIB module. > >=20 > > It looks like people on this list want to be able to use different=20 > > sets of power states in order to support different energy=20 > management=20 > > interfaces. An example for a set would be the set of DMTF power > states. > >=20 > > A way to support this and still allowing very simple=20 > implementations=20 > > would be the following: > >=20 > > We can be open to any set of power states by having them=20 > registered at=20 > > IANA. For each set we would register > > - an ID (number) for identifying the set > > - a number for each power state in this set > >=20 > > For example: > > EMAN: > > set ID: 0 > > states IDs: off(0). sleep(1). on(2) > >=20 > > DMTF:=20 > > set ID: 1 > > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. > >=20 > > ACPI: > > setID: 2 > > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. > >=20 > > Then we can define power state tables such that they have=20 > two indices: > > First the setID and then the stateID.=20 > >=20 > > In such a table you could implement several sets (interfaces) at the > same time. > > a device can support three basic power states with setID 0 as first > index, > > but as well show all DMTF power states with setID 1 as first index. > And another > > index could be used for ACPI and other power state sets. Simple > implementations > > would just implement a single (simple) set, but device makers would > have the=20 > > chance to provide support for multiple interfaces (sets). > >=20 > > A small disadvantage is that for identifying a power state=20 > we need two > numbers. > > We can solve this at MIB level by a textual convention for=20 > power state > index objects > > that defines the index as a string consisting of two=20 > numbers separated > by a dot, > > for example, "0.2" or "4.12". The first number would=20 > identify the set > and the second > > one the state within the set. > >=20 > > Any organization that specifies or builds devices can then=20 > define sets > of power=20 > > states, for example, for light bulbs or for UPS systems,=20 > and register > them at IANA. > > This mechanism is still simple but provides openness to future > developments > > without need to modify or extend the MIB module. >=20 > I am likely confused what the goal is. If every power state=20 > set needs to be registered with IANA, then why not simply use=20 > an enumeration? >=20 > simple-off(0), simple-sleep(1), simple-on(2),=20 > dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... > acpi-offHard(200), acpi-offSoft(201), hibernate(202),=20 > sleepDeep(203), ... >=20 > You can add whatever text is needed to tell implementors they=20 > should just use the values of one set only. If you want to=20 > support non-IANA registered power states, the normal thing to=20 > do in MIB land is to use OBJECT-IDENTITIES, that is defined=20 > object identifier constants. This is how we identify say=20 > crypto-algorithms. We also have numeric TCs that define a set=20 > of well known values and that partition some of the integer=20 > number space for private use, in case a small number of well=20 > known power states with vendor extensibility is the way to go. >=20 > I think it is crucial to figure out how much flexibility is=20 > needed and desirable and once that question has been=20 > answered, I think we should talk about the encoding (and I=20 > prefer encodings that are already known in MIB land over new=20 > creations). >=20 > /js >=20 > --=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 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 From j.schoenwaelder@jacobs-university.de Thu Mar 17 04:30:36 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE39D3A6931 for ; Thu, 17 Mar 2011 04:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7PGTw3PtBeJ for ; Thu, 17 Mar 2011 04:30:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 068D73A6924 for ; Thu, 17 Mar 2011 04:30:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B67AC0036; Thu, 17 Mar 2011 12:32:00 +0100 (CET) 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 eTFMXjjrDC5O; Thu, 17 Mar 2011 12:32:00 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8131C000F; Thu, 17 Mar 2011 12:31:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 289D716FE773; Thu, 17 Mar 2011 12:31:58 +0100 (CET) Date: Thu, 17 Mar 2011 12:31:58 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110317113158.GB3733@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, eman@ietf.org References: <20110308155405.GA12027@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110308155405.GA12027@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] Use of ENTITY-MIB in EMAN (version 01) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 11:30:36 -0000 On Tue, Mar 08, 2011 at 07:54:05AM -0800, chrisv@cyberswitching.com wrote: > The conclusion that I'm coming away with at this point is that > ENTITY-MIB was designed to model physical entities, where an "entity" is > some construct that is intended for management purposes. Logical > entities are not handled by entLogicalTable, which instead manages > logical contexts (slight difference in that a context is not intended to > be directly managed.) So for EMAN's purposes, a mechanism to manage > both physical and logical entities is needed. This may be an extension > of ENTITY-MIB (are other WG's needing something like this?) or may be a > separate structure wholy contained in the EMAN MIB schema. I request that we change the terminology to avoid the use of the term "logical entity" with two different meanings. Since the ENTITY-MIB has a define meaning of "logical entity", I think EMAN should use a different term to refer to "functional groupings". The ENTITY-MIB models a containment hierarchy of physical entities representing components of a managed system. Every physical entity has 0 or 1 parents (entPhysicalTable, entPhysicalContainsTable). Physical entities can have stable identifiers, such as URIs (containing UUIDs) or assigned stable identifiers (entPhysicalAssetID, entPhysicalAlias). Every physical entity can point to an arbitrary number of other modelled resources such as bridge ports, network interfaces, ... (entAliasMappingTable). A logical entity is an SNMP context, that is an instantiation of a MIB object tree in a naming scope identified by the contextEngineID and the contextName. An SNMP agent can provide access to multiple contexts (multiple MIB object trees). The ENTITY-MIB provides a list of existing logical entities (SNMP contexts) and it provides pointers in which logical contexts physical entities participate (entLogicalTable, entLPMappingTable). If there is a need to represent "functional groupings", then we can either use SNMP contexts (note that the entLPMappingTable allows to map physical entities into logical contexts), although that might not be sufficient, or we could extend the ENTITY-MIB by providing a functional grouping mechanism (perhaps designing an indexing scheme that makes it easy to refer to both physical entities and functional groupings of physical entities), or we might follow the path of creating a data model only loosely coupled to the ENTITY-MIB (but then I think we should avoid overlap as much as possible and for the overlap that is not avoidable, we need to explain how this is going to be implemented). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From russ@cisco.com Thu Mar 17 04:56:02 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C9D3A6940 for ; Thu, 17 Mar 2011 04:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XonccAGLViYu for ; Thu, 17 Mar 2011 04:56:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CEC413A693A for ; Thu, 17 Mar 2011 04:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1250; q=dns/txt; s=iport; t=1300363049; x=1301572649; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=iu9uCtjzk3A861m+KofyGG3lG457NPmhcEUFvfFaGMM=; b=Q7MVr58srVvcsBzeB52jOqsbGXqw5lpJkFgAwPAy2ZDEahSm69AppPKs c9uz0s4zcF0rEqwRGuFl+Iv583FwEc+5r+SSRw/vAYGNr7CRcb4Esq8cn WxrnUTPDw8nEht7+GdsZykJuBWebpMJRFBsMDFpf45sjLMZyeq29Hbmy0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACeUgU2tJXHB/2dsb2JhbAClTneoM5wuhWMEjF6DTQ X-IronPort-AV: E=Sophos;i="4.63,198,1299456000"; d="scan'208";a="348177404" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 17 Mar 2011 11:57:28 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2HBvS10008900; Thu, 17 Mar 2011 11:57:28 GMT Message-ID: <4D81F720.8030705@cisco.com> Date: Thu, 17 Mar 2011 07:57:20 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local> <4D80F7D2.1040200@cisco.com> <20110317071828.GA2375@elstar.local> In-Reply-To: <20110317071828.GA2375@elstar.local> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 11:56:03 -0000 > Reporting different states for different components of the system > makes sense to me. Reporting a vector of states for a single component > does not make much sense to me. Agreed --what I think would make sense is something like this: energy +--common states | +--on | +--off | +--low power mode | +--standard low power states | +--whatever makes sense here (DMTF/etc) | +--standard battery states +--whatever makes sense here In other words, restricted to three branches, a set of common states, a set of standard states, and a set of battery states. The device should be required to implement at least the common states, and always set them. If the device contains a battery, then it would implement some form of battery state (maybe there should only be one battery state, time remaining on charge, or something). And then based on the class of device, it may implement one of the other standard states. A system that knows how to read various more detailed information would know to look for those, and make use of them. Otherwise, ignore and use the common states. Anyway, just an idea for discussion on how to structure this. :-) Russ From chrisv@cyberswitching.com Thu Mar 17 08:42:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8E13A686C for ; Thu, 17 Mar 2011 08:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoSSQ4ceRP-N for ; Thu, 17 Mar 2011 08:42:29 -0700 (PDT) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) by core3.amsl.com (Postfix) with ESMTP id 323303A67EB for ; Thu, 17 Mar 2011 08:42:29 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o147.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id d3c228d4.0.5645.00-321.13307.p01c11o147.mxlogic.net (envelope-from ); Thu, 17 Mar 2011 09:43:57 -0600 (MDT) X-MXL-Hash: 4d822c3d6251c0f5-15c8902f8390d7293ddc5b30c56ccd4780bd7007 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 08:42:13 -0700 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id CB76FAB426D; Thu, 17 Mar 2011 08:43:56 -0700 (PDT) Date: Thu, 17 Mar 2011 08:43:56 -0700 From: chrisv@cyberswitching.com To: Juergen Schoenwaelder Message-ID: <20110317154356.GA25808@cslinux-build01.cyberswitching.local> References: <20110308155405.GA12027@cslinux-build01.cyberswitching.local> <20110317113158.GB3733@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110317113158.GB3733@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 17 Mar 2011 15:42:13.0176 (UTC) FILETIME=[E2961380:01CBE4B9] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=nPeTO2waIjAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=wzgqfsuUAAAA:8 a=F99] X-AnalysisOut: [QD316BxUA_jS2aSsA:9 a=qoAVa_SloF3Lvuim_dMA:7 a=ZVLJsrtt2QH] X-AnalysisOut: [w3_UBjK9OwsSTOmEA:4 a=CjuIK1q_8ugA:10 a=yvfu_RGVus0A:10 a=] X-AnalysisOut: [OIgOaPhCdG2kq8ST:21 a=8XSXqzv2UGkZxVRk:21] Cc: eman@ietf.org Subject: Re: [eman] Use of ENTITY-MIB in EMAN (version 01) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 15:42:30 -0000 On Thu, Mar 17, 2011 at 12:31:58PM +0100, Juergen Schoenwaelder wrote: > On Tue, Mar 08, 2011 at 07:54:05AM -0800, chrisv@cyberswitching.com wrote: > > > The conclusion that I'm coming away with at this point is that > > ENTITY-MIB was designed to model physical entities, where an "entity" is > > some construct that is intended for management purposes. Logical > > entities are not handled by entLogicalTable, which instead manages > > logical contexts (slight difference in that a context is not intended to > > be directly managed.) So for EMAN's purposes, a mechanism to manage > > both physical and logical entities is needed. This may be an extension > > of ENTITY-MIB (are other WG's needing something like this?) or may be a > > separate structure wholy contained in the EMAN MIB schema. > > I request that we change the terminology to avoid the use of the term > "logical entity" with two different meanings. Since the ENTITY-MIB has > a define meaning of "logical entity", I think EMAN should use a > different term to refer to "functional groupings". Rather than "functional groupings," which does not reflect the managed entity nature of the end goal, how about the following breakdown instead? 1. Physical entity - ENTITY-MIB 2. Logical entity - ENTITY-MIB 3. Virtual entity - EMAN 4. Power entity - EMAN A "power entity" can either refer to a "physical entity" or a "virtual entity." A "virtual entity" is anything that behaves similar to a "physical entity" but which has no actual physical nature, like a virtual machine or an outlet gang or a daemon running on the system. This clarifies the point that we need to manage "virtual entities" just like we would "physical entities." The term "functional groupings" makes it seem like we're bundling things just for abstract purposes only, whereas there is a deeper use case being answered in reality. > If there is a need to represent "functional groupings", then we can > either use SNMP contexts (note that the entLPMappingTable allows to > map physical entities into logical contexts), although that might not > be sufficient, or we could extend the ENTITY-MIB by providing a > functional grouping mechanism (perhaps designing an indexing scheme > that makes it easy to refer to both physical entities and functional > groupings of physical entities), or we might follow the path of > creating a data model only loosely coupled to the ENTITY-MIB (but then > I think we should avoid overlap as much as possible and for the > overlap that is not avoidable, we need to explain how this is going to > be implemented). Since ENTITY-MIB was specifically designed to represent a physical instantiation of a system, it does not handle virtual entities (as described above) properly. I would like to see it extended to solve the cases that we are grappling with here; however, such an undertaking would be outside of EMAN's scope and delay the development and release of EMAN-MIB significantly. Please feel free to let the ENTITY-MIB working group know that some changes are desired in their model and let them begin working on it as a separate undertaking -- I am happy to help explain use cases if needed. But we need to focus on developing something that will work for EMAN in a timely manner, and already have solutions for doing that. In both draft-verges and draft-parello (now draft-ietf-eman-energy-aware), we create such a data model that loosely couples with ENTITY-MIB but does not rely on it. I'm hearing that you may be coming around to the same conclusion that ENTITY-MIB won't properly handle these "virtual entities" that EMAN needs to support, so would either of these proposed models in the drafts fit your needs? If not, what needs to change? Thanks, Chris From jparello@cisco.com Thu Mar 17 09:00:34 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3663A6A88 for ; Thu, 17 Mar 2011 09:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sisNCVVJjXow for ; Thu, 17 Mar 2011 09:00:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 338A63A6A86 for ; Thu, 17 Mar 2011 09:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=7330; q=dns/txt; s=iport; t=1300377721; x=1301587321; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=XY951ESbz2vARgkjNIJoORMdHbENsQnoxK/S4qtFIBM=; b=ALX47UArutu0AIAPzIZMRNqvclkhdJJJYWApwTvwEOi/L+UXmx5omWGg YN1Edom4l4IZhiyVkMsBz8jayYk5SO39vbszJ8que/g67HV/g1zlaL5dN BKB7lldNN8EvEjih4NwzcjaW4bpcIzaLl7I3xBBjdJo0av9IaYdArY8RV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAFfNgU2tJXG+/2dsb2JhbACYHY0xd6cdnD4Cgnkagk4EhS+LAg X-IronPort-AV: E=Sophos;i="4.63,199,1299456000"; d="scan'208";a="321420107" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 17 Mar 2011 16:02:00 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2HG1woO017800; Thu, 17 Mar 2011 16:02:00 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 09:01:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 08:58:54 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvjmygyVgXEmDSxTpC9Rv2sJDYOlAAa5ZVwACJM09AAColukA== References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at><20110316052854.GA2249@elstar.local> From: "John Parello (jparello)" To: "Romascanu, Dan (Dan)" , "Juergen Schoenwaelder" , "Juergen Quittek" X-OriginalArrivalTime: 17 Mar 2011 16:01:51.0115 (UTC) FILETIME=[A0B14DB0:01CBE4BC] Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:00:34 -0000 Hi Dan, True a registry with long list with a name space is equivalent. So how about giving a dns like name to the state. It would also clear up the ownership and the registry would be human readable. Thinking out loud here how about.... org.dmtf.off 17 org.dmtf.sleep 42 : . org.ietf.eman.off 93 : . com.hal.off 102 com.hal.drowsey 117 etc... would allow for sorting and then perhaps a set by name without a cryptic indexing=20 setStatebyName('com.hal.off') setState(102) That may also handle the issue of subcomponents? Although I'm not sure of the implications of this as yet... com.hal.battery.off 73 One different issue I'd like to see addressed is whether or not setting a state in one name space implies a setting to an equivalent state in another name space.=20 Jp -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Thursday, March 17, 2011 3:46 AM To: John Parello (jparello); Juergen Schoenwaelder; Juergen Quittek Cc: eman mailing list Subject: RE: [eman] MIB-friendly proposal for flexible power states Hi John,=20 This grouping that you are talking about seems to me to be a matter of document readability by humans. It does not have any application significance, as the management application just gets an integer value. Am I wrong?=20 We can do a few things to improve human readability - for example similar prefixing of enumerated value names that belong to the same group, or sparse grouping that leaves room for definition of new enumerated values in the same group for the foreseeing future.=20 Regards, Dan=20 (speaking as contributor) =20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of John Parello (jparello) > Sent: Wednesday, March 16, 2011 8:23 PM > To: Juergen Schoenwaelder; Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] MIB-friendly proposal for flexible power states >=20 > Hi Juergen, >=20 > You could have one long list as you suggest but then if=20 > someone added a state they are not grouped. So in your=20 > example if the dmtf adds a state foo you would have to add=20 > dmtf-foo to the end? >=20 > It seems clearer to have these groups in sets and those sets=20 > are interfaces. >=20 > Also there will be a question of parity on states. If I set=20 > to EMAN-OFF does that imply I am in DMTF-OFF and HAL-HARD-OFF as well? >=20 > From a strict interface implementation split such a=20 > distinction would make sense. >=20 > Jp >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On=20 > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, March 15, 2011 10:29 PM > To: Juergen Quittek > Cc: eman mailing list > Subject: Re: [eman] MIB-friendly proposal for flexible power states >=20 > On Wed, Mar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote: > > Dear all, > >=20 > > here is a proposal for our power state discussion. > > It is not new and has been discussed in different flavors already. > > I just try to promote it by showing that it is flexible and at the=20 > > same time simple concerning its definition in a MIB module. > >=20 > > It looks like people on this list want to be able to use different=20 > > sets of power states in order to support different energy=20 > management=20 > > interfaces. An example for a set would be the set of DMTF power > states. > >=20 > > A way to support this and still allowing very simple=20 > implementations=20 > > would be the following: > >=20 > > We can be open to any set of power states by having them=20 > registered at=20 > > IANA. For each set we would register > > - an ID (number) for identifying the set > > - a number for each power state in this set > >=20 > > For example: > > EMAN: > > set ID: 0 > > states IDs: off(0). sleep(1). on(2) > >=20 > > DMTF:=20 > > set ID: 1 > > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. > >=20 > > ACPI: > > setID: 2 > > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. > >=20 > > Then we can define power state tables such that they have=20 > two indices: > > First the setID and then the stateID.=20 > >=20 > > In such a table you could implement several sets (interfaces) at the > same time. > > a device can support three basic power states with setID 0 as first > index, > > but as well show all DMTF power states with setID 1 as first index. > And another > > index could be used for ACPI and other power state sets. Simple > implementations > > would just implement a single (simple) set, but device makers would > have the=20 > > chance to provide support for multiple interfaces (sets). > >=20 > > A small disadvantage is that for identifying a power state=20 > we need two > numbers. > > We can solve this at MIB level by a textual convention for=20 > power state > index objects > > that defines the index as a string consisting of two=20 > numbers separated > by a dot, > > for example, "0.2" or "4.12". The first number would=20 > identify the set > and the second > > one the state within the set. > >=20 > > Any organization that specifies or builds devices can then=20 > define sets > of power=20 > > states, for example, for light bulbs or for UPS systems,=20 > and register > them at IANA. > > This mechanism is still simple but provides openness to future > developments > > without need to modify or extend the MIB module. >=20 > I am likely confused what the goal is. If every power state=20 > set needs to be registered with IANA, then why not simply use=20 > an enumeration? >=20 > simple-off(0), simple-sleep(1), simple-on(2),=20 > dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... > acpi-offHard(200), acpi-offSoft(201), hibernate(202),=20 > sleepDeep(203), ... >=20 > You can add whatever text is needed to tell implementors they=20 > should just use the values of one set only. If you want to=20 > support non-IANA registered power states, the normal thing to=20 > do in MIB land is to use OBJECT-IDENTITIES, that is defined=20 > object identifier constants. This is how we identify say=20 > crypto-algorithms. We also have numeric TCs that define a set=20 > of well known values and that partition some of the integer=20 > number space for private use, in case a small number of well=20 > known power states with vendor extensibility is the way to go. >=20 > I think it is crucial to figure out how much flexibility is=20 > needed and desirable and once that question has been=20 > answered, I think we should talk about the encoding (and I=20 > prefer encodings that are already known in MIB land over new=20 > creations). >=20 > /js >=20 > --=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 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 From bill.mielke@alcatel-lucent.com Thu Mar 17 09:37:16 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817D93A6AA1 for ; Thu, 17 Mar 2011 09:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErVpsSrSKTGl for ; Thu, 17 Mar 2011 09:37:15 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 07D453A6A9D for ; Thu, 17 Mar 2011 09:22:50 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p2HGODFi012915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2011 11:24:14 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2HGODCO013966 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Mar 2011 11:24:13 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 17 Mar 2011 11:24:13 -0500 From: "Mielke, William F (Bill)" To: Juergen Quittek , eman mailing list Date: Thu, 17 Mar 2011 11:24:09 -0500 Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvjbK8aGE13lEBOTnm1JseDNYDMVwBS9Ccg Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299E1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> In-Reply-To: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:37:16 -0000 > Juergen Quittek wrote: > > We can be open to any set of power states by having them registered=20 > at IANA. For each set we would register > - an ID (number) for identifying the set > - a number for each power state in this set >=20 > For example: > EMAN: > set ID: 0 > states IDs: off(0). sleep(1). on(2) >=20 > DMTF:=20 > set ID: 1 > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. >=20 > ACPI: > setID: 2 > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. > I have been tied up with non-IETF duties of late so have not been able to r= espond before now. I see that this thread is gaining some momentum which i= s good because I (personally) favor either (a) a minimalist set of states a= s Bruce has been arguing, or (b) a more flexible approach which can be exte= ned over time as things evolve without requiring changes to the core EMAN a= pproach to power states. While I favor incorporating more flexibility I am not tied to any particula= r approach to achieving that flexibility. This approach seems to be a nice= middle ground approach but allow me to play devil's advocate and ask a few= questions to explore what we achieve with this approach. I ask only to in= crease my understanding of the proposal not because I have any opinion pro = or con. This approach appears to give us the ability to have multiple sets of power= states where each set is effectively an enumerated type. I see this as a = good thing, in general, because I argue that having a meaningful set of sta= tes will have some element of a technology specific dependency. We are see= ing that in some of the later replies in this thread where the subject of b= attery states comes up vs. PC states vs. perahps camera states, etc. Now one element of your proposal is to have these sets of power states (eac= h effectively an enumerated type) be "standardized" by having them register= ed at IANA. One advantage of requiring IANA registration is that the resul= ting states would at least be well defined and relatively stable while allo= wing for evolution in the face of changing technologies and vendor implemen= tation choices. Now let me ask you a more fundamental question. Once we open the door to h= aving an extensible set of enumerated types as your proposal does, from the= perspective of "enabling more effect management" of a given device does re= gistering those enumerated types with IANA actually add anything over the a= lternative of having those enumerated types being dynamically discoverable = through the MIB? I am not arguing this point one way or the other, but I w= ould be interested in hearing your thoughts on the topic. The main difference that I can see from an implementation perspective is th= at with your proposal the vendors of management applications could then wri= te code which is "hard coded" to one or more specific sets of states and po= ssibly have logic which is "hard bound" to the semantics associated with th= e states being registered with IANA. This then raises a follow-up question. When these sets of states are regis= tered with IANA are there also specific definitions of the semantics that a= re tied to the states being so registered, or is IANA only managing the set= of integer values that are associated each of the enumerated power states?= In other words, is the interpretation of what those states actually mean = in practice still an implementation specific detail decide at the whim of e= ach vendor? One final question, given that you envision different sets of power states = what are the core variabilities at play that you believe would drive the de= finition of a new power state set? Over time would these sets be driven by= technology specific differences, vender specific differences, both, or som= ething entirely different? I think gaining more clarity on why we would ev= en want a new set of states may shed light on how best to organize things t= o support that type of evolution over time. Some food for thought. Thanks, William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein From bill.mielke@alcatel-lucent.com Thu Mar 17 09:47:02 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B8A3A6AC2 for ; Thu, 17 Mar 2011 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqgicEaEYHHz for ; Thu, 17 Mar 2011 09:47:01 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 19D7A3A6A88 for ; Thu, 17 Mar 2011 09:47:01 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2HGmQYw024303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2011 11:48:26 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2HGmNR9002391 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Mar 2011 11:48:26 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 17 Mar 2011 11:48:23 -0500 From: "Mielke, William F (Bill)" To: Juergen Schoenwaelder , Russ White Date: Thu, 17 Mar 2011 11:48:20 -0500 Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: Acvkc4nwg/wU7pWfTmCBDTyPGoun/gATOTAg Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299E4B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local> <4D80F7D2.1040200@cisco.com> <20110317071828.GA2375@elstar.local> In-Reply-To: <20110317071828.GA2375@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:47:02 -0000 > Juergen Schoenwaelder wrote: >=20 > Reporting different states for different components of the system > makes sense to me. Reporting a vector of states for a single component > does not make much sense to me. >=20 +1 on the observation that power states are actually tied to the components= of a system and not the system as a whole (although that too may have a po= wer state). +1 on the observation that different components will need to have different= states to make those states "meaningful" depending on the type of the comp= onent. Regading your vector comment I think that you have misinterpreted Mouli's c= omment. When he said "vector" another way of saying what he meant would be= "tuple", because he was talking about the fundamental idea in JourgenQ's p= roposal where the "state" of a component is actually a tuple (i.e. a vector= ) which is composed of "(x1,y1)" where x1 actually specifies the state type= (i.e. which set or enumeration applies) and y1 specifies the actual state = (i.e. which value within the corresponding set or enumeration has been sele= cted). Please correct me, Mouli, if this was not your meaning. In this context you seem to be using the term "vector" to mean "a list of s= uch states" for each component which I don't think anyone has proposed. I = think that there is a simply a miscommunication here based on the use of th= e term "vector". William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein From bill.mielke@alcatel-lucent.com Thu Mar 17 10:35:59 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF1A3A69F7 for ; Thu, 17 Mar 2011 10:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0wett3BGcBK for ; Thu, 17 Mar 2011 10:35:58 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 895803A69F3 for ; Thu, 17 Mar 2011 10:35:58 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2HHbOaQ006498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2011 12:37:24 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2HHbI2C001966 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Mar 2011 12:37:24 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 17 Mar 2011 12:37:21 -0500 From: "Mielke, William F (Bill)" To: Russ White , Juergen Quittek , eman mailing list Date: Thu, 17 Mar 2011 12:37:18 -0500 Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvkmoJwgA5iKs4rTKKcZUnbaT2H3gAKQOiw Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299EB3@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local> <4D80F7D2.1040200@cisco.com> <20110317071828.GA2375@elstar.local> <4D81F720.8030705@cisco.com> In-Reply-To: <4D81F720.8030705@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:35:59 -0000 > Russ White wrote: >=20 > Agreed --what I think would make sense is something like this: >=20 > energy > +--common states > | +--on > | +--off > | +--low power mode > | > +--standard low power states > | +--whatever makes sense here (DMTF/etc) > | > +--standard battery states > +--whatever makes sense here >=20 > In other words, restricted to three branches, a set of common=20 > states, a > set of standard states, and a set of battery states. The device should > be required to implement at least the common states, and always set > them. If the device contains a battery, then it would implement some > form of battery state (maybe there should only be one battery state, > time remaining on charge, or something). And then based on=20 > the class of device, it may implement one of the other standard states. I am curious as to why you believe that batteries are important enough to b= e called out explicitly within your hierarchy? What is special about batte= ries that makes them not suitable to simply use the common or standard powe= r states? If we generalize from where this is heading, might there not be other equal= ly important types of components which need to have similarly specialized s= tates? I generally like your idea of a hierarchy of states as long as we could app= ly a meaningful structure to it. I would actually take this idea and morph= it into a 2 level hierachy as follows: energy +--common power state | +--on | +--off | +--low power mode -> See domain specific states for more details. | +--domain specific power states +--whatever makes sense here. --> Details specified per JuergenQ= 's=20 IANA proposal or similar. At the top is the most abstract view possible: on, off, or low power mode. = That makes for a nice high level, reasonably universal set of states that = gives the management application a general sense of the state of the entity= . I would then merge your last two levels into one with the concept being tha= t these are "domain specific" power states. I have thus far argued that th= ese domains are likely to be aligned with the underlying technology involve= d but they need not be restricted to that dimension. They could be literal= ly anything. Within this "domain specific level" of the hierarchy the concept of the sta= tes being tuples, as proposed by JuergenQ, can come into play. What I am c= alling "domain specific power states" maps cleanly one-to-one with the powe= r sets or enumerated types JuergenQ proposes to have registered at IANA. E= ach such set forms the set of states which are meaningful to a particular "= domain". Thus things like ACPI and DMTF are simply specialized domains. F= or components where those states make sense, by all means utilize them. Fo= r components where they don't, use a different set. If there are no existi= ng sets of states already registered at IANA which are meaningful for a giv= en component then propose and register a meaningful set unique to that comp= onent's domain. Operationally the management applications would start by simply reporting t= he common state for each component. In the case where that state is "low p= ower mode" the software could then use the "set type identifier" from Juerg= enQ's proposal to then lookup and and invoke the proper "domain specific pl= ugin" that you alluded to earlier. This would then be able to report and m= anage things based on the domain specific states actually defined for that = specific grouping. I think an implication of this approach is that each component/entity would= actually have two power states associated with it in the MIB. The first i= s universal and defined as part of the eman standard and corresponds to you= r "common power states". The second is actually tied to domain specific po= wer states which are registered and maintained within IANA and could be imp= lemented as suggested by JuergenQ's proposal or somthing similar. Thoughts from others? William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein From jparello@cisco.com Thu Mar 17 10:47:44 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FF73A6AC9 for ; Thu, 17 Mar 2011 10:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TTk3nRFsjup for ; Thu, 17 Mar 2011 10:47:43 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0802A3A6A12 for ; Thu, 17 Mar 2011 10:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=5424; q=dns/txt; s=iport; t=1300384151; x=1301593751; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=r/1MStMryAheKJuIOi0FG8KxNVLf2LCV7S/+UsS1aQU=; b=Y7F8emVbFSLp5pqbiJyPyjJAcMVUg6dssAjnW8eOzWKbEAOJ9P8DkMyz YYpMoaz21x6LbpI6zidXjigKXWYMyDYj2vDwJM/b/lXuDrxYsteSJTQtp mAuzzlwfA6HN12W28CByvA6seTxh6dUOXgcX272U+XkHxgu3BnF1Dd48a Y=; X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="scan'208";a="321468884" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 17 Mar 2011 17:49:11 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2HHn6w8006911; Thu, 17 Mar 2011 17:49:10 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 10:49:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 10:44:12 -0700 Message-ID: In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299EB3@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvkmoJwgA5iKs4rTKKcZUnbaT2H3gAKQOiwAAG9GPA= References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at><4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local><4D80F7D2.1040200@cisco.com> <20110317071828.GA2375@elstar.local><4D81F720.8030705@cisco.com> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299EB3@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: "John Parello (jparello)" To: "Mielke, William F (Bill)" , "russ (mailer list)" , "Juergen Quittek" , "emanmailing list" X-OriginalArrivalTime: 17 Mar 2011 17:49:08.0569 (UTC) FILETIME=[9DB6D490:01CBE4CB] Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:47:44 -0000 Hi William, I'm curious on one point you called out as well regarding battery. At some management level does the administrator care about whether the battery is charging or if the devices is charging. Think from a use point of view. I charge my phone, my ipod, my car. Do I charge the battery? So from a device object point of view no - you probably charge the device. Is the device sleeping and the battery charging or is the device simply charging. It's a tricky relationship that needs to be modeled. Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mielke, William F (Bill) Sent: Thursday, March 17, 2011 10:37 AM To: russ (mailer list); Juergen Quittek; emanmailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states > Russ White wrote: >=20 > Agreed --what I=20 would make sense is something like this: >=20 > energy > +--common states > | +--on > | +--off > | +--low power mode > | > +--standard low power states > | +--whatever makes sense here (DMTF/etc) > | > +--standard battery states > +--whatever makes sense here >=20 > In other words, restricted to three branches, a set of common=20 > states, a > set of standard states, and a set of battery states. The device should > be required to implement at least the common states, and always set > them. If the device contains a battery, then it would implement some > form of battery state (maybe there should only be one battery state, > time remaining on charge, or something). And then based on=20 > the class of device, it may implement one of the other standard states. I am curious as to why you believe that batteries are important enough to be called out explicitly within your hierarchy? What is special about batteries that makes them not suitable to simply use the common or standard power states? If we generalize from where this is heading, might there not be other equally important types of components which need to have similarly specialized states? I generally like your idea of a hierarchy of states as long as we could apply a meaningful structure to it. I would actually take this idea and morph it into a 2 level hierachy as follows: energy +--common power state | +--on | +--off | +--low power mode -> See domain specific states for more details. | +--domain specific power states +--whatever makes sense here. --> Details specified per JuergenQ's=20 IANA proposal or similar. At the top is the most abstract view possible: on, off, or low power mode. That makes for a nice high level, reasonably universal set of states that gives the management application a general sense of the state of the entity. I would then merge your last two levels into one with the concept being that these are "domain specific" power states. I have thus far argued that these domains are likely to be aligned with the underlying technology involved but they need not be restricted to that dimension. They could be literally anything. Within this "domain specific level" of the hierarchy the concept of the states being tuples, as proposed by JuergenQ, can come into play. What I am calling "domain specific power states" maps cleanly one-to-one with the power sets or enumerated types JuergenQ proposes to have registered at IANA. Each such set forms the set of states which are meaningful to a particular "domain". Thus things like ACPI and DMTF are simply specialized domains. For components where those states make sense, by all means utilize them. For components where they don't, use a different set. If there are no existing sets of states already registered at IANA which are meaningful for a given component then propose and register a meaningful set unique to that component's domain. Operationally the management applications would start by simply reporting the common state for each component. In the case where that state is "low power mode" the software could then use the "set type identifier" from JuergenQ's proposal to then lookup and and invoke the proper "domain specific plugin" that you alluded to earlier. This would then be able to report and manage things based on the domain specific states actually defined for that specific grouping. I think an implication of this approach is that each component/entity would actually have two power states associated with it in the MIB. The first is universal and defined as part of the eman standard and corresponds to your "common power states". The second is actually tied to domain specific power states which are registered and maintained within IANA and could be implemented as suggested by JuergenQ's proposal or somthing similar. Thoughts from others? William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From russ@cisco.com Thu Mar 17 10:56:28 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28BF3A6ADF for ; Thu, 17 Mar 2011 10:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-A031I0BzHE for ; Thu, 17 Mar 2011 10:56:27 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A3DD13A6A1C for ; Thu, 17 Mar 2011 10:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1856; q=dns/txt; s=iport; t=1300384676; x=1301594276; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=OxjfSe23k6I8BrgkyJH3WECvpRDKpwiOfSzKklujjWI=; b=cIhJ2Btk17eqGRpTmyvkvFWeRKo2qX8y4qBPvjKI5VD+bf0x1q3YR+sx ufrFLWW6gRzEnEWe/gzSNBbQky+B0jKCk79FJBQCDMncReMqCqf+WM/jZ B/zAE+D5vBE0gMIZasOnPFQAwYsjFIJSezdR/GK9TtP9KN/yJvraN9OBx w=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="asc'?scan'208";a="348362797" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 17 Mar 2011 17:57:42 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2HHvfcR027194; Thu, 17 Mar 2011 17:57:42 GMT Message-ID: <4D824B8A.3010701@cisco.com> Date: Thu, 17 Mar 2011 13:57:30 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "John Parello (jparello)" References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at><4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local><4D80F7D2.1040200@cisco.com> <20110317071828.GA2375@elstar.local><4D81F720.8030705@cisco.com> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299EB3@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig13E75F8EE61FE4B884370750" Cc: emanmailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:56:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig13E75F8EE61FE4B884370750 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > So from a device object point of view no - you probably charge the > device. Is the device sleeping and the battery charging or is the devic= e > simply charging. Well, there was a discussion a while back on the list about including battery state for various reasons... I was just thinking that batteries exist on some devices and not on others that are otherwise identical. So, if we _wanted_ to include battery, this seems like a good way to do it. If we don't, then... I'm fine with dropping it, and going to two sections. I know that in the MANET world battery power is really important --you actually base routing on battery power remaining, for instance. But I wouldn't want to have one model for a wireless AP without a battery, and another with a battery... :-) Russ --=20 riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone If the whole universe has no meaning, we should never have found out that it has no meaning: just as, if there were no light in the universe and therefore no creatures with eyes, we should never know it was dark. Dark would be without meaning. -C. S. Lewis --------------enig13E75F8EE61FE4B884370750 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2CS40ACgkQER27sUhU9OTrZgCg0rDkRrZfoNnOCUMU/4QkknSv ql4Anjhl+GUHvNs/DyoHVTkMjyd9uiQS =HKdz -----END PGP SIGNATURE----- --------------enig13E75F8EE61FE4B884370750-- From jparello@cisco.com Thu Mar 17 10:57:49 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA713A69FE for ; Thu, 17 Mar 2011 10:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKSslYwPub9i for ; Thu, 17 Mar 2011 10:57:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D9E603A6A09 for ; Thu, 17 Mar 2011 10:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=11215; q=dns/txt; s=iport; t=1300384754; x=1301594354; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=L1LCCDUJsoa+kmCrnZt8fC65scK5MzjVfwpC/Q+r+cY=; b=hlc/Nxbg0c1rZsSo5c0gSSh+Mv7aF0/TbWRfvOTQvK+jl4rbiEv+WemG 0EC6YT1HISNH3vdW+4pQI4osaGGxpBpqSjAkUbTYnqv1Lt17YWj34TApo jIxK4iHklHzjJY2o64v54N2gdsWr1FOEz4aA/dcwYPRx+3JSQbCJLjGXM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAMPogU2tJXG+/2dsb2JhbACCW5VCjTF3px+cPoVjBIUviwI X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="scan'208,217";a="668194613" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-6.cisco.com with ESMTP; 17 Mar 2011 17:59:12 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2HHx9nK006961; Thu, 17 Mar 2011 17:59:12 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 10:59:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE4CC.FFF24D2C" Date: Thu, 17 Mar 2011 10:54:08 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: Awareness Thread-Index: AcvkgK9BMewYMEIRTiGJTDcFvuhadAASqXIA References: From: "John Parello (jparello)" To: "Juergen Quittek" X-OriginalArrivalTime: 17 Mar 2011 17:59:03.0427 (UTC) FILETIME=[0046F530:01CBE4CD] Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:57:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE4CC.FFF24D2C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Juergen, =20 Inline... =20 From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Thursday, March 17, 2011 1:53 AM To: John Parello (jparello) Cc: Bruce Nordman; eman mailing list Subject: Re: [eman] Terminology: Awareness =20 Hi John, =20 Let's start defining terms. According you your email below and our discussions before I assume the following: =20 [jp] we'll have to cover the separate values of power and energy? =20 "energy-metered"=20 A device is energy-metered if some entity measures the energy consumption of the device. This may happen internally or externally of the device.=20 =20 "energy-aware"=20 A device is enerhy-aware if the information that the devices is metered is available at the device even if metering is conducted externally. =20 "energy-monitored" A device is energy-monitored if some energy monitoring system observes metered energy values of a device. For self-managed devices, it may be the device itself that monitors it. =20 Would you agree on these definitions or do you have other ones? =20 If yes, I am still waiting for someone explaining me what we need the concept of "energy-awareness" for if we have "metered" and "monitored". =20 [jp] Well someone other than me I assume ;) - Aware covers your case of defining monitoring as being monitored and self-metered (monitored?) which would make your definition non terminal. We can discuss offline if you like for efficiency. =20 Jp =20 =20 =20 ------_=_NextPart_001_01CBE4CC.FFF24D2C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Juergen,

 

Inline…

 

From:= Juergen = Quittek [mailto:ietf@quittek.at]
Sent: Thursday, March 17, 2011 1:53 AM
To: John Parello (jparello)
Cc: Bruce Nordman; eman mailing list
Subject: Re: [eman] Terminology: Awareness

 

Hi John,

 

Let's start defining terms.

According you your email below and our discussions = before I assume the following:

 

[jp] we’ll have to cover the separate values of = power and energy?

 

"energy-metered" 

A device is energy-metered if some entity measures = the energy consumption of the device. This may happen internally or = externally of the device. 

 

"energy-aware" 

A device is enerhy-aware if the information that = the devices is metered is available at the device even if metering is conducted externally.

 

"energy-monitored"

A device is energy-monitored if some energy = monitoring system observes metered energy values of a device. For self-managed = devices, it may be the device itself that monitors it.

 

Would you agree on these definitions or do you have = other ones?

 

If yes, I am still waiting for someone explaining = me what we need the concept of "energy-awareness" for if we have "metered" and "monitored".

 

[jp] Well someone other than me I assume ;)   - = Aware covers your case of defining monitoring as being monitored and = self-metered (monitored?) which would make your definition non terminal.  We can discuss offline if you like for efficiency. 

Jp

 

 

 

------_=_NextPart_001_01CBE4CC.FFF24D2C-- From bill.mielke@alcatel-lucent.com Thu Mar 17 11:23:40 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307933A6A22 for ; Thu, 17 Mar 2011 11:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.242 X-Spam-Level: X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZT-mb9SOBJM for ; Thu, 17 Mar 2011 11:23:38 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 9F6CB3A6A10 for ; Thu, 17 Mar 2011 11:23:38 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2HIP5O3001490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 17 Mar 2011 13:25:06 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2HIP5Uw029286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 17 Mar 2011 13:25:05 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 17 Mar 2011 13:25:05 -0500 From: "Mielke, William F (Bill)" To: emanmailing list Date: Thu, 17 Mar 2011 13:25:03 -0500 Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvkmoJwgA5iKs4rTKKcZUnbaT2H3gAKQOiwAAG9GPAAAIkP4A== Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299F0A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at><4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local><4D80F7D2.1040200@cisco.com> <20110317071828.GA2375@elstar.local><4D81F720.8030705@cisco.com> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299EB3@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:23:40 -0000 > John Parello wrote: >=20 > So from a device object point of view no - you probably charge the > device. Is the device sleeping and the battery charging or is=20 > the device > simply charging. >=20 > It's a tricky relationship that needs to be modeled. I agree that it is tricky. I think that the answer is tied to how the device is modeled. If we presen= t the device as an entity in its own right, as I think most people would ar= gue we should, then at that level your point makes sense to me. If we also= model not only the device but also it's contained hierachy of components w= herein the battery becomes a unique entity then at that level I would argue= that the domain specific set of "battery states" applies only at the batte= ry level. Given this your question starts to lead me down the path of thinking about = parent/child relationships and containment hierachies. Along with that dis= cussion will also come the inevitable question of whether and how things li= ke power states "aggregate" up the containment hierachy. I can imagine com= ing up with rules for how things like the common states (on, off, low power= mode) might aggregate up the hierachy in a meaningful sense, but the devic= e specific states not as much. At the abstract level of an "iPhone" I would argue that a state like "charg= ing" doesn't make sense even though you point out that in common language u= sage it would. Literally speaking, to say that your iPhone is charging mea= ns that it contains a battery that is charging. The term "charging" only a= pplies to the specific domain of the battery and to the specific contained = entity that is the battery. In my view of things, and I am open to other perspectives, the way that a h= uman operator would identify that the iPhone is "charging" is that they wou= ld have to specifically drill down into the iPhone entity, discover that it= contained a battery, and observe that the battery is in the charging state= . It is less clear to me how one takes what I just described and codifies = it into an application, but obviously it can be done so long as the code in= question knows to explicitly look for this relationship. Now, one possible approach if we actually feel that aggegrating device spec= ific component states up the containment hierarchy is important is to intro= duce the concept of a power state vector similar to what JuergenS was talki= ng about (but in a separate context). Abstract entities which are themselv= es composites of simple entities could report a vector of all the contained= domain specific states of all of it's simple "leaf components". In practi= ce I would expect this to become quite large and unwieldly and so I would a= rgue against such an approach, but it is certainly possible. Thus the doma= in specific state of a composite entity is actually the union of the domain= specific state of the composite entity itself along with the domain specif= ic states of all of its constituent components. Does that make sense? William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein From moulchan@cisco.com Thu Mar 17 11:25:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23D63A699E for ; Thu, 17 Mar 2011 11:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcypmsrotoHg for ; Thu, 17 Mar 2011 11:25:28 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A06033A6A22 for ; Thu, 17 Mar 2011 11:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=2492; q=dns/txt; s=iport; t=1300386417; x=1301596017; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=uAwFiU8r2HMLYOHn2tDEevD6cZcS8lgIJQajgX37FjE=; b=FiUhI36/h1dDI1cLZIJeSEXS0MFhVx3fOK10+Yj6mTI9dxDpyTxRosZD 51lTbrrZKe4ZyKa/Oz6jRw5FYzq57cA36rMunzOkLqSFoHyJGi31M+BeR 3YRoAv+FRjUeq57aGFC+1c1WnjovyECQ5YgBFTKOx+jY8MkneJd84vY9j 8=; X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="scan'208";a="226598128" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 17 Mar 2011 18:26:54 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2HIQspf029385; Thu, 17 Mar 2011 18:26:54 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 13:26:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 13:26:50 -0500 Message-ID: In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299E4B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: Acvkc4nwg/wU7pWfTmCBDTyPGoun/gATOTAgAAPrGfA= References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at><4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local><4D80F7D2.1040200@cisco.com> <20110317071828.GA2375@elstar.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299E4B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: "Mouli Chandramouli (moulchan)" To: "Mielke, William F (Bill)" , "Juergen Schoenwaelder" , "russ (mailer list)" X-OriginalArrivalTime: 17 Mar 2011 18:26:54.0541 (UTC) FILETIME=[E456B7D0:01CBE4D0] Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:25:30 -0000 Hi William, Exactly, this is what I had intended. (x1, y1), where x1 is the power state type and y1 is the specific power state within that model.=20 I thought there is value when an NMS queries an end-device, it would be useful to know what is the power state model implemented in the device. Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mielke, William F (Bill) Sent: Thursday, March 17, 2011 10:18 PM To: Juergen Schoenwaelder; russ (mailer list) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states > Juergen Schoenwaelder wrote: >=20 > Reporting different states for different components of the system > makes sense to me. Reporting a vector of states for a single component > does not make much sense to me. >=20 +1 on the observation that power states are actually tied to the components of a system and not the system as a whole (although that too may have a power state). +1 on the observation that different components will need to have different states to make those states "meaningful" depending on the type of the component. Regading your vector comment I think that you have misinterpreted Mouli's comment. When he said "vector" another way of saying what he meant would be "tuple", because he was talking about the fundamental idea in JourgenQ's proposal where the "state" of a component is actually a tuple (i.e. a vector) which is composed of "(x1,y1)" where x1 actually specifies the state type (i.e. which set or enumeration applies) and y1 specifies the actual state (i.e. which value within the corresponding set or enumeration has been selected). Please correct me, Mouli, if this was not your meaning. In this context you seem to be using the term "vector" to mean "a list of such states" for each component which I don't think anyone has proposed. I think that there is a simply a miscommunication here based on the use of the term "vector". William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From tirth.ghose@gmail.com Thu Mar 17 11:27:53 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06493A6A20 for ; Thu, 17 Mar 2011 11:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvzrDQFOVkhu for ; Thu, 17 Mar 2011 11:27:52 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 14C3F3A6A10 for ; Thu, 17 Mar 2011 11:27:52 -0700 (PDT) Received: by iwl42 with SMTP id 42so3680334iwl.31 for ; Thu, 17 Mar 2011 11:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=HlQAVNB555z7aBYMmosqMHBh1W7DD37BqxMLd2v7ITI=; b=Y6xPJksXca2jq2MTTFDDm/B8YDl/7wdjLGwUxMgGyebsqxXTRl+AiWgmkbTA0Pq+Mo A8lunCWFFHc5p0Z7YkOALH+loFSzXnsFDJZJ1qJddipYpnqgBJrdvMfsMgwaj7qfiK6u K9p2dR8l+KJinfLG5/qUXYtKkAZ77sAxyTPr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=phi9Sm4cT59ETjN/EEgTT2ysbNCb8LF8JJ+sl97R27VIfMKRZ+jFm4X6bXN7cgloVp fyLGqfuKLHAKoFB7M6sXDV8eWNqjDkI+WOMOVJEhxv375rQ2FSy2rVIxanGVyptIcqdj V6LSJI8YKXvzCieiYTPOyQKTTEDmtqyPTzPRc= MIME-Version: 1.0 Received: by 10.231.185.76 with SMTP id cn12mr102716ibb.33.1300386559721; Thu, 17 Mar 2011 11:29:19 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Thu, 17 Mar 2011 11:29:19 -0700 (PDT) In-Reply-To: <20110316052854.GA2249@elstar.local> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> Date: Thu, 17 Mar 2011 11:29:19 -0700 X-Google-Sender-Auth: PFbcygWudUnYZPhKpMaX_2h3S0Q Message-ID: From: Ted Ghose To: Juergen Schoenwaelder , Juergen Quittek , eman mailing list Content-Type: multipart/alternative; boundary=005045016234f6816c049eb1d6ed Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:27:53 -0000 --005045016234f6816c049eb1d6ed Content-Type: text/plain; charset=ISO-8859-1 Hi Juergen If the proposal here to display any collection of any states that people will go and register in IANA, are we not loosing the main focus of standardizing, and what that means. You were arguing else where "what's the state of the 'device off battery charging' be", and I agree with you. But without standardizing some basic EMAN states, but displaying wide varieties of state of overlapping and even conflicting meaning registered in IANA, what will be a real value add. Different devices some how or other does shows different states they have implemented, anyway. I'd urge the WG to bring some standard and avoid the explosion of power states in IANA. thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Tue, Mar 15, 2011 at 10:28 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Mar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote: > > Dear all, > > > > here is a proposal for our power state discussion. > > It is not new and has been discussed in different flavors already. > > I just try to promote it by showing that it is flexible and > > at the same time simple concerning its definition in a MIB module. > > > > It looks like people on this list want to be able to use different > > sets of power states in order to support different energy management > > interfaces. An example for a set would be the set of DMTF power states. > > > > A way to support this and still allowing very simple implementations > > would be the following: > > > > We can be open to any set of power states by having them registered > > at IANA. For each set we would register > > - an ID (number) for identifying the set > > - a number for each power state in this set > > > > For example: > > EMAN: > > set ID: 0 > > states IDs: off(0). sleep(1). on(2) > > > > DMTF: > > set ID: 1 > > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. > > > > ACPI: > > setID: 2 > > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. > > > > Then we can define power state tables such that they have two indices: > > First the setID and then the stateID. > > > > In such a table you could implement several sets (interfaces) at the same > time. > > a device can support three basic power states with setID 0 as first > index, > > but as well show all DMTF power states with setID 1 as first index. And > another > > index could be used for ACPI and other power state sets. Simple > implementations > > would just implement a single (simple) set, but device makers would have > the > > chance to provide support for multiple interfaces (sets). > > > > A small disadvantage is that for identifying a power state we need two > numbers. > > We can solve this at MIB level by a textual convention for power state > index objects > > that defines the index as a string consisting of two numbers separated by > a dot, > > for example, "0.2" or "4.12". The first number would identify the set and > the second > > one the state within the set. > > > > Any organization that specifies or builds devices can then define sets of > power > > states, for example, for light bulbs or for UPS systems, and register > them at IANA. > > This mechanism is still simple but provides openness to future > developments > > without need to modify or extend the MIB module. > > I am likely confused what the goal is. If every power state set needs > to be registered with IANA, then why not simply use an enumeration? > > simple-off(0), simple-sleep(1), simple-on(2), > dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... > acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203), ... > > You can add whatever text is needed to tell implementors they should > just use the values of one set only. If you want to support non-IANA > registered power states, the normal thing to do in MIB land is to use > OBJECT-IDENTITIES, that is defined object identifier constants. This > is how we identify say crypto-algorithms. We also have numeric TCs > that define a set of well known values and that partition some of the > integer number space for private use, in case a small number of well > known power states with vendor extensibility is the way to go. > > I think it is crucial to figure out how much flexibility is needed and > desirable and once that question has been answered, I think we should > talk about the encoding (and I prefer encodings that are already known > in MIB land over new creations). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --005045016234f6816c049eb1d6ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi=A0Juergen=A0

If the proposal here to display any coll= ection of any states that people will go and register in IANA, are we not l= oosing the main focus of standardizing, and what that means.

=
You were arguing else where "what's the state of the 'dev= ice off battery charging' be", and I agree with you.
But without standardizing some basic EMAN states, but displayin= g=A0wide=A0varieties=A0of state of overlapping and even conflicting meaning= registered in IANA, what will be a real value add.

Different devices some how or other does shows differen= t states they have=A0implemented, anyway.=A0

I'= ;d urge the WG to bring some standard and=A0avoid=A0the=A0explosion=A0of po= wer states in IANA.

thanks

-tg-
*= :-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:= -.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time..= . see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:= *'``'*:-.,_:-.,_,.-:**:-.,_,.


On Tue, Mar 15, 2011 at 10:28 PM, Juerge= n Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrot= e:
On Wed, M= ar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote:
> Dear all,
>
> here is a proposal for our power state discussion.
> It is not new and has been discussed in different flavors already.
> I just try to promote it by showing that it is flexible and
> at the same time simple concerning its definition in a MIB module.
>
> It looks like people on this list want to be able to use different
> sets of power states in order to support different energy management > interfaces. An example for a set would be the set of DMTF power states= .
>
> A way to support this and still allowing very simple implementations > would be the following:
>
> We can be open to any set of power states by having them registered > at IANA. For each set we would register
> =A0 - an ID (number) for identifying the set
> =A0 - a number for each power state in this set
>
> For example:
> EMAN:
> set ID: 0
> states IDs: off(0). sleep(1). on(2)
>
> DMTF:
> set ID: 1
> states: =A0powerOn(2), sleepLight(3), sleepDeep(4), etc.
>
> ACPI:
> setID: 2
> states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. >
> Then we can define power state tables such that they have two indices:=
> First the setID and then the stateID.
>
> In such a table you could implement several sets (interfaces) at the s= ame time.
> a device can support three basic power states with setID 0 as first in= dex,
> but as well show all DMTF power states with setID 1 as first index. An= d another
> index could be used for ACPI and other power state sets. Simple implem= entations
> would just implement a single (simple) set, but device makers would ha= ve the
> chance to provide support for multiple interfaces (sets).
>
> A small disadvantage is that for identifying a power state we need two= numbers.
> We can solve this at MIB level by a textual convention for power state= index objects
> that defines the index as a string consisting of two numbers separated= by a dot,
> for example, "0.2" or "4.12". The first number wou= ld identify the set and the second
> one the state within the set.
>
> Any organization that specifies or builds devices can then define sets= of power
> states, for example, for light bulbs or for UPS systems, and register = them at IANA.
> This mechanism is still simple but provides openness to future develop= ments
> without need to modify or extend the MIB module.

I am likely confused what the goal is. If every power state set= needs
to be registered with IANA, then why not simply use an enumeration?

simple-off(0), simple-sleep(1), simple-on(2),
dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ...
acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203), ...
You can add whatever text is needed to tell implementors they should
just use the values of one set only. If you want to support non-IANA
registered power states, the normal thing to do in MIB land is to use
OBJECT-IDENTITIES, that is defined object identifier constants. This
is how we identify say crypto-algorithms. We also have numeric TCs
that define a set of well known values and that partition some of the
integer number space for private use, in case a small number of well
known power states with vendor extensibility is the way to go.

I think it is crucial to figure out how much flexibility is needed and
desirable and once that question has been answered, I think we should
talk about the encoding (and I prefer encodings that are already known
in MIB land over new creations).

/js

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

--005045016234f6816c049eb1d6ed-- From ietf@quittek.at Thu Mar 17 15:19:53 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3054F3A6B2C for ; Thu, 17 Mar 2011 15:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzLDgcVZZ8JS for ; Thu, 17 Mar 2011 15:19:52 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 401F83A69E5 for ; Thu, 17 Mar 2011 15:19:51 -0700 (PDT) Received: from [192.168.1.133] (HSI-KBW-091-089-140-037.hsi2.kabel-badenwuerttemberg.de [91.89.140.37]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0M25gB-1Pkb4924WB-00tyZs; Thu, 17 Mar 2011 23:21:18 +0100 References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> In-Reply-To: <20110316052854.GA2249@elstar.local> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Thu, 17 Mar 2011 23:21:18 +0100 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:kvBO0O0hd7oPXDC08S9n5nfd126kck0BL10OqWpACND Up+2nxUNtBBi0QT10FCTpsmgDPkFuVlKW9OLFS/HkS6ubh85hr hx1z4KnSkAgaJW8CCSyb0UHbbZeZ7kt9Vkc8N5Tjj0htpCekk2 9GFizDscmyGdC1W1viBbQG5E+Yip46M8gkOjJfFB86ZXIL9axQ 5EcGjp1sxTsEVRjDgbtQA== Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 22:19:53 -0000 Am 16.03.2011 um 06:28 schrieb Juergen Schoenwaelder: >=20 > I am likely confused what the goal is. If every power state set needs > to be registered with IANA, then why not simply use an enumeration? >=20 > simple-off(0), simple-sleep(1), simple-on(2), > dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... > acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203), = .. Yes, this is a good alternative. It is cleaner in the MIB because it uses just one index level. The other alternative was cleaner because it separates the set index = from the state index. Thanks, Juergen From ietf@quittek.at Thu Mar 17 15:19:56 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBB713A6B31 for ; Thu, 17 Mar 2011 15:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gTeLIztyvkZ for ; Thu, 17 Mar 2011 15:19:55 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 7F6D23A6B2C for ; Thu, 17 Mar 2011 15:19:55 -0700 (PDT) Received: from [192.168.1.133] (HSI-KBW-091-089-140-037.hsi2.kabel-badenwuerttemberg.de [91.89.140.37]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0LheLp-1PeXL94BAv-00mvHG; Thu, 17 Mar 2011 23:21:23 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-6--29264214 Message-Id: <543B7386-E907-4E20-A21D-A7F1560B0F9B@quittek.at> From: Juergen Quittek Date: Thu, 17 Mar 2011 23:21:22 +0100 To: John Parello (jparello) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:lvwGiJcFP/e0dRuGBXtoyvcVYYfrbbrtmxxmChSwH/B pawW6HTLSsyDXaARxiY33gCY3fYvvzREY0fu5wLdoHHj/v+Ghb nRxgBW+jMM1fvAZ1v/bK4lwKcXwcY7U3y4kJTod+Qjtbvz6yTo gVhMtfqLeax4ucOzt0CIMB1Ya+k8EpxLVrbXgyuDiVh7HV3i/R yiZZaAzZsYJNAqO7mm1KA== Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 22:19:56 -0000 --Apple-Mail-6--29264214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi John, Let's rather discuss here on the list than privately. If we have the terms "monitored" and "metered" as defined below, in what cases would we need the term "aware"? Can you give an example for such a case or scenario? Thanks, Juergen Am 17.03.2011 um 18:54 schrieb John Parello (jparello): > Hi Juergen, > =20 > Inline=85 > =20 > From: Juergen Quittek [mailto:ietf@quittek.at]=20 > Sent: Thursday, March 17, 2011 1:53 AM > To: John Parello (jparello) > Cc: Bruce Nordman; eman mailing list > Subject: Re: [eman] Terminology: Awareness > =20 > Hi John, > =20 > Let's start defining terms. > According you your email below and our discussions before I assume the = following: > =20 > [jp] we=92ll have to cover the separate values of power and energy? > =20 > "energy-metered"=20 > A device is energy-metered if some entity measures the energy = consumption of the device. This may happen internally or externally of = the device.=20 > =20 > "energy-aware"=20 > A device is enerhy-aware if the information that the devices is = metered is available at the device even if metering is conducted = externally. > =20 > "energy-monitored" > A device is energy-monitored if some energy monitoring system observes = metered energy values of a device. For self-managed devices, it may be = the device itself that monitors it. > =20 > Would you agree on these definitions or do you have other ones? > =20 > If yes, I am still waiting for someone explaining me what we need the = concept of "energy-awareness" for if we have "metered" and "monitored". > =20 > [jp] Well someone other than me I assume ;) - Aware covers your case = of defining monitoring as being monitored and self-metered (monitored?) = which would make your definition non terminal. We can discuss offline = if you like for efficiency.=20 > Jp > =20 > =20 > =20 --Apple-Mail-6--29264214 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi John,

Let's rather discuss = here on the list than privately.

If we have the = terms "monitored" and "metered" as defined below,
in what = cases would we need the term "aware"?

Can you = give an example for such a case or = scenario?

Thanks,

 =    Juergen


Am = 17.03.2011 um 18:54 schrieb John Parello (jparello):

Hi = Juergen,
From: Juergen Quittek = [mailto:ietf@quittek.at] 
Sent: Thursday, March 17, 2011 = 1:53 AM
To: John Parello = (jparello)
Cc: Bruce Nordman; eman mailing = list
Subject: Re: [eman] Terminology: = Awareness
Hi = John,
Let's start defining = terms.
According you your email = below and our discussions before I assume the = following:
 
[jp] we=92ll have to cover the = separate values of power and energy?
A device is energy-metered if some entity measures the energy = consumption of the device. This may happen internally or externally = of the device. 
A device is enerhy-aware if the information that the devices is = metered is available at the device even if metering is conducted = externally.
A device is = energy-monitored if some energy monitoring system observes metered = energy values of a device. For self-managed devices, it may be the = device itself that monitors it.
 
Would you = agree on these definitions or do you have other = ones?
If yes, I am still = waiting for someone explaining me what we need the concept of = "energy-awareness" for if we have "metered" and = "monitored".
 
[jp] Well someone other than me I = assume ;)   - Aware covers your case of defining monitoring as = being monitored and self-metered (monitored?) which would make your = definition non terminal.  We can discuss offline if you like for = efficiency. 
X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:EFKDfjkdnRxYUGFIYOkjg8kbjmKtHkU28PvpPkmWaYn KWyZJa/77p+OX6o7FWuzPzC74FSdCqXsGij8x+0BMQZrcJYNtS mCEzl4vahsFYwOnNMOCL6TFqngsIuZ8G75TsWFBwQxHjy5+cBV 5mmJ3TLykopmfriT1THT/GMm3hllYeRBv7+yCRwqjMbLFQVz8Y noZgLIDYQhcDi6GfO5lWQ== Cc: emanmailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 22:19:59 -0000 Dear John, Bill, and all, I agree, that it does not make sense to combine states of a battery with = state of a PC. Imaging you would also consider a fan. The fan may be = still running while the PC is already off or sleeping until the = temperature is low enough. If we combined states, we would end up with something like - off - off-charging - off-fan-on - off-charging-fan-on - sleep - sleep-charging - sleep-charging-fan-on etc. And there may be more then just fan and battery to be considered. Thus, we should be able to report on components of a device separately, - PC - fan - battery - etc. The ENTITY MIB gives us means for indicating that all in contained in = the same physical device. It also gives us the list of contained = entities. And reporting of power states should be independent for each = entity. Thanks, Juergen Am 17.03.2011 um 19:25 schrieb Mielke, William F (Bill): >> John Parello wrote: >>=20 >> So from a device object point of view no - you probably charge the >> device. Is the device sleeping and the battery charging or is=20 >> the device >> simply charging. >>=20 >> It's a tricky relationship that needs to be modeled. >=20 > I agree that it is tricky. >=20 > I think that the answer is tied to how the device is modeled. If we = present the device as an entity in its own right, as I think most people = would argue we should, then at that level your point makes sense to me. = If we also model not only the device but also it's contained hierachy of = components wherein the battery becomes a unique entity then at that = level I would argue that the domain specific set of "battery states" = applies only at the battery level. >=20 > Given this your question starts to lead me down the path of thinking = about parent/child relationships and containment hierachies. Along with = that discussion will also come the inevitable question of whether and = how things like power states "aggregate" up the containment hierachy. I = can imagine coming up with rules for how things like the common states = (on, off, low power mode) might aggregate up the hierachy in a = meaningful sense, but the device specific states not as much. >=20 > At the abstract level of an "iPhone" I would argue that a state like = "charging" doesn't make sense even though you point out that in common = language usage it would. Literally speaking, to say that your iPhone is = charging means that it contains a battery that is charging. The term = "charging" only applies to the specific domain of the battery and to the = specific contained entity that is the battery. >=20 > In my view of things, and I am open to other perspectives, the way = that a human operator would identify that the iPhone is "charging" is = that they would have to specifically drill down into the iPhone entity, = discover that it contained a battery, and observe that the battery is in = the charging state. It is less clear to me how one takes what I just = described and codifies it into an application, but obviously it can be = done so long as the code in question knows to explicitly look for this = relationship. >=20 > Now, one possible approach if we actually feel that aggegrating device = specific component states up the containment hierarchy is important is = to introduce the concept of a power state vector similar to what = JuergenS was talking about (but in a separate context). Abstract = entities which are themselves composites of simple entities could report = a vector of all the contained domain specific states of all of it's = simple "leaf components". In practice I would expect this to become = quite large and unwieldly and so I would argue against such an approach, = but it is certainly possible. Thus the domain specific state of a = composite entity is actually the union of the domain specific state of = the composite entity itself along with the domain specific states of all = of its constituent components. >=20 > Does that make sense? >=20 > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 >=20 > "Live like you're going to die tomorrow. > Learn like you're going to live forever." >=20 > - Albert Einstein > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From ietf@quittek.at Thu Mar 17 15:20:07 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F833A6A58 for ; Thu, 17 Mar 2011 15:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbvHwtyEWQmV for ; Thu, 17 Mar 2011 15:20:06 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 442993A69E5 for ; Thu, 17 Mar 2011 15:20:06 -0700 (PDT) Received: from [192.168.1.133] (HSI-KBW-091-089-140-037.hsi2.kabel-badenwuerttemberg.de [91.89.140.37]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MSr7l-1QSE4o3uEv-00Rq5O; Thu, 17 Mar 2011 23:21:28 +0100 References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at><4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local><4D80F7D2.1040200@cisco.com> <20110317071828.GA2375@elstar.local><4D81F720.8030705@cisco.com> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299EB3@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D824B8A.3010701@cisco.com> In-Reply-To: <4D824B8A.3010701@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Thu, 17 Mar 2011 23:21:27 +0100 To: Russ White X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:9VM6gbAj/5cL/NTJQTNEQIJ4kW8S9pGGwIaQy5L8Zqo /lOJOPuZaQtd8pEO7t7f0teP6FBS/7sqMTGzppzYmTy+yNWQs1 Y7l53dDA3YFB8gTPWW09gZYCYDQsRccOv2UQZ8o0VFyI0h0rvt VhcrhEw3bgxd4tiINy4jGfXPbRuYlswQ9ZSEs6W6JWEQ6bIz+8 vYADK4V2lrcOptGMiuvpw== Cc: emanmailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 22:20:07 -0000 Hi Russ, I think there is more devices than just batteries which need different = power states. For example fans, lamps, air conditionings, etc. So, I would like to not have the number of sets of power states be = limited. Thanks, Juergen Am 17.03.2011 um 18:57 schrieb Russ White: >> So from a device object point of view no - you probably charge the >> device. Is the device sleeping and the battery charging or is the = device >> simply charging. >=20 > Well, there was a discussion a while back on the list about including > battery state for various reasons... I was just thinking that = batteries > exist on some devices and not on others that are otherwise identical. >=20 > So, if we _wanted_ to include battery, this seems like a good way to = do > it. If we don't, then... I'm fine with dropping it, and going to two > sections. I know that in the MANET world battery power is really > important --you actually base routing on battery power remaining, for > instance. But I wouldn't want to have one model for a wireless AP > without a battery, and another with a battery... >=20 > :-) >=20 > Russ >=20 > --=20 > riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone >=20 > If the whole universe has no meaning, we should never have found out > that it has no meaning: just as, if there were no light in the = universe > and therefore no creatures with eyes, we should never know it was = dark. > Dark would be without meaning. -C. S. Lewis >=20 >=20 From jparello@cisco.com Thu Mar 17 16:22:51 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064563A6B48 for ; Thu, 17 Mar 2011 16:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E+RIRIPV+tz for ; Thu, 17 Mar 2011 16:22:46 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 96ABF3A69E5 for ; Thu, 17 Mar 2011 16:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=15575; q=dns/txt; s=iport; t=1300404254; x=1301613854; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=h4g2NQfK9ecq2CuS8CYSbz1EWtlKAGkkUwIIVZ5hTmk=; b=CRXWrt4nYOYLYsbBunBuN3J+sc6xFQsU+f+ZlszTpNGkyN3EF908EmNC qqsuaPt3XT9V0cSarsXTggr1ZJX/la9r8l6F3s9jKTtTufGlc8v6wvHtJ QrSgYRlBdSHkGCJrhA6YyVWdf5LCmirUc0XHyAL9+WaS3gvzl4ccOhQ3t c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAO40gk2tJV2b/2dsb2JhbACCW5VIjTJ3pwOcF4VjBIUviwI X-IronPort-AV: E=Sophos;i="4.63,202,1299456000"; d="scan'208,217";a="226692919" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 17 Mar 2011 23:24:13 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2HNO42I017618; Thu, 17 Mar 2011 23:24:13 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 16:24:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE4FA.6B017DDE" Date: Thu, 17 Mar 2011 16:23:21 -0700 Message-ID: In-Reply-To: <543B7386-E907-4E20-A21D-A7F1560B0F9B@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: Awareness Thread-Index: Acvk8cCgImOstOgCTlGwwrUQDxf8KQACHu0Q References: <543B7386-E907-4E20-A21D-A7F1560B0F9B@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" X-OriginalArrivalTime: 17 Mar 2011 23:24:10.0137 (UTC) FILETIME=[6B2EB090:01CBE4FA] Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 23:22:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE4FA.6B017DDE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Fine see my previous emails. I've explained it with use cases already. =20 Jp =20 From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Thursday, March 17, 2011 3:21 PM To: John Parello (jparello) Cc: Bruce Nordman; eman mailing list Subject: Re: [eman] Terminology: Awareness =20 Hi John, =20 Let's rather discuss here on the list than privately. =20 If we have the terms "monitored" and "metered" as defined below, in what cases would we need the term "aware"? =20 Can you give an example for such a case or scenario? =20 Thanks, =20 Juergen =20 =20 Am 17.03.2011 um 18:54 schrieb John Parello (jparello): Hi Juergen, =20 Inline... =20 From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Thursday, March 17, 2011 1:53 AM To: John Parello (jparello) Cc: Bruce Nordman; eman mailing list Subject: Re: [eman] Terminology: Awareness =20 Hi John, =20 Let's start defining terms. According you your email below and our discussions before I assume the following: =20 [jp] we'll have to cover the separate values of power and energy? =20 "energy-metered"=20 A device is energy-metered if some entity measures the energy consumption of the device. This may happen internally or externally of the device.=20 =20 "energy-aware"=20 A device is enerhy-aware if the information that the devices is metered is available at the device even if metering is conducted externally. =20 "energy-monitored" A device is energy-monitored if some energy monitoring system observes metered energy values of a device. For self-managed devices, it may be the device itself that monitors it. =20 Would you agree on these definitions or do you have other ones? =20 If yes, I am still waiting for someone explaining me what we need the concept of "energy-awareness" for if we have "metered" and "monitored". =20 [jp] Well someone other than me I assume ;) - Aware covers your case of defining monitoring as being monitored and self-metered (monitored?) which would make your definition non terminal. We can discuss offline if you like for efficiency.=20 Jp =20 =20 =20 =20 ------_=_NextPart_001_01CBE4FA.6B017DDE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Fine see my previous emails.  I’ve explained = it with use cases already.

 

Jp

 

From:= Juergen = Quittek [mailto:ietf@quittek.at]
Sent: Thursday, March 17, 2011 3:21 PM
To: John Parello (jparello)
Cc: Bruce Nordman; eman mailing list
Subject: Re: [eman] Terminology: Awareness

 

Hi John,

 

Let's rather discuss here on the list than = privately.

 

If we have the terms "monitored" and "metered" as defined below,

in what cases would we need the term = "aware"?

 

Can you give an example for such a case or = scenario?

 

Thanks,

 

    Juergen

 

 

Am 17.03.2011 um 18:54 schrieb John Parello = (jparello):



Hi Juergen,

 

Inline…

 

From:=  Juergen = Quittek [mailto:ietf@quittek.at] 
Sent: Thursday, = March 17, 2011 1:53 AM
To: John Parello (jparello)
Cc: Bruce = Nordman; eman mailing list
Subject: Re: = [eman] Terminology: Awareness

 

Hi John,

 

Let's start defining terms.

According you your email below and our discussions = before I assume the following:

 

[jp] we’ll have to cover the separate values of = power and energy?

 

"energy-metered" 

A device is energy-metered if some entity measures = the energy consumption of the device. This may happen internally or = externally of the device. 

 

"energy-aware" 

A device is enerhy-aware if the information that = the devices is metered is available at the device even if metering is conducted externally.

 

"energy-monitored"

A device is energy-monitored if some energy = monitoring system observes metered energy values of a device. For self-managed = devices, it may be the device itself that monitors it.

 

Would you agree on these definitions or do you have = other ones?

 

If yes, I am still waiting for someone explaining = me what we need the concept of "energy-awareness" for if we have "metered" and "monitored".

 

[jp] Well someone other than me I assume ;)   - = Aware covers your case of defining monitoring as being monitored and = self-metered (monitored?) which would make your definition non terminal.  We can discuss offline if you like for efficiency. 

Jp

 

 

 

 

------_=_NextPart_001_01CBE4FA.6B017DDE-- From chrisv@cyberswitching.com Thu Mar 17 16:34:12 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DD733A6B4C for ; Thu, 17 Mar 2011 16:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.487 X-Spam-Level: X-Spam-Status: No, score=-7.487 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAiv0uVzP1V1 for ; Thu, 17 Mar 2011 16:34:11 -0700 (PDT) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by core3.amsl.com (Postfix) with ESMTP id 54C083A6B4B for ; Thu, 17 Mar 2011 16:34:11 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o142.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id bca928d4.0.23272.00-369.52362.p01c11o142.mxlogic.net (envelope-from ); Thu, 17 Mar 2011 17:35:40 -0600 (MDT) X-MXL-Hash: 4d829acc7c535638-640f58bf2d7f622d46c49809189458af5df18163 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 16:33:51 -0700 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 7C1B3AB426D; Thu, 17 Mar 2011 16:35:39 -0700 (PDT) Date: Thu, 17 Mar 2011 16:35:39 -0700 From: chrisv@cyberswitching.com To: Juergen Quittek Message-ID: <20110317233539.GA2891@cslinux-build01.cyberswitching.local> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 17 Mar 2011 23:33:51.0484 (UTC) FILETIME=[C5B133C0:01CBE4FB] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XYJHFtupD_QA:10 a=PO4OC_ceetEA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=SV] X-AnalysisOut: [mr_peUovvdksjS6zQA:9 a=OzKOoA9Wk76_JS8H40MA:7 a=_BKeQGDBY3] X-AnalysisOut: [6saPbl3qPbeTJ2SUgA:4 a=CjuIK1q_8ugA:10] Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 23:34:12 -0000 On Thu, Mar 17, 2011 at 11:21:18PM +0100, Juergen Quittek wrote: > Am 16.03.2011 um 06:28 schrieb Juergen Schoenwaelder: > > > > I am likely confused what the goal is. If every power state set needs > > to be registered with IANA, then why not simply use an enumeration? > > > > simple-off(0), simple-sleep(1), simple-on(2), > > dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... > > acpi-offHard(200), acpi-offSoft(201), hibernate(202), sleepDeep(203), .. > > Yes, this is a good alternative. > It is cleaner in the MIB because it uses just one index level. > The other alternative was cleaner because it separates the set index > from the state index. RFC 2578, Section 7.1.1. Integer32 and INTEGER Finally, a label for a named-number enumeration must consist of one or more letters or digits, up to a maximum of 64 characters, and the initial character must be a lower-case letter. (However, labels longer than 32 characters are not recommended.) Note that hyphens are not allowed by this specification (except for use by information modules converted from SMIv1 which did allow hyphens). Just hoping you're not relying on the "-" character to help with this. I'm still not quite following how this is supposed to work. Is the plan to have a single object that can take in all of these enumerated values? If so, how would an entity report its state using multiple representations (simple-off, dmtf-powerOff, and acpi-offHard all being equivalent) from the same OID interface? It seems like you still need multiple interfaces, one for each representation, otherwise the various representations start clobbering each other. Chris From ietf@quittek.at Thu Mar 17 23:20:40 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620113A6783 for ; Thu, 17 Mar 2011 23:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL-wFTU0-tWr for ; Thu, 17 Mar 2011 23:20:39 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id BE9483A6405 for ; Thu, 17 Mar 2011 23:20:38 -0700 (PDT) Received: from [192.168.1.133] (HSI-KBW-091-089-140-037.hsi2.kabel-badenwuerttemberg.de [91.89.140.37]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lnlst-1PYXFE2QLn-00hjTu; Fri, 18 Mar 2011 07:22:05 +0100 References: <543B7386-E907-4E20-A21D-A7F1560B0F9B@quittek.at> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-7--423983 Message-Id: <65669F97-B39A-4EAD-9068-A4603E14317F@quittek.at> From: Juergen Quittek Date: Fri, 18 Mar 2011 07:22:03 +0100 To: John Parello (jparello) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:1I/+4a8sC3BjmiVHMAf2X8Q2UToUyvexgaGs+D5oIWA Lg2we2HmvzX0erPFj2CoC7R24MSxP9RruBJ8aF5kBBcja2FY7V J+k7ESZoglrgRVSPDU/JWkJItOZwgEWrGxmJ2Yg0rZ5XAZt3xL fYGCtopgoM3i29OR3CZgfyX37MbAggmvXxvF++/xgYjx3h8xiH SgbOLRdXhxxj3kLLvgzOg== Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 06:20:40 -0000 --Apple-Mail-7--423983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi John, Am 18.03.2011 um 00:23 schrieb John Parello (jparello): > Fine see my previous emails. I=92ve explained it with use cases = already. I guess you refer to this text: > IF you implement a set of objects we define in this WG you are aware = of your energy. You may or may not be monitored by someone accessing the = object. You can=92t assume just because you implement the objects = there=92s some miraculous observer making SNMP request to you or = monitoring you. You may never be contacted but you are still aware. This is just a definition of "aware" not a use case. I still would like = to have someone pointing me at any case where it is useful to know = whether a devices is "aware" or not "aware". I see cases where it is = important to know if a device is "metered" or "monitored" (as defined = below), but I fail to see a cases where it is useful to know if a = device is "aware". Without a good case for it we do not need the term "aware". BTW: I don't think your definition above is 100% correct. You say "IF = you implement a set of objects we define in this WG you are aware of = your energy". But you may implement the objects as a "parent" and report = on other devices energy. You can do so without having your own energy = metered, i.e. without being "aware of your energy". You would then be = just "aware" of OTHER devices energy.=20 Thanks, Juergen > =20 > Jp > =20 > From: Juergen Quittek [mailto:ietf@quittek.at]=20 > Sent: Thursday, March 17, 2011 3:21 PM > To: John Parello (jparello) > Cc: Bruce Nordman; eman mailing list > Subject: Re: [eman] Terminology: Awareness > =20 > Hi John, > =20 > Let's rather discuss here on the list than privately. > =20 > If we have the terms "monitored" and "metered" as defined below, > in what cases would we need the term "aware"? > =20 > Can you give an example for such a case or scenario? > =20 > Thanks, > =20 > Juergen > =20 > =20 > Am 17.03.2011 um 18:54 schrieb John Parello (jparello): >=20 >=20 > Hi Juergen, > =20 > Inline=85 > =20 > From: Juergen Quittek [mailto:ietf@quittek.at]=20 > Sent: Thursday, March 17, 2011 1:53 AM > To: John Parello (jparello) > Cc: Bruce Nordman; eman mailing list > Subject: Re: [eman] Terminology: Awareness > =20 > Hi John, > =20 > Let's start defining terms. > According you your email below and our discussions before I assume the = following: > =20 > [jp] we=92ll have to cover the separate values of power and energy? > =20 > "energy-metered"=20 > A device is energy-metered if some entity measures the energy = consumption of the device. This may happen internally or externally of = the device.=20 > =20 > "energy-aware"=20 > A device is enerhy-aware if the information that the devices is = metered is available at the device even if metering is conducted = externally. > =20 > "energy-monitored" > A device is energy-monitored if some energy monitoring system observes = metered energy values of a device. For self-managed devices, it may be = the device itself that monitors it. > =20 > Would you agree on these definitions or do you have other ones? > =20 > If yes, I am still waiting for someone explaining me what we need the = concept of "energy-awareness" for if we have "metered" and "monitored". > =20 > [jp] Well someone other than me I assume ;) - Aware covers your case = of defining monitoring as being monitored and self-metered (monitored?) = which would make your definition non terminal. We can discuss offline = if you like for efficiency.=20 > Jp > =20 > =20 > =20 > =20 --Apple-Mail-7--423983 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi John,

Am 18.03.2011 um 00:23 = schrieb John Parello (jparello):

Fine see my previous emails. =  I=92ve explained it with use cases = already.

I = guess you refer to this text:

IF you implement a set = of objects we define in this WG you are aware of your energy. You may or = may not be monitored by someone accessing the object. You can=92t assume = just because you implement the objects there=92s some miraculous = observer making SNMP request to you or monitoring you. You may never be = contacted but you are still = aware.

This is just a definition = of "aware" not a use case. I still would like to have someone pointing = me at any case where it is useful to know whether a devices is "aware" = or not "aware".  I see cases where it is important to know if a = device is "metered" or "monitored" (as defined below), but I fail to see = a cases where  it is useful to know if a device is = "aware".

Without a good case for it  we do = not need the term "aware".


BTW: = I don't think your definition above is 100% correct. You say "IF you = implement a set of objects we define in this WG you are aware of your = energy". But you may implement the objects as a "parent" and report on = other devices energy. You can do so without having your own energy = metered, i.e. without being "aware of your energy". You would then be = just "aware" of OTHER devices = energy. 

Thanks,

&n= bsp;   Juergen

From: Juergen Quittek = [mailto:ietf@quittek.at] 
Sent: Thursday, March 17, 2011 = 3:21 PM
To: John Parello = (jparello)
Cc: Bruce Nordman; eman mailing = list
Subject: Re: [eman] Terminology: = Awareness
Hi = John,
Let's rather discuss here = on the list than privately.
 
If we have the = terms "monitored" and "metered" as defined = below,
in what cases would we = need the term "aware"?
 
Can you give = an example for such a case or scenario?
 
   =  Juergen
Am 17.03.2011 um 18:54 = schrieb John Parello (jparello):


Hi Juergen,
Inline=85
Juergen Quittek [mailto:ietf@quittek.at] 
Sent: Thursday, March 17, 2011 = 1:53 AM
To: John Parello = (jparello)
Cc: Bruce Nordman; eman mailing = list
Subject: Re: [eman] Terminology: = Awareness
 
Hi = John,
Let's start = defining terms.
According you your email below and our discussions before I = assume the following:
[jp] we=92ll have to cover the separate values of = power and energy?
"energy-metered" 
A device is energy-metered if some entity measures the energy = consumption of the device. This may happen internally or externally = of the device. 
 
"energy-aware" 
A device is enerhy-aware if the information that the devices is = metered is available at the device even if metering is conducted = externally.
 
"energy-monitored"
A device is energy-monitored if some energy monitoring system = observes metered energy values of a device. For self-managed devices, it = may be the device itself that monitors = it.
Would you = agree on these definitions or do you have other = ones?
If yes, I am = still waiting for someone explaining me what we need the concept of = "energy-awareness" for if we have "metered" and = "monitored".
[jp] Well someone other than me I assume = ;)   - Aware covers your case of defining monitoring as being = monitored and self-metered (monitored?) which would make your definition = non terminal.  We can discuss offline if you like for = efficiency. 
 
 

<= /div>= --Apple-Mail-7--423983-- From j.schoenwaelder@jacobs-university.de Fri Mar 18 01:59:24 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7483A67FC for ; Fri, 18 Mar 2011 01:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr3QIaguzIXZ for ; Fri, 18 Mar 2011 01:59:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 85D853A679C for ; Fri, 18 Mar 2011 01:59:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAF8CC0016; Fri, 18 Mar 2011 10:00:49 +0100 (CET) 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 oCJa9y4LbSzz; Fri, 18 Mar 2011 10:00:49 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0271C0007; Fri, 18 Mar 2011 10:00:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A1A641702803; Fri, 18 Mar 2011 10:00:48 +0100 (CET) Date: Fri, 18 Mar 2011 10:00:48 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110318090048.GA6963@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, eman@ietf.org References: <20110308155405.GA12027@cslinux-build01.cyberswitching.local> <20110317113158.GB3733@elstar.local> <20110317154356.GA25808@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110317154356.GA25808@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] Use of ENTITY-MIB in EMAN (version 01) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 08:59:24 -0000 On Thu, Mar 17, 2011 at 08:43:56AM -0700, chrisv@cyberswitching.com wrote: > On Thu, Mar 17, 2011 at 12:31:58PM +0100, Juergen Schoenwaelder wrote: > > On Tue, Mar 08, 2011 at 07:54:05AM -0800, chrisv@cyberswitching.com wrote: > > > > > The conclusion that I'm coming away with at this point is that > > > ENTITY-MIB was designed to model physical entities, where an "entity" is > > > some construct that is intended for management purposes. Logical > > > entities are not handled by entLogicalTable, which instead manages > > > logical contexts (slight difference in that a context is not intended to > > > be directly managed.) So for EMAN's purposes, a mechanism to manage > > > both physical and logical entities is needed. This may be an extension > > > of ENTITY-MIB (are other WG's needing something like this?) or may be a > > > separate structure wholy contained in the EMAN MIB schema. > > > > I request that we change the terminology to avoid the use of the term > > "logical entity" with two different meanings. Since the ENTITY-MIB has > > a define meaning of "logical entity", I think EMAN should use a > > different term to refer to "functional groupings". > > Rather than "functional groupings," which does not reflect the managed > entity nature of the end goal, how about the following breakdown > instead? > > 1. Physical entity - ENTITY-MIB > 2. Logical entity - ENTITY-MIB > 3. Virtual entity - EMAN > 4. Power entity - EMAN > > A "power entity" can either refer to a "physical entity" or a "virtual > entity." A "virtual entity" is anything that behaves similar to a > "physical entity" but which has no actual physical nature, like a > virtual machine or an outlet gang or a daemon running on the system. > > This clarifies the point that we need to manage "virtual entities" just > like we would "physical entities." The term "functional groupings" > makes it seem like we're bundling things just for abstract purposes > only, whereas there is a deeper use case being answered in reality. The ENTITY-MIB has been designed to be relatively generic. If arbitrary groupings of physical entities need to be added, we better do it in a generic way instead of inventing this N times over again. > > If there is a need to represent "functional groupings", then we can > > either use SNMP contexts (note that the entLPMappingTable allows to > > map physical entities into logical contexts), although that might not > > be sufficient, or we could extend the ENTITY-MIB by providing a > > functional grouping mechanism (perhaps designing an indexing scheme > > that makes it easy to refer to both physical entities and functional > > groupings of physical entities), or we might follow the path of > > creating a data model only loosely coupled to the ENTITY-MIB (but then > > I think we should avoid overlap as much as possible and for the > > overlap that is not avoidable, we need to explain how this is going to > > be implemented). > > Since ENTITY-MIB was specifically designed to represent a physical > instantiation of a system, it does not handle virtual entities (as > described above) properly. That is not what I said. > I would like to see it extended to solve > the cases that we are grappling with here; however, such an undertaking > would be outside of EMAN's scope and delay the development and release > of EMAN-MIB significantly. Please feel free to let the ENTITY-MIB > working group know that some changes are desired in their model and let > them begin working on it as a separate undertaking -- I am happy to help > explain use cases if needed. But we need to focus on developing > something that will work for EMAN in a timely manner, and already have > solutions for doing that. The process argument and that claim that extending the ENTITY-MIB is going to be way slower than EMAN can tolerate. Been there before. > In both draft-verges and draft-parello (now > draft-ietf-eman-energy-aware), we create such a data model that > loosely couples with ENTITY-MIB but does not rely on it. I'm > hearing that you may be coming around to the same conclusion that > ENTITY-MIB won't properly handle these "virtual entities" that EMAN > needs to support, so would either of these proposed models in the > drafts fit your needs? If not, what needs to change? No, virtual entities are just fine (or we have different definition what virtual entities means). I see a large duplication of the ENTITY-MIB in several of the MIBs flowing around (sometimes lacking essential pieces that are in the ENTITY-MIB) and I fail to see why that can be desirable. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 18 02:07:21 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9903A680E for ; Fri, 18 Mar 2011 02:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4T06dWIR7EZ for ; Fri, 18 Mar 2011 02:07:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E6E7A3A679C for ; Fri, 18 Mar 2011 02:07:20 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2C9BC0012; Fri, 18 Mar 2011 10:08:49 +0100 (CET) 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 Pho18Q0Kxth7; Fri, 18 Mar 2011 10:08:49 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8225C0010; Fri, 18 Mar 2011 10:08:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B3779170292B; Fri, 18 Mar 2011 10:08:48 +0100 (CET) Date: Fri, 18 Mar 2011 10:08:48 +0100 From: Juergen Schoenwaelder To: "Mielke, William F (Bill)" Message-ID: <20110318090848.GA7027@elstar.local> Mail-Followup-To: "Mielke, William F (Bill)" , Russ White , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <4D80EB27.4080900@cisco.com> <20110316174246.GB1468@elstar.local> <4D80F7D2.1040200@cisco.com> <20110317071828.GA2375@elstar.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299E4B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299E4B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 09:07:21 -0000 On Thu, Mar 17, 2011 at 11:48:20AM -0500, Mielke, William F (Bill) wrote: > > Juergen Schoenwaelder wrote: > > > > Reporting different states for different components of the system > > makes sense to me. Reporting a vector of states for a single component > > does not make much sense to me. > > > > +1 on the observation that power states are actually tied to the components of a system and not the system as a whole (although that too may have a power state). > > +1 on the observation that different components will need to have different states to make those states "meaningful" depending on the type of the component. > > Regading your vector comment I think that you have misinterpreted Mouli's comment. When he said "vector" another way of saying what he meant would be "tuple", because he was talking about the fundamental idea in JourgenQ's proposal where the "state" of a component is actually a tuple (i.e. a vector) which is composed of "(x1,y1)" where x1 actually specifies the state type (i.e. which set or enumeration applies) and y1 specifies the actual state (i.e. which value within the corresponding set or enumeration has been selected). Please correct me, Mouli, if this was not your meaning. > > In this context you seem to be using the term "vector" to mean "a list of such states" for each component which I don't think anyone has proposed. I think that there is a simply a miscommunication here based on the use of the term "vector". If I misunderstood something, I apologize. However, as mentioned before, I think (x1,y1) can simply be z = (x1*100+y1) or something like that, making MIB design, IANA allocations, and SNMP on the wire more efficient. That is what I meant with "encoding". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 18 02:13:13 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052D53A6A60 for ; Fri, 18 Mar 2011 02:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDf-VCnTwJv2 for ; Fri, 18 Mar 2011 02:13:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0C89E3A680E for ; Fri, 18 Mar 2011 02:13:12 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDB2AC0010; Fri, 18 Mar 2011 10:14:40 +0100 (CET) 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 8KDJQZTDsYp8; Fri, 18 Mar 2011 10:14:40 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DAD5C0007; Fri, 18 Mar 2011 10:14:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E2B9917029CE; Fri, 18 Mar 2011 10:14:39 +0100 (CET) Date: Fri, 18 Mar 2011 10:14:39 +0100 From: Juergen Schoenwaelder To: "John Parello (jparello)" Message-ID: <20110318091439.GB7027@elstar.local> Mail-Followup-To: "John Parello (jparello)" , "Romascanu, Dan (Dan)" , Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@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 mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 09:13:13 -0000 On Thu, Mar 17, 2011 at 08:58:54AM -0700, John Parello (jparello) wrote: > That may also handle the issue of subcomponents? Although I'm not sure > of the implications of this as yet... A state is per component. If a component has subcomponents, they can report their own state. > One different issue I'd like to see addressed is whether or not > setting a state in one name space implies a setting to an equivalent > state in another name space. The idea is that a component supports a set of states. If you set a state it does not support, you will get an inconsistentValue error or something close to that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 18 02:14:25 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AE33A69F9 for ; Fri, 18 Mar 2011 02:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LpGfxJj9oiS for ; Fri, 18 Mar 2011 02:14:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C2C683A682E for ; Fri, 18 Mar 2011 02:14:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90E69C0016; Fri, 18 Mar 2011 10:15:53 +0100 (CET) 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 aipUUuLouUsA; Fri, 18 Mar 2011 10:15:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C20A8C0010; Fri, 18 Mar 2011 10:15:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 981261702A21; Fri, 18 Mar 2011 10:15:52 +0100 (CET) Date: Fri, 18 Mar 2011 10:15:52 +0100 From: Juergen Schoenwaelder To: Ted Ghose Message-ID: <20110318091552.GC7027@elstar.local> Mail-Followup-To: Ted Ghose , Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@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 mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 09:14:25 -0000 On Thu, Mar 17, 2011 at 11:29:19AM -0700, Ted Ghose wrote: > If the proposal here to display any collection of any states that people > will go and register in IANA, are we not loosing the main focus of > standardizing, and what that means. > You were arguing else where "what's the state of the 'device off battery > charging' be", and I agree with you. > But without standardizing some basic EMAN states, but > displaying wide varieties of state of overlapping and even conflicting > meaning registered in IANA, what will be a real value add. > Different devices some how or other does shows different states they > have implemented, anyway. > I'd urge the WG to bring some standard and avoid the explosion of power > states in IANA. Every IANA registry has defined rules how something can be added. The WG would have to define the rules and they can be restrictive. IANA control does not imply explosion of power states. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 18 02:16:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F263A680E for ; Fri, 18 Mar 2011 02:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbjXrABnb++E for ; Fri, 18 Mar 2011 02:16:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F27E53A679C for ; Fri, 18 Mar 2011 02:16:09 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1F81C0016; Fri, 18 Mar 2011 10:17:38 +0100 (CET) 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 1sg8mABGycgH; Fri, 18 Mar 2011 10:17:38 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F4C4C0007; Fri, 18 Mar 2011 10:17:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 135B61702A64; Fri, 18 Mar 2011 10:17:38 +0100 (CET) Date: Fri, 18 Mar 2011 10:17:38 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20110318091737.GD7027@elstar.local> Mail-Followup-To: Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 09:16:11 -0000 On Thu, Mar 17, 2011 at 11:21:18PM +0100, Juergen Quittek wrote: > The other alternative was cleaner because it separates the set index > from the state index. But this separation does not add any real value since a state value is only meaningful together with the set index. Hence, by making them one thing, you make a number of errors simply impossible and you gain efficiency. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 18 02:18:24 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03E93A682E for ; Fri, 18 Mar 2011 02:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCpRzJWkvaHZ for ; Fri, 18 Mar 2011 02:18:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DB5F83A679C for ; Fri, 18 Mar 2011 02:18:23 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABDC5C0016; Fri, 18 Mar 2011 10:19:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N6Z2uRU8W0L1; Fri, 18 Mar 2011 10:19:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07FBBC0007; Fri, 18 Mar 2011 10:19:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F03581702AAC; Fri, 18 Mar 2011 10:19:51 +0100 (CET) Date: Fri, 18 Mar 2011 10:19:51 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110318091951.GE7027@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110317233539.GA2891@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 09:18:24 -0000 On Thu, Mar 17, 2011 at 04:35:39PM -0700, chrisv@cyberswitching.com wrote: > I'm still not quite following how this is supposed to work. Is the plan > to have a single object that can take in all of these enumerated values? > > If so, how would an entity report its state using multiple > representations (simple-off, dmtf-powerOff, and acpi-offHard all being > equivalent) from the same OID interface? It seems like you still need > multiple interfaces, one for each representation, otherwise the various > representations start clobbering each other. A component of a device reports one possible value, the value that is in the set of states it supports natively. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 18 02:30:31 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFBB3A682E for ; Fri, 18 Mar 2011 02:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcLiPL-Qst7W for ; Fri, 18 Mar 2011 02:30:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 990A03A680E for ; Fri, 18 Mar 2011 02:30:29 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 113C8C0010; Fri, 18 Mar 2011 10:31:58 +0100 (CET) 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 9GYG8hwoJlDt; Fri, 18 Mar 2011 10:31:57 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10CF5C0016; Fri, 18 Mar 2011 10:31:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 55B981702AFE; Fri, 18 Mar 2011 10:31:56 +0100 (CET) Date: Fri, 18 Mar 2011 10:31:55 +0100 From: Juergen Schoenwaelder To: "Mielke, William F (Bill)" Message-ID: <20110318093154.GF7027@elstar.local> Mail-Followup-To: "Mielke, William F (Bill)" , Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299E1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507299E1D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 09:30:31 -0000 On Thu, Mar 17, 2011 at 11:24:09AM -0500, Mielke, William F (Bill) wrote: > Now one element of your proposal is to have these sets of power states (each effectively an enumerated type) be "standardized" by having them registered at IANA. One advantage of requiring IANA registration is that the resulting states would at least be well defined and relatively stable while allowing for evolution in the face of changing technologies and vendor implementation choices. > > Now let me ask you a more fundamental question. Once we open the door to having an extensible set of enumerated types as your proposal does, from the perspective of "enabling more effect management" of a given device does registering those enumerated types with IANA actually add anything over the alternative of having those enumerated types being dynamically discoverable through the MIB? I am not arguing this point one way or the other, but I would be interested in hearing your thoughts on the topic. The registration procedure needs to be spelled out and this will regulate how easy or painful it is to register new states. If we allow arbitrary registrations, then all we have is a central registry to lookup what the value 42 means (which is still better than having nothing). I personally would argue for more restrictive IANA rules. > The main difference that I can see from an implementation perspective is that with your proposal the vendors of management applications could then write code which is "hard coded" to one or more specific sets of states and possibly have logic which is "hard bound" to the semantics associated with the states being registered with IANA. > > This then raises a follow-up question. When these sets of states are registered with IANA are there also specific definitions of the semantics that are tied to the states being so registered, or is IANA only managing the set of integer values that are associated each of the enumerated power states? In other words, is the interpretation of what those states actually mean in practice still an implementation specific detail decide at the whim of each vendor? It all depends on the rules given to IANA. I would expect some controlled procedure for new registrations and I would assume that the procedure requires to document what a new state means. The WG can even create templates for this purpose, a common way to deal with such IANA things. > One final question, given that you envision different sets of power states what are the core variabilities at play that you believe would drive the definition of a new power state set? Over time would these sets be driven by technology specific differences, vender specific differences, both, or something entirely different? I think gaining more clarity on why we would even want a new set of states may shed light on how best to organize things to support that type of evolution over time. As far as I understand things, we do have defined power states coming from other organizations/consortiums, e.g. ACPI. It might well be that in 5 or 10 years ACPI is replaced by something else that is gaining widespread support. In that case, one might extend the IANA registry to cover these new states. We also have power states that are specific to component types, the common case today are batteries. I do not know what types of components we will have in 5 or 10 years, but I would not be surprised if at some point new power states might be needed for specific new component types, e.g. components that generate energy. A controlled IANA registry allows to deal with all this in a sensible way. /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 Fri Mar 18 03:27:31 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906ED3A68C9 for ; Fri, 18 Mar 2011 03:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phdU3bQZQvy1 for ; Fri, 18 Mar 2011 03:27:26 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2BB303A67CC for ; Fri, 18 Mar 2011 03:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=12974; q=dns/txt; s=iport; t=1300444135; x=1301653735; h=mime-version:subject:date:message-id:from:to; bh=bRhS5tkBR66uMd6Te1tJwVvoTmbVkED1J/v1aueTf14=; b=PWX7szsJDlHVHCEtzbB6lHqKW/YgxQ/1iVh6erfMKKQtKMOcIbs6zR+u I4WMy7vL8jIU3hRjzURoyWITzozP8fTLUoSrClUEydSNKVBQKn3I5jnHp 2G/6GdhABVvSY5SwjY9VudormxZ9p5jWyzvc1CnIC34ZZaIna/RVoxIMp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMvQgk2tJXG+/2dsb2JhbACCYKMHd6ZEnBCFYwSFMYsH X-IronPort-AV: E=Sophos;i="4.63,204,1299456000"; d="scan'208,217";a="279517702" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 18 Mar 2011 10:28:54 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2IASsg7012987 for ; Fri, 18 Mar 2011 10:28:54 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 05:28:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE557.482B06A6" Date: Fri, 18 Mar 2011 05:28:50 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Energy Monitoring MIB - draft-claise-energy-monitoring-mib-07 Thread-Index: AcvlRWl8GzlTZTHJQjGMAqn61h/3zgAC7MCA From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 18 Mar 2011 10:28:54.0824 (UTC) FILETIME=[484EF280:01CBE557] Subject: [eman] Energy Monitoring MIB - draft-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 10:27:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE557.482B06A6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As an action item from the last IETF meeting at Beijing,=20 the Cisco MIB (http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06) and NEC MIB (http://tools.ietf.org/html/draft-quittek-power-mib-02) have been merged in to a single draft. The merged draft can be found at http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07. =20 Battery MIB module has been separated and posted. http://www.ietf.org/id/draft-quittek-eman-battery-mib-00.txt =20 Here are the significant changes based on the integration with the NEC MIB.=20 =20 * For the pmPowerEntry table =20 o the index pmPowerIndex- based on the concept from the NEC MIB - has been added o pmPowerStateEnterReason - indicate the reason for power state transition - has been added o For devices that can not measure power - pmPowerMeasurementCaliber - shall report as "Unavailable" =20 * For the pmPowerStateEntry table=20 o pmPowerStateTotalTime - total time spent in each state - has been added o pmPowerStateEnterCount - the number of times an entity has entered a power state - has been added =20 * pmDemandEnergyTable renamed as pmEnergyTable=20 * For the table PmEnergyIntervalEntry o pmEnergyIntervalDiscontinuityTime - to indicate discontinuities in energy measurement - has been added =20 The Power states has not been merged.=20 It is clear that Power States has been a discussion topic in the email list.=20 Based on the discussions and WG meeting, the merged MIB document shall update the power states appropriately.=20 =20 Thanks Mouli =20 ------_=_NextPart_001_01CBE557.482B06A6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As an action item from the last IETF meeting at Beijing, =

the Cisco MIB (http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06) and NEC MIB  (http://too= ls.ietf.org/html/draft-quittek-power-mib-02)  have been merged in to a single  draft. The merged draft can = be found at  http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07.&nb= sp;

Battery MIB module has been separated and posted. htt= p://www.ietf.org/id/draft-quittek-eman-battery-mib-00.txt<= /span>

 

Here are the significant changes based on the integration with the NEC MIB. =

 

·         For the pmPowerEntry table 

o   the index pmPowerIndex– based on the concept from = the NEC MIB - has been added

o   pmPowerStateEnterReason  - indicate the reason for = power state transition - has been added

o   For devices that can not measure power - = pmPowerMeasurementCaliber – shall report as “Unavailable”

 

·         For the pmPowerStateEntry table

o   pmPowerStateTotalTime – total time spent in each = state - has been added

o   pmPowerStateEnterCount  - the number of times an = entity has entered a power state - has been added

 

·         pmDemandEnergyTable renamed as pmEnergyTable =

·         For the table PmEnergyIntervalEntry

o   pmEnergyIntervalDiscontinuityTime  - to indicate = discontinuities in energy measurement  - has been added

 

The Power states has not been merged.

It is clear that Power States has been a discussion topic in the email = list.

Based on the discussions and WG meeting, the merged MIB document shall update = the power states appropriately.

 

Thanks

Mouli

 

------_=_NextPart_001_01CBE557.482B06A6-- From ietf@quittek.at Fri Mar 18 04:37:04 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A96D3A68D8 for ; Fri, 18 Mar 2011 04:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3EkESNZvpZq for ; Fri, 18 Mar 2011 04:37:01 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id BDD823A68AA for ; Fri, 18 Mar 2011 04:37:00 -0700 (PDT) Received: from n-0711.office.hd (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0McxrW-1QHWvm22ok-00ICM5; Fri, 18 Mar 2011 12:38:28 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-8-18561050 Message-Id: <7A652854-89E1-4752-89B3-284327E0D839@quittek.at> From: Juergen Quittek Date: Fri, 18 Mar 2011 12:38:28 +0100 To: Mouli Chandramouli (moulchan) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:oxHREnLjuWT/KSPNXIYkH/HRrzSXgLXWLsEF9GxLgY0 wOwZaNWLMrM4x1JCdDaSi3lfu7KD+7sdHhoZkbpJOwkl1KaJNA aIl3YdHg3Z6BpcSnLHrZyUbd3W3X5Ag2aG/Nq6oIi3ojUsLCnQ ifBsInyAO307+aENlMKMFalP8h1MlLdaKgrSaQN5TxJbUJv5EX 9NpMeDU0LolSX6B2JXS8Q== Cc: eman mailing list Subject: Re: [eman] Energy Monitoring MIB - draft-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 11:37:05 -0000 --Apple-Mail-8-18561050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all, As Mouli stated this document is a first step of the merger. Many issues have been solved between the two original drafts, but some = remain open. Fortunately, the most controversially discussed remaining issues are=20 being discussed intensively on this list.=20 I look forward to come to conclusions on them soon. Juergen Am 18.03.2011 um 11:28 schrieb Mouli Chandramouli (moulchan): > As an action item from the last IETF meeting at Beijing, > the Cisco MIB = (http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06) and = NEC MIB (http://tools.ietf.org/html/draft-quittek-power-mib-02) have = been merged in to a single draft. The merged draft can be found at = http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07.=20 > Battery MIB module has been separated and posted. = http://www.ietf.org/id/draft-quittek-eman-battery-mib-00.txt > =20 > Here are the significant changes based on the integration with the NEC = MIB. > =20 > =B7 For the pmPowerEntry table=20 > o the index pmPowerIndex=96 based on the concept from the NEC MIB - = has been added > o pmPowerStateEnterReason - indicate the reason for power state = transition - has been added > o For devices that can not measure power - pmPowerMeasurementCaliber = =96 shall report as =93Unavailable=94 > =20 > =B7 For the pmPowerStateEntry table > o pmPowerStateTotalTime =96 total time spent in each state - has = been added > o pmPowerStateEnterCount - the number of times an entity has = entered a power state - has been added > =20 > =B7 pmDemandEnergyTable renamed as pmEnergyTable > =B7 For the table PmEnergyIntervalEntry > o pmEnergyIntervalDiscontinuityTime - to indicate discontinuities = in energy measurement - has been added > =20 > The Power states has not been merged. > It is clear that Power States has been a discussion topic in the email = list. > Based on the discussions and WG meeting, the merged MIB document shall = update the power states appropriately. > =20 > Thanks > Mouli > =20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-8-18561050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear all,

As Mouli stated this = document is a first step of the merger.
Many issues have been = solved between the two original drafts, but some remain = open.
Fortunately, the most controversially discussed = remaining issues are 
being discussed intensively on this = list. 
I look forward to come to conclusions on them = soon.

   =  Juergen


Am 18.03.2011 um = 11:28 schrieb Mouli Chandramouli (moulchan):

As an = action item from the last IETF meeting at = Beijing,
the = Cisco MIB (   
Hi all, > > in some recent emails on this list I read "If the device is energy-aware" > Also we have a draft called draft-ietf-eman-energy-aware-mib containing > a MIB module called ENERGY-AWARE-MIB. > > My question is: What do we mean when we say "aware"? > > Is it a term to which we give a clear technical meaning > or does it just sound sexy and is good for marketing? > > According to Merriam-Webster aware means > > "having or showing realization, perception, or knowledge" > > This rather sounds like a cognitive performance that most of the > devices we are talking about will never be able to show. > > So what else would "aware" mean for us? > And is it OK to re-define it? > > Is a switch that measures its own energy consumption "energy-aware"? > Then it would be as well packet-aware if it has a counter for packets. > It would be flow-aware if it supports NetFlow, and of course it would > be TCP-aware if it implements the TCP-MIB and IP aware with the IF-MIB. > > According to draft-ietf-eman-energy-aware-mib a device can even become > energy-aware if an external meter measures its power and reports it to > a management station. In this case, the "energy-aware" device does never > get any access to its power and energy values. This is terribly misleading. > Let's please stop such nonsense. > > Considering that the IETF creates technical specifications > and not marketing brochures, I suggest replacing this term > in all our documents with other terms that are technically accurate. > > Which term to be used depends on the context. In many cases, just > calling them "monitored" devices or entities is fine. But in other cases > the replacement is more difficult. For example, MIB module > ENERGY-AWARE-MIB could more appropriately be called > EMAN-ENTITY-ID-MIB or EMAN-RELATIONSHIP-MIB, etc., > depending on which feature of the module we consider most > important. > > Thanks, > > Juergen > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Fri Mar 18 07:38:03 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D543A6916 for ; Fri, 18 Mar 2011 07:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PujU+ygS72sA for ; Fri, 18 Mar 2011 07:37:57 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EA3593A68D5 for ; Fri, 18 Mar 2011 07:37:56 -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 p2IEZahX010467; Fri, 18 Mar 2011 15:35:36 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2IEZZic005148; Fri, 18 Mar 2011 15:35:36 +0100 (CET) Message-ID: <4D836DB7.5010303@cisco.com> Date: Fri, 18 Mar 2011 15:35:35 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Chris Verges References: <20110304190215.GA5072@cslinux-build01.cyberswitching.local> <4D7DEA2A.3050100@cisco.com> <68FBE0F3CE97264395875AC1C468F22CF36864@mail03.cyberswitching.local> In-Reply-To: <68FBE0F3CE97264395875AC1C468F22CF36864@mail03.cyberswitching.local> Content-Type: multipart/alternative; boundary="------------000800050404000501010802" Cc: eman@ietf.org Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 14:38:03 -0000 This is a multi-part message in MIME format. --------------000800050404000501010802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Chris, I understand your concern. However, we can't redo the full ENTITY-MIB physical and logical entities in EMAN. Would it be sufficient for you to implement the ENTITY-MIB, following the link to the entityPhysicalIndex from http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01? Regards, Benoit. > > Hi Benoit, > > Could we solve it with a "keywords" style field? Perhaps. However, > the relationship of an outlet gang to its physical outlets is more > structural than that. It should be a separate field/mechanism so that > modifying one does not inadvertently affect the other. Trying to > combine the two is not the best solution and will bring up limitations > of the schema later. > > For example, why use pmParentId rather than including this information > in pmKeywords? The pmParentId/pmIndex relationship is separate from > the pmIndex/pmKeywords relationship in an object class diagram and for > good reason. > > Chris > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Monday, March 14, 2011 3:13 AM > *To:* Chris Verges > *Cc:* eman@ietf.org > *Subject:* Re: [eman] Outlet Gang addition to > draft-ietf-eman-requirements-00 > > Hi Chris, > > Thanks for your proposal. > I also believe we should be solving the case of multiple power supplies > However, we will have to pay attention that we don't double count the > traffic in the Power Monitor Metering Domain. > See http://tools.ietf.org/html/draft-ietf-eman-framework-00 -> > Section 5.2. Power Monitor Topologies: Metering versus Control versus > Power Distribution. So, even if there are two topologies for power > distribution, we would need a single Power Monitor Parent. > > Regarding the gang, could we solve this one with the context > information? For example, the pmKeywords in > http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01 > > Regards, Benoit. > > Hi Juergen, > > I wrote an additon to the various scenarios described in > draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario > found on Smart PDUs. Please let me know if you have any questions while > integrating it. > > $ diff draft-ietf-eman-requirements-00.txt draft-ietf-eman-requirements-01.txt > 416a417,449 > > 2.9. Scenario 9: Ganged outlets on a Smart Power Strip > > > > Some PDUs allow physical entities like outlets to be "ganged" together as a > > logical entity for simplified management purposes. This is particularly > > useful for servers with multiple power supplies, where each power supply is > > connected to a different physical outlet. Other implementations allow > > "gangs" to be created based on common ownership of outlets, such as > > business units or load shed priority or other non-physical relationships. > > > > Current implementations allow for an "M-to-N" mapping between outlet > > "gangs" and physical outlets. An example of this mapping includes the > > following: > > > > Outlet 1 (physical entity) > > Outlet 2 (physical entity) > > Outlet 3 (physical entity) > > Outlet 4 (physical entity) > > Outlet Gang A (virtual entity) > > Outlet Gang B (virtual entity) > > > > Gang A -> Outlets 1, 2 and 3 > > Gang B -> Outlets 3 and 4 > > > > Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both > > "gangs." > > > > Each "Outlet Gang" entity reports the aggregated data from the individual > > outlet entities that comprise it and enables a single point of control for > > all the individual outlet entities. For example, turning "Outlet Gang A" > > to the "off" state would turn outlets 1, 2, and 3 "off" in some > > implementations. (The impact of this action on "Outlet Gang B" is to be > > defined by the equipment manufacturer.) > > > > > Thanks, > Chris > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --------------000800050404000501010802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Chris,

I understand your concern.
However, we can't redo the full ENTITY-MIB physical and logical entities in EMAN.
Would it be sufficient for you to implement the ENTITY-MIB, following the link to the
entityPhysicalIndex from http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01?

Regards, Benoit.

Hi Benoit,

 

Could we solve it with a “keywords” style field?  Perhaps.  However, the relationship of an outlet gang to its physical outlets is more structural than that.  It should be a separate field/mechanism so that modifying one does not inadvertently affect the other.  Trying to combine the two is not the best solution and will bring up limitations of the schema later.

 

For example, why use pmParentId rather than including this information in pmKeywords?  The pmParentId/pmIndex relationship is separate from the pmIndex/pmKeywords relationship in an object class diagram and for good reason. 

 

Chris

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, March 14, 2011 3:13 AM
To: Chris Verges
Cc: eman@ietf.org
Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00

 

Hi Chris,

Thanks for your proposal.
I also believe we should be solving the case of multiple power supplies
However, we will have to pay attention that we don't double count the traffic in the Power Monitor Metering Domain.
See http://tools.ietf.org/html/draft-ietf-eman-framework-00 ->   Section 5.2. Power Monitor Topologies: Metering versus Control versus Power Distribution. So, even if there are two topologies for power distribution, we would need a single Power Monitor Parent.

Regarding the gang, could we solve this one with the context information? For example, the pmKeywords in http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01

Regards, Benoit.

Hi Juergen,
 
I wrote an additon to the various scenarios described in
draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario
found on Smart PDUs.  Please let me know if you have any questions while
integrating it.
 
$ diff draft-ietf-eman-requirements-00.txt draft-ietf-eman-requirements-01.txt
416a417,449
2.9.  Scenario 9: Ganged outlets on a Smart Power Strip
 
   Some PDUs allow physical entities like outlets to be "ganged" together as a
   logical entity for simplified management purposes.  This is particularly
   useful for servers with multiple power supplies, where each power supply is
   connected to a different physical outlet.  Other implementations allow
   "gangs" to be created based on common ownership of outlets, such as
   business units or load shed priority or other non-physical relationships.
 
   Current implementations allow for an "M-to-N" mapping between outlet
   "gangs" and physical outlets.  An example of this mapping includes the
   following:
 
      Outlet 1             (physical entity)
      Outlet 2             (physical entity)
      Outlet 3             (physical entity)
      Outlet 4             (physical entity)
      Outlet Gang A        (virtual entity)
      Outlet Gang B        (virtual entity)
 
      Gang A -> Outlets 1, 2 and 3
      Gang B -> Outlets 3 and 4
 
   Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both
   "gangs."
 
   Each "Outlet Gang" entity reports the aggregated data from the individual
   outlet entities that comprise it and enables a single point of control for
   all the individual outlet entities.  For example, turning "Outlet Gang A"
   to the "off" state would turn outlets 1, 2, and 3 "off" in some
   implementations.  (The impact of this action on "Outlet Gang B" is to be
   defined by the equipment manufacturer.)
 
 
Thanks,
Chris
 
 
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

 


--------------000800050404000501010802-- From russ@cisco.com Wed Mar 16 09:49:53 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8193A69E7 for ; Wed, 16 Mar 2011 09:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xze9yH8mdEr for ; Wed, 16 Mar 2011 09:49:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7D9D63A69E8 for ; Wed, 16 Mar 2011 09:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1414; q=dns/txt; s=iport; t=1300294279; x=1301503879; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=HZQOl/cu6Bvzjz0pPD5DFZVfPsH7fH8EXSQ2/5dohcE=; b=ko+8lHz+pLJFK2GTjo5VPkdZ9MMG84q+e4UpWKc3Mq7zsOzOkddJcwUP ceDFiJbLYwyVf6Z7JKdxqIxPLTh5WYwl8i9bt3ITEAzqq/aJpguOT1fx/ e7RqHRZOw7PdIkIyMUoUsuq3h6jDJAFw+/I5I/w4+9dZWCtYJdMveum+A 4=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJqHgE2tJV2c/2dsb2JhbACmD3ekUZxRhWMEjF6DTQ X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="asc'?scan'208";a="225832433" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2011 16:51:18 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2GGpIqV026561; Wed, 16 Mar 2011 16:51:18 GMT Message-ID: <4D80EA7D.8060502@cisco.com> Date: Wed, 16 Mar 2011 12:51:09 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Juergen Quittek References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> In-Reply-To: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA0B5DE44AD6E6D036463F07" X-Mailman-Approved-At: Fri, 18 Mar 2011 07:39:37 -0700 Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 16:49:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA0B5DE44AD6E6D036463F07 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > We can be open to any set of power states by having them registered=20 > at IANA. For each set we would register > - an ID (number) for identifying the set > - a number for each power state in this set I really like this idea... The only thing I would do is have it split into two "spaces," perhaps. All devices should support "on" and "off," so those should be in the "primary space." Then you could have an "extended state" that is defined as below. You could also actually support multiple "extended spaces." For instance, you could have one space for batteries, and another for various ranges of device states. I would support this idea. :-) Russ --------------enigDA0B5DE44AD6E6D036463F07 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2A6n8ACgkQER27sUhU9OTvJACdFqBw1MVhbnOaA93eH3LcVncy pjgAn321pPqWpryvz6QkckPtg7OYlAlU =6LzE -----END PGP SIGNATURE----- --------------enigDA0B5DE44AD6E6D036463F07-- From jparello@cisco.com Fri Mar 18 07:51:03 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78A63A6916 for ; Fri, 18 Mar 2011 07:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86cWlDYWMgE4 for ; Fri, 18 Mar 2011 07:50:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D24F23A68D5 for ; Fri, 18 Mar 2011 07:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=26925; q=dns/txt; s=iport; t=1300459945; x=1301669545; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=q8Y5Tk1N0ZuajRrK9VMMJG20eQRmOYsx/8rjc/uvzEQ=; b=j+lgFlb2eqCHD5qJK35yFZsPsa9lKv1PRDE8fcDk8XZNU6fu64msAyjB BR8o/CECLIsXMWxLVULUuXVxF4idhaf5jjbpcHd+D1Gqui4CxAx2tbDla 94X9WrmuCDuTIeFn6N5onHb0CoD0iAGJXEswHG3KLVHicoOrxGKZd4a7P A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAADwOg02tJXG+/2dsb2JhbACCYJVWjTZ3pjucFoVjBIUxiwc X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208,217";a="415831364" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 18 Mar 2011 14:52:24 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2IEoidR023789; Fri, 18 Mar 2011 14:52:24 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 07:52:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE57C.1665BB05" Date: Fri, 18 Mar 2011 07:47:24 -0700 Message-ID: In-Reply-To: <65669F97-B39A-4EAD-9068-A4603E14317F@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Terminology: Awareness Thread-Index: AcvlNNiuRx4NbCo0QISxSGbnKXvapgARXxzg References: <543B7386-E907-4E20-A21D-A7F1560B0F9B@quittek.at> <65669F97-B39A-4EAD-9068-A4603E14317F@quittek.at> From: "John Parello (jparello)" To: "Juergen Quittek" X-OriginalArrivalTime: 18 Mar 2011 14:52:22.0825 (UTC) FILETIME=[169C7990:01CBE57C] Cc: eman mailing list , Bruce Nordman Subject: Re: [eman] Terminology: Awareness X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 14:51:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE57C.1665BB05 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Juergen, =20 Yes as below I prefer the term as a distinction as to whether the device is implementing the objects as we define. The distinction is need because there will be devices that will not implement the object and still join in the managed community,=20 =20 They can still be metered or monitored by a the parent. =20 For example In the case below you can have parent that is aware that is acting on behalf of children that are or are not aware.=20 =20 I think your origination of this thread was to indicate that you thought the term was superfluous. I do not. =20 I completely agree we need more terminology definitions in the framework drafts and will put those in there to show the distinctions a long side the use cases in the draft. =20 As it's too late to publish a revision before Prague I will update my drafts with definitions sections. =20 Thanks I see your concerns and I will make sure to clarify it in the drafts and we can continue the discussion of terms and uses cases in that context. Jp=20 =20 From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Thursday, March 17, 2011 11:22 PM To: John Parello (jparello) Cc: Bruce Nordman; eman mailing list Subject: Re: [eman] Terminology: Awareness =20 Hi John, =20 Am 18.03.2011 um 00:23 schrieb John Parello (jparello): Fine see my previous emails. I've explained it with use cases already. =20 I guess you refer to this text: =20 IF you implement a set of objects we define in this WG you are aware of your energy. You may or may not be monitored by someone accessing the object. You can't assume just because you implement the objects there's some miraculous observer making SNMP request to you or monitoring you. You may never be contacted but you are still aware. =20 This is just a definition of "aware" not a use case. I still would like to have someone pointing me at any case where it is useful to know whether a devices is "aware" or not "aware". I see cases where it is important to know if a device is "metered" or "monitored" (as defined below), but I fail to see a cases where it is useful to know if a device is "aware". =20 Without a good case for it we do not need the term "aware". =20 =20 BTW: I don't think your definition above is 100% correct. You say "IF you implement a set of objects we define in this WG you are aware of your energy". But you may implement the objects as a "parent" and report on other devices energy. You can do so without having your own energy metered, i.e. without being "aware of your energy". You would then be just "aware" of OTHER devices energy.=20 =20 Thanks, =20 Juergen =20 =20 Jp =20 From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Thursday, March 17, 2011 3:21 PM To: John Parello (jparello) Cc: Bruce Nordman; eman mailing list Subject: Re: [eman] Terminology: Awareness =20 Hi John, =20 Let's rather discuss here on the list than privately. =20 If we have the terms "monitored" and "metered" as defined below, in what cases would we need the term "aware"? =20 Can you give an example for such a case or scenario? =20 Thanks, =20 Juergen =20 =20 Am 17.03.2011 um 18:54 schrieb John Parello (jparello): =09 =09 =09 =09 Hi Juergen, =20 Inline... =20 From: Juergen Quittek [mailto:ietf@quittek.at]=20 Sent: Thursday, March 17, 2011 1:53 AM To: John Parello (jparello) Cc: Bruce Nordman; eman mailing list Subject: Re: [eman] Terminology: Awareness =20 Hi John, =20 Let's start defining terms. According you your email below and our discussions before I assume the following: =20 [jp] we'll have to cover the separate values of power and energy? =20 "energy-metered"=20 A device is energy-metered if some entity measures the energy consumption of the device. This may happen internally or externally of the device.=20 =20 "energy-aware"=20 A device is enerhy-aware if the information that the devices is metered is available at the device even if metering is conducted externally. =20 "energy-monitored" A device is energy-monitored if some energy monitoring system observes metered energy values of a device. For self-managed devices, it may be the device itself that monitors it. =20 Would you agree on these definitions or do you have other ones? =20 If yes, I am still waiting for someone explaining me what we need the concept of "energy-awareness" for if we have "metered" and "monitored". =20 [jp] Well someone other than me I assume ;) - Aware covers your case of defining monitoring as being monitored and self-metered (monitored?) which would make your definition non terminal. We can discuss offline if you like for efficiency.=20 Jp =20 =20 =20 =20 =20 ------_=_NextPart_001_01CBE57C.1665BB05 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Juergen,

 

Yes as below I prefer the term as a distinction as to = whether the device is implementing the objects as we define. The distinction is need because there will be devices that will not implement the object and = still join in the managed community,

 

They can still be metered or monitored by a the = parent.

 

For example In  the case below you can have  = parent that is aware that is acting on behalf of children that are or are not = aware.

 

I think your origination of this thread was to indicate = that you thought the term was superfluous. I do not.

 

I completely agree we need more terminology definitions = in the framework drafts and will put those in there to show the distinctions a = long side the use cases in the draft.

 

As it’s too late to publish a revision before = Prague I will update my drafts with definitions sections.

 

Thanks I see your concerns and I will make sure to = clarify it in the drafts and we can continue the discussion of terms and uses cases in = that context.

Jp

 

From:= Juergen = Quittek [mailto:ietf@quittek.at]
Sent: Thursday, March 17, 2011 11:22 PM
To: John Parello (jparello)
Cc: Bruce Nordman; eman mailing list
Subject: Re: [eman] Terminology: Awareness

 

Hi John,

 

Am 18.03.2011 um 00:23 schrieb John Parello = (jparello):



Fine see my previous emails.  I’ve explained = it with use cases already.

 

I guess you refer to this text:

 

IF you implement a set of objects we define in this WG = you are aware of your energy. You may or may not be monitored by someone = accessing the object. You can’t assume just because you implement the objects there’s some miraculous observer making SNMP request to you or = monitoring you. You may never be contacted but you are still = aware.

 

This is just a definition of "aware" not = a use case. I still would like to have someone pointing me at any case where = it is useful to know whether a devices is "aware" or not = "aware".  I see cases where it is important to know if a device is "metered" or "monitored" (as defined below), but I = fail to see a cases where  it is useful to know if a device is = "aware".

 

Without a good case for it  we do not need the = term "aware".

 

 

BTW: I don't think your definition above is 100% = correct. You say "IF you implement a set of objects we define in this WG you = are aware of your energy". But you may implement the objects as a "parent" and report on other devices energy. You can do so = without having your own energy metered, i.e. without being "aware of your energy". You would then be just "aware" of OTHER devices energy. 

 

Thanks,

 

    Juergen

 

 

Jp

 

From:=  Juergen = Quittek [mailto:ietf@quittek.at] 
Sent: Thursday, = March 17, 2011 3:21 PM
To: John Parello (jparello)
Cc: Bruce = Nordman; eman mailing list
Subject: Re: = [eman] Terminology: Awareness

 

Hi John,

 

Let's rather discuss here on the list than = privately.

 

If we have the terms "monitored" and "metered" as defined below,

in what cases would we need the term = "aware"?

 

Can you give an example for such a case or = scenario?

 

Thanks,

 

    Juergen

 

 

Am 17.03.2011 um 18:54 schrieb John Parello = (jparello):




Hi Juergen,

 

Inline…

 

From:=  Juergen = Quittek [mailto:ietf@quittek.at] 
Sent: Thursday, = March 17, 2011 1:53 AM
To: John Parello (jparello)
Cc: Bruce = Nordman; eman mailing list
Subject: Re: = [eman] Terminology: Awareness

 

Hi John,

 

Let's start defining terms.

According you your email below and our discussions = before I assume the following:

 

[jp] we’ll have to cover the separate values of = power and energy?

 

"energy-metered" 

A device is energy-metered if some entity measures = the energy consumption of the device. This may happen internally or = externally of the device. 

 

"energy-aware" 

A device is enerhy-aware if the information that = the devices is metered is available at the device even if metering is conducted externally.

 

"energy-monitored"

A device is energy-monitored if some energy = monitoring system observes metered energy values of a device. For self-managed = devices, it may be the device itself that monitors it.

 

Would you agree on these definitions or do you have = other ones?

 

If yes, I am still waiting for someone explaining = me what we need the concept of "energy-awareness" for if we have "metered" and "monitored".

 

[jp] Well someone other than me I assume ;)   - = Aware covers your case of defining monitoring as being monitored and = self-metered (monitored?) which would make your definition non terminal.  We can discuss offline if you like for efficiency. 

Jp

 

 

 

 

 

------_=_NextPart_001_01CBE57C.1665BB05-- From chrisv@cyberswitching.com Fri Mar 18 08:03:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5453A692D for ; Fri, 18 Mar 2011 08:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW17JdP+Hp4E for ; Fri, 18 Mar 2011 08:03:26 -0700 (PDT) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by core3.amsl.com (Postfix) with ESMTP id 4A8043A691C for ; Fri, 18 Mar 2011 08:03:26 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o144.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 794738d4.0.3825.00-388.9090.p01c11o144.mxlogic.net (envelope-from ); Fri, 18 Mar 2011 09:04:56 -0600 (MDT) X-MXL-Hash: 4d8374985949ae4f-5175d806111a190eaa7cb0248334f3d248c1ea85 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 08:03:00 -0700 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 607B0AB426D; Fri, 18 Mar 2011 08:04:55 -0700 (PDT) Date: Fri, 18 Mar 2011 08:04:55 -0700 From: chrisv@cyberswitching.com To: eman@ietf.org Message-ID: <20110318150454.GA19324@cslinux-build01.cyberswitching.local> References: <20110308155405.GA12027@cslinux-build01.cyberswitching.local> <20110317113158.GB3733@elstar.local> <20110317154356.GA25808@cslinux-build01.cyberswitching.local> <20110318090048.GA6963@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110318090048.GA6963@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 18 Mar 2011 15:03:00.0044 (UTC) FILETIME=[926C60C0:01CBE57D] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XYJHFtupD_QA:10 a=nPeTO2waIjAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=go] X-AnalysisOut: [Q8pnnJmsUHHbPgQtkA:9 a=tAPANFlv3dTxmIj6aVwA:7 a=mABaCT1N4P] X-AnalysisOut: [pOo6cH9nrNSyNNL9IA:4 a=CjuIK1q_8ugA:10 a=HcrTHBdnl1LQIeE-:] X-AnalysisOut: [21 a=_4tYBqVEArzF3Cqy:21] Subject: Re: [eman] Use of ENTITY-MIB in EMAN (version 01) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:03:27 -0000 On Fri, Mar 18, 2011 at 10:00:48AM +0100, Juergen Schoenwaelder wrote: > > Rather than "functional groupings," which does not reflect the managed > > entity nature of the end goal, how about the following breakdown > > instead? > > > > 1. Physical entity - ENTITY-MIB > > 2. Logical entity - ENTITY-MIB > > 3. Virtual entity - EMAN > > 4. Power entity - EMAN > > > > A "power entity" can either refer to a "physical entity" or a "virtual > > entity." A "virtual entity" is anything that behaves similar to a > > "physical entity" but which has no actual physical nature, like a > > virtual machine or an outlet gang or a daemon running on the system. > > > > This clarifies the point that we need to manage "virtual entities" just > > like we would "physical entities." The term "functional groupings" > > makes it seem like we're bundling things just for abstract purposes > > only, whereas there is a deeper use case being answered in reality. > > The ENTITY-MIB has been designed to be relatively generic. If > arbitrary groupings of physical entities need to be added, we better > do it in a generic way instead of inventing this N times over again. > > > > If there is a need to represent "functional groupings", then we can > > > either use SNMP contexts (note that the entLPMappingTable allows to > > > map physical entities into logical contexts), although that might not > > > be sufficient, or we could extend the ENTITY-MIB by providing a > > > functional grouping mechanism (perhaps designing an indexing scheme > > > that makes it easy to refer to both physical entities and functional > > > groupings of physical entities), or we might follow the path of > > > creating a data model only loosely coupled to the ENTITY-MIB (but then > > > I think we should avoid overlap as much as possible and for the > > > overlap that is not avoidable, we need to explain how this is going to > > > be implemented). > > > > Since ENTITY-MIB was specifically designed to represent a physical > > instantiation of a system, it does not handle virtual entities (as > > described above) properly. > > That is not what I said. > > > I would like to see it extended to solve > > the cases that we are grappling with here; however, such an undertaking > > would be outside of EMAN's scope and delay the development and release > > of EMAN-MIB significantly. Please feel free to let the ENTITY-MIB > > working group know that some changes are desired in their model and let > > them begin working on it as a separate undertaking -- I am happy to help > > explain use cases if needed. But we need to focus on developing > > something that will work for EMAN in a timely manner, and already have > > solutions for doing that. > > The process argument and that claim that extending the ENTITY-MIB is > going to be way slower than EMAN can tolerate. Been there before. > > > In both draft-verges and draft-parello (now > > draft-ietf-eman-energy-aware), we create such a data model that > > loosely couples with ENTITY-MIB but does not rely on it. I'm > > hearing that you may be coming around to the same conclusion that > > ENTITY-MIB won't properly handle these "virtual entities" that EMAN > > needs to support, so would either of these proposed models in the > > drafts fit your needs? If not, what needs to change? > > No, virtual entities are just fine (or we have different definition > what virtual entities means). I see a large duplication of the > ENTITY-MIB in several of the MIBs flowing around (sometimes lacking > essential pieces that are in the ENTITY-MIB) and I fail to see why > that can be desirable. Given that I defined "virtual entities" above, what aspect of the definition are we in disagreement on? If you really are seeing several working groups that are implementing something like ENTITY-MIB but not using ENTITY-MIB itself, there has to be a reason. Either ENTITY-MIB doesn't meet their needs (like we are encountering in EMAN) or it's an education problem (certainly we experienced that on the mailing list, too) or something else might be going on. I'd suggest that those who are responsible for ENTITY-MIB do their own due-diligence to vet out these newer use cases and change ENTITY-MIB appropriately. However, if we hold up several working groups while waiting for this analysis to be finished, you're talking about effectively stopping forward progress on multiple WG's while this is being done. I don't know about your employer, but mine would probably fire me for something like this. :-) We can always spin the EMAN MIBs later to bring them into alignment with the new model when (if?) it is developed. Chris From chrisv@cyberswitching.com Fri Mar 18 08:04:33 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108BA3A692D for ; Fri, 18 Mar 2011 08:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hEilbA5fdFB for ; Fri, 18 Mar 2011 08:04:32 -0700 (PDT) Received: from p01c11o141.mxlogic.net (p01c11o141.mxlogic.net [208.65.144.64]) by core3.amsl.com (Postfix) with ESMTP id 04D533A691C for ; Fri, 18 Mar 2011 08:04:31 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o141.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 9d4738d4.0.6333.00-374.15216.p01c11o141.mxlogic.net (envelope-from ); Fri, 18 Mar 2011 09:06:01 -0600 (MDT) X-MXL-Hash: 4d8374d967a24bac-b08e512a6c2a371568b75c2a96e703c3a136f16e Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 08:04:02 -0700 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 344B0AB426D; Fri, 18 Mar 2011 08:05:58 -0700 (PDT) Date: Fri, 18 Mar 2011 08:05:58 -0700 From: chrisv@cyberswitching.com To: Juergen Quittek , eman mailing list Message-ID: <20110318150557.GB19324@cslinux-build01.cyberswitching.local> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110318091951.GE7027@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 18 Mar 2011 15:04:02.0834 (UTC) FILETIME=[B7D95F20:01CBE57D] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=PO4OC_ceetEA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel] X-AnalysisOut: [0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=PiiTPRh-pzSzZU6wM2oA] X-AnalysisOut: [:9 a=-zdWQmUFl3W4TdzbJUvvCeVGAWUA:4 a=CjuIK1q_8ugA:10] Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:04:33 -0000 On Fri, Mar 18, 2011 at 10:19:51AM +0100, Juergen Schoenwaelder wrote: > > If so, how would an entity report its state using multiple > > representations (simple-off, dmtf-powerOff, and acpi-offHard all being > > equivalent) from the same OID interface? It seems like you still need > > multiple interfaces, one for each representation, otherwise the various > > representations start clobbering each other. > > A component of a device reports one possible value, the value that is > in the set of states it supports natively. But an entity (i.e. "a component of a device") cannot support more than one set of states natively? It must choose only one paradigm? Chris From chrisv@cyberswitching.com Fri Mar 18 08:20:53 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB613A691D for ; Fri, 18 Mar 2011 08:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+xg6ckGF7IM for ; Fri, 18 Mar 2011 08:20:51 -0700 (PDT) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by core3.amsl.com (Postfix) with ESMTP id 5B4A43A691C for ; Fri, 18 Mar 2011 08:20:51 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c11o142.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id ca8738d4.0.22591.00-354.53224.p01c11o142.mxlogic.net (envelope-from ); Fri, 18 Mar 2011 09:22:21 -0600 (MDT) X-MXL-Hash: 4d8378ad6b42cc43-2dfba1d9e3b9135f33c83641ceff813a055a0c86 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 08:20:24 -0700 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 83EAAAB426D; Fri, 18 Mar 2011 08:22:20 -0700 (PDT) Date: Fri, 18 Mar 2011 08:22:20 -0700 From: chrisv@cyberswitching.com To: Benoit Claise Message-ID: <20110318152220.GC19324@cslinux-build01.cyberswitching.local> References: <20110304190215.GA5072@cslinux-build01.cyberswitching.local> <4D7DEA2A.3050100@cisco.com> <68FBE0F3CE97264395875AC1C468F22CF36864@mail03.cyberswitching.local> <4D836DB7.5010303@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D836DB7.5010303@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 18 Mar 2011 15:20:25.0033 (UTC) FILETIME=[01490B90:01CBE580] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XYJHFtupD_QA:10 a=Vdpz72tn5H4A:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=8ugJt9aZpiMyZzL3LV4A:9 a=B7SWhqyX0Sz9kaasPm] X-AnalysisOut: [QA:7 a=UHFP17oIs2QJxouHmY8trl4R_ZMA:4 a=CjuIK1q_8ugA:10] Cc: eman@ietf.org Subject: Re: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:20:53 -0000 On Fri, Mar 18, 2011 at 03:35:35PM +0100, Benoit Claise wrote: > I understand your concern. However, we can't redo the full ENTITY-MIB > physical and logical entities in EMAN. Would it be sufficient for you > to implement the ENTITY-MIB, following the link to the > entityPhysicalIndex from > http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01? But we can't (shouldn't) represent "virtual entities" in the "physical entity" table. So I'm failing to see how this is supposed to help. I agree with JS' point (different thread) that ENTITY-MIB should be extended to provide a "Generic Entity" index that "Physical Entities" and "Virtual Entities" and "Logical Entities" then become sparse tables out of. This allows for a single index and lets us worry about structure inside this new EXTENDED-ENTITY-MIB. However, we don't have this (yet). So if we decide to move forward with EMAN-MIB, then we are taking on the responsibility of setting up the structure needed. This includes properly separating filter mechanisms (keywords) from object relationship (structure). You're proposing to use both, but mixing the two confuses the unique purpose behind each. This confusion can be best exemplified if we want to change keywords: Outlet A -> outlet_gang_1, foo, bar Outlet B -> outlet_gang_1, baz, fred Outlet Gang 1 -> outlet_gang_1, foo Conceptually, we want to say that "Outlet Gang 1" has members "Outlet A" and "Outlet B." However, given that certain keywords ("foo") are shared between "Outlet Gang 1" and "Outlet A," which keyword should actually be used for the structural grouping identifier? Furthermore, if we set a new collection of keywords, do we have to ensure that we always copy the structurally-critical ones? snmpset ... "Outlet Gang 1".keywords.0 "fred" Would the above snmpset automatically populate the keyword "outlet_gang_1" on the agent side? Not only does this seem confusing (since it implies a hidden modality) but begs the question of what we do in a simlar snmpset for a regular outlet. EMAN-MIB should either build the entity structure needed or fully rely on an external MIB to do so. Let's not compromise the integrity of EMAN-MIB on a desire to reduce duplication where there is no duplication at this point anyway. Chris From bclaise@cisco.com Fri Mar 18 08:33:07 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5733B3A691D for ; Fri, 18 Mar 2011 08:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm4ooeK5GMBa for ; Fri, 18 Mar 2011 08:33:05 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id E573D3A67DB for ; Fri, 18 Mar 2011 08:33:03 -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 p2IFYTRG016404; Fri, 18 Mar 2011 16:34:29 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2IFYTuo023425; Fri, 18 Mar 2011 16:34:29 +0100 (CET) Message-ID: <4D837B84.7070601@cisco.com> Date: Fri, 18 Mar 2011 16:34:28 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "John Parello (jparello)" References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at><20110316052854.GA2249@elstar.local> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080306000100070100000008" Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:33:07 -0000 This is a multi-part message in MIME format. --------------080306000100070100000008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi John, We can go with a single series like this. However, I have some concerns because there is actually a data modelling behind this IANA registry. What if I decide to request "org.dmtf.ietf.com.sleep"? What are the consequences? I mean, we would need a really good IANA section to: 1. explain the data modelling behind the naming conventions 2. block the proliferation of power states ... to effectively try to model power state _series_. Regards, Benoit. > Hi Dan, > > True a registry with long list with a name space is equivalent. So how > about giving a dns like name to the state. It would also clear up the > ownership and the registry would be human readable. > > Thinking out loud here how about.... > > org.dmtf.off 17 > org.dmtf.sleep 42 > : > . > org.ietf.eman.off 93 > : > . > com.hal.off 102 > com.hal.drowsey 117 > etc... > > would allow for sorting and then perhaps a set by name without a cryptic > indexing > > setStatebyName('com.hal.off') > setState(102) > > That may also handle the issue of subcomponents? Although I'm not sure > of the implications of this as yet... > > com.hal.battery.off 73 > > One different issue I'd like to see addressed is whether or not setting > a state in one name space implies a setting to an equivalent state in > another name space. > > Jp > > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, March 17, 2011 3:46 AM > To: John Parello (jparello); Juergen Schoenwaelder; Juergen Quittek > Cc: eman mailing list > Subject: RE: [eman] MIB-friendly proposal for flexible power states > > > > Hi John, > > This grouping that you are talking about seems to me to be a matter of > document readability by humans. It does not have any application > significance, as the management application just gets an integer value. > Am I wrong? > > We can do a few things to improve human readability - for example > similar prefixing of enumerated value names that belong to the same > group, or sparse grouping that leaves room for definition of new > enumerated values in the same group for the foreseeing future. > > Regards, > > Dan > (speaking as contributor) > > >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On >> Behalf Of John Parello (jparello) >> Sent: Wednesday, March 16, 2011 8:23 PM >> To: Juergen Schoenwaelder; Juergen Quittek >> Cc: eman mailing list >> Subject: Re: [eman] MIB-friendly proposal for flexible power states >> >> Hi Juergen, >> >> You could have one long list as you suggest but then if >> someone added a state they are not grouped. So in your >> example if the dmtf adds a state foo you would have to add >> dmtf-foo to the end? >> >> It seems clearer to have these groups in sets and those sets >> are interfaces. >> >> Also there will be a question of parity on states. If I set >> to EMAN-OFF does that imply I am in DMTF-OFF and HAL-HARD-OFF as well? >> >> From a strict interface implementation split such a >> distinction would make sense. >> >> Jp >> >> -----Original Message----- >> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On >> Behalf Of Juergen Schoenwaelder >> Sent: Tuesday, March 15, 2011 10:29 PM >> To: Juergen Quittek >> Cc: eman mailing list >> Subject: Re: [eman] MIB-friendly proposal for flexible power states >> >> On Wed, Mar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote: >>> Dear all, >>> >>> here is a proposal for our power state discussion. >>> It is not new and has been discussed in different flavors already. >>> I just try to promote it by showing that it is flexible and at the >>> same time simple concerning its definition in a MIB module. >>> >>> It looks like people on this list want to be able to use different >>> sets of power states in order to support different energy >> management >>> interfaces. An example for a set would be the set of DMTF power >> states. >>> A way to support this and still allowing very simple >> implementations >>> would be the following: >>> >>> We can be open to any set of power states by having them >> registered at >>> IANA. For each set we would register >>> - an ID (number) for identifying the set >>> - a number for each power state in this set >>> >>> For example: >>> EMAN: >>> set ID: 0 >>> states IDs: off(0). sleep(1). on(2) >>> >>> DMTF: >>> set ID: 1 >>> states: powerOn(2), sleepLight(3), sleepDeep(4), etc. >>> >>> ACPI: >>> setID: 2 >>> states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. >>> >>> Then we can define power state tables such that they have >> two indices: >>> First the setID and then the stateID. >>> >>> In such a table you could implement several sets (interfaces) at the >> same time. >>> a device can support three basic power states with setID 0 as first >> index, >>> but as well show all DMTF power states with setID 1 as first index. >> And another >>> index could be used for ACPI and other power state sets. Simple >> implementations >>> would just implement a single (simple) set, but device makers would >> have the >>> chance to provide support for multiple interfaces (sets). >>> >>> A small disadvantage is that for identifying a power state >> we need two >> numbers. >>> We can solve this at MIB level by a textual convention for >> power state >> index objects >>> that defines the index as a string consisting of two >> numbers separated >> by a dot, >>> for example, "0.2" or "4.12". The first number would >> identify the set >> and the second >>> one the state within the set. >>> >>> Any organization that specifies or builds devices can then >> define sets >> of power >>> states, for example, for light bulbs or for UPS systems, >> and register >> them at IANA. >>> This mechanism is still simple but provides openness to future >> developments >>> without need to modify or extend the MIB module. >> I am likely confused what the goal is. If every power state >> set needs to be registered with IANA, then why not simply use >> an enumeration? >> >> simple-off(0), simple-sleep(1), simple-on(2), >> dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ... >> acpi-offHard(200), acpi-offSoft(201), hibernate(202), >> sleepDeep(203), ... >> >> You can add whatever text is needed to tell implementors they >> should just use the values of one set only. If you want to >> support non-IANA registered power states, the normal thing to >> do in MIB land is to use OBJECT-IDENTITIES, that is defined >> object identifier constants. This is how we identify say >> crypto-algorithms. We also have numeric TCs that define a set >> of well known values and that partition some of the integer >> number space for private use, in case a small number of well >> known power states with vendor extensibility is the way to go. >> >> I think it is crucial to figure out how much flexibility is >> needed and desirable and once that question has been >> answered, I think we should talk about the encoding (and I >> prefer encodings that are already known in MIB land over new >> creations). >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman >> _______________________________________________ >> 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 --------------080306000100070100000008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi John,

We can go with a single series like this.
However, I have some concerns because there is actually a data modelling behind this IANA registry.
What if I decide to request "org.dmtf.ietf.com.sleep"? What are the consequences?
I mean, we would need a really good IANA section to:
    1. explain the data modelling behind the naming conventions
    2. block the proliferation of power states
... to effectively try to model power state series.

Regards, Benoit. 
Hi Dan,

True a registry with long list with a name space is equivalent. So how
about giving a dns like name to the state. It would also clear up the
ownership and the registry would be human readable.

Thinking out loud here how about....

org.dmtf.off  17
org.dmtf.sleep 42
:
.
org.ietf.eman.off  93
:
.
com.hal.off 102
com.hal.drowsey 117
etc...

would allow for sorting and then perhaps a set by name without a cryptic
indexing 

setStatebyName('com.hal.off')
setState(102)

That may also handle the issue of subcomponents? Although I'm not sure
of the implications of this as yet...

com.hal.battery.off  73

One different issue I'd like to see addressed is whether or not setting
a state in one name space implies a setting to an equivalent state in
another name space. 

Jp


-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
Sent: Thursday, March 17, 2011 3:46 AM
To: John Parello (jparello); Juergen Schoenwaelder; Juergen Quittek
Cc: eman mailing list
Subject: RE: [eman] MIB-friendly proposal for flexible power states



Hi John, 

This grouping that you are talking about seems to me to be a matter of
document readability by humans. It does not have any application
significance, as the management application just gets an integer value.
Am I wrong? 

We can do a few things to improve human readability - for example
similar prefixing of enumerated value names that belong to the same
group, or sparse grouping that leaves room for definition of new
enumerated values in the same group for the foreseeing future. 

Regards,

Dan 
(speaking as contributor)
 


-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On 
Behalf Of John Parello (jparello)
Sent: Wednesday, March 16, 2011 8:23 PM
To: Juergen Schoenwaelder; Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] MIB-friendly proposal for flexible power states

Hi Juergen,

You could have one long list as you suggest but then if 
someone added a state they are not grouped. So in your 
example if the dmtf adds a state foo you would have to add 
dmtf-foo to the end?

It seems clearer to have these groups in sets and those sets 
are interfaces.

Also there will be a question of parity on states. If I set 
to EMAN-OFF does that imply I am in DMTF-OFF and HAL-HARD-OFF as well?

>From a strict interface implementation split such a 
distinction would make sense.

Jp

-----Original Message-----
From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On 
Behalf Of Juergen Schoenwaelder
Sent: Tuesday, March 15, 2011 10:29 PM
To: Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] MIB-friendly proposal for flexible power states

On Wed, Mar 16, 2011 at 12:56:55AM +0100, Juergen Quittek wrote:

Dear all,

here is a proposal for our power state discussion.
It is not new and has been discussed in different flavors already.
I just try to promote it by showing that it is flexible and at the 
same time simple concerning its definition in a MIB module.

It looks like people on this list want to be able to use different 
sets of power states in order to support different energy 

management 

interfaces. An example for a set would be the set of DMTF power

states.

A way to support this and still allowing very simple 

implementations 

would be the following:

We can be open to any set of power states by having them 

registered at 

IANA. For each set we would register
  - an ID (number) for identifying the set
  - a number for each power state in this set

For example:
EMAN:
set ID: 0
states IDs: off(0). sleep(1). on(2)

DMTF: 
set ID: 1
states:  powerOn(2), sleepLight(3), sleepDeep(4), etc.

ACPI:
setID: 2
states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc.

Then we can define power state tables such that they have 

two indices:

First the setID and then the stateID. 

In such a table you could implement several sets (interfaces) at the

same time.

a device can support three basic power states with setID 0 as first

index,

but as well show all DMTF power states with setID 1 as first index.

And another

index could be used for ACPI and other power state sets. Simple

implementations

would just implement a single (simple) set, but device makers would

have the 

chance to provide support for multiple interfaces (sets).

A small disadvantage is that for identifying a power state 

we need two
numbers.

We can solve this at MIB level by a textual convention for 

power state
index objects

that defines the index as a string consisting of two 

numbers separated
by a dot,

for example, "0.2" or "4.12". The first number would 

identify the set
and the second

one the state within the set.

Any organization that specifies or builds devices can then 

define sets
of power 

states, for example, for light bulbs or for UPS systems, 

and register
them at IANA.

This mechanism is still simple but provides openness to future

developments

without need to modify or extend the MIB module.

I am likely confused what the goal is. If every power state 
set needs to be registered with IANA, then why not simply use 
an enumeration?

simple-off(0), simple-sleep(1), simple-on(2), 
dmtf-powerOn(100), dmtf-sleepLight(101), dmtf-sleepDeep(102), ...
acpi-offHard(200), acpi-offSoft(201), hibernate(202), 
sleepDeep(203), ...

You can add whatever text is needed to tell implementors they 
should just use the values of one set only. If you want to 
support non-IANA registered power states, the normal thing to 
do in MIB land is to use OBJECT-IDENTITIES, that is defined 
object identifier constants. This is how we identify say 
crypto-algorithms. We also have numeric TCs that define a set 
of well known values and that partition some of the integer 
number space for private use, in case a small number of well 
known power states with vendor extensibility is the way to go.

I think it is crucial to figure out how much flexibility is 
needed and desirable and once that question has been 
answered, I think we should talk about the encoding (and I 
prefer encodings that are already known in MIB land over new 
creations).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
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

--------------080306000100070100000008-- From j.schoenwaelder@jacobs-university.de Fri Mar 18 08:39:42 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFF33A691D for ; Fri, 18 Mar 2011 08:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnMtw6qNm6JW for ; Fri, 18 Mar 2011 08:39:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 651843A67DB for ; Fri, 18 Mar 2011 08:39:41 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1D91C006D; Fri, 18 Mar 2011 16:41:09 +0100 (CET) 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 RT6x7PltmBPG; Fri, 18 Mar 2011 16:41:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BE1EC0010; Fri, 18 Mar 2011 16:41:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B54C61703DEB; Fri, 18 Mar 2011 16:41:08 +0100 (CET) Date: Fri, 18 Mar 2011 16:41:08 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110318154108.GB11947@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> <20110318150557.GB19324@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110318150557.GB19324@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:39:42 -0000 On Fri, Mar 18, 2011 at 08:05:58AM -0700, chrisv@cyberswitching.com wrote: > On Fri, Mar 18, 2011 at 10:19:51AM +0100, Juergen Schoenwaelder wrote: > > > If so, how would an entity report its state using multiple > > > representations (simple-off, dmtf-powerOff, and acpi-offHard all being > > > equivalent) from the same OID interface? It seems like you still need > > > multiple interfaces, one for each representation, otherwise the various > > > representations start clobbering each other. > > > > A component of a device reports one possible value, the value that is > > in the set of states it supports natively. > > But an entity (i.e. "a component of a device") cannot support more than > one set of states natively? It must choose only one paradigm? Such an assumption likely makes things tremendously simpler. Why does a component of a device have to be in several states at the same time? What is the set of meaningful combinations and how is a management system going to do anything useful with N concurrent power states of a component? /js -- 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 Fri Mar 18 08:46:00 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8BE3A691D for ; Fri, 18 Mar 2011 08:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fxIwVDcfgfK for ; Fri, 18 Mar 2011 08:45:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 5D58F3A691C for ; Fri, 18 Mar 2011 08:45:59 -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 p2IFRixu015595; Fri, 18 Mar 2011 16:27:44 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2IFRisY015666; Fri, 18 Mar 2011 16:27:44 +0100 (CET) Message-ID: <4D8379F0.90909@cisco.com> Date: Fri, 18 Mar 2011 16:27:44 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Juergen Quittek References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> In-Reply-To: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:46:00 -0000 Hi Juergen, I like this proposal, because only the time will tell us which power states will be accepted by the industry. Trying to impose a single one might not work. It might happen that different industry segments will have different series. Let me answer to some possible optimization later in the email thread. Regards, Benoit. > Dear all, > > here is a proposal for our power state discussion. > It is not new and has been discussed in different flavors already. > I just try to promote it by showing that it is flexible and > at the same time simple concerning its definition in a MIB module. > > It looks like people on this list want to be able to use different > sets of power states in order to support different energy management > interfaces. An example for a set would be the set of DMTF power states. > > A way to support this and still allowing very simple implementations > would be the following: > > We can be open to any set of power states by having them registered > at IANA. For each set we would register > - an ID (number) for identifying the set > - a number for each power state in this set > > For example: > EMAN: > set ID: 0 > states IDs: off(0). sleep(1). on(2) > > DMTF: > set ID: 1 > states: powerOn(2), sleepLight(3), sleepDeep(4), etc. > > ACPI: > setID: 2 > states: offHard(35), offSoft(25), hibernate(14), sleepDeep(13), etc. > > Then we can define power state tables such that they have two indices: > First the setID and then the stateID. > > In such a table you could implement several sets (interfaces) at the same time. > a device can support three basic power states with setID 0 as first index, > but as well show all DMTF power states with setID 1 as first index. And another > index could be used for ACPI and other power state sets. Simple implementations > would just implement a single (simple) set, but device makers would have the > chance to provide support for multiple interfaces (sets). > > A small disadvantage is that for identifying a power state we need two numbers. > We can solve this at MIB level by a textual convention for power state index objects > that defines the index as a string consisting of two numbers separated by a dot, > for example, "0.2" or "4.12". The first number would identify the set and the second > one the state within the set. > > Any organization that specifies or builds devices can then define sets of power > states, for example, for light bulbs or for UPS systems, and register them at IANA. > This mechanism is still simple but provides openness to future developments > without need to modify or extend the MIB module. > > Juergen > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Fri Mar 18 08:49:48 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8373A6950 for ; Fri, 18 Mar 2011 08:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMEt+QJyD6KC for ; Fri, 18 Mar 2011 08:49:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D94843A694E for ; Fri, 18 Mar 2011 08:49:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1253BC006B; Fri, 18 Mar 2011 16:51:16 +0100 (CET) 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 JNzMmpHhbc0h; Fri, 18 Mar 2011 16:51:15 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C1F8C0010; Fri, 18 Mar 2011 16:51:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 396E51703E34; Fri, 18 Mar 2011 16:51:15 +0100 (CET) Date: Fri, 18 Mar 2011 16:51:15 +0100 From: Juergen Schoenwaelder To: chrisv@cyberswitching.com Message-ID: <20110318155115.GC11947@elstar.local> Mail-Followup-To: chrisv@cyberswitching.com, eman@ietf.org References: <20110308155405.GA12027@cslinux-build01.cyberswitching.local> <20110317113158.GB3733@elstar.local> <20110317154356.GA25808@cslinux-build01.cyberswitching.local> <20110318090048.GA6963@elstar.local> <20110318150454.GA19324@cslinux-build01.cyberswitching.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110318150454.GA19324@cslinux-build01.cyberswitching.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] Use of ENTITY-MIB in EMAN (version 01) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:49:48 -0000 On Fri, Mar 18, 2011 at 08:04:55AM -0700, chrisv@cyberswitching.com wrote: > If you really are seeing several working groups that are implementing > something like ENTITY-MIB but not using ENTITY-MIB itself, there has to > be a reason. Either ENTITY-MIB doesn't meet their needs (like we are > encountering in EMAN) or it's an education problem (certainly we > experienced that on the mailing list, too) or something else might be > going on. I'd suggest that those who are responsible for ENTITY-MIB do > their own due-diligence to vet out these newer use cases and change > ENTITY-MIB appropriately. However, if we hold up several working groups > while waiting for this analysis to be finished, you're talking about > effectively stopping forward progress on multiple WG's while this is > being done. I don't know about your employer, but mine would probably > fire me for something like this. :-) We can always spin the EMAN MIBs > later to bring them into alignment with the new model when (if?) it is > developed. I was talking about EMAN related MIBs, not multiple working groups. And as you might have noticed, the IETF is not working like a normal company. I got involved here because I did not find a good description why using existing MIB modules does not work - and this is a reasonable question to ask since there is quite some overlap in some of the MIB modules I have seen related to this working group. I found that some people were confused how the ENTITY-MIB works and I took an initiative to clear up the confusion while learning more about the things this WG is trying to achieve. You may or may not appreciate this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Fri Mar 18 08:57:23 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1973A691D for ; Fri, 18 Mar 2011 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUYzqXTaZUUj for ; Fri, 18 Mar 2011 08:57:23 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 370383A6926 for ; Fri, 18 Mar 2011 08:57:16 -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 p2IFePd7017100; Fri, 18 Mar 2011 16:40:25 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2IFePe7001035; Fri, 18 Mar 2011 16:40:25 +0100 (CET) Message-ID: <4D837CE8.6030804@cisco.com> Date: Fri, 18 Mar 2011 16:40:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110318091737.GD7027@elstar.local> In-Reply-To: <20110318091737.GD7027@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:57:24 -0000 Dear all, > On Thu, Mar 17, 2011 at 11:21:18PM +0100, Juergen Quittek wrote: > >> The other alternative was cleaner because it separates the set index >> from the state index. > But this separation does not add any real value since a state value is > only meaningful together with the set index. Hence, by making them one > thing, you make a number of errors simply impossible and you gain > efficiency. I agree with your argument on reducing the error by combining two indexes into one. However, isn't it interesting to discover which power state series (EMAN, ACPI, manufacturer, etc...) a device support? And then within that series, which states are supported? Regards, Benoit. > /js > From chrisv@cyberswitching.com Fri Mar 18 09:03:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816E23A6920 for ; Fri, 18 Mar 2011 09:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcMu5KIFSZCg for ; Fri, 18 Mar 2011 09:03:10 -0700 (PDT) Received: from p01c12o147.mxlogic.net (p01c12o147.mxlogic.net [208.65.145.70]) by core3.amsl.com (Postfix) with ESMTP id 5DE723A67DB for ; Fri, 18 Mar 2011 09:03:10 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o147.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 792838d4.0.5165.00-365.12050.p01c12o147.mxlogic.net (envelope-from ); Fri, 18 Mar 2011 10:04:40 -0600 (MDT) X-MXL-Hash: 4d8382981ea4c55a-5dda6c6c38d21617d3ad1cbb9cbefd7ac41a7e4f Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 09:02:21 -0700 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id D0E1CAB426D; Fri, 18 Mar 2011 09:04:17 -0700 (PDT) Date: Fri, 18 Mar 2011 09:04:17 -0700 From: chrisv@cyberswitching.com To: Juergen Quittek , eman mailing list Message-ID: <20110318160417.GA26516@cslinux-build01.cyberswitching.local> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> <20110318150557.GB19324@cslinux-build01.cyberswitching.local> <20110318154108.GB11947@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110318154108.GB11947@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 18 Mar 2011 16:02:21.0977 (UTC) FILETIME=[DD803890:01CBE585] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XYJHFtupD_QA:10 a=PO4OC_ceetEA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=1c] X-AnalysisOut: [pEORWtgSLRsbtZOk4A:9 a=qiEdaXMc4e2Pu2q-7rm0sVFR0GEA:4 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10 a=9vWFaI-z4rPDignG:21 a=NaucnaZNKIVrnHQR:21] Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:03:11 -0000 On Fri, Mar 18, 2011 at 04:41:08PM +0100, Juergen Schoenwaelder wrote: > > > A component of a device reports one possible value, the value that > > > is in the set of states it supports natively. > > > > But an entity (i.e. "a component of a device") cannot support more > > than one set of states natively? It must choose only one paradigm? > > Such an assumption likely makes things tremendously simpler. Why > does a component of a device have to be in several states at the > same time? What is the set of meaningful combinations and how is > a management system going to do anything useful with N concurrent > power states of a component? The entity is in one state, but it may be described by different paradigms in totally equivalent ways. Some users may understand ACPI better than DMTF for whatever reason. In that case, let's say that they purchase a server whose manufacturer, for no reason other than personal preference, sets DMTF as its "native" language. We're saying that the user can speak ACPI to the server, but the server responds back in DMTF? Doesn't this seem asinine? Philosophically, I think you've hit on a key point that "simple-off" and "acpi-off" and "dmtf-off" are all the same operational state. However, how you represent "off" changes based on the language you speak. English: "off." Spanish: "apagado." Russian: "OT." We don't want to force Russians to speak English. :-) Similarly, we're talking about developing a "Tower of Babel" style language here in EMAN to reflect power states. Such is an enormous undertaking, and prone to error as concepts are mistranslated or misunderstood. Wouldn't it be better to put together an interface like a Rosetta stone? Let each user access the system in whatever ways make sense for that user, and then have the agent provide the equivalent translation of power states that makes sense for that agent? Chris P.S. Google Translate pulled the "OT" for Russian, so no clue if it's right. From chrisv@cyberswitching.com Fri Mar 18 09:13:21 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DB73A6920 for ; Fri, 18 Mar 2011 09:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u+8UqkgJKlO for ; Fri, 18 Mar 2011 09:13:20 -0700 (PDT) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id 38A283A691B for ; Fri, 18 Mar 2011 09:13:20 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o144.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 9f4838d4.0.1780.00-387.3984.p01c12o144.mxlogic.net (envelope-from ); Fri, 18 Mar 2011 10:14:50 -0600 (MDT) X-MXL-Hash: 4d8384fa152df6bb-aecaed39439ba3c403e3be7b038cb9b810496a59 Received: from cslinux-build01.localdomain ([10.0.2.250]) by mail03.cyberswitching.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 09:07:44 -0700 Received: by cslinux-build01.localdomain (Postfix, from userid 1000) id 6EE5CAB426D; Fri, 18 Mar 2011 09:09:40 -0700 (PDT) Date: Fri, 18 Mar 2011 09:09:40 -0700 From: chrisv@cyberswitching.com To: eman@ietf.org Message-ID: <20110318160940.GB26516@cslinux-build01.cyberswitching.local> References: <20110308155405.GA12027@cslinux-build01.cyberswitching.local> <20110317113158.GB3733@elstar.local> <20110317154356.GA25808@cslinux-build01.cyberswitching.local> <20110318090048.GA6963@elstar.local> <20110318150454.GA19324@cslinux-build01.cyberswitching.local> <20110318155115.GC11947@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110318155115.GC11947@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 18 Mar 2011 16:07:44.0518 (UTC) FILETIME=[9DC01260:01CBE586] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XYJHFtupD_QA:10 a=nPeTO2waIjAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=1Eql4bHns2NoxN2V9ejGkg==:17 a=8e] X-AnalysisOut: [k7I6MLRiqx7rxN0TEA:9 a=3eeoKv9kS0EhgOUguPdNiu_HrosA:4 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10] Subject: Re: [eman] Use of ENTITY-MIB in EMAN (version 01) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:13:21 -0000 On Fri, Mar 18, 2011 at 04:51:15PM +0100, Juergen Schoenwaelder wrote: > I was talking about EMAN related MIBs, not multiple working groups. > And as you might have noticed, the IETF is not working like a normal > company. I apologize for misunderstanding then. I thought you were indicating that several working groups were coming up against the same challenge. That does not negate the sense of urgency surrounding EMAN's undertaking, however. > I got involved here because I did not find a good description why > using existing MIB modules does not work - and this is a reasonable > question to ask since there is quite some overlap in some of the MIB > modules I have seen related to this working group. I found that some > people were confused how the ENTITY-MIB works and I took an initiative > to clear up the confusion while learning more about the things this WG > is trying to achieve. You may or may not appreciate this. And your input into ENTITY-MIB is greatly appreciated. I certainly learned a lot from your and Dan's comments on the list. But I keep coming back to the conclusion that ENTITY-MIB was not structured to work for virtual entities, and EMAN has a requirement to support virtual entities alongside physical entities. How do we drive the discusion about ENTITY-MIB to an actionable conclusion? Do we (EMAN WG) propose whatever extensions are needed to ENTITY-MIB to make it work? Or do we ask the WG who originally created it to take this venture on? Or do we say that we are going to set up our own entity structure and simply give a nod (reference) ENTITY-MIB where appropriate for physical entities? Or some fourth choice that isn't yet mentioned? Thanks, Chris From tirth.ghose@gmail.com Fri Mar 18 09:20:47 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327173A6975 for ; Fri, 18 Mar 2011 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUaa21Kgsr2b for ; Fri, 18 Mar 2011 09:20:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D41443A6920 for ; Fri, 18 Mar 2011 09:20:39 -0700 (PDT) Received: by iyi12 with SMTP id 12so4838047iyi.31 for ; Fri, 18 Mar 2011 09:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=/iM2z9LqcbIypimfz1T/OAQueKtpTpUPUu3AX7rT7ZI=; b=hQWwvZINBw22Sag3zGjI86SeppzEfP96JfHxsutCd/SmLbm89q8H2aSWkFlhpMXrZW Ek2B//joufhdYg99jXWOzQ1Y7CXtT4s+oD9AWcLvZQs37UH2907btW8yGOHHCbEA3ouF i6a3/GagNSo8s4fh5+bPJ2F0RapvoyKfiMpbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=BrQadVZEJ2z/uu6fIQ+LDYKwLcy5I9gZUiP9Je7Ro2WDypGHKrBdcaM5ZPjMq4aqEf WjUBIQPsg04qdfqxCrHEFg+AHalDH5V2UExdb4QGPHTAcaAllokL1fhZauex2t5huXbF LD2/my56MXdrAczVSe6nk5w6VTWyzXHJlB/mY= MIME-Version: 1.0 Received: by 10.231.185.76 with SMTP id cn12mr1161932ibb.33.1300465328233; Fri, 18 Mar 2011 09:22:08 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Fri, 18 Mar 2011 09:22:08 -0700 (PDT) In-Reply-To: <20110318091552.GC7027@elstar.local> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <20110318091552.GC7027@elstar.local> Date: Fri, 18 Mar 2011 09:22:08 -0700 X-Google-Sender-Auth: BlH6vBJgr9lBem4YysRPeoTuhFE Message-ID: From: Ted Ghose To: Juergen Schoenwaelder , Ted Ghose , Juergen Quittek , eman mailing list Content-Type: multipart/alternative; boundary=005045016234ee9f9a049ec42d36 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:20:47 -0000 --005045016234ee9f9a049ec42d36 Content-Type: text/plain; charset=ISO-8859-1 This approach will then be similarly useless that what we have today, without a MIB! If the charter of the WG is to publish an yellow book of all existing practices and just open a registration forum in IANA, can we think for a moment how does it going to help end users? Device manufactures will have a easy task, yes. But I belief WG authors MIB to help end users. If that is not the case, I belief I'm wasting my time over here. thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Fri, Mar 18, 2011 at 2:15 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Mar 17, 2011 at 11:29:19AM -0700, Ted Ghose wrote: > > > If the proposal here to display any collection of any states that > people > > will go and register in IANA, are we not loosing the main focus of > > standardizing, and what that means. > > You were arguing else where "what's the state of the 'device off > battery > > charging' be", and I agree with you. > > But without standardizing some basic EMAN states, but > > displaying wide varieties of state of overlapping and even conflicting > > meaning registered in IANA, what will be a real value add. > > Different devices some how or other does shows different states they > > have implemented, anyway. > > I'd urge the WG to bring some standard and avoid the explosion of > power > > states in IANA. > > Every IANA registry has defined rules how something can be added. The > WG would have to define the rules and they can be restrictive. IANA > control does not imply explosion of power states. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --005045016234ee9f9a049ec42d36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This approach will then be similarly useless that what we have today, witho= ut a MIB!

If the charter of the WG is to publish an yell= ow book of all existing practices and just open a registration forum in IAN= A, can we think for a moment how does it going to help end users?=A0

Device manufactures will have a easy task, yes. But I b= elief WG authors MIB to help end users.

If that is= not the case, I belief I'm wasting my time over here.

thanks

-tg-

*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,= _:-.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time= ... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_= :-.,_,.-:**:-.,_,.


On Fri, Mar 18, 2011 at 2:15 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote= :
On Thu, Mar 17, 2011 at 1= 1:29:19AM -0700, Ted Ghose wrote:

> =A0 =A0If the proposal here to display any collection of any states th= at people
> =A0 =A0will go and register in IANA, are we not loosing the main focus= of
> =A0 =A0standardizing, and what that means.
> =A0 =A0You were arguing else where "what's the state of the &= #39;device off battery
> =A0 =A0charging' be", and I agree with you.
> =A0 =A0But without standardizing some basic EMAN states, but
> =A0 =A0displaying wide varieties of state of overlapping and even conf= licting
> =A0 =A0meaning registered in IANA, what will be a real value add.
> =A0 =A0Different devices some how or other does shows different states= they
> =A0 =A0have implemented, anyway.
> =A0 =A0I'd urge the WG to bring some standard and avoid the explos= ion of power
> =A0 =A0states in IANA.

Every IANA registry has defined rules how something can be added. The=
WG would have to define the rules and they can be restrictive. IANA
control does not imply explosion of power states.

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 = =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 +49 421 200 3103 =A0 = =A0 =A0 =A0 <http://www.jacobs-university.de/>

--005045016234ee9f9a049ec42d36-- From j.schoenwaelder@jacobs-university.de Fri Mar 18 09:22:49 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C579E3A6920 for ; Fri, 18 Mar 2011 09:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meuUorJknnyO for ; Fri, 18 Mar 2011 09:22:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4346B3A6975 for ; Fri, 18 Mar 2011 09:22:38 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00885C006D; Fri, 18 Mar 2011 17:24:02 +0100 (CET) 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 ti+TtOJXKTJk; Fri, 18 Mar 2011 17:24:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3003EC0010; Fri, 18 Mar 2011 17:24:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4B05B1703F5C; Fri, 18 Mar 2011 17:23:59 +0100 (CET) Date: Fri, 18 Mar 2011 17:23:58 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20110318162358.GD11947@elstar.local> Mail-Followup-To: Benoit Claise , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110318091737.GD7027@elstar.local> <4D837CE8.6030804@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D837CE8.6030804@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:22:49 -0000 On Fri, Mar 18, 2011 at 04:40:24PM +0100, Benoit Claise wrote: > I agree with your argument on reducing the error by combining two > indexes into one. > However, isn't it interesting to discover which power state series > (EMAN, ACPI, manufacturer, etc...) a device support? And then within > that series, which states are supported? If you report the set type and the set value in separate objects, I think you still have the same question. In other words, the question whether there is a function to discover supported sets of power states seems to be independent of the encoding. I many (if no most) MIB modules, there are no objects that let you discover which values you may write. There are likely three reasons: a) Originally, the idea was that SNMP implementations were providing AGENT-CAPABILITIES that would provide this information out of band. b) Providing this information in band takes a lot of extra work since you end up needing additional objects. c) Even if you have an object that tells you that a device supports a certain value, there is still no guarantee that you can successfully write it. Hence, it is often easier for a management system to simply try the desired value and to fallback to some fallback value if the desired value did not work. Perhaps it helps to answer the question how many different sets of power states we will likely have first (that is how restrictive IANA rules would be) and based on that whether a discovery mechanism is necessary for the first version of the MIB module. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tirth.ghose@gmail.com Fri Mar 18 09:22:50 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D4A3A6990 for ; Fri, 18 Mar 2011 09:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z+MAuU+uBvL for ; Fri, 18 Mar 2011 09:22:48 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id C35E93A698F for ; Fri, 18 Mar 2011 09:22:44 -0700 (PDT) Received: by yxk30 with SMTP id 30so1936742yxk.31 for ; Fri, 18 Mar 2011 09:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AzVLG+Ciue1nLscR/Qk4yaYLhddaplmSDz7BdlxVKyw=; b=SripQiRFKMY+bfIOLI3h6XkIx8CACeDgvdq2Jx8tHO0RG0YctT3WoqQZIE/UknKUqZ JWT0WveS5thwahHK9lxAfU4ll3xzfzg20XehyUwotSp9q3CeBRgHiO5AJTkCiCX+JJi4 T+VGaYzX8RQ6Rb2+81Da9L5fC3j5pcmuoFHaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SusRh9PeYwEIGqiABtZ975CqsKMb8OYco+JZzkfvZNKKzJ9F9yd9xIgW4HwYPbCgXo FtKKaII5SCWceX1AQtlAN8CUVfKXUrMpVzCDx1zxg7oN1sCIAUOqpxrrYil3aw1Gdqt8 phu3fhgE/Ap5j8tl3hu8p5i80iv1dA33nR1Ik= MIME-Version: 1.0 Received: by 10.43.56.140 with SMTP id wc12mr1823959icb.237.1300465453595; Fri, 18 Mar 2011 09:24:13 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Fri, 18 Mar 2011 09:24:13 -0700 (PDT) In-Reply-To: <20110318160417.GA26516@cslinux-build01.cyberswitching.local> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> <20110318150557.GB19324@cslinux-build01.cyberswitching.local> <20110318154108.GB11947@elstar.local> <20110318160417.GA26516@cslinux-build01.cyberswitching.local> Date: Fri, 18 Mar 2011 09:24:13 -0700 X-Google-Sender-Auth: lR-ei0xStT1Wzgp__Dn8THlQgOs Message-ID: From: Ted Ghose To: chrisv@cyberswitching.com Content-Type: multipart/alternative; boundary=bcaec517ad0e677c84049ec4353c Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:22:50 -0000 --bcaec517ad0e677c84049ec4353c Content-Type: text/plain; charset=ISO-8859-1 +1 -tg- On Fri, Mar 18, 2011 at 9:04 AM, wrote: > On Fri, Mar 18, 2011 at 04:41:08PM +0100, Juergen Schoenwaelder wrote: > > > > A component of a device reports one possible value, the value that > > > > is in the set of states it supports natively. > > > > > > But an entity (i.e. "a component of a device") cannot support more > > > than one set of states natively? It must choose only one paradigm? > > > > Such an assumption likely makes things tremendously simpler. Why > > does a component of a device have to be in several states at the > > same time? What is the set of meaningful combinations and how is > > a management system going to do anything useful with N concurrent > > power states of a component? > > The entity is in one state, but it may be described by different > paradigms in totally equivalent ways. > > Some users may understand ACPI better than DMTF for whatever reason. In > that case, let's say that they purchase a server whose manufacturer, for > no reason other than personal preference, sets DMTF as its "native" > language. We're saying that the user can speak ACPI to the server, but > the server responds back in DMTF? > > Doesn't this seem asinine? > > Philosophically, I think you've hit on a key point that "simple-off" and > "acpi-off" and "dmtf-off" are all the same operational state. However, > how you represent "off" changes based on the language you speak. > English: "off." Spanish: "apagado." Russian: "OT." We don't want to > force Russians to speak English. :-) > > Similarly, we're talking about developing a "Tower of Babel" style > language here in EMAN to reflect power states. Such is an enormous > undertaking, and prone to error as concepts are mistranslated or > misunderstood. > > Wouldn't it be better to put together an interface like a Rosetta stone? > Let each user access the system in whatever ways make sense for that > user, and then have the agent provide the equivalent translation of > power states that makes sense for that agent? > > Chris > > P.S. Google Translate pulled the "OT" for Russian, so no clue if it's > right. > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --bcaec517ad0e677c84049ec4353c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

-tg-

On Fri, Mar 18= , 2011 at 9:04 AM, <chrisv@cyberswitching.com> wrote:
On Fri, Mar 18, 2011 at 04:41:08PM +0100, Juergen Schoenw= aelder wrote:
> > > A component of a device reports one possible value, the valu= e that
> > > is in the set of states it supports natively.
> >
> > But an entity (i.e. "a component of a device") cannot s= upport more
> > than one set of states natively? =A0It must choose only one parad= igm?
>
> Such an assumption likely makes things tremendously simpler. Why
> does a component of a device have to be in several states at the
> same time? What is the set of meaningful combinations and how is
> a management system going to do anything useful with N concurrent
> power states of a component?

The entity is in one state, but it may be described by different
paradigms in totally equivalent ways.

Some users may understand ACPI better than DMTF for whatever reason. =A0In<= br> that case, let's say that they purchase a server whose manufacturer, fo= r
no reason other than personal preference, sets DMTF as its "native&quo= t;
language. =A0We're saying that the user can speak ACPI to the server, b= ut
the server responds back in DMTF?

Doesn't this seem asinine?

Philosophically, I think you've hit on a key point that "simple-of= f" and
"acpi-off" and "dmtf-off" are all the same operational = state. =A0However,
how you represent "off" changes based on the language you speak.<= br> English: "off." =A0Spanish: "apagado." =A0Russian: &quo= t;OT." =A0We don't want to
force Russians to speak English. =A0:-)

Similarly, we're talking about developing a "Tower of Babel" = style
language here in EMAN to reflect power states. =A0Such is an enormous
undertaking, and prone to error as concepts are mistranslated or
misunderstood.

Wouldn't it be better to put together an interface like a Rosetta stone= ?
Let each user access the system in whatever ways make sense for that
user, and then have the agent provide the equivalent translation of
power states that makes sense for that agent?

Chris

P.S. =A0Google Translate pulled the "OT" for Russian, so no clue = if it's
right.
_________________________________________= ______
eman mailing list
eman@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/eman

--bcaec517ad0e677c84049ec4353c-- From bill.mielke@alcatel-lucent.com Fri Mar 18 09:26:25 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84CCA3A695F for ; Fri, 18 Mar 2011 09:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+4Sx2DK92ib for ; Fri, 18 Mar 2011 09:26:24 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 9820B3A691C for ; Fri, 18 Mar 2011 09:26:24 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p2IGRrcN001531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 18 Mar 2011 11:27:53 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2IGRrH4011128 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 18 Mar 2011 11:27:53 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 18 Mar 2011 11:27:53 -0500 From: "Mielke, William F (Bill)" To: eman mailing list Date: Fri, 18 Mar 2011 11:27:42 -0500 Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvlhWq830ERmfb6QOKQ5nNfauSw1gAAve4g Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A25C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110318091737.GD7027@elstar.local> <4D837CE8.6030804@cisco.com> In-Reply-To: <4D837CE8.6030804@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:26:25 -0000 > Benoit Claise wrote: >=20 > I agree with your argument on reducing the error by combining two=20 > indexes into one. > However, isn't it interesting to discover which power state series=20 > (EMAN, ACPI, manufacturer, etc...) a device support? And then within=20 > that series, which states are supported? My $0.02 on this is that I can accept either approach as each has its own b= enefits. If I got to pick I would argue that the benefit (intuitive clarity from a m= odeling perspective for lack of a better description) of the 2 index approa= ch proposed by JuergenQ outweighs the efficiency argument of JuergenS to co= mbine the two into a single index. But this is just my personal opinion. = YMMV. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein From j.schoenwaelder@jacobs-university.de Fri Mar 18 09:31:32 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834323A6954 for ; Fri, 18 Mar 2011 09:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TefFksMXN6+b for ; Fri, 18 Mar 2011 09:31:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5DE693A6926 for ; Fri, 18 Mar 2011 09:31:31 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96951C0010; Fri, 18 Mar 2011 17:33:00 +0100 (CET) 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 pE4qw6ywmzlA; Fri, 18 Mar 2011 17:33:00 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D85E9C006B; Fri, 18 Mar 2011 17:32:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 831801704098; Fri, 18 Mar 2011 17:32:59 +0100 (CET) Date: Fri, 18 Mar 2011 17:32:59 +0100 From: Juergen Schoenwaelder To: Ted Ghose Message-ID: <20110318163259.GF11947@elstar.local> Mail-Followup-To: Ted Ghose , Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <20110318091552.GC7027@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 mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:31:32 -0000 On Fri, Mar 18, 2011 at 09:22:08AM -0700, Ted Ghose wrote: > This approach will then be similarly useless that what we have today, > without a MIB! > > If the charter of the WG is to publish an yellow book of all existing > practices and just open a registration forum in IANA, can we think for a > moment how does it going to help end users? > > Device manufactures will have a easy task, yes. But I belief WG authors MIB > to help end users. > > If that is not the case, I belief I'm wasting my time over here. Once again, the WG specifies the IANA rules. And they can be as strict as requiring a standards action to make changes. The implication "IANA controlled" => "yellow book of all existing practices" is wrong. For more details, I suggest reading RFC 5226. /js -- 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 Fri Mar 18 09:43:02 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23893A695F for ; Fri, 18 Mar 2011 09:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fal7DcmzrDKF for ; Fri, 18 Mar 2011 09:43:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A9BEF3A6962 for ; Fri, 18 Mar 2011 09:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=1584; q=dns/txt; s=iport; t=1300466671; x=1301676271; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=uVcjKjMdEYQC4flEJegCajxwz8ymRiXEFglZ6qia8Do=; b=AjhJA6qt/Gn+DfoYETPNdL3MFWUapBm0KBDgw+Jbku4QwnXjo5QN2H/1 LrluhclH7fAsccv3oRXmlhSi7cdKdiwaEHyNYHf66jFA2j9cVXPoBOh5N MKRTifZ/y8E+EvW4vsL4FbvaC78wIO1eI+sUsDN2kEHuumxnt8BTYyDMD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAHMog02tJXG//2dsb2JhbACYN402d4hNnWucEAKDE4JOBIUxiwc X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208";a="348838741" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 18 Mar 2011 16:44:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2IGiO9c013109; Fri, 18 Mar 2011 16:44:30 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 09:44:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Mar 2011 09:44:28 -0700 Message-ID: In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A25C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvlhWq830ERmfb6QOKQ5nNfauSw1gAAve4gAACnLnA= References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at><20110316052854.GA2249@elstar.local><45565870-4E34-4999-8E4E-297C52460A08@quittek.at><20110318091737.GD7027@elstar.local> <4D837CE8.6030804@cisco.com> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A25C@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: "John Parello (jparello)" To: "Mielke, William F (Bill)" , "eman mailing list" X-OriginalArrivalTime: 18 Mar 2011 16:44:28.0599 (UTC) FILETIME=[BF7C2470:01CBE58B] Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:43:02 -0000 +1 If we must support interfaces of states then the two index is clearer. Next best is list with domain name style names spaces IMO Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mielke, William F (Bill) Sent: Friday, March 18, 2011 9:28 AM To: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states > Benoit Claise wrote: >=20 > I agree with your argument on reducing the error by combining two=20 > indexes into one. > However, isn't it interesting to discover which power state series=20 > (EMAN, ACPI, manufacturer, etc...) a device support? And then within=20 > that series, which states are supported? My $0.02 on this is that I can accept either approach as each has its own benefits. If I got to pick I would argue that the benefit (intuitive clarity from a modeling perspective for lack of a better description) of the 2 index approach proposed by JuergenQ outweighs the efficiency argument of JuergenS to combine the two into a single index. But this is just my personal opinion. YMMV. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From tirth.ghose@gmail.com Fri Mar 18 09:45:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0A23A695F for ; Fri, 18 Mar 2011 09:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Esci2UcBtdmC for ; Fri, 18 Mar 2011 09:45:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id F18B73A6954 for ; Fri, 18 Mar 2011 09:45:29 -0700 (PDT) Received: by iyi12 with SMTP id 12so4863641iyi.31 for ; Fri, 18 Mar 2011 09:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=jZiKtgrDokDAU2JtQCg56ucDaqly/+66KvDwL15iZJc=; b=BRubUHor82U5mlplsvZu2DRFmb18DW6sqR/vIyYEexemFFbL6U9mkOZ1RRji1zFxQ4 f8IrH22+PJIEkU6ToHbrh2cvyYQQuB9HlzsLQaBB8kDO5TqaVQypF0uHCx4aXm6B1JOE LBkHMli8XBfxG58m44yn5H3e904kElXczlxxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=jr6x+mvXGnCRNkDvcKb/peCq4xCwQC5si/hQhugLrSPb6a4sRlHumLNigcMmvr64Z4 NTKOoBMDTogCD648cq5QhGZIHiyiq2izFh/OFXwzGosupbpRFozyrgns8EvkdnoccoDb bRKHD6JYqTLBC+y3DE/yKnEmH66aP6/C7c8Co= MIME-Version: 1.0 Received: by 10.231.3.145 with SMTP id 17mr1168493ibn.83.1300466819382; Fri, 18 Mar 2011 09:46:59 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Fri, 18 Mar 2011 09:46:59 -0700 (PDT) In-Reply-To: <20110318163259.GF11947@elstar.local> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <20110318091552.GC7027@elstar.local> <20110318163259.GF11947@elstar.local> Date: Fri, 18 Mar 2011 09:46:59 -0700 X-Google-Sender-Auth: R1xdFWxDXJycWlFJSZF171J_4Ic Message-ID: From: Ted Ghose To: Juergen Schoenwaelder , Ted Ghose , Juergen Quittek , eman mailing list Content-Type: multipart/alternative; boundary=0022152d5e55cfbe52049ec48632 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:45:30 -0000 --0022152d5e55cfbe52049ec48632 Content-Type: text/plain; charset=ISO-8859-1 Hi Juergen Once again, the WG specifies the IANA rules. And they can be as strict > as requiring a standards action to make changes. The implication "IANA > controlled" => "yellow book of all existing practices" is wrong. > For more details, I suggest reading RFC 5226. > according to RFC 5226: 5. Registering New Values in an Existing Registry so, anyone can come and register a new set of states. WG will not allow that? why? why APCI and DMTF got a differential treatment? I do not see why you are saying "yellow book of all existing practices" is wrong. I clearly see that where you are taking this to, anyway! Its a mute point if u use one index or two. -tg- --0022152d5e55cfbe52049ec48632 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi =A0Juergen=A0

Once again, the WG specifies t= he IANA rules. And they can be as strict
as requiring a standards action to make changes. The i= mplication "IANA
controlled" =3D>= ; "yellow book of all existing practices" is wrong.
For more details, I sug= gest reading RFC 5226.

according= to RFC 5226:












5.  Registering New Values in an Existing Registry

so, anyone can come and register a new set of states. WG will not allow th= at? why? why APCI and DMTF got a differential treatment?

I do not see why you are saying=A0=A0"yellow book of all existing practices"= ; is wrong.

I clearly see that where you are = taking this to, anyway! Its a mute point if u use one index or two.<= /div>

-tg-
--0022152d5e55cfbe52049ec48632-- From jparello@cisco.com Fri Mar 18 09:50:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EBD93A698D for ; Fri, 18 Mar 2011 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXhDefTtbNPD for ; Fri, 18 Mar 2011 09:50:26 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 45D373A6955 for ; Fri, 18 Mar 2011 09:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=571; q=dns/txt; s=iport; t=1300467116; x=1301676716; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=rvR+tEFvZK82+rilXrKh5RxMqUDjdrRkjkUUXx5A0s4=; b=DGc0+W2cHENZ/f2XzUY9/N1ZKFBwipPEX1ToC+2SE9o2oxhWJP8579DI HDdLzwo09lfDzeCHzdfkUNtCA7yXLQLW16+MKg1ctvgGI1jqxgSWsL4UU +pGM9r0ifkZcyhIvFrGwxrPWp6MIyzki2pMv5IvN8xLIPH9oS0MDCkQPA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI8qg02tJXHA/2dsb2JhbAClbXemNZwQhWMEhTGLBw X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208";a="321879562" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2011 16:51:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2IGpsFX003175 for ; Fri, 18 Mar 2011 16:51:54 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 09:51:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Mar 2011 09:46:52 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Will orgs ( DMTF, ACPI, etc) use a state registry Thread-Index: AcvljBVBFDoN7D8PTGm36zREP0kojA== From: "John Parello (jparello)" To: "eman mailing list" X-OriginalArrivalTime: 18 Mar 2011 16:51:54.0456 (UTC) FILETIME=[C93C8580:01CBE58C] Subject: [eman] Will orgs ( DMTF, ACPI, etc) use a state registry X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:50:27 -0000 Hi, Wanted to ask this question separately to the proponents of a registry. If the WG decides to have a registry of power states in IANA (in whatever form): 1) Can this WG add states on behalf of other org like DMTF, ACPI, or manufacturers to an IANA registry? 2) If not then do those bodies need to be approached to add their states to the IANA registry? 3) Do we have a sense of their willingness to do this?=20 4) What if they don't agree to add their states? Are we left with a registry for everyone with nothing but on, off and standby? Jp From j.schoenwaelder@jacobs-university.de Fri Mar 18 10:13:19 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515663A6986 for ; Fri, 18 Mar 2011 10:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.197 X-Spam-Level: X-Spam-Status: No, score=-103.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeEYjzNGFa-T for ; Fri, 18 Mar 2011 10:13:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2E20B3A696F for ; Fri, 18 Mar 2011 10:13:18 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EFC6C001B; Fri, 18 Mar 2011 18:14:47 +0100 (CET) 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 ZvdNjlmHhYfL; Fri, 18 Mar 2011 18:14:47 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC298C0010; Fri, 18 Mar 2011 18:14:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A9023170423E; Fri, 18 Mar 2011 18:14:46 +0100 (CET) Date: Fri, 18 Mar 2011 18:14:46 +0100 From: Juergen Schoenwaelder To: Ted Ghose Message-ID: <20110318171446.GA12280@elstar.local> Mail-Followup-To: Ted Ghose , Juergen Quittek , eman mailing list References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <20110318091552.GC7027@elstar.local> <20110318163259.GF11947@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 mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:13:19 -0000 On Fri, Mar 18, 2011 at 09:46:59AM -0700, Ted Ghose wrote: > Hi Juergen > > Once again, the WG specifies the IANA rules. And they can be as strict > > as requiring a standards action to make changes. The implication "IANA > > controlled" => "yellow book of all existing practices" is wrong. > > For more details, I suggest reading RFC 5226. > > > > according to RFC 5226: > > > 5. Registering New Values in an Existing Registry > > > so, anyone can come and register a new set of states. It might help to read the whole document. > WG will not allow > that? why? why APCI and DMTF got a differential treatment? Standards are about interoperability. An open ended set of states is likely a failure from this point of view. Not recognizing widely implemented states such as ACPI is likely a failure as well. An IANA registry allows to have controlled extensibility. The WG needs to decide what the initial content of the registry should be. /js -- 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 Fri Mar 18 10:25:55 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11CE3A69AC for ; Fri, 18 Mar 2011 10:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF2D4oFFy5U8 for ; Fri, 18 Mar 2011 10:25:55 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9D72C3A69A3 for ; Fri, 18 Mar 2011 10:25:54 -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 p2IHRNqD027958 for ; Fri, 18 Mar 2011 18:27:23 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2IHRM6e023665 for ; Fri, 18 Mar 2011 18:27:23 +0100 (CET) Message-ID: <4D8395FA.8030805@cisco.com> Date: Fri, 18 Mar 2011 18:27:22 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: eman mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] EMAN Agenda Proposal X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:25:55 -0000 Dear all, Here is the agenda proposal for the 2 hours EMAN meeting. http://www.ietf.org/proceedings/80/agenda/eman.txt Any feedback is welcome. Also, Juergen Schoenwaelder kindly accepted to help the WG answering the first of the two following questions: 1. could we solve the problems specified in draft-ietf-eman-requirements with the ENTITY-MIB? 2. if yes, do we chose to do so? Indeed, we have many people with different backgrounds in the EMAN WG, and Juergen will be teach us about ENTITY MIB + SNMP context + the physical view + logical view + local versus remote Thanks in advance Juergen. Regards, Bruce and Benoit. From tirth.ghose@gmail.com Fri Mar 18 10:40:48 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A483A69B2 for ; Fri, 18 Mar 2011 10:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4khB4v2VigKt for ; Fri, 18 Mar 2011 10:40:47 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 286C03A69B7 for ; Fri, 18 Mar 2011 10:40:47 -0700 (PDT) Received: by iwl42 with SMTP id 42so4975272iwl.31 for ; Fri, 18 Mar 2011 10:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=08LEPKLuHK2BCnl3ZKZBPWAMHwa3QLyCIcUuU1bTu6Q=; b=aK5d1CzGtBVjsLUfo47ZCF8g4DUwwjrArfypP78WGzZFV7loTTxkk3eyxML6TvB4Lr mvja8iW7q7RHlCRpGW1HD8DUUKutvEcvw5zoIty1IgRsCWHe20yB6dDFxmG0epVnCtdO AQq92X4M4IpmBB7KQzlKI39Ph+OaNmBuiYn1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=gVLJcBQ6qItURVI/mTdmXsr/7u9Mw0q8OEcsdHXJXSFue3b56lRFRn5k4mScy8dy8l X/UPl5qXcUY6XKqez+umZ1BGrxJeWTmx0119J15hmWyBgmcw6i/M+C8luvtcQT3JUTI/ QSzvhqxX0GRgqEnJ33moXN1a8wjFz3gR5a+E8= MIME-Version: 1.0 Received: by 10.231.185.76 with SMTP id cn12mr1245318ibb.33.1300470136170; Fri, 18 Mar 2011 10:42:16 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Fri, 18 Mar 2011 10:42:16 -0700 (PDT) In-Reply-To: <20110318171446.GA12280@elstar.local> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <20110318091552.GC7027@elstar.local> <20110318163259.GF11947@elstar.local> <20110318171446.GA12280@elstar.local> Date: Fri, 18 Mar 2011 10:42:16 -0700 X-Google-Sender-Auth: Mc2vD4liQDeuw5hpYu-bMUu_aa8 Message-ID: From: Ted Ghose To: Juergen Schoenwaelder , Ted Ghose , Juergen Quittek , eman mailing list Content-Type: multipart/alternative; boundary=00504501623481e9f0049ec54c06 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:40:48 -0000 --00504501623481e9f0049ec54c06 Content-Type: text/plain; charset=ISO-8859-1 > > > > Once again, the WG specifies the IANA rules. And they can be as strict > > > as requiring a standards action to make changes. The implication "IANA > > > controlled" => "yellow book of all existing practices" is wrong. > > > For more details, I suggest reading RFC 5226. > > > > > > > according to RFC 5226: > > > > > > 5. Registering New Values in an Existing Registry > > > > > > so, anyone can come and register a new set of states. > > It might help to read the whole document. > whats your point? > > > WG will not allow > > that? why? why APCI and DMTF got a differential treatment? > > Standards are about interoperability. An open ended set of states is > likely a failure from this point of view. Not recognizing widely > implemented states such as ACPI is likely a failure as well. An IANA > registry allows to have controlled extensibility. The WG needs to > decide what the initial content of the registry should be. I have a great respect for standard and WG. I belief people in WG will lead and define (not open ended) a set of states. There is no question of not recognizing an implemented state like ACPI, but to give them guidance in future what IETF's state it will align to. we had miles/lb system, and it was recognized! we globally adopted SI system scientifically. We do not define a superset of different standard saying it will be flexible! My appeal to you and the WG is to define "a standard" not an yellow page of existing standards. thanks -tg- --00504501623481e9f0049ec54c06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> Once again, the WG specifies the IANA rules. And they can be as strict=
> > as requiring a standards action to make changes. The implication = "IANA
> > controlled" =3D> "yellow book of all existing practi= ces" is wrong.
> > For more details, I suggest reading RFC 5226.
> >
>
> according to RFC 5226:
>
>
> 5. =A0Registering New Values in an Existing Registry
>
>
> so, anyone can come and register a new set of states.

It might help to read the whole document.

whats your point?
=A0

> WG will not allow
> that? why? why APCI and DMTF got a differential treatment?

Standards are about interoperability. An open ended set of states is<= br> likely a failure from this point of view. Not recognizing widely
implemented states such as ACPI is likely a failure as well. An IANA
registry allows to have controlled extensibility. The WG needs to
decide what the initial content of the registry should be.

I have a great respect for standard and WG. =A0I belief peo= ple in WG will lead and define (not open ended) a set of states.

There is no question of not recognizing an implemented state= like ACPI, but to give them guidance in future what IETF's state it wi= ll align to.

we had miles/lb system, and it was re= cognized! we globally adopted SI system scientifically. We do not define a = superset of different standard saying it will be flexible!

My=A0appeal=A0to you and the WG is to define "a st= andard" not an yellow page of existing standards.

=
thanks

-tg-
--00504501623481e9f0049ec54c06-- From bill.mielke@alcatel-lucent.com Fri Mar 18 11:10:12 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8278C3A6A04 for ; Fri, 18 Mar 2011 11:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5usZkEILWauN for ; Fri, 18 Mar 2011 11:10:09 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id CCE0A3A69F6 for ; Fri, 18 Mar 2011 11:10:08 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p2IIBbo4016986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 18 Mar 2011 13:11:37 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2IIBaYp024099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 18 Mar 2011 13:11:37 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 18 Mar 2011 13:11:36 -0500 From: "Mielke, William F (Bill)" To: eman mailing list Date: Fri, 18 Mar 2011 13:11:20 -0500 Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvlhjQYqzNjqG9JQy2nS2rSx1PdQwAA6iIg Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A2FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> <20110318150557.GB19324@cslinux-build01.cyberswitching.local> <20110318154108.GB11947@elstar.local> <20110318160417.GA26516@cslinux-build01.cyberswitching.local> In-Reply-To: <20110318160417.GA26516@cslinux-build01.cyberswitching.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:10:12 -0000 > chrisv@cyberswitching.com wrote: >=20 > Wouldn't it be better to put together an interface like a=20 > Rosetta stone? > Let each user access the system in whatever ways make sense for that > user, and then have the agent provide the equivalent translation of > power states that makes sense for that agent? I think that this would be a nice thing to do but I also think that it is n= ot achievable. This notion of defining an equivalence of states between the sets is the so= urce of much of our angst here. Defining such an "eqivalency map" between = disparate sets of states is the essence of why it is difficult to create a = single common set of states in the first place. If it were possible to bucket the various states from all of these differen= t sets into "equivalence classes" then the "equivalence classes" would BE t= he universal set of states that we seek. I argue that this is not really p= ossible to do, at least not to the level people seem to want. It may be ea= sy for some states like the various "off" states, or the "on" states, but b= eyond that the underlying semantics associated with the more specialized st= ates are inherently NOT equivalent so they cannot be so cleanly grouped. Y= ou will quickly degenerate down to the point where each equivalence class i= s mapped one-to-one with a single state from a single set. So in the end y= ou have what is essentially the complete union of all the states from all t= he sets combined into one big set and I question the utility of having one = big set. For this reason I favor an approach which defines meaningful sets of states= that map cleanly to the semantics associated with the capabilities of the = device in question. The IANA proposals enable us to have state definitions= which do that while still offering some benefit to the management applicat= ions from having a constrained process for the creation of new power state = sets. The device vendors will still be constrained to using IANA registered sets = and thus they will have a reasonable incentive to reuse those sets before e= mbarking down the path of defining a whole new set. And even in the course= of defining a new set they will, presumably, be challenged to justify why = they need a whole new set instead of utilizing or extending an existing one= . Note this is likely to lead to an overall reduction in the number of unique= sets (which is what the management applications want) but in a way that do= es not require EMAN as a working group to try to be omniscient about where = things will move in the future. The list of sets will grow only as needed = and based on legitimate reasons for creating them rather than on the simple= whim of every vendor. So what does this all mean for your reference to a Rosetta Stone approach? Personally I believe that it means, or should be constrained by us to mean,= that a particular device gets to decide which state set makes sense for IT= given its capabilities and that the operators and management applications = need to talk to that device using the set IT says it understands. If a par= ticular device (or component) feels that the ACPI set best matches its need= s then it should adopt and use that set and the management applications sho= uld be constrained to talking to it using that set. A device which adopts ACPI should not be in the position of trying to guess= what a management application means when it subsequently tries to set it t= o some DMTF state. Or worse, try to guess what two different management ap= plications mean when one is speaking ACPI and the other is speaking DMTF. = If a device that adopts ACPI receives a request to set itself to a particul= ar DMTF state the response should simply be, IMHO, "No hablo DMTF. Hablo A= CPI." At least that is the case if we want to foster clear and unambiguous= communications between the management applications and the devices. Allowing the management applications to ASSUME the equivalence of states be= tween the various sets is likely to lead to the old canard about assuming t= hings (i.e. never ASSUME anything because it makes an ...). Conversely, tr= ying to force an equivalence by standards body fiat is only going to lead t= o a situation where the standard is not well adopted because it doesn't map= cleanly to the underlying reality of a given device's capabilities. I would love to be proven wrong here but thus far I remain unconvinced that= we (or anyone) can define a reasonable equivalence map between the meaning= ful power states of all possible devices. If some people here (and this is= not directed specifically at Chris or anyone else) want us to achieve a si= ngle set of such states then let's see some proposals for how to make that = actually work in real life scenarios. I certainly agree that this is a wor= thy goal, I just don't believe that it is an attainable one. So, unless and until such a unified state proposal is put forth I personall= y favor an approach which seeks to at least acknowledge the inherent real l= ife complexity we are dealing with and thus far I think that the IANA based= proposals are a pragmatic step in that direction. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein From Fritz.Ebner@xerox.com Fri Mar 18 11:10:19 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C843A6A3E for ; Fri, 18 Mar 2011 11:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Spglv3KLSSd for ; Fri, 18 Mar 2011 11:10:17 -0700 (PDT) Received: from USA7109MR004.ACS-INC.COM (usa7109mr004.acs-inc.com [63.101.151.13]) by core3.amsl.com (Postfix) with ESMTP id 023EB3A6A07 for ; Fri, 18 Mar 2011 11:10:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0GAE49g00Nh9IPgGdsb2JhbACCYJYZjHgUAQEUKCXCZoVjBIUxiwc X-IronPort-AV: E=Sophos;i="4.63,206,1299477600"; d="scan'208,217";a="22224142" Received: from usa0300gw002.na.xerox.net ([13.135.210.15]) by USA7109MR004.ACS-INC.COM with ESMTP; 18 Mar 2011 13:11:45 -0500 Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA0300GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 14:11:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE597.EF250C97" Date: Fri, 18 Mar 2011 11:11:41 -0700 Message-ID: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF EMAN request to address printers... Thread-Index: Acvll6FzD28WkpGoQ6iA8pCZYWG2+g== From: "Ebner, Fritz" To: X-OriginalArrivalTime: 18 Mar 2011 18:11:44.0756 (UTC) FILETIME=[F07A4B40:01CBE597] X-Mailman-Approved-At: Sun, 20 Mar 2011 08:55:42 -0700 Subject: [eman] IETF EMAN request to address printers... X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:11:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE597.EF250C97 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, Please make sure that any power control or monitoring MIBs or drafts that the EMAN WG produces can cover the use cases, power controls, and power monitoring features provided in the printer working group. Details are below: =20 The IEEE/ISTO Printer Working Group has published their Candidate Standard for Power Management and the associate protocol binding for SNMP. Below are the links to the abstract model and MIB. =20 PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0: =20 The PWG Power Management Model for Imaging Systems 1.0 specification was recently approved as a PWG Candidate Standard and is now available at: http://www.pwg.org/standards.html and ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf / doc =20 PWG 5106-5 - PWG Imaging System Power MIB v1.0 =20 The PWG Imaging System Power MIB v1.0 specification was recently approved as a PWG Candidate Standard and is now available at: http://www.pwg.org/standards.html and =20 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.p df / doc / mib - PDF, MS Word, and ASN.1 source in plaintext =20 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-m ib.pdf - ASN.1 source in color highlighted PDF =20 Thanks, Fritz Ebner ------_=_NextPart_001_01CBE597.EF250C97 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello,

Please = make sure that any power control or monitoring MIBs or drafts that the = EMAN WG produces can cover the use cases, power controls, and power = monitoring features provided in the printer working group.  Details = are below:

 

The IEEE/ISTO Printer Working Group has published = their Candidate Standard for Power Management and the associate protocol = binding for SNMP.  Below are the links to the abstract model and = MIB.

 

PWG 5106.4 - PWG Power = Management Model for Imaging Systems 1.0:

 

The PWG Power Management Model for = Imaging Systems 1.0 specification was
recently approved as a PWG = Candidate = Standard and = is now available at:

 http://www.pwg.org/standards.html

and
 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-201= 10214-5106.4.pdf / doc

 

PWG 5106-5 - PWG Imaging = System Power MIB v1.0

 

The PWG Imaging System Power MIB v1.0 = specification was recently approved
as a PWG Candidate = Standard and = is now available at:

 http://www.pwg.org/standards.html

and
 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-= 20110214-5106.5.pdf / doc / mib
 - PDF, MS Word, and ASN.1 = source in plaintext

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-= 20110214-5106.5-mib.pdf
 - ASN.1 source in color highlighted = PDF

 

Thanks,

Fritz = Ebner

------_=_NextPart_001_01CBE597.EF250C97-- From Rolf.Winter@neclab.eu Mon Mar 21 05:24:05 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A38328C123 for ; Mon, 21 Mar 2011 05:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIFj-z+7maNz for ; Mon, 21 Mar 2011 05:24:04 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 71F5C28C10E for ; Mon, 21 Mar 2011 05:24:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B0BFF2C0002EB; Mon, 21 Mar 2011 13:27:48 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nl+qibveR4o; Mon, 21 Mar 2011 13:27:48 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 90ADC2C0002EA; Mon, 21 Mar 2011 13:27:28 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 21 Mar 2011 13:25:16 +0100 From: Rolf Winter To: Ted Ghose , Juergen Schoenwaelder , Juergen Quittek , eman mailing list Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AQHL42y6THdhrIafvU+yzPT5yM5IhpQvXncAgAJsYICAAPezAIAAdxkAgAADCICAAAPqgIAAB8MAgAAHrwCABG3HoA== Date: Mon, 21 Mar 2011 12:25:16 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DEC846@DAPHNIS.office.hd> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <20110318091552.GC7027@elstar.local> <20110318163259.GF11947@elstar.local> <20110318171446.GA12280@elstar.local> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 12:24:05 -0000 Hi, I guess the real underlying question is whether one actually can come up wi= th one set of states that is applicable to _all_ devices out there and for = future devices yet to come. My personal take on this is that that's probabl= y not the case as the set of industry standards out there seems to imply. A= ssuming it is possible, the question arises whether the IETF folks are inde= ed the right crowd to define such a set. I have serious doubts that they ar= e. An attempt of protocol engineers to define them will likely do more harm= than good. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Ted Ghose > Sent: Freitag, 18. M=E4rz 2011 18:42 > To: Juergen Schoenwaelder; Ted Ghose; Juergen Quittek; eman mailing > list > Subject: Re: [eman] MIB-friendly proposal for flexible power states >=20 >=20 > > Once again, the WG specifies the IANA rules. And they can be as > strict > > > as requiring a standards action to make changes. The > implication "IANA > > > controlled" =3D> "yellow book of all existing practices" is > wrong. > > > For more details, I suggest reading RFC 5226. > > > > > > > according to RFC 5226: > > > > > > 5. Registering New Values in an Existing Registry > > > > > > so, anyone can come and register a new set of states. >=20 >=20 > It might help to read the whole document. >=20 >=20 >=20 > whats your point? >=20 >=20 >=20 > > WG will not allow > > that? why? why APCI and DMTF got a differential treatment? >=20 >=20 > Standards are about interoperability. An open ended set of states > is > likely a failure from this point of view. Not recognizing widely > implemented states such as ACPI is likely a failure as well. An > IANA > registry allows to have controlled extensibility. The WG needs to > decide what the initial content of the registry should be. >=20 >=20 > I have a great respect for standard and WG. I belief people in WG will > lead and define (not open ended) a set of states. >=20 > There is no question of not recognizing an implemented state like ACPI, > but to give them guidance in future what IETF's state it will align to. >=20 > we had miles/lb system, and it was recognized! we globally adopted SI > system scientifically. We do not define a superset of different > standard saying it will be flexible! >=20 > My appeal to you and the WG is to define "a standard" not an yellow > page of existing standards. >=20 > thanks >=20 > -tg- From tirth.ghose@gmail.com Mon Mar 21 08:06:43 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0253F28C157 for ; Mon, 21 Mar 2011 08:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRAuAckAYQNV for ; Mon, 21 Mar 2011 08:06:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id A6A6828C149 for ; Mon, 21 Mar 2011 08:06:41 -0700 (PDT) Received: by iyi12 with SMTP id 12so7574471iyi.31 for ; Mon, 21 Mar 2011 08:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dW7WBR3dZnuUH831XcX4AgNzylPgwpY2RiIcIO7g5tg=; b=D5cGOvfwwGLvGILX9qr+BctYCn4bR9+m+YEZ6RsT9JQdFDU9kImCUezIB4+UrxSwmL vvK0+8rJch2R7ceYD54buzhe4UAxYWcjkN9ir9Foqc+BAw9nGrmZG7JosYeE8EdLpmvi vJYEoUU6sk+ccKGlk2AYZj+kLoS732HaPqBR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=qFTQG1KWrlsNfLU6JbfKws1fCGwZuUccSsQXMXScVwMaiQWw+PtqoZlUwBOZ5qdsSp RIFlpr3YfcyFpgW2qMXZH7RAhQJP4miXhjBshdpJkL3Bt2O8XoiJDeUbSDjEAIr7Uz5u dr4zwZV30toDiVhH32K3MXZ7L37/zVLJzwi5Q= MIME-Version: 1.0 Received: by 10.43.54.133 with SMTP id vu5mr940686icb.36.1300719988182; Mon, 21 Mar 2011 08:06:28 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.231.161.17 with HTTP; Mon, 21 Mar 2011 08:06:28 -0700 (PDT) In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DEC846@DAPHNIS.office.hd> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <20110318091552.GC7027@elstar.local> <20110318163259.GF11947@elstar.local> <20110318171446.GA12280@elstar.local> <791AD3077F94194BB2BDD13565B6295D05DEC846@DAPHNIS.office.hd> Date: Mon, 21 Mar 2011 08:06:28 -0700 X-Google-Sender-Auth: vFhL-rEWVVuVcOFS9B0NEw_zdg4 Message-ID: From: Ted Ghose To: Rolf Winter Content-Type: multipart/alternative; boundary=bcaec51ddb2fd90faa049eff7847 Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:06:43 -0000 --bcaec51ddb2fd90faa049eff7847 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rolf This is a great observation, and I'm in total agreement with you. Can we take a lead to defining a broad class of devices, and seek engagemen= t of people from these industries? I refuse to call quits even without trying= . Once we have a broad classification of devices, I'll reach out to people in various industry so that we have a fair representation while defining one set of power states. Thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Mon, Mar 21, 2011 at 5:25 AM, Rolf Winter wrote: > Hi, > > I guess the real underlying question is whether one actually can come up > with one set of states that is applicable to _all_ devices out there and = for > future devices yet to come. My personal take on this is that that's proba= bly > not the case as the set of industry standards out there seems to imply. > Assuming it is possible, the question arises whether the IETF folks are > indeed the right crowd to define such a set. I have serious doubts that t= hey > are. An attempt of protocol engineers to define them will likely do more > harm than good. > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n > W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > > Ted Ghose > > Sent: Freitag, 18. M=E4rz 2011 18:42 > > To: Juergen Schoenwaelder; Ted Ghose; Juergen Quittek; eman mailing > > list > > Subject: Re: [eman] MIB-friendly proposal for flexible power states > > > > > > > Once again, the WG specifies the IANA rules. And they can be as > > strict > > > > as requiring a standards action to make changes. The > > implication "IANA > > > > controlled" =3D> "yellow book of all existing practices" is > > wrong. > > > > For more details, I suggest reading RFC 5226. > > > > > > > > > > according to RFC 5226: > > > > > > > > > 5. Registering New Values in an Existing Registry > > > > > > > > > so, anyone can come and register a new set of states. > > > > > > It might help to read the whole document. > > > > > > > > whats your point? > > > > > > > > > WG will not allow > > > that? why? why APCI and DMTF got a differential treatment? > > > > > > Standards are about interoperability. An open ended set of states > > is > > likely a failure from this point of view. Not recognizing widely > > implemented states such as ACPI is likely a failure as well. An > > IANA > > registry allows to have controlled extensibility. The WG needs to > > decide what the initial content of the registry should be. > > > > > > I have a great respect for standard and WG. I belief people in WG will > > lead and define (not open ended) a set of states. > > > > There is no question of not recognizing an implemented state like ACPI, > > but to give them guidance in future what IETF's state it will align to. > > > > we had miles/lb system, and it was recognized! we globally adopted SI > > system scientifically. We do not define a superset of different > > standard saying it will be flexible! > > > > My appeal to you and the WG is to define "a standard" not an yellow > > page of existing standards. > > > > thanks > > > > -tg- > --bcaec51ddb2fd90faa049eff7847 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rolf

This is a great observation, and I'm in tota= l=A0agreement=A0with you.

Can we take a lead to de= fining a broad class of devices, and seek engagement of people from these= =A0industries? I refuse to call quits even without trying.

Once we have a broad=A0classification=A0of devices, I&#= 39;ll reach out to people in various industry so that we have a fair repres= entation while=A0defining=A0one set of power states.

Thanks

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:= *'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time... see it my way
*:-.,_,.-:*&#= 39;``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-= .,_,.


On Mon, Mar 21, 2011 at 5:25 AM, Rolf Wi= nter <Rolf.Wi= nter@neclab.eu> wrote:
Hi,

I guess the real underlying question is whether one actually can come up wi= th one set of states that is applicable to _all_ devices out there and for = future devices yet to come. My personal take on this is that that's pro= bably not the case as the set of industry standards out there seems to impl= y. Assuming it is possible, the question arises whether the IETF folks are = indeed the right crowd to define such a set. I have serious doubts that the= y are. An attempt of protocol engineers to define them will likely do more = harm than good.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014


> -----Original Message-----
> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
> Ted Ghose
> Sent: Freitag, 18. M=E4rz 2011 18:42
> To: Juergen Schoenwaelder; Ted Ghose; Juergen Quittek; eman mailing > list
> Subject: Re: [eman] MIB-friendly proposal for flexible power states >
>
> =A0 =A0 =A0 > Once again, t= he WG specifies the IANA rules. And they can be as
> strict
> =A0 =A0 =A0 > > as requiring a standards action to make changes.= The
> implication "IANA
> =A0 =A0 =A0 > > controlled" =3D> "yellow book of al= l existing practices" is
> wrong.
> =A0 =A0 =A0 > > For more details, I suggest reading RFC 5226. > =A0 =A0 =A0 > >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > according to RFC 5226:
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > 5. =A0Registering New Values in an Existing Registry<= br> > =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > so, anyone can come and register a new set of states.=
>
>
> =A0 =A0 =A0 It might help to read the whole document.
>
>
>
> whats your point?
>
>
>
> =A0 =A0 =A0 > WG will not allow
> =A0 =A0 =A0 > that? why? why APCI and DMTF got a differential treat= ment?
>
>
> =A0 =A0 =A0 Standards are about interoperability. An open ended set of= states
> is
> =A0 =A0 =A0 likely a failure from this point of view. Not recognizing = widely
> =A0 =A0 =A0 implemented states such as ACPI is likely a failure as wel= l. An
> IANA
> =A0 =A0 =A0 registry allows to have controlled extensibility. The WG n= eeds to
> =A0 =A0 =A0 decide what the initial content of the registry should be.=
>
>
> I have a great respect for standard and WG. =A0I belief people in WG w= ill
> lead and define (not open ended) a set of states.
>
> There is no question of not recognizing an implemented state like ACPI= ,
> but to give them guidance in future what IETF's state it will alig= n to.
>
> we had miles/lb system, and it was recognized! we globally adopted SI<= br> > system scientifically. We do not define a superset of different
> standard saying it will be flexible!
>
> My appeal to you and the WG is to define "a standard" not an= yellow
> page of existing standards.
>
> thanks
>
> -tg-

--bcaec51ddb2fd90faa049eff7847-- From bclaise@cisco.com Tue Mar 22 02:43:49 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1275A3A67F2 for ; Tue, 22 Mar 2011 02:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQnVP2UOK3ji for ; Tue, 22 Mar 2011 02:43:47 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 79FF93A67F3 for ; Tue, 22 Mar 2011 02:43:47 -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 p2M9jJdI027303 for ; Tue, 22 Mar 2011 10:45:20 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2M9jJPg016242 for ; Tue, 22 Mar 2011 10:45:19 +0100 (CET) Message-ID: <4D886FAF.50100@cisco.com> Date: Tue, 22 Mar 2011 10:45:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: eman mailing list Content-Type: multipart/mixed; boundary="------------080007030906040308010501" Subject: [eman] Applicability statement: IEEE/ISTO Printer Working Group and ODVA X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 09:43:49 -0000 This is a multi-part message in MIME format. --------------080007030906040308010501 Content-Type: multipart/alternative; boundary="------------050602040900060607090205" --------------050602040900060607090205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear applicability statement authors, From the charter: 6. Applicability statement The EMAN WG will develop an applicability statement, describing the variety of applications that can use the energy framework and associated MIB modules. Potential examples are building networks, home energy gateway, etc. Finally, the document will also discuss relationships of the framework to other architectures and frameworks (such as smartgrid). The applicability statement will explain the relationship between the work in this WG and the other existing standards such as those from the IEC, ANSI, DMTF, and others. That would be great, if you could say a few words about IEEE/ISTO Printer Working Group. Btw, ODVA would be interesting to add as well. Remember that they will be an OVDA presentation in Prague. Regards, Benoit. -------- Original Message -------- Subject: [eman] IETF EMAN request to address printers... Date: Fri, 18 Mar 2011 11:11:41 -0700 From: Ebner, Fritz To: Hello, Please make sure that any power control or monitoring MIBs or drafts that the EMAN WG produces can cover the use cases, power controls, and power monitoring features provided in the printer working group. Details are below: The IEEE/ISTO Printer Working Group has published their Candidate Standard for Power Management and the associate protocol binding for SNMP. Below are the links to the abstract model and MIB. PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0: The PWG Power Management Model for Imaging Systems 1.0 specification was recently approved as a PWG Candidate Standard and is now available at: http://www.pwg.org/standards.html and ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf / doc PWG 5106-5 - PWG Imaging System Power MIB v1.0 The PWG Imaging System Power MIB v1.0 specification was recently approved as a PWG Candidate Standard and is now available at: http://www.pwg.org/standards.html and ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf / doc / mib - PDF, MS Word, and ASN.1 source in plaintext ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf - ASN.1 source in color highlighted PDF Thanks, Fritz Ebner --------------050602040900060607090205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear applicability statement authors,

From the charter:
6. Applicability statement
The EMAN WG will develop an applicability statement, describing the
variety of applications that can use the energy framework and associated
MIB modules. Potential examples are building networks, home energy
gateway, etc. Finally, the document will also discuss relationships of
the framework to other architectures and frameworks (such as smartgrid).
The applicability statement will explain the relationship between the
work in this WG and the other existing standards such as those from the
IEC, ANSI, DMTF, and others.

That would be great, if you could say a few words about IEEE/ISTO Printer Working Group.
Btw, ODVA would be interesting to add as well. Remember that they will be an OVDA presentation in Prague.

Regards, Benoit.

-------- Original Message --------
Subject: [eman] IETF EMAN request to address printers...
Date: Fri, 18 Mar 2011 11:11:41 -0700
From: Ebner, Fritz <Fritz.Ebner@xerox.com>
To: <eman@ietf.org>


Hello,

Please make sure that any power control or monitoring MIBs or drafts that the EMAN WG produces can cover the use cases, power controls, and power monitoring features provided in the printer working group.  Details are below:

 

The IEEE/ISTO Printer Working Group has published their Candidate Standard for Power Management and the associate protocol binding for SNMP.  Below are the links to the abstract model and MIB.

 

PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:

 

PWG 5106-5 - PWG Imaging System Power MIB v1.0

 

The PWG Imaging System Power MIB v1.0 specification was recently approved
as a PWG Candidate Standard and is now available at:

 http://www.pwg.org/standards.html

and

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf / doc / mib
 - PDF, MS Word, and ASN.1 source in plaintext

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf
 - ASN.1 source in color highlighted PDF

 

Thanks,

Fritz Ebner

--------------050602040900060607090205-- --------------080007030906040308010501 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman --------------080007030906040308010501-- From bclaise@cisco.com Tue Mar 22 02:44:57 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0200D3A67F2 for ; Tue, 22 Mar 2011 02:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LNfC-slq0Qw for ; Tue, 22 Mar 2011 02:44:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id B8B5C3A67D0 for ; Tue, 22 Mar 2011 02:44:52 -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 p2M9geJf027032; Tue, 22 Mar 2011 10:42:40 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2M9gadg013238; Tue, 22 Mar 2011 10:42:36 +0100 (CET) Message-ID: <4D886F0C.2090207@cisco.com> Date: Tue, 22 Mar 2011 10:42:36 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Ebner, Fritz" References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> In-Reply-To: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> Content-Type: multipart/alternative; boundary="------------080802050504040607040001" Cc: eman@ietf.org Subject: Re: [eman] IETF EMAN request to address printers... X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 09:44:57 -0000 This is a multi-part message in MIME format. --------------080802050504040607040001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Fritz, Thanks for your participation to this WG. May I ask you a favor? Can you please provide your feedback the requirements draft: http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/. I'm wondering if this draft addresses for "your" printer issues, or if we need to adapt it. Regards, Benoit. > Hello, > > Please make sure that any power control or monitoring MIBs or drafts > that the EMAN WG produces can cover the use cases, power controls, and > power monitoring features provided in the printer working group. > Details are below: > > The IEEE/ISTO Printer Working Group has published their Candidate > Standard for Power Management and the associate protocol binding for > SNMP. Below are the links to the abstract model and MIB. > > PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0: > > The PWG Power Management Model for Imaging Systems 1.0 specification was > recently approved as a PWG Candidate Standard and is now available at: > > http://www.pwg.org/standards.html > > and > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf / > doc > > PWG 5106-5 - PWG Imaging System Power MIB v1.0 > > The PWG Imaging System Power MIB v1.0 specification was recently approved > as a PWG Candidate Standard and is now available at: > > http://www.pwg.org/standards.html > > and > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf > / doc / mib > - PDF, MS Word, and ASN.1 source in plaintext > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf > - ASN.1 source in color highlighted PDF > > Thanks, > > Fritz Ebner > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------080802050504040607040001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Fritz,

Thanks for your participation to this WG.
May I ask you a favor? Can you please provide your feedback the requirements draft: http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/.
I'm wondering if this draft addresses for "your" printer issues, or if we need to adapt it.

Regards, Benoit.

Hello,

Please make sure that any power control or monitoring MIBs or drafts that the EMAN WG produces can cover the use cases, power controls, and power monitoring features provided in the printer working group.  Details are below:

 

The IEEE/ISTO Printer Working Group has published their Candidate Standard for Power Management and the associate protocol binding for SNMP.  Below are the links to the abstract model and MIB.

 

PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0:

 

The PWG Power Management Model for Imaging Systems 1.0 specification was
recently approved as a PWG Candidate Standard and is now available at:

 http://www.pwg.org/standards.html

and

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf / doc

 

PWG 5106-5 - PWG Imaging System Power MIB v1.0

 

The PWG Imaging System Power MIB v1.0 specification was recently approved
as a PWG Candidate Standard and is now available at:

 http://www.pwg.org/standards.html

and

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf / doc / mib
 - PDF, MS Word, and ASN.1 source in plaintext

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf
 - ASN.1 source in color highlighted PDF

 

Thanks,

Fritz Ebner


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

--------------080802050504040607040001-- From bclaise@cisco.com Tue Mar 22 03:57:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60303A6840 for ; Tue, 22 Mar 2011 03:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMna-Q9WZVtT for ; Tue, 22 Mar 2011 03:57:29 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id BC5983A6817 for ; Tue, 22 Mar 2011 03:57:28 -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 p2MA8HoV029354; Tue, 22 Mar 2011 11:08:17 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2MA8GPK014791; Tue, 22 Mar 2011 11:08:16 +0100 (CET) Message-ID: <4D887510.50507@cisco.com> Date: Tue, 22 Mar 2011 11:08:16 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Mielke, William F (Bill)" References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> <20110318150557.GB19324@cslinux-build01.cyberswitching.local> <20110318154108.GB11947@elstar.local> <20110318160417.GA26516@cslinux-build01.cyberswitching.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A2FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A2FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------020008010102010307040907" Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 10:57:30 -0000 This is a multi-part message in MIME format. --------------020008010102010307040907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi William, I like your analysis, and I arrive to the same conclusion in http://www.ietf.org/mail-archive/web/eman/current/msg00221.html Based on the recent conclusions, I would complement my analysis What I believe the solution is in terms of EMAN: - we must be ready to support multiple power states series - we must be ready to support a new power states series. - the device must report which power states series it supports With - lock the IANA process so that we don't have an explosion of new power states (series) Regards, Benoit. >> chrisv@cyberswitching.com wrote: >> >> Wouldn't it be better to put together an interface like a >> Rosetta stone? >> Let each user access the system in whatever ways make sense for that >> user, and then have the agent provide the equivalent translation of >> power states that makes sense for that agent? > I think that this would be a nice thing to do but I also think that it is not achievable. > > This notion of defining an equivalence of states between the sets is the source of much of our angst here. Defining such an "eqivalency map" between disparate sets of states is the essence of why it is difficult to create a single common set of states in the first place. > > If it were possible to bucket the various states from all of these different sets into "equivalence classes" then the "equivalence classes" would BE the universal set of states that we seek. I argue that this is not really possible to do, at least not to the level people seem to want. It may be easy for some states like the various "off" states, or the "on" states, but beyond that the underlying semantics associated with the more specialized states are inherently NOT equivalent so they cannot be so cleanly grouped. You will quickly degenerate down to the point where each equivalence class is mapped one-to-one with a single state from a single set. So in the end you have what is essentially the complete union of all the states from all the sets combined into one big set and I question the utility of having one big set. > > For this reason I favor an approach which defines meaningful sets of states that map cleanly to the semantics associated with the capabilities of the device in question. The IANA proposals enable us to have state definitions which do that while still offering some benefit to the management applications from having a constrained process for the creation of new power state sets. > > The device vendors will still be constrained to using IANA registered sets and thus they will have a reasonable incentive to reuse those sets before embarking down the path of defining a whole new set. And even in the course of defining a new set they will, presumably, be challenged to justify why they need a whole new set instead of utilizing or extending an existing one. > > Note this is likely to lead to an overall reduction in the number of unique sets (which is what the management applications want) but in a way that does not require EMAN as a working group to try to be omniscient about where things will move in the future. The list of sets will grow only as needed and based on legitimate reasons for creating them rather than on the simple whim of every vendor. > > So what does this all mean for your reference to a Rosetta Stone approach? > > Personally I believe that it means, or should be constrained by us to mean, that a particular device gets to decide which state set makes sense for IT given its capabilities and that the operators and management applications need to talk to that device using the set IT says it understands. If a particular device (or component) feels that the ACPI set best matches its needs then it should adopt and use that set and the management applications should be constrained to talking to it using that set. > > A device which adopts ACPI should not be in the position of trying to guess what a management application means when it subsequently tries to set it to some DMTF state. Or worse, try to guess what two different management applications mean when one is speaking ACPI and the other is speaking DMTF. If a device that adopts ACPI receives a request to set itself to a particular DMTF state the response should simply be, IMHO, "No hablo DMTF. Hablo ACPI." At least that is the case if we want to foster clear and unambiguous communications between the management applications and the devices. > > Allowing the management applications to ASSUME the equivalence of states between the various sets is likely to lead to the old canard about assuming things (i.e. never ASSUME anything because it makes an ...). Conversely, trying to force an equivalence by standards body fiat is only going to lead to a situation where the standard is not well adopted because it doesn't map cleanly to the underlying reality of a given device's capabilities. > > I would love to be proven wrong here but thus far I remain unconvinced that we (or anyone) can define a reasonable equivalence map between the meaningful power states of all possible devices. If some people here (and this is not directed specifically at Chris or anyone else) want us to achieve a single set of such states then let's see some proposals for how to make that actually work in real life scenarios. I certainly agree that this is a worthy goal, I just don't believe that it is an attainable one. > > So, unless and until such a unified state proposal is put forth I personally favor an approach which seeks to at least acknowledge the inherent real life complexity we are dealing with and thus far I think that the IANA based proposals are a pragmatic step in that direction. > > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 > > "Live like you're going to die tomorrow. > Learn like you're going to live forever." > > - Albert Einstein > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --------------020008010102010307040907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi William,

I like your analysis, and I arrive to the same conclusion in http://www.ietf.org/mail-archive/web/eman/current/msg00221.html

Based on the recent conclusions, I would complement my analysis
What I believe the solution is in terms of EMAN:
- we must be ready to support multiple power states series
- we must be ready to support a new power states series.
- the device must report which power states series it supports
With
          - lock the IANA process so that we don't have an explosion of new power states (series)

Regards, Benoit.
chrisv@cyberswitching.com wrote:

Wouldn't it be better to put together an interface like a 
Rosetta stone?
Let each user access the system in whatever ways make sense for that
user, and then have the agent provide the equivalent translation of
power states that makes sense for that agent?

I think that this would be a nice thing to do but I also think that it is not achievable.

This notion of defining an equivalence of states between the sets is the source of much of our angst here.  Defining such an "eqivalency map" between disparate sets of states is the essence of why it is difficult to create a single common set of states in the first place.

If it were possible to bucket the various states from all of these different sets into "equivalence classes" then the "equivalence classes" would BE the universal set of states that we seek.  I argue that this is not really possible to do, at least not to the level people seem to want.  It may be easy for some states like the various "off" states, or the "on" states, but beyond that the underlying semantics associated with the more specialized states are inherently NOT equivalent so they cannot be so cleanly grouped.  You will quickly degenerate down to the point where each equivalence class is mapped one-to-one with a single state from a single set.  So in the end you have what is essentially the complete union of all the states from all the sets combined into one big set and I question the utility of having one big set.

For this reason I favor an approach which defines meaningful sets of states that map cleanly to the semantics associated with the capabilities of the device in question.  The IANA proposals enable us to have state definitions which do that while still offering some benefit to the management applications from having a constrained process for the creation of new power state sets.

The device vendors will still be constrained to using IANA registered sets and thus they will have a reasonable incentive to reuse those sets before embarking down the path of defining a whole new set.  And even in the course of defining a new set they will, presumably, be challenged to justify why they need a whole new set instead of utilizing or extending an existing one.

Note this is likely to lead to an overall reduction in the number of unique sets (which is what the management applications want) but in a way that does not require EMAN as a working group to try to be omniscient about where things will move in the future.  The list of sets will grow only as needed and based on legitimate reasons for creating them rather than on the simple whim of every vendor.

So what does this all mean for your reference to a Rosetta Stone approach?

Personally I believe that it means, or should be constrained by us to mean, that a particular device gets to decide which state set makes sense for IT given its capabilities and that the operators and management applications need to talk to that device using the set IT says it understands.  If a particular device (or component) feels that the ACPI set best matches its needs then it should adopt and use that set and the management applications should be constrained to talking to it using that set.

A device which adopts ACPI should not be in the position of trying to guess what a management application means when it subsequently tries to set it to some DMTF state.  Or worse, try to guess what two different management applications mean when one is speaking ACPI and the other is speaking DMTF.  If a device that adopts ACPI receives a request to set itself to a particular DMTF state the response should simply be, IMHO, "No hablo DMTF.  Hablo ACPI."  At least that is the case if we want to foster clear and unambiguous communications between the management applications and the devices.

Allowing the management applications to ASSUME the equivalence of states between the various sets is likely to lead to the old canard about assuming things (i.e. never ASSUME anything because it makes an ...).  Conversely, trying to force an equivalence by standards body fiat is only going to lead to a situation where the standard is not well adopted because it doesn't map cleanly to the underlying reality of a given device's capabilities.

I would love to be proven wrong here but thus far I remain unconvinced that we (or anyone) can define a reasonable equivalence map between the meaningful power states of all possible devices.  If some people here (and this is not directed specifically at Chris or anyone else) want us to achieve a single set of such states then let's see some proposals for how to make that actually work in real life scenarios.  I certainly agree that this is a worthy goal, I just don't believe that it is an attainable one.

So, unless and until such a unified state proposal is put forth I personally favor an approach which seeks to at least acknowledge the inherent real life complexity we are dealing with and thus far I think that the IANA based proposals are a pragmatic step in that direction.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

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

--------------020008010102010307040907-- From jparello@cisco.com Tue Mar 22 07:15:14 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585E528C0D0 for ; Tue, 22 Mar 2011 07:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlb6Mv2UOpLx for ; Tue, 22 Mar 2011 07:15:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A7E9F28C113 for ; Tue, 22 Mar 2011 07:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=16882; q=dns/txt; s=iport; t=1300803404; x=1302013004; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=O+/HotEIuCkqRa4gLjpytTkvZ9a8LGfPZ6yFJ7SP8oM=; b=FJRfa4iY5pupQ7MOFhODvozu5yGpBtPHqYPbBAaGubk3eBHBNHVwa5/S oQxF0xPYhzyoOiJUCQwwJcXo62aZMQJ4cq2cvc+U6Na99PPV8H7NmgKZa 60PmqM/Z2IhTzYtop/KVc//2myWwBHskoD2WJexMRmEzgLjxN7Ryt05cp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAIdLiE2rRDoI/2dsb2JhbACCYZUkjTZ3pkWcZoVoBIU1iw4 X-IronPort-AV: E=Sophos;i="4.63,224,1299456000"; d="scan'208,217";a="669390309" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2011 14:16:42 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2MEGgdb023381 for ; Tue, 22 Mar 2011 14:16:42 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Mar 2011 07:16:42 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE89B.C4822204" Date: Tue, 22 Mar 2011 07:13:21 -0700 Message-ID: In-Reply-To: <4D886FAF.50100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Applicability statement: IEEE/ISTO Printer Working Group Thread-Index: AcvodeKyC7d8Ky9yTTiH6gnpZonvfQAJVreQ References: <4D886FAF.50100@cisco.com> From: "John Parello (jparello)" To: "Benoit Claise (bclaise)" , "eman mailing list" X-OriginalArrivalTime: 22 Mar 2011 14:16:42.0939 (UTC) FILETIME=[C4CAC8B0:01CBE89B] Subject: Re: [eman] Applicability statement: IEEE/ISTO Printer Working Group X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 14:15:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE89B.C4822204 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI All, =20 I don't think the ODVA applies to the IEEE/ISTO Printer working group. It's a different organization. =20 Jp =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Benoit Claise (bclaise) Sent: Tuesday, March 22, 2011 2:45 AM To: eman mailing list Subject: [eman] Applicability statement: IEEE/ISTO Printer Working Group andODVA =20 Dear applicability statement authors, >From the charter: 6. Applicability statement The EMAN WG will develop an applicability statement, describing the variety of applications that can use the energy framework and associated MIB modules. Potential examples are building networks, home energy gateway, etc. Finally, the document will also discuss relationships of the framework to other architectures and frameworks (such as smartgrid). The applicability statement will explain the relationship between the work in this WG and the other existing standards such as those from the IEC, ANSI, DMTF, and others. That would be great, if you could say a few words about IEEE/ISTO Printer Working Group. Btw, ODVA would be interesting to add as well. Remember that they will be an OVDA presentation in Prague. Regards, Benoit. -------- Original Message --------=20 Subject:=20 [eman] IETF EMAN request to address printers... Date:=20 Fri, 18 Mar 2011 11:11:41 -0700 From:=20 Ebner, Fritz =20 To:=20 =20 Hello, Please make sure that any power control or monitoring MIBs or drafts that the EMAN WG produces can cover the use cases, power controls, and power monitoring features provided in the printer working group. Details are below: =20 The IEEE/ISTO Printer Working Group has published their Candidate Standard for Power Management and the associate protocol binding for SNMP. Below are the links to the abstract model and MIB. =20 PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0: =20 The PWG Power Management Model for Imaging Systems 1.0 specification was recently approved as a PWG Candidate Standard and is now available at: http://www.pwg.org/standards.html and ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf / doc =20 PWG 5106-5 - PWG Imaging System Power MIB v1.0 =20 The PWG Imaging System Power MIB v1.0 specification was recently approved as a PWG Candidate Standard and is now available at: http://www.pwg.org/standards.html and =20 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.p df / doc / mib - PDF, MS Word, and ASN.1 source in plaintext =20 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-m ib.pdf - ASN.1 source in color highlighted PDF =20 Thanks, Fritz Ebner ------_=_NextPart_001_01CBE89B.C4822204 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI = All,

 

I don’t think = the ODVA applies to the IEEE/ISTO Printer working group. It’s a different organization.

 

Jp

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Benoit Claise = (bclaise)
Sent: Tuesday, March 22, 2011 2:45 AM
To: eman mailing list
Subject: [eman] Applicability statement: IEEE/ISTO Printer = Working Group andODVA

 

Dear applicability statement authors,

>From the charter:

6. Applicability statement
The EMAN WG will develop an applicability statement, describing the
variety of applications that can use the energy framework and = associated
MIB modules. Potential examples are building networks, home energy
gateway, etc. Finally, the document will also discuss relationships = of
the framework to other architectures and frameworks (such as = smartgrid).
The applicability statement will explain the relationship between = the
work in this WG and the other existing standards such as those from = the
IEC, ANSI, DMTF, and others.


That would be great, if you could say a few words about IEEE/ISTO = Printer Working Group.
Btw, ODVA would be interesting to add as well. Remember that they will = be an OVDA presentation in Prague.

Regards, Benoit.

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

Subject:

[eman] IETF EMAN request to address printers...

Date: =

Fri, 18 Mar 2011 11:11:41 -0700

From: =

Ebner, Fritz <Fritz.Ebner@xerox.com>

To: =

<eman@ietf.org>=




Hello,

Please make sure that any power control or = monitoring MIBs or drafts that the EMAN WG produces can cover the use cases, power controls, and power monitoring features provided in the printer working group.  Details are below:

 

The IEEE/ISTO Printer Working Group has published = their Candidate Standard for Power Management and the associate protocol = binding for SNMP.  Below are the links to the abstract model and = MIB.

 

PWG 5106.4 - PWG = Power Management Model for Imaging Systems 1.0:

 

The PWG Power Management Model for Imaging Systems = 1.0 specification was
recently approved as a PWG Candidate Standard and is now available at:

 http://www.pwg.org/standards.html

and

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-201= 10214-5106.4.pdf / doc

 

PWG 5106-5 - PWG = Imaging System Power MIB v1.0

 

The PWG Imaging System Power MIB v1.0 specification = was recently approved
as a PWG Candidate Standard and is now available at:

 http://www.pwg.org/standards.html

and

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-= 20110214-5106.5.pdf / doc / mib
 - PDF, MS Word, and ASN.1 source in plaintext

 ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-= 20110214-5106.5-mib.pdf
 - ASN.1 source in color highlighted PDF

 

Thanks,

Fritz Ebner

------_=_NextPart_001_01CBE89B.C4822204-- From tirth.ghose@gmail.com Tue Mar 22 07:51:26 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19FE28C13D for ; Tue, 22 Mar 2011 07:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA-zsOBh2Kqa for ; Tue, 22 Mar 2011 07:51:19 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id E5FB928C140 for ; Tue, 22 Mar 2011 07:51:18 -0700 (PDT) Received: by yic13 with SMTP id 13so3435885yic.31 for ; Tue, 22 Mar 2011 07:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1rMVadqik2r5Xo8WV2RhDy1s3zRNBLaTZq8xG6B0oMs=; b=ZA+FE1L4jyxzxlN7LTLyY3+zWKUNLS90wnFhf5Cj4Nmdg4nGOAgu4AP1xAf/cO9sPC fioLuNutevp9yJr5YnlNwLZUCe2EiABfwOL/JQfMOhiovbFhL1TjClvfWRTZT7SCitpm ZZI0CiFo4CgotCvzGQUP9wmYny4euzodOlouE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=M/wPrZPGZQ38HsNbzmp9i9fQRyoX14d0+jhxF+fMuWAea5bs4WA3iwmF2QEoP5LKEl RYj5GRzSrffK5cfl9zqdJfMk48Uy6PKekhX4wNYNpzLCGj+IqXdRnUyY51hcrIv6dUAE f6yDaROz24sJhfipe/zMwWBGQeiHAfyGg3TPk= MIME-Version: 1.0 Received: by 10.151.133.17 with SMTP id k17mr5092365ybn.412.1300805571913; Tue, 22 Mar 2011 07:52:51 -0700 (PDT) Sender: tirth.ghose@gmail.com Received: by 10.151.158.17 with HTTP; Tue, 22 Mar 2011 07:52:51 -0700 (PDT) In-Reply-To: <4D887510.50507@cisco.com> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> <20110318150557.GB19324@cslinux-build01.cyberswitching.local> <20110318154108.GB11947@elstar.local> <20110318160417.GA26516@cslinux-build01.cyberswitching.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A2FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D887510.50507@cisco.com> Date: Tue, 22 Mar 2011 07:52:51 -0700 X-Google-Sender-Auth: xW3GvqNbIhYG_GYN-hCV9QMQYMk Message-ID: From: Ted Ghose To: Benoit Claise Content-Type: multipart/alternative; boundary=001485eb9de4092a14049f1366a8 Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 14:51:26 -0000 --001485eb9de4092a14049f1366a8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Benoit I see a great value to define one standard power state set. supporting multiple power state series will bring more confusion thanks -tg- *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. Save time... see it my way *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. On Tue, Mar 22, 2011 at 3:08 AM, Benoit Claise wrote: > Hi William, > > I like your analysis, and I arrive to the same conclusion in > http://www.ietf.org/mail-archive/web/eman/current/msg00221.html > > Based on the recent conclusions, I would complement my analysis > > What I believe the solution is in terms of EMAN: > - we must be ready to support multiple power states series > - we must be ready to support a new power states series. > - the device must report which power states series it supports > > With > - lock the IANA process so that we don't have an explosion of n= ew > power states (series) > > Regards, Benoit. > > chrisv@cyberswitching.com wrote: > > Wouldn't it be better to put together an interface like a > Rosetta stone? > Let each user access the system in whatever ways make sense for that > user, and then have the agent provide the equivalent translation of > power states that makes sense for that agent? > > I think that this would be a nice thing to do but I also think that it i= s not achievable. > > This notion of defining an equivalence of states between the sets is the = source of much of our angst here. Defining such an "eqivalency map" betwee= n disparate sets of states is the essence of why it is difficult to create = a single common set of states in the first place. > > If it were possible to bucket the various states from all of these differ= ent sets into "equivalence classes" then the "equivalence classes" would BE= the universal set of states that we seek. I argue that this is not really= possible to do, at least not to the level people seem to want. It may be = easy for some states like the various "off" states, or the "on" states, but= beyond that the underlying semantics associated with the more specialized = states are inherently NOT equivalent so they cannot be so cleanly grouped. = You will quickly degenerate down to the point where each equivalence class= is mapped one-to-one with a single state from a single set. So in the end= you have what is essentially the complete union of all the states from all= the sets combined into one big set and I question the utility of having on= e big set. > > For this reason I favor an approach which defines meaningful sets of stat= es that map cleanly to the semantics associated with the capabilities of th= e device in question. The IANA proposals enable us to have state definitio= ns which do that while still offering some benefit to the management applic= ations from having a constrained process for the creation of new power stat= e sets. > > The device vendors will still be constrained to using IANA registered set= s and thus they will have a reasonable incentive to reuse those sets before= embarking down the path of defining a whole new set. And even in the cour= se of defining a new set they will, presumably, be challenged to justify wh= y they need a whole new set instead of utilizing or extending an existing o= ne. > > Note this is likely to lead to an overall reduction in the number of uniq= ue sets (which is what the management applications want) but in a way that = does not require EMAN as a working group to try to be omniscient about wher= e things will move in the future. The list of sets will grow only as neede= d and based on legitimate reasons for creating them rather than on the simp= le whim of every vendor. > > So what does this all mean for your reference to a Rosetta Stone approach= ? > > Personally I believe that it means, or should be constrained by us to mea= n, that a particular device gets to decide which state set makes sense for = IT given its capabilities and that the operators and management application= s need to talk to that device using the set IT says it understands. If a p= articular device (or component) feels that the ACPI set best matches its ne= eds then it should adopt and use that set and the management applications s= hould be constrained to talking to it using that set. > > A device which adopts ACPI should not be in the position of trying to gue= ss what a management application means when it subsequently tries to set it= to some DMTF state. Or worse, try to guess what two different management = applications mean when one is speaking ACPI and the other is speaking DMTF.= If a device that adopts ACPI receives a request to set itself to a partic= ular DMTF state the response should simply be, IMHO, "No hablo DMTF. Hablo= ACPI." At least that is the case if we want to foster clear and unambiguo= us communications between the management applications and the devices. > > Allowing the management applications to ASSUME the equivalence of states = between the various sets is likely to lead to the old canard about assuming= things (i.e. never ASSUME anything because it makes an ...). Conversely, = trying to force an equivalence by standards body fiat is only going to lead= to a situation where the standard is not well adopted because it doesn't m= ap cleanly to the underlying reality of a given device's capabilities. > > I would love to be proven wrong here but thus far I remain unconvinced th= at we (or anyone) can define a reasonable equivalence map between the meani= ngful power states of all possible devices. If some people here (and this = is not directed specifically at Chris or anyone else) want us to achieve a = single set of such states then let's see some proposals for how to make tha= t actually work in real life scenarios. I certainly agree that this is a w= orthy goal, I just don't believe that it is an attainable one. > > So, unless and until such a unified state proposal is put forth I persona= lly favor an approach which seeks to at least acknowledge the inherent real= life complexity we are dealing with and thus far I think that the IANA bas= ed proposals are a pragmatic step in that direction. > > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 > > "Live like you're going to die tomorrow. > Learn like you're going to live forever." > > - Albert Einstein > _______________________________________________ > eman mailing listeman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --001485eb9de4092a14049f1366a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi=A0Benoit=A0

I see a great value to define one standar= d power state set.

supporting multiple power state= series will bring more confusion

thanks

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'= ;``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 Save time... see it my way
*:-.,_,.-:*'``= '*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.=


On Tue, Mar 22, 2011 at 3:08 AM, Benoit = Claise <bclaise@c= isco.com> wrote:
=20 =20 =20
Hi William,

I like your analysis, and I arrive to the same conclusion in http://www.ietf.org/mail-archive/web/eman/current/ms= g00221.html

Based on the recent conclusions, I would complement my analysis
What I believe the solution is in terms of EMAN:
- we must be ready to support multiple power states series
- we must be ready to support a new power states series.
- the device must report which power states series it supports
With
=A0=A0=A0=A0=A0=A0=A0=A0=A0 - lock the IANA process so that we don'= t have an explosion of new power states (series)

Regards, Benoit.

chrisv@cyberswitching.com wrote:

Wouldn't it be better to put together an interface like a=20
Rosetta stone?
Let each user access the system in whatever ways make sense for that
user, and then have the agent provide the equivalent translation of
power states that makes sense for that agent?

I think that this would be a nice thing to do but I also think t=
hat it is not achievable.

This notion of defining an equivalence of states between the sets is the so=
urce of much of our angst here.  Defining such an "eqivalency map"=
; between disparate sets of states is the essence of why it is difficult to=
 create a single common set of states in the first place.

If it were possible to bucket the various states from all of these differen=
t sets into "equivalence classes" then the "equivalence clas=
ses" would BE the universal set of states that we seek.  I argue that =
this is not really possible to do, at least not to the level people seem to=
 want.  It may be easy for some states like the various "off" sta=
tes, or the "on" states, but beyond that the underlying semantics=
 associated with the more specialized states are inherently NOT equivalent =
so they cannot be so cleanly grouped.  You will quickly degenerate down to =
the point where each equivalence class is mapped one-to-one with a single s=
tate from a single set.  So in the end you have what is essentially the com=
plete union of all the states from all the sets combined into one big set a=
nd I question the utility of having one big set.

For this reason I favor an approach which defines meaningful sets of states=
 that map cleanly to the semantics associated with the capabilities of the =
device in question.  The IANA proposals enable us to have state definitions=
 which do that while still offering some benefit to the management applicat=
ions from having a constrained process for the creation of new power state =
sets.

The device vendors will still be constrained to using IANA registered sets =
and thus they will have a reasonable incentive to reuse those sets before e=
mbarking down the path of defining a whole new set.  And even in the course=
 of defining a new set they will, presumably, be challenged to justify why =
they need a whole new set instead of utilizing or extending an existing one=
.

Note this is likely to lead to an overall reduction in the number of unique=
 sets (which is what the management applications want) but in a way that do=
es not require EMAN as a working group to try to be omniscient about where =
things will move in the future.  The list of sets will grow only as needed =
and based on legitimate reasons for creating them rather than on the simple=
 whim of every vendor.

So what does this all mean for your reference to a Rosetta Stone approach?

Personally I believe that it means, or should be constrained by us to mean,=
 that a particular device gets to decide which state set makes sense for IT=
 given its capabilities and that the operators and management applications =
need to talk to that device using the set IT says it understands.  If a par=
ticular device (or component) feels that the ACPI set best matches its need=
s then it should adopt and use that set and the management applications sho=
uld be constrained to talking to it using that set.

A device which adopts ACPI should not be in the position of trying to guess=
 what a management application means when it subsequently tries to set it t=
o some DMTF state.  Or worse, try to guess what two different management ap=
plications mean when one is speaking ACPI and the other is speaking DMTF.  =
If a device that adopts ACPI receives a request to set itself to a particul=
ar DMTF state the response should simply be, IMHO, "No hablo DMTF.  Ha=
blo ACPI."  At least that is the case if we want to foster clear and u=
nambiguous communications between the management applications and the devic=
es.

Allowing the management applications to ASSUME the equivalence of states be=
tween the various sets is likely to lead to the old canard about assuming t=
hings (i.e. never ASSUME anything because it makes an ...).  Conversely, tr=
ying to force an equivalence by standards body fiat is only going to lead t=
o a situation where the standard is not well adopted because it doesn't=
 map cleanly to the underlying reality of a given device's capabilities=
.

I would love to be proven wrong here but thus far I remain unconvinced that=
 we (or anyone) can define a reasonable equivalence map between the meaning=
ful power states of all possible devices.  If some people here (and this is=
 not directed specifically at Chris or anyone else) want us to achieve a si=
ngle set of such states then let's see some proposals for how to make t=
hat actually work in real life scenarios.  I certainly agree that this is a=
 worthy goal, I just don't believe that it is an attainable one.

So, unless and until such a unified state proposal is put forth I personall=
y favor an approach which seeks to at least acknowledge the inherent real l=
ife complexity we are dealing with and thus far I think that the IANA based=
 proposals are a pragmatic step in that direction.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: =
Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein
_______________________________________________
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


--001485eb9de4092a14049f1366a8-- From bclaise@cisco.com Tue Mar 22 08:00:42 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6DC28C13D for ; Tue, 22 Mar 2011 08:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRFAGWP1BQ1r for ; Tue, 22 Mar 2011 08:00:34 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 6A55528C137 for ; Tue, 22 Mar 2011 08:00:34 -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 p2MF1reD026251; Tue, 22 Mar 2011 16:01:53 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2MF1qKk013129; Tue, 22 Mar 2011 16:01:53 +0100 (CET) Message-ID: <4D88B9E0.1010105@cisco.com> Date: Tue, 22 Mar 2011 16:01:52 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ted Ghose References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> <20110318150557.GB19324@cslinux-build01.cyberswitching.local> <20110318154108.GB11947@elstar.local> <20110318160417.GA26516@cslinux-build01.cyberswitching.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A2FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D887510.50507@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040705080302010602080108" Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 15:00:42 -0000 This is a multi-part message in MIME format. --------------040705080302010602080108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ted, Which one then? An existing one? A new one? Regards, Benoit. > hi Benoit > > I see a great value to define one standard power state set. > > supporting multiple power state series will bring more confusion > > thanks > > -tg- > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > Save time... see it my way > *:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,. > > > On Tue, Mar 22, 2011 at 3:08 AM, Benoit Claise > wrote: > > Hi William, > > I like your analysis, and I arrive to the same conclusion in > http://www.ietf.org/mail-archive/web/eman/current/msg00221.html > > Based on the recent conclusions, I would complement my analysis > > What I believe the solution is in terms of EMAN: > - we must be ready to support multiple power states series > - we must be ready to support a new power states series. > - the device must report which power states series it supports > > With > - lock the IANA process so that we don't have an > explosion of new power states (series) > > Regards, Benoit. > >>> chrisv@cyberswitching.com wrote: >>> >>> Wouldn't it be better to put together an interface like a >>> Rosetta stone? >>> Let each user access the system in whatever ways make sense for that >>> user, and then have the agent provide the equivalent translation of >>> power states that makes sense for that agent? >> I think that this would be a nice thing to do but I also think that it is not achievable. >> >> This notion of defining an equivalence of states between the sets is the source of much of our angst here. Defining such an "eqivalency map" between disparate sets of states is the essence of why it is difficult to create a single common set of states in the first place. >> >> If it were possible to bucket the various states from all of these different sets into "equivalence classes" then the "equivalence classes" would BE the universal set of states that we seek. I argue that this is not really possible to do, at least not to the level people seem to want. It may be easy for some states like the various "off" states, or the "on" states, but beyond that the underlying semantics associated with the more specialized states are inherently NOT equivalent so they cannot be so cleanly grouped. You will quickly degenerate down to the point where each equivalence class is mapped one-to-one with a single state from a single set. So in the end you have what is essentially the complete union of all the states from all the sets combined into one big set and I question the utility of having one big set. >> >> For this reason I favor an approach which defines meaningful sets of states that map cleanly to the semantics associated with the capabilities of the device in question. The IANA proposals enable us to have state definitions which do that while still offering some benefit to the management applications from having a constrained process for the creation of new power state sets. >> >> The device vendors will still be constrained to using IANA registered sets and thus they will have a reasonable incentive to reuse those sets before embarking down the path of defining a whole new set. And even in the course of defining a new set they will, presumably, be challenged to justify why they need a whole new set instead of utilizing or extending an existing one. >> >> Note this is likely to lead to an overall reduction in the number of unique sets (which is what the management applications want) but in a way that does not require EMAN as a working group to try to be omniscient about where things will move in the future. The list of sets will grow only as needed and based on legitimate reasons for creating them rather than on the simple whim of every vendor. >> >> So what does this all mean for your reference to a Rosetta Stone approach? >> >> Personally I believe that it means, or should be constrained by us to mean, that a particular device gets to decide which state set makes sense for IT given its capabilities and that the operators and management applications need to talk to that device using the set IT says it understands. If a particular device (or component) feels that the ACPI set best matches its needs then it should adopt and use that set and the management applications should be constrained to talking to it using that set. >> >> A device which adopts ACPI should not be in the position of trying to guess what a management application means when it subsequently tries to set it to some DMTF state. Or worse, try to guess what two different management applications mean when one is speaking ACPI and the other is speaking DMTF. If a device that adopts ACPI receives a request to set itself to a particular DMTF state the response should simply be, IMHO, "No hablo DMTF. Hablo ACPI." At least that is the case if we want to foster clear and unambiguous communications between the management applications and the devices. >> >> Allowing the management applications to ASSUME the equivalence of states between the various sets is likely to lead to the old canard about assuming things (i.e. never ASSUME anything because it makes an ...). Conversely, trying to force an equivalence by standards body fiat is only going to lead to a situation where the standard is not well adopted because it doesn't map cleanly to the underlying reality of a given device's capabilities. >> >> I would love to be proven wrong here but thus far I remain unconvinced that we (or anyone) can define a reasonable equivalence map between the meaningful power states of all possible devices. If some people here (and this is not directed specifically at Chris or anyone else) want us to achieve a single set of such states then let's see some proposals for how to make that actually work in real life scenarios. I certainly agree that this is a worthy goal, I just don't believe that it is an attainable one. >> >> So, unless and until such a unified state proposal is put forth I personally favor an approach which seeks to at least acknowledge the inherent real life complexity we are dealing with and thus far I think that the IANA based proposals are a pragmatic step in that direction. >> >> William F. Mielke >> Alcatel-Lucent >> Distinguished Member of Technical Staff >> 6200 East Broad Street >> Room: 4B01-1V >> Columbus, OH 43213-1530 >> Email:Bill.Mielke@alcatel-lucent.com >> Phone:614 367 5628 >> Fax:614 367 5965 >> >> "Live like you're going to die tomorrow. >> Learn like you're going to live forever." >> >> - Albert Einstein >> _______________________________________________ >> 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 > > --------------040705080302010602080108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Ted,

Which one then? An existing one? A new one?

Regards, Benoit.
hi Benoit 

I see a great value to define one standard power state set.

supporting multiple power state series will bring more confusion

thanks

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.
                     Save time... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.


On Tue, Mar 22, 2011 at 3:08 AM, Benoit Claise <bclaise@cisco.com> wrote:
Hi William,

I like your analysis, and I arrive to the same conclusion in http://www.ietf.org/mail-archive/web/eman/current/msg00221.html

Based on the recent conclusions, I would complement my analysis
What I believe the solution is in terms of EMAN:
- we must be ready to support multiple power states series
- we must be ready to support a new power states series.
- the device must report which power states series it supports
With
          - lock the IANA process so that we don't have an explosion of new power states (series)

Regards, Benoit. 

chrisv@cyberswitching.com wrote:

Wouldn't it be better to put together an interface like a 
Rosetta stone?
Let each user access the system in whatever ways make sense for that
user, and then have the agent provide the equivalent translation of
power states that makes sense for that agent?

I think that this would be a nice thing to do but I also think that it is not achievable.

This notion of defining an equivalence of states between the sets is the source of much of our angst here.  Defining such an "eqivalency map" between disparate sets of states is the essence of why it is difficult to create a single common set of states in the first place.

If it were possible to bucket the various states from all of these different sets into "equivalence classes" then the "equivalence classes" would BE the universal set of states that we seek.  I argue that this is not really possible to do, at least not to the level people seem to want.  It may be easy for some states like the various "off" states, or the "on" states, but beyond that the underlying semantics associated with the more specialized states are inherently NOT equivalent so they cannot be so cleanly grouped.  You will quickly degenerate down to the point where each equivalence class is mapped one-to-one with a single state from a single set.  So in the end you have what is essentially the complete union of all the states from all the sets combined into one big set and I question the utility of having one big set.

For this reason I favor an approach which defines meaningful sets of states that map cleanly to the semantics associated with the capabilities of the device in question.  The IANA proposals enable us to have state definitions which do that while still offering some benefit to the management applications from having a constrained process for the creation of new power state sets.

The device vendors will still be constrained to using IANA registered sets and thus they will have a reasonable incentive to reuse those sets before embarking down the path of defining a whole new set.  And even in the course of defining a new set they will, presumably, be challenged to justify why they need a whole new set instead of utilizing or extending an existing one.

Note this is likely to lead to an overall reduction in the number of unique sets (which is what the management applications want) but in a way that does not require EMAN as a working group to try to be omniscient about where things will move in the future.  The list of sets will grow only as needed and based on legitimate reasons for creating them rather than on the simple whim of every vendor.

So what does this all mean for your reference to a Rosetta Stone approach?

Personally I believe that it means, or should be constrained by us to mean, that a particular device gets to decide which state set makes sense for IT given its capabilities and that the operators and management applications need to talk to that device using the set IT says it understands.  If a particular device (or component) feels that the ACPI set best matches its needs then it should adopt and use that set and the management applications should be constrained to talking to it using that set.

A device which adopts ACPI should not be in the position of trying to guess what a management application means when it subsequently tries to set it to some DMTF state.  Or worse, try to guess what two different management applications mean when one is speaking ACPI and the other is speaking DMTF.  If a device that adopts ACPI receives a request to set itself to a particular DMTF state the response should simply be, IMHO, "No hablo DMTF.  Hablo ACPI."  At least that is the case if we want to foster clear and unambiguous communications between the management applications and the devices.

Allowing the management applications to ASSUME the equivalence of states between the various sets is likely to lead to the old canard about assuming things (i.e. never ASSUME anything because it makes an ...).  Conversely, trying to force an equivalence by standards body fiat is only going to lead to a situation where the standard is not well adopted because it doesn't map cleanly to the underlying reality of a given device's capabilities.

I would love to be proven wrong here but thus far I remain unconvinced that we (or anyone) can define a reasonable equivalence map between the meaningful power states of all possible devices.  If some people here (and this is not directed specifically at Chris or anyone else) want us to achieve a single set of such states then let's see some proposals for how to make that actually work in real life scenarios.  I certainly agree that this is a worthy goal, I just don't believe that it is an attainable one.

So, unless and until such a unified state proposal is put forth I personally favor an approach which seeks to at least acknowledge the inherent real life complexity we are dealing with and thus far I think that the IANA based proposals are a pragmatic step in that direction.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein
_______________________________________________
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



--------------040705080302010602080108-- From bclaise@cisco.com Tue Mar 22 10:50:00 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1240828C13C for ; Tue, 22 Mar 2011 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_URI_REFID1=0.648] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9GvVkYrogBj for ; Tue, 22 Mar 2011 10:49:55 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 301B628C14C for ; Tue, 22 Mar 2011 10:49:49 -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 p2MHNTQm008420 for ; Tue, 22 Mar 2011 18:23:29 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2MHNN9t014849 for ; Tue, 22 Mar 2011 18:23:23 +0100 (CET) Message-ID: <4D88DB0B.1000405@cisco.com> Date: Tue, 22 Mar 2011 18:23:23 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: eman mailing list References: <4D88D2D1.2070306@cisco.com> In-Reply-To: <4D88D2D1.2070306@cisco.com> Content-Type: multipart/alternative; boundary="------------010304070504010404050805" Subject: [eman] draft-tychon-eman-applicability-statement-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 17:50:00 -0000 This is a multi-part message in MIME format. --------------010304070504010404050805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear draft-tychon-eman-applicability-statement-01 authors, Thanks for your draft. In preparation for our EMAN WG next week, I've reviewed the draft, specifically in light of the charter 6. Applicability statement The EMAN WG will develop an applicability statement, describing the variety of applications that can use the energy framework and associated MIB modules. Potential examples are building networks, home energy gateway, etc. Finally, the document will also discuss _relationships _of the framework to other architectures and frameworks (such as smartgrid). The applicability statement will explain the _relationship _between the work in this WG and the other existing standards such as those from the IEC, ANSI, DMTF, and others. First of, as mentioned in http://www.ietf.org/mail-archive/web/eman/current/msg00407.html, IEEE/ISTO Printer Working Group and ODVA should be mentioned. Second, there are still a few valid points at: http://www.ietf.org/mail-archive/web/eman/current/msg00101.html > > Energy Management Working Group E. > Tychon > Internet Draft M. > Laherty > Intended status: Informational Cisco > Systems, Inc. > Expires: September 15, 2011 B. > Schoening > Independent > Consultant > > March > 15, 2011 > > > > > Energy Management (EMAN) Applicability Statement > draft-tychon-eman-applicability-statement-01.txt > > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. This document may not be > modified, > and derivative works of it may not be created, and it may not be > published except as an Internet-Draft. > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. This document may not be > modified, > and derivative works of it may not be created, except to > publish it > as an RFC and to translate it into languages other than English. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents > at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as "work in > progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html > > This Internet-Draft will expire on September 15, 2011. > > > > > Expires September 15, 2011 [Page 1] > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > Copyright Notice > > Copyright (c) 2011 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with > respect to this document. Code Components extracted from this > document must include Simplified BSD License text as described in > Section 4.e of the Trust Legal Provisions and are provided > without > warranty as described in the Simplified BSD License. > > Abstract > > The Energy Management (EMAN) framework will work on the > management A lot of sentences use the future tense. Since the applicability statement is the last of our series of document, you should be using the present. Anyway, when published, the EMAN framework and MIB modules must be available. > of energy-aware devices. In this document we describe the In IETF draft, we don't use "we" > applicability of the EMAN framework for a variety of > applications. > We show how network elements and applications can use EMAN. What do you mean "use EMAN". The framework, the MIB module? This is a generic statement for the draft. Sometimes, I'm not clear if you refer the concepts in the framework, or the MIB modules, or both. > We > furthermore describe relations of the EMAN framework to other > architectures and frameworks. > > > > Table of Contents > > 1. > Introduction...................................................3 > 1.1. Energy > Measurement........................................4 > 1.2. Energy > Control............................................4 > 1.3. > Examples..................................................5 > 1.3.1. Corporate > Networks...................................5 > 1.3.2. Building > Networks....................................5 > 1.3.3. Home Energy > Gateways.................................5 > 1.3.4. > Datacenters..........................................5 > 1.3.5. Intelligent Power > Strips.............................6 > 2. Relation of EMAN to Other Frameworks and > Technologies..........6 > 2.1. > IEC.......................................................6 > 2.2. > ISO.......................................................7 > 2.3. ANSI > C12..................................................7 > 2.4. > EnergyStar................................................8 > 2.5. > DMTF......................................................8 > 2.5.1. Common Information Model > Profiles....................9 > 2.5.2. Desktop And Mobile Architecture for System Hardware > > (DASH)......................................................9 > 2.6. > SmartGrid.................................................9 > > > Expires September 15, 2011 [Page 2] > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > 2.7. NAESB, ASHRAE and > NEMA...................................10 > 2.8. > ZigBee...................................................11 > 3. > Limitations...................................................12 > 4. Security > Considerations.......................................12 > 4.1. > SmartGrid................................................12 > 5. IANA > Considerations...........................................13 > 6. > References....................................................13 > 6.1. Normative > References.....................................13 > 6.2. Informative > References...................................13 > 7. > Acknowledgments...............................................13 > > > > (Beginning of section to be removed from the final version) > > TO DO > > > > (End of section to be removed from the final version) > > > > 1. Introduction > > The EMAN framework describes how energy information can be > retrieved, controlled and monitored from IP-enabled consumers > with > traditional methods such as Simple Network Management Protocol > (SNMP). In essence, the framework defines Management Information > Base (MIBs) for SNMP. > > In this document, we describe typical applications of the EMAN > framework; we will show opportunities and limitations of the > framework. Furthermore, we describe other standards that are > similar > to EMAN but addresses different domains or users. > > EMAN will enable heterogeneous energy consumers to report > their own > consumption, and to a lesser extent, external system to control > them. There is also the case, as discussed these days on the mailing list, of a device consumption being monitored by an another device. For example, PoE. > There are multiple scenarios where this is desirable, > particularly today considering the increased importance of > limiting > consumption of finite energy resources and reducing operational > expenses. > > 1.1. EMAN Documents Overview > > The EMAN working group is actively working on a series of > documents. > (TODO: list existing documents) > > > Expires September 15, 2011 [Page 3] > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > > > 1.2. Energy Measurement > > More and more devices today are able to measure and report > their own > energy consumption. power and energy > Smart power strips and some current generation > Power-over-Ethernet switches are already able to meter > consumption > of the connected devices. However, when managed and reported > through proprietary means, this information is not really > useful at > the enterprise level. Can you expand why? > > The primary goal of EMAN is to enable reporting and management > within a standard framework that is applicable to the wide > variety > of today's end devices, meters and proxies. > > Being able to know who's consuming what, when and how at any > time by what do you mean "how"? > leveraging existing networks, and across various equipment is one > pillar of the EMAN framework. > > 1.3. Energy Control > > There are many cases where reducing energy consumption is > desirable, > such as when the demand is already high, when there's no one > using > the resource, and so on. > > In some cases, you can't simply turn it off without > considering the > context. For instance you cannot turn off all phones, because > some > still need to be available in case of emergency. You can't turn > office cooling off totally during non-work hours, but you can > reduce > the comfort level, and so on. > > In other cases, there are intermediate power levels between > off and > on, such as standby, sleep or soft-off modes [DQERM]. > > The EMAN framework will provide a control mechanism that is > generalized for all devices, power states, and allows for fine- > grained priority control, and emergency function. > > Power control requires flexibility and support for different > polices > and mechanisms; including centralized management with a network > management station, autonomous management by individual > devices, and > alignment with dynamic demand-response mechanisms. > > > > Expires September 15, 2011 [Page 4] > > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > 1.4. Examples > > 1.4.1. Corporate Networks > > Corporate networks connect computers, printers, phones, network > equipment and other devices over local and wide area networks. > These networks are typically centrally managed and operate 24x7. > > Today, no standard MIB exists for monitoring and control of > energy > in enterprise network using SNMP. Generic statement for all the examples. You should really explain how the EMAN framework can be applied... or not. When I read this section 1.4.*, it seems like I read the EMAN requirements draft. > > 1.4.2. Building Networks > > Buildings are big energy consumers, and companies are looking > into > ways to reduce their energy consumption, as well as to react > positively in case of an emergency, such as a brownout risk day. > > While building networks may be IP enabled, most use older network > technologies including serial RS-485 and token ring technologies. > Within these networks, gateways may connect the building system > protocol to IP networks for management and control. > > Air conditioning, lighting and so on can all be metered and > controlled using the EMAN framework. Coming back the previous comment. Here is _an example_ of what I believe is needed. "For example, by implementing the ENERGY-AWARE MIB module on the aggregator and monitoring building specific devices as Power Monitor Children, actually acting as proxy between IP on one side and building management specific protocols." > EMAN can, for instance, act as > a communication protocol between a presence system to > deactivate the > cooling and phones when there's no one on the floor. > > 1.4.3. Home Energy Gateways > > Home Energy Gateways (HEG) are devices with remote metering > capabilities, and will let service providers and utility > companies > respond to demand by varying pricing according to time of usage. > > The HEG itself may use specific protocols, but using the EMAN > framework, same comment again. > it will be able to report usage, pricing or other > indicators to the user using SNMP. Using a simple application > on its > home network, the consumer is now empowered to see and decide > how to > use energy. > > 1.4.4. Datacenters > > Datacenters too are big energy consumers. All that equipment > generates heat, and heat needs to be evacuated though a HVAC > (Heating, Ventilating, and Air Conditioning) system. > Controlling the > datacenter consumption means slowing down or turning off > equipment > and cooling. > > > Expires September 15, 2011 [Page 5] > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > The EMAN framework will enable a new level of control by > providing a > unified means of communication between heterogeneous devices > over a > network. > > 1.4.5. Intelligent Power Strips > > Intelligent Power Strips are power distribution units with IP > communication capability to remotely enable / disable a > particular > outlet, and often have the ability to measure power > consumption for > each outlet. > > These devices are currently supporting either their own > proprietary > protocol or a proprietary SNMP MIB, but EMAN will provide a > uniform > framework designed for power control and monitoring for all > vendors. How? Do we have to give specific example of the outlet gang and dual power supplies case here? > > 2. Relation of EMAN to Other Frameworks and Technologies > > EMAN as a framework is tied with other standards and efforts > in the > area. We will try to re-use existing standards as much as > possible, > as well as providing control to adjacent technologies such as > Smart > Grid. > > We have listed most of them with a brief description of their > objectives and the current state. For most the section 2.X, I miss the relationship to EMAN. > > 2.1. IEC > > The International Electrotechnical Commission (IEC) has > developed a > broad set of standards for power management. Among these, the > most > applicable to our purposes is IEC 61850, a standard for the > design > of electric utility automation. The abstract data model > defined in > 61850 is built upon and extends the Common Information Model > (CIM). > The complete 61850 CIM model includes over a hundred object > classes > and is widely used by utilities in the US and worldwide > > This set of standards was originally conceived to automate > control > of a substation. An electrical substation is a subsidiary > station of > an electricity generation, transmission and distribution system > where voltage is transformed from high to low or the reverse > using > transformers. While the original domain of 61850 is substation > automation, the extensive model that resulted has been widely > used > in other areas, including Energy Management Systems (EMS) and > forms > the core of many Smart Grid standards. > > IEC TC57 WG19 is an ongoing working group to harmonize the CIM > data > model and 61850 standards. What about the IEC61968? Is there a relationship to EMAN? > > > > Expires September 15, 2011 [Page 6] > > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > With its broad installed base and foundational data model for > recent > smart grid efforts, it's highly advisable that the EMON model > reuse > as much as possible from the IEC standards. Done already in http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07. Btw, EMON = EMAN? ;-) > > 2.2. ISO > > The ISO is developing an energy management standard called ISO > 50001. The intent of the framework is to facilitate the > creation of > energy management programs for industrial, commercial and other > entities. The standard defines a process for energy > management at > an organization level. It is not expected to define the way in > which devices report energy and consume energy. The IETF effort > would be complementary. Good. This is the type of information we need in this draft. > > ISO 50001 is based on the common elements found in all of ISO's > management system standards, assuring a high level of > compatibility > with ISO 9001 (quality management) and ISO 14001 (environmental > management). ISO 50001 benefits will include > > - Integrating energy efficiency into management practices and > throughout the supply chain. > - Energy management best practices and good energy management > behaviors > - benchmarking, measuring, documenting, and reporting energy > intensity improvements and their projected impact on > reductions in > greenhouse gas (GHG) emissions > - Evaluating and prioritizing the implementation of new energy- > efficient technologies > > ISO 50001 is being developed by ISO project committee ISO/PC 242, > Energy management and is expected to be published as an > International > Standard by 2011. > > http://www.iso.org/iso/pressrelease.htm?refid=Ref1337 > > 2.3. ANSI C12 > > The American National Standards Institute (ANSI) has defined a > collection of power meter standards under ANSI C12. The primary > standards include communication protocols (C12.18, 21 and 22), > data > and schema definitions (C12.19), and measurement accuracy > (C12.20). > European equivalent standards are provided by the IEC. > > > > > Expires September 15, 2011 [Page 7] > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > ANSI C12.20 defines accuracy classes for watt-hour meters. > Typical > accuracy classes are class 0.5, class 1, and class 3; which > correspond to +/- 0.5%, +/- 1% and +/- 3% accuracy thresholds. > > All of these standards are oriented toward the meter itself, > and are > therefore very specific and used by electricity distributors and > producers. > > The EMON standard should be compatible with existing ANSI C.12 > standards. EMAN? > > 2.4. EnergyStar > > The US Environmental Protection Agency (EPA) and US Department of > Energy (DOE) jointly sponsor the Energy Star program. The > program > promotes the development of energy efficient products and > practices. > > To earn Energy Star approval, appliances in the home or business > must meet specific energy efficiency targets. The Energy Star > program also provides planning tools and technical > documentation to > help homeowners design more energy efficient homes. Energy > Star is a > program; it's not a protocol or standard. > > For businesses and data centers, Energy Star offers technical > support to help companies establish energy conservation > practices. > Energy Star provides best practices for measuring current energy > performance, goal setting, and tracking improvement. The Energy > Star tools offered include a rating system for building > performance > and comparative benchmarks. > > http://www.energystar.gov/index.cfm?c=about.ab_history > > 2.5. DMTF > > The DMTF has standardized management solutions for power-state > configuration and management of elements in a heterogeneous > environment. These specifications provide physical, logical and > virtual system management requirements for power-state control. > > Through various Working Group efforts these specifications > continue > to evolve and advance in features and functionalities. The full > specifications can be found at the DMTF web site: > > http://www.dmtf.org > > > > Expires September 15, 2011 [Page 8] > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > 2.5.1. Common Information Model Profiles > > The DMTF uses CIM-based (Common Information Model) 'Profiles' to > represent and manage power utilization and configuration of a > managed element. The key profiles are 'Power Supply' (DSP 1015), > 'Power State' (DSP 1027) and 'Power Utilization Management' (DSP > 1085). > > These profiles define monitoring and configuration of a Power > Managed Element's static and dynamic power saving modes, power > allocation limits and power states, among other features. > > Power saving modes can be established as static or dynamic. > Static > modes are fixed policies that limit power to a utilization or > wattage limit. Dynamic power saving modes rely upon internal > feedback to control power consumption. > > Power states are eight named operational and non operational > levels. > These are On, Sleep-Light, Sleep-Deep, Hibernate, Off-Soft, > and Off- > Hard. Power change capabilities provide immediate, timed > interval, > and graceful transitions between on, off, and reset power states. > Table 3 of the Power State Profile defines the correspondence > between the ACPI and DMTF power state models, although it is not > necessary for a managed element to support ACPI. Optionally, a > TransitingToPowerState property can represent power state > transitions in progress. that's a good description, but what's the relationship to EMAN > > 2.5.2. Desktop And Mobile Architecture for System Hardware (DASH) > > DMTF DASH (DSP0232) has addressed the challenges of managing > heterogeneous desktop and mobile systems (including power) via > in- > band and out-of-band environments. Utilizing the DMTF's WS- > Management web services and the CIM data model, DASH provides > management and control of managed elements like power, CPU etc. > > Both in service and out-of-service systems can be managed with > the > DASH specification in a fully secured remote environment. Full > power lifecycle management is possible using out-of-band > management. Relationship with EMAN? Can we use DASH in the EMAN framework since the communication between Parent and Child is out of the scope? > > 2.6. SmartGrid > > The Smart Grid standards efforts underway in the United States > are > overseen by the US National Institute of Standards and Technology > [NIST]. NIST was given the charter to oversee the development of > smart grid related standards by the Energy Independence and > Security > Act of 2007. NIST is responsible for coordinating a > public-private > > > > Expires September 15, 2011 [Page 9] > > Internet-Draft EMAN Applicability Statement > March 2011 > > > partnership with key energy and consumer stakeholders in order to > facilitate the development of smart grid standards. > > The smart grid standards activity (sponsored and hosted by > NIST) is > monitored and facilitated by the SGIP (Smart Grid > Interoperability > Panel). This group has several sub groups called working groups. > These teams examine smaller parts of the smart grid. They > include > B2G, I2G, and H2G and others (Building to Grid; Industrial to > Grid > and Home to Grid). > > http://collaborate.nist.gov/twiki- > sggrid/bin/view/SmartGrid/SGIPWorkingGroupsAndCommittees > > When a working group detects a standard or technology gap, the > team > seeks approval from the SGIP for the creation of a Priority > Action > Plan (PAP). The PAP is a private-public partnership with a > charter > to close a specific gap. There are currently 17 Priority Action > Plans (PAP). > > PAP 10 Addresses "Standard Energy Usage Information". > > Smart Grid standards will provide distributed intelligence in the > network and allow enhanced load shedding. For example, pricing > signals will enable selective shutdown of non critical activities > during peak-load pricing periods. These actions can be effected > through both centralized and distributed management controls. > Similarly, brown-outs, air quality alerts, and peak demand limits > can be managed through the smart grid data models, based upon IEC > 61850. Relationship to EMAN? We can control the IT devices to consume less when SmartGrid requires it. > > 2.7. NAESB, ASHRAE and NEMA > > As an output of the PAP10's work on the standard information > model, > multiple stakeholders agreed to work on a utility centric > model in > NAESB (North American Electric Standards Board) and the building > side information model in a joint effort by American Society of > Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) > and > National Electrical Manufacturers Association (NEMA). > > The NAESB effort is a NAESB REQ/WEQ. > http://www.naesb.org/smart_grid_PAP10.asp > > The ASHRAE effort is SPC201. http://collaborate.nist.gov/twiki- > sggrid/bin/view/SmartGrid/PAP17Information > > The output of both ANSI approved SDO's Do you mean NAESB and ASHRAE? > is an information model. Sometimes you speak about information model, sometimes about data model in this section. Please refer to RFC3444. > It > is not a device level monitoring protocol. > > > Expires September 15, 2011 [Page 10] > > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > After the ASHRAE SPC201 group formed as a result of initial work > done by the PAP 10, the SGIP added PAP17 in order to focus > specifically on in-building standards for energy using devices. > > PAP 17 "will lead to development of a data model standard to > enable > energy consuming devices and control systems in the customer > premises to manage electrical loads and generation sources in > response to communication with the Smart Grid. It will be > possible > to communicate information about those electrical loads to > utilities, other electrical service providers, and market > operators. > > The term "Facility Smart Grid Information" is intended to > convey the > nature of critical information originating from the customer > operated "facility" which deals with the representation and > dynamics > of loads including prediction, measurement and shedding. It also > helps to distinguish between this PAP and that of PAP10 which > deals > exclusively with the representation of energy usage. > > This data model standard will complement the flow, aggregation, > summary, and forecasting of energy usage information being > standardized by NAESB in PAP10 through the definition of > additional > distinct model components. While the NAESB standard is > focusing on > "a single limited-scope information model" that "will not > cover all > interactions associated with energy in the home or commercial > space" > including, for example, load management ("Report to the SGIP > Governing Board: PAP10 plan," June 15, 2010), these new > components > will address load modeling and behavior necessary to manage > on-site > generation, demand response, electrical storage, peak demand > management, load shedding capability estimation, and responsive > energy load control." > > http://collaborate.nist.gov/twiki- > > sggrid/bin/view/SmartGrid/PAP17FacilitySmartGridInformationStandard > > > > 2.8. ZigBee > > The "Zigbee Smart Energy 2.0 effort" currently focuses on > wireless > communication to smart home appliances. It is intended to enable > home energy management and direct load control by utilities. > > ZigBee protocols are intended for use in embedded applications > requiring low data rates and low power consumption. ZigBee's > current > focus is to define a general-purpose, inexpensive, > self-organizing > mesh network that can be used for industrial control, embedded > > > > Expires September 15, 2011 [Page 11] > > > > > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > sensing, medical data collection, smoke and intruder warning, > building automation, home automation, etc. > > It is not known if the Zigbee Alliance plans to extend support to > business class devices. There also does not appear to be a > plan for > context aware marking. > > Zigbee is currently not an ANSI recognized SDO -- but they are > working toward formal recognition. > > 3. Limitations > > EMAN will address the needs of the network operators in term of > measurement and, to a lesser extend, control over IP networks. > > It is not the purpose of EMAN to create a new protocol stack for > energy-aware endpoints, but rather to create a data model to > measure > and report energy and other metrics over SNMP. > > Other legacy protocols may already exists (ModBus), but are not > designed initially to work on IP, even if in some cases it is > possible to transport them over IP with some limitations. > > The EMAN framework does not aim to address questions regarding > Smartgrid, Electricity producers, distributors even if there is > obvious link between them. it seems like a requirement statement. The readers are interested in the relationship. How everything should work together. > > 4. Security Considerations > > EMAN uses the SNMP protocol and is subject to its own > security. More > specifically, SNMPv3 [RFC3411] provides important security > features > such as confidentiality, integrity, and authentication. > > 4.1. SmartGrid > > Even if discussing SmartGrid security is not the scope of this > document, NIST has found at least five standards that are > directly > related to smart grid security. That includes standards from > NERC, > IEEE, AMI System Security Requirements, UtilityAMI Home Area > Network > System Requirements and IEC standards. > > The SmartGrid security issue is more difficult being actually an > open network, spawning entire territories and devices from smart > meters, secondary and primary sub stations, etc. > > EDITOR'S NODE: TO BE EXPANDED > > > > Expires September 15, 2011 [Page 12] > > > > > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > 5. IANA Considerations > > This memo includes no request to IANA. > > 6. References > > 6.1. Normative References > > [RFC3411] An Architecture for Describing Simple Network > Management > Protocol (SNMP) Management Frameworks I was expecting a coupe of EMAN references. At least the working group items. Regards, Benoit. > > 6.2. Informative References > > [DQERM] https://datatracker.ietf.org/doc/draft-quittek-eman- > reference-model/ > > [NIST] http://www.nist.gov/smartgrid/ > > > > > > 7. Acknowledgments > > This document was prepared using 2-Word-v2.0.template.dot. > > The authors would like to thank Jeff Wheeler for its > contribution to > the DMTF section. > > > > Copyright (c) 2011 IETF Trust and the persons identified as > authors > of the code. All rights reserved. > > Redistribution and use in source and binary forms, with or > without > modification, is permitted pursuant to, and subject to the > license > terms contained in, the Simplified BSD License set forth in > Section > 4.c of the IETF Trust's Legal Provisions Relating to IETF > Documents > (http://trustee.ietf.org/license-info). > > > > > > > > > > > Expires September 15, 2011 [Page 13] > > > > > > > Internet-Draft EMAN Applicability Statement > March 2011 > > > Authors' Addresses > > Emmanuel Tychon > Cisco Systems, Inc. > De Keleetlaan, 6A > B1831 Diegem > Belgium > Email: etychon@cisco.com > > > Matthew Laherty > Cisco Systems, Inc. > Email: mlaherty@cisco.com > > > Brad Schoening > 44 Rivers Edge Drive > Little Silver, NJ 07739 > USA > Email: brad@bradschoening.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Expires September 15, 2011 [Page 14] > > > > > > > --------------010304070504010404050805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear draft-tychon-eman-applicability-statement-01 authors,

Thanks for your draft.

In preparation for our EMAN WG next week, I've reviewed the draft, specifically in light of the charter
6. Applicability statement
The EMAN WG will develop an applicability statement, describing the
variety of applications that can use the energy framework and associated
MIB modules. Potential examples are building networks, home energy
gateway, etc. Finally, the document will also discuss relationships of
the framework to other architectures and frameworks (such as smartgrid).
The applicability statement will explain the relationship between the
work in this WG and the other existing standards such as those from the
IEC, ANSI, DMTF, and others.

First of, as mentioned in http://www.ietf.org/mail-archive/web/eman/current/msg00407.html, IEEE/ISTO Printer Working Group and ODVA should be mentioned.
Second, there are still a few valid points at: http://www.ietf.org/mail-archive/web/eman/current/msg00101.html

     Energy Management Working Group                               E. Tychon
     Internet Draft                                               M. Laherty
     Intended status: Informational                      Cisco Systems, Inc.
     Expires: September 15, 2011                                B. Schoening
                                                      Independent Consultant

                                                              March 15, 2011




                  Energy Management (EMAN) Applicability Statement
                  draft-tychon-eman-applicability-statement-01.txt


     Status of this Memo

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

        This Internet-Draft is submitted in full conformance with the
        provisions of BCP 78 and BCP 79. This document may not be modified,
        and derivative works of it may not be created, and it may not be
        published except as an Internet-Draft.

        This Internet-Draft is submitted in full conformance with the
        provisions of BCP 78 and BCP 79. This document may not be modified,
        and derivative works of it may not be created, except to publish it
        as an RFC and to translate it into languages other than English.

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

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

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

        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

        This Internet-Draft will expire on September 15, 2011.




<Tychon, et Al.>       Expires September 15, 2011               [Page 1]


     Internet-Draft       EMAN Applicability Statement            March 2011


     Copyright Notice

        Copyright (c) 2011 IETF Trust and the persons identified as the
        document authors. All rights reserved.

        This document is subject to BCP 78 and the IETF Trust's Legal
        Provisions Relating to IETF Documents
        (http://trustee.ietf.org/license-info) in effect on the date of
        publication of this document. Please review these documents
        carefully, as they describe your rights and restrictions with
        respect to this document. Code Components extracted from this
        document must include Simplified BSD License text as described in
        Section 4.e of the Trust Legal Provisions and are provided without
        warranty as described in the Simplified BSD License.

     Abstract

        The Energy Management (EMAN) framework will work on the management
A lot of sentences use the future tense. Since the applicability statement is the last of our series of document, you should be using the present. Anyway, when published, the EMAN framework and MIB modules must be available.
        of energy-aware devices. In this document we describe the
In IETF draft, we don't use "we"
        applicability of the EMAN framework for a variety of applications.
        We show how network elements and applications can use EMAN.
What do you mean "use EMAN". The framework, the MIB module?
This is a generic statement for the draft. Sometimes, I'm not clear if you refer the concepts in the framework, or the MIB modules, or both.
We
        furthermore describe relations of the EMAN framework to other
        architectures and frameworks.



     Table of Contents

        1. Introduction...................................................3
           1.1. Energy Measurement........................................4
           1.2. Energy Control............................................4
           1.3. Examples..................................................5
              1.3.1. Corporate Networks...................................5
              1.3.2. Building Networks....................................5
              1.3.3. Home Energy Gateways.................................5
              1.3.4. Datacenters..........................................5
              1.3.5. Intelligent Power Strips.............................6
        2. Relation of EMAN to Other Frameworks and Technologies..........6
           2.1. IEC.......................................................6
           2.2. ISO.......................................................7
           2.3. ANSI C12..................................................7
           2.4. EnergyStar................................................8
           2.5. DMTF......................................................8
              2.5.1. Common Information Model Profiles....................9
              2.5.2. Desktop And Mobile Architecture for System Hardware
              (DASH)......................................................9
           2.6. SmartGrid.................................................9


     <Tychon, et Al.>       Expires September 15, 2011               [Page 2]


     Internet-Draft       EMAN Applicability Statement            March 2011


           2.7. NAESB, ASHRAE and NEMA...................................10
           2.8. ZigBee...................................................11
        3. Limitations...................................................12
        4. Security Considerations.......................................12
           4.1. SmartGrid................................................12
        5. IANA Considerations...........................................13
        6. References....................................................13
           6.1. Normative References.....................................13
           6.2. Informative References...................................13
        7. Acknowledgments...............................................13



        (Beginning of section to be removed from the final version)

        TO DO



        (End of section to be removed from the final version)



     1. Introduction

        The EMAN framework describes how energy information can be
        retrieved, controlled and monitored from IP-enabled consumers with
        traditional methods such as Simple Network Management Protocol
        (SNMP). In essence, the framework defines Management Information
        Base (MIBs) for SNMP.

        In this document, we describe typical applications of the EMAN
        framework; we will show opportunities and limitations of the
        framework. Furthermore, we describe other standards that are similar
        to EMAN but addresses different domains or users.

        EMAN will enable heterogeneous energy consumers to report their own
        consumption, and to a lesser extent, external system to control
        them.
There is also the case, as discussed these days on the mailing list, of a device consumption being monitored by an another device. For example, PoE.
There are multiple scenarios where this is desirable,
        particularly today considering the increased importance of limiting
        consumption of finite energy resources and reducing operational
        expenses.

     1.1. EMAN Documents Overview

        The EMAN working group is actively working on a series of documents.
        (TODO: list existing documents)


     <Tychon, et Al.>       Expires September 15, 2011               [Page 3]


     Internet-Draft       EMAN Applicability Statement            March 2011




     1.2. Energy Measurement

        More and more devices today are able to measure and report their own
        energy consumption.
power and energy
Smart power strips and some current generation
        Power-over-Ethernet switches are already able to meter consumption
        of the connected devices.  However, when managed and reported
        through proprietary means, this information is not really useful at
        the enterprise level.
Can you expand why?

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

        Being able to know who's consuming what, when and how at any time by
what do you mean "how"?
        leveraging existing networks, and across various equipment is one
        pillar of the EMAN framework.

     1.3. Energy Control

        There are many cases where reducing energy consumption is desirable,
        such as when the demand is already high, when there's no one using
        the resource, and so on.

        In some cases, you can't simply turn it off without considering the
        context. For instance you cannot turn off all phones, because some
        still need to be available in case of emergency. You can't turn
        office cooling off totally during non-work hours, but you can reduce
        the comfort level, and so on.

        In other cases, there are intermediate power levels between off and
        on, such as standby, sleep or soft-off modes [DQERM].

        The EMAN framework will provide a control mechanism that is
        generalized for all devices, power states, and allows for fine-
        grained priority control, and emergency function.

        Power control requires flexibility and support for different polices
        and mechanisms; including centralized management with a network
        management station, autonomous management by individual devices, and
        alignment with dynamic demand-response mechanisms.



     <Tychon, et Al.>       Expires September 15, 2011               [Page 4]



     Internet-Draft       EMAN Applicability Statement            March 2011


     1.4. Examples

     1.4.1. Corporate Networks

        Corporate networks connect computers, printers, phones, network
        equipment and other devices over local and wide area networks.
        These networks are typically centrally managed and operate 24x7.

        Today, no standard MIB exists for monitoring and control of energy
        in enterprise network using SNMP.
Generic statement for all the examples.
You should really explain how the EMAN framework can be applied... or not.
When I read this section 1.4.*, it seems like I read the EMAN requirements draft.

     1.4.2. Building Networks

        Buildings are big energy consumers, and companies are looking into
        ways to reduce their energy consumption, as well as to react
        positively in case of an emergency, such as a brownout risk day.

        While building networks may be IP enabled, most use older network
        technologies including serial RS-485 and token ring technologies.
        Within these networks, gateways may connect the building system
        protocol to IP networks for management and control.

        Air conditioning, lighting and so on can all be metered and
        controlled using the EMAN framework.
Coming back the previous comment. Here is an example of what I believe is needed.
"For example, by implementing the ENERGY-AWARE MIB module on the aggregator and monitoring building specific devices as Power Monitor Children, actually acting as proxy between IP on one side and building management specific protocols."
EMAN can, for instance, act as
        a communication protocol between a presence system to deactivate the
        cooling and phones when there's no one on the floor.

     1.4.3. Home Energy Gateways

        Home Energy Gateways (HEG) are devices with remote metering
        capabilities, and will let service providers and utility companies
        respond to demand by varying pricing according to time of usage.

        The HEG itself may use specific protocols, but using the EMAN
        framework,
same comment again.
it will be able to report usage, pricing or other
        indicators to the user using SNMP. Using a simple application on its
        home network, the consumer is now empowered to see and decide how to
        use energy.

     1.4.4. Datacenters

        Datacenters too are big energy consumers. All that equipment
        generates heat, and heat needs to be evacuated though a HVAC
        (Heating, Ventilating, and Air Conditioning) system. Controlling the
        datacenter consumption means slowing down or turning off equipment
        and cooling.


     <Tychon, et Al.>       Expires September 15, 2011               [Page 5]


     Internet-Draft       EMAN Applicability Statement            March 2011


        The EMAN framework will enable a new level of control by providing a
        unified means of communication between heterogeneous devices over a
        network.

     1.4.5. Intelligent Power Strips

        Intelligent Power Strips are power distribution units with IP
        communication capability to remotely enable / disable a particular
        outlet, and often have the ability to measure power consumption for
        each outlet.

        These devices are currently supporting either their own proprietary
        protocol or a proprietary SNMP MIB, but EMAN will provide a uniform
        framework designed for power control and monitoring for all vendors.
How?
Do we have to give specific example of the outlet gang and dual power supplies case here?

     2. Relation of EMAN to Other Frameworks and Technologies

        EMAN as a framework is tied with other standards and efforts in the
        area. We will try to re-use existing standards as much as possible,
        as well as providing control to adjacent technologies such as Smart
        Grid.

        We have listed most of them with a brief description of their
        objectives and the current state.
For most the section 2.X, I miss the relationship to EMAN.

     2.1. IEC

        The International Electrotechnical Commission (IEC) has developed a
        broad set of standards for power management.  Among these, the most
        applicable to our purposes is IEC 61850, a standard for the design
        of electric utility automation.  The abstract data model defined in
        61850 is built upon and extends the Common Information Model (CIM).
        The complete 61850 CIM model includes over a hundred object classes
        and is widely used by utilities in the US and worldwide

        This set of standards was originally conceived to automate control
        of a substation. An electrical substation is a subsidiary station of
        an electricity generation, transmission and distribution system
        where voltage is transformed from high to low or the reverse using
        transformers. While the original domain of 61850 is substation
        automation, the extensive model that resulted has been widely used
        in other areas, including Energy Management Systems (EMS) and forms
        the core of many Smart Grid standards.

        IEC TC57 WG19 is an ongoing working group to harmonize the CIM data
        model and 61850 standards.
What about the IEC61968?
Is there a relationship to EMAN?



     <Tychon, et Al.>       Expires September 15, 2011               [Page 6]



     Internet-Draft       EMAN Applicability Statement            March 2011


        With its broad installed base and foundational data model for recent
        smart grid efforts, it's highly advisable that the EMON model reuse
        as much as possible from the IEC standards.
Done already in http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07.
Btw, EMON = EMAN? ;-)

     2.2. ISO

        The ISO is developing an energy management standard called ISO
        50001.  The intent of the framework is to facilitate the creation of
        energy management programs for industrial, commercial and other
        entities.  The standard defines a process for energy management at
        an organization level.  It is not expected to define the way in
        which devices report energy and consume energy. The IETF effort
        would be complementary.
Good.
This is the type of information we need in this draft.

        ISO 50001 is based on the common elements found in all of ISO's
        management system standards, assuring a high level of compatibility
        with ISO 9001 (quality management) and ISO 14001 (environmental
        management). ISO 50001 benefits will include

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

       ISO 50001 is being developed by ISO project committee ISO/PC 242,
       Energy management and is expected to be published as an International
       Standard by 2011.

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

     2.3. ANSI C12

        The American National Standards Institute (ANSI) has defined a
        collection of power meter standards under ANSI C12.  The primary
        standards include communication protocols (C12.18, 21 and 22), data
        and schema definitions (C12.19), and measurement accuracy (C12.20).
        European equivalent standards are provided by the IEC.




     <Tychon, et Al.>       Expires September 15, 2011               [Page 7]


     Internet-Draft       EMAN Applicability Statement            March 2011


        ANSI C12.20 defines accuracy classes for watt-hour meters.  Typical
        accuracy classes are class 0.5, class 1, and class 3; which
        correspond to +/- 0.5%, +/- 1% and +/- 3% accuracy thresholds.

        All of these standards are oriented toward the meter itself, and are
        therefore very specific and used by electricity distributors and
        producers.

        The EMON standard should be compatible with existing ANSI C.12
        standards.
EMAN?

     2.4. EnergyStar

        The US Environmental Protection Agency (EPA) and US Department of
        Energy (DOE) jointly sponsor the Energy Star program.  The program
        promotes the development of energy efficient products and practices.

        To earn Energy Star approval, appliances in the home or business
        must meet specific energy efficiency targets.  The Energy Star
        program also provides planning tools and technical documentation to
        help homeowners design more energy efficient homes. Energy Star is a
        program; it's not a protocol or standard.

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

        http://www.energystar.gov/index.cfm?c=about.ab_history

     2.5. DMTF

        The DMTF has standardized management solutions for power-state
        configuration and management of elements in a heterogeneous
        environment.  These specifications provide physical, logical and
        virtual system management requirements for power-state control.

        Through various Working Group efforts these specifications continue
        to evolve and advance in features and functionalities.  The full
        specifications can be found at the DMTF web site:

        http://www.dmtf.org



     <Tychon, et Al.>       Expires September 15, 2011               [Page 8]


     Internet-Draft       EMAN Applicability Statement            March 2011


     2.5.1. Common Information Model Profiles

        The DMTF uses CIM-based (Common Information Model) 'Profiles' to
        represent and manage power utilization and configuration of a
        managed element.  The key profiles are 'Power Supply' (DSP 1015),
        'Power State' (DSP 1027) and 'Power Utilization Management' (DSP
        1085).

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

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

        Power states are eight named operational and non operational levels.
        These are On, Sleep-Light, Sleep-Deep, Hibernate, Off-Soft, and Off-
        Hard.  Power change capabilities provide immediate, timed interval,
        and graceful transitions between on, off, and reset power states.
        Table 3 of the Power State Profile defines the correspondence
        between the ACPI and DMTF power state models, although it is not
        necessary for a managed element to support ACPI. Optionally, a
        TransitingToPowerState property can represent power state
        transitions in progress.
that's a good description, but what's the relationship to EMAN

     2.5.2. Desktop And Mobile Architecture for System Hardware (DASH)

        DMTF DASH (DSP0232) has addressed the challenges of managing
        heterogeneous desktop and mobile systems (including power) via in-
        band and out-of-band environments.  Utilizing the DMTF's WS-
        Management web services and the CIM data model, DASH provides
        management and control of managed elements like power, CPU etc.

        Both in service and out-of-service systems can be managed with the
        DASH specification in a fully secured remote environment.  Full
        power lifecycle management is possible using out-of-band management.
Relationship with EMAN? Can we use DASH in the EMAN framework since the communication between Parent and Child is out of the scope?

     2.6. SmartGrid

        The Smart Grid standards efforts underway in the United States are
        overseen by the US National Institute of Standards and Technology
        [NIST].  NIST was given the charter to oversee the development of
        smart grid related standards by the Energy Independence and Security
        Act of 2007.  NIST is responsible for coordinating a public-private



     <Tychon, et Al.>       Expires September 15, 2011               [Page 9]

     Internet-Draft       EMAN Applicability Statement            March 2011


        partnership with key energy and consumer stakeholders in order to
        facilitate the development of smart grid standards.

        The smart grid standards activity (sponsored and hosted by NIST) is
        monitored and facilitated by the SGIP (Smart Grid Interoperability
        Panel).  This group has several sub groups called working groups.
        These teams examine smaller parts of the smart grid.  They include
        B2G, I2G, and H2G and others (Building to Grid; Industrial to Grid
        and Home to Grid).

        http://collaborate.nist.gov/twiki-
        sggrid/bin/view/SmartGrid/SGIPWorkingGroupsAndCommittees

        When a working group detects a standard or technology gap, the team
        seeks approval from the SGIP for the creation of a Priority Action
        Plan (PAP).  The PAP is a private-public partnership with a charter
        to close a specific gap.  There are currently 17 Priority Action
        Plans (PAP).

        PAP 10 Addresses "Standard Energy Usage Information".

        Smart Grid standards will provide distributed intelligence in the
        network and allow enhanced load shedding.  For example, pricing
        signals will enable selective shutdown of non critical activities
        during  peak-load pricing periods.  These actions can be effected
        through both centralized and distributed management controls.
        Similarly, brown-outs, air quality alerts, and peak demand limits
        can be managed through the smart grid data models, based upon IEC
        61850.
Relationship to EMAN? We can control the IT devices to consume less when SmartGrid requires it.

     2.7. NAESB, ASHRAE and NEMA

        As an output of the PAP10's work on the standard information model,
        multiple stakeholders agreed to work on a utility centric model in
        NAESB (North American Electric Standards Board) and the building
        side information model in a joint effort by American Society of
        Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) and
        National Electrical Manufacturers Association (NEMA).

        The NAESB effort is a NAESB REQ/WEQ.
        http://www.naesb.org/smart_grid_PAP10.asp

        The ASHRAE effort is SPC201.   http://collaborate.nist.gov/twiki-
        sggrid/bin/view/SmartGrid/PAP17Information

        The output of both ANSI approved SDO's
Do you mean NAESB and ASHRAE?
is an information model. 
Sometimes you speak about information model, sometimes about data model in this section.
Please refer to RFC3444.

It
        is not a device level monitoring protocol.


     <Tychon, et Al.>       Expires September 15, 2011              [Page 10]



     Internet-Draft       EMAN Applicability Statement            March 2011


        After the ASHRAE SPC201 group formed as a result of initial work
        done by the PAP 10, the SGIP added PAP17 in order to focus
        specifically on in-building standards for energy using devices.

        PAP 17 "will lead to development of a data model standard to enable

        energy consuming devices and control systems in the customer
        premises to manage electrical loads and generation sources in
        response to communication with the Smart Grid. It will be possible
        to communicate information about those electrical loads to
        utilities, other electrical service providers, and market operators.

        The term "Facility Smart Grid Information" is intended to convey the
        nature of critical information originating from the customer
        operated "facility" which deals with the representation and dynamics
        of loads including prediction, measurement and shedding. It also
        helps to distinguish between this PAP and that of PAP10 which deals
        exclusively with the representation of energy usage.

        This data model standard will complement the flow, aggregation,
        summary, and forecasting of energy usage information being
        standardized by NAESB in PAP10 through the definition of additional
        distinct model components. While the NAESB standard is focusing on
        "a single limited-scope information model" that "will not cover all
        interactions associated with energy in the home or commercial space"
        including, for example, load management ("Report to the SGIP
        Governing Board: PAP10 plan," June 15, 2010), these new components
        will address load modeling and behavior necessary to manage on-site
        generation, demand response, electrical storage, peak demand
        management, load shedding capability estimation, and responsive
        energy load control."

        http://collaborate.nist.gov/twiki-
        sggrid/bin/view/SmartGrid/PAP17FacilitySmartGridInformationStandard



     2.8. ZigBee

        The "Zigbee Smart Energy 2.0 effort" currently focuses on wireless
        communication to smart home appliances.  It is intended to enable
        home energy management and direct load control by utilities.

        ZigBee protocols are intended for use in embedded applications
        requiring low data rates and low power consumption. ZigBee's current
        focus is to define a general-purpose, inexpensive, self-organizing
        mesh network that can be used for industrial control, embedded



     <Tychon, et Al.>       Expires September 15, 2011              [Page 11]






     Internet-Draft       EMAN Applicability Statement            March 2011


        sensing, medical data collection, smoke and intruder warning,
        building automation, home automation, etc.

        It is not known if the Zigbee Alliance plans to extend support to
        business class devices.  There also does not appear to be a plan for
        context aware marking.

        Zigbee is currently not an ANSI recognized SDO -- but they are
        working toward formal recognition.

     3. Limitations

        EMAN will address the needs of the network operators in term of
        measurement and, to a lesser extend, control over IP networks.

        It is not the purpose of EMAN to create a new protocol stack for
        energy-aware endpoints, but rather to create a data model to measure
        and report energy and other metrics over SNMP.

        Other legacy protocols may already exists (ModBus), but are not
        designed initially to work on IP, even if in some cases it is
        possible to transport them over IP with some limitations.

        The EMAN framework does not aim to address questions regarding
        Smartgrid, Electricity producers, distributors even if there is
        obvious link between them.
it seems like a requirement statement.
The readers are interested in the relationship. How everything should work together.

     4. Security Considerations

        EMAN uses the SNMP protocol and is subject to its own security. More
        specifically, SNMPv3 [RFC3411] provides important security features
        such as confidentiality, integrity, and authentication.

     4.1. SmartGrid

        Even if discussing SmartGrid security is not the scope of this
        document, NIST has found at least five standards that are directly
        related to smart grid security. That includes standards from NERC,
        IEEE, AMI System Security Requirements, UtilityAMI Home Area Network
        System Requirements and IEC standards.

        The SmartGrid security issue is more difficult being actually an
        open network, spawning entire territories and devices from smart
        meters, secondary and primary sub stations, etc.

        EDITOR'S NODE: TO BE EXPANDED



     <Tychon, et Al.>       Expires September 15, 2011              [Page 12]






     Internet-Draft       EMAN Applicability Statement            March 2011


     5. IANA Considerations

        This memo includes no request to IANA.

     6. References

     6.1. Normative References

        [RFC3411] An Architecture for Describing Simple Network Management
        Protocol (SNMP) Management Frameworks
I was expecting a coupe of EMAN references. At least the working group items.

Regards, Benoit.

     6.2. Informative References

         [DQERM] https://datatracker.ietf.org/doc/draft-quittek-eman-
        reference-model/

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





     7. Acknowledgments

        This document was prepared using 2-Word-v2.0.template.dot.

        The authors would like to thank Jeff Wheeler for its contribution to
        the DMTF section.



        Copyright (c) 2011 IETF Trust and the persons identified as authors
        of the code. All rights reserved.

        Redistribution and use in source and binary forms, with or without
        modification, is permitted pursuant to, and subject to the license
        terms contained in, the Simplified BSD License set forth in Section
        4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
        (http://trustee.ietf.org/license-info).










     <Tychon, et Al.>       Expires September 15, 2011              [Page 13]






     Internet-Draft       EMAN Applicability Statement            March 2011


     Authors' Addresses

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


        Matthew Laherty
        Cisco Systems, Inc.
        Email: mlaherty@cisco.com


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





























     <Tychon, et Al.>       Expires September 15, 2011              [Page 14]








--------------010304070504010404050805-- From moulchan@cisco.com Wed Mar 23 05:46:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A203B3A6850 for ; Wed, 23 Mar 2011 05:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf-0OiTWnsTL for ; Wed, 23 Mar 2011 05:46:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 098B63A6836 for ; Wed, 23 Mar 2011 05:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=9217; q=dns/txt; s=iport; t=1300884471; x=1302094071; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=3M08MJeVsACfTidN9aUpp+uAFcxlLXc66kjZX9L3LzQ=; b=aA/+x042x8Z2PMu9G41NQ5KqKb5Z3e4JQxwnmRp/0BkkpKm0QfYhUizD MN9RpaK/g2fXcslCUmR3uA+BwWK31zdRxbKETkG/43itRQSpHRD3owGEA aXbrhvSwFdrthw0Krol3f5Aeki2yYAhMWB7a6zADinpAiItRbZ965F0YH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACWJiU2tJV2a/2dsb2JhbACCYaJid6dPnBSFaQSFN4sQ X-IronPort-AV: E=Sophos;i="4.63,231,1299456000"; d="scan'208,217";a="669800607" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2011 12:47:50 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2NCloxd020343 for ; Wed, 23 Mar 2011 12:47:50 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Mar 2011 07:47:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE958.848284B5" Date: Wed, 23 Mar 2011 07:47:46 -0500 Message-ID: In-Reply-To: <4D88DB0B.1000405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-quittek-eman-reference-model-01 Thread-Index: AcvoudHSl1HkhIkBTLKSudqKsgpAtAAnlm6Q References: <4D88D2D1.2070306@cisco.com> <4D88DB0B.1000405@cisco.com> From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 23 Mar 2011 12:47:50.0722 (UTC) FILETIME=[84F4CA20:01CBE958] Subject: [eman] Review of draft-quittek-eman-reference-model-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 12:46:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE958.848284B5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 Here is a review of draft-quittek-eman-reference-model-01.=20 =20 Thanks Mouli =20 Firstly, the draft is very well organized and written. The title seems appropriate -a reference diagram for the monitoring scenarios. The second section covers Terminology of energy terms. The third section proposes a - Reference model - the notions of a power source, meter, and device are clearly explained. Internal measurement and the external measurement are illustrated for clarity. Several different monitoring scenarios have been considered. For those scenarios, control is added and illustrated.=20 =20 Firstly, the reference model described as in Figure 1, is an useful as a logical construction. However, in the case of external measurement, it is also possible to get additional information such as power states from end-devices. It is possible that the "Power- Monitor" layer can communicate with the end-device, and report the usage information and the power state information. I think this aspect can be considered in the reference model, for externally powered/ metered devices.=20 =20 While the logical separation of Source, Meter and Device is useful, the measurement at all these points should be the same ? Unless the measurement points are geographically separated in physical distance; in that scenario transmission loss comes in to play.=20 =20 In Section 4- Energy Management Reference Model - If there are 3 shades of Cntrl - Power Source Cntrl, Power Meter Cntrl, and Power State Control, there should be some co-ordination between these actions and cannot be independent. A small nit - the figure after figure 9 is not indexed =20 In Section 4, in Figure 14. 15, how can Power-State be configured ? Similarly, for devices beyond a gateway, as in Figure 16, how can Power-States be configured on the device ?=20 =20 Power Source Terminology - it is not the source of power or generation of power - It is only the power supply feed to the device.=20 =20 Not sure about if we should label Energy Monitoring protocol using SNMP as EMON ?=20 =20 I think there should be some information should be added for Security consideration in view of configuration, =20 =20 The notion of energy management - power-states is it only restricted to ON and OFF ? in which case, the control can reside at the source or switch which can be turn ON or OFF. =20 =20 ------_=_NextPart_001_01CBE958.848284B5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = all,

 

Here is a review of = draft-quittek-eman-reference-model-01.

 

Thanks

Mouli

 

Firstly, the draft is = very well organized and written.  The title seems appropriate –a = reference diagram for the monitoring scenarios.  The second section covers Terminology of energy terms. The third section  proposes a - = Reference model  - the notions of a power source, meter, and  device are clearly explained.  Internal measurement and the external = measurement are illustrated for clarity.  Several different monitoring scenarios = have been considered.  For those scenarios, control is added and illustrated. =

 

Firstly, the reference = model described    as in Figure 1, is an useful as a logical construction.  However, in the case of external measurement, it is = also possible to get additional information such as power states from end-devices.  It is possible that the “Power- Monitor” = layer can communicate with the end-device, and report the usage information = and the power state information. I think this aspect can be considered in the = reference model, for externally powered/ metered devices.

 

While the logical = separation of Source, Meter and Device  is useful, the measurement at all these = points should be the same ? Unless the measurement points are geographically = separated in physical distance; in that scenario transmission loss comes in to = play.

 

In Section 4- Energy = Management Reference Model – If there are 3 shades of Cntrl – Power = Source Cntrl, Power Meter Cntrl, and Power State Control, there should be some co-ordination between these actions and cannot be independent. A small = nit -  the figure after figure 9 is not indexed

 

In Section 4, in Figure = 14. 15, how can Power-State be configured ?  Similarly, for devices beyond = a gateway, as in Figure 16, how can Power-States be configured on the = device ?

 

Power Source = Terminology – it is not the source of power or generation of power – It is only = the power supply feed to the device.

 

Not sure about if we = should label Energy Monitoring protocol using SNMP as  EMON ? =

 

I think there should be = some information should be added for Security consideration in view of configuration, 

 

The notion of energy = management - power-states is it only restricted to ON and OFF ?  in which case, = the control can reside at the source or switch which can be turn ON or OFF.    

 

------_=_NextPart_001_01CBE958.848284B5-- From moulchan@cisco.com Wed Mar 23 09:58:17 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7463A6935 for ; Wed, 23 Mar 2011 09:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nad7CGzgQO-g for ; Wed, 23 Mar 2011 09:58:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9D6B63A6933 for ; Wed, 23 Mar 2011 09:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=6173; q=dns/txt; s=iport; t=1300899587; x=1302109187; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=PiRaKNhB4/qyHdqe/iluW/7lcZ94iQHiSBOZXEWyLTQ=; b=bRn3sWKDyOYwpGmxJlWZZ0XEJ7oueD5twOGb3/hKGF9/QvSbwPN86BmE IBHRHNuUPs38vwpXGQjDoZiNv+28YtJPRKArCcY9DHUggvFzAqmYaPQag ECLOidXKgVtGwCRB2aCm0pstcdf26A0vUJsyYpvCFAG2yRH2CRC5B6lGj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACvEiU2tJV2b/2dsb2JhbACCYKJkd6c0nCOFaQSFN4sQ X-IronPort-AV: E=Sophos;i="4.63,232,1299456000"; d="scan'208,217";a="281542979" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2011 16:59:46 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2NGxl3a003875 for ; Wed, 23 Mar 2011 16:59:47 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Mar 2011 11:59:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE97B.B702C6F8" Date: Wed, 23 Mar 2011 11:59:42 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-quittek-eman-battery-mib-00.txt Thread-Index: AcvoudHSl1HkhIkBTLKSudqKsgpAtAAnlm6QAAjELRA= References: <4D88D2D1.2070306@cisco.com> <4D88DB0B.1000405@cisco.com> From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 23 Mar 2011 16:59:47.0516 (UTC) FILETIME=[B7447FC0:01CBE97B] Subject: [eman] draft-quittek-eman-battery-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 16:58:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE97B.B702C6F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all,=20 =20 Here is my review of draft-quittek-eman-battery-mib-00.txt =20 Thanks Mouli =20 This draft is also well-written. This draft and has a good description of the MIB objects for battery monitoring.=20 =20 I have a couple of comments and questions.=20 =20 First, the batteryIndex - how can this be associated with an Entity such as PC for which the battery is providing backup power ? What if there are two batteries for a device ?=20 =20 So, for a Data center use case, they should use the UPS MIB to monitor the UPS capacity to ensure UPS is not drained out ?=20 =20 I have a basic question on barteryState. You have defined five states - full(1), partiallyCharged(2), empty(3), charging(4), discharging(5), unknown(6). =20 Isn't this similar in spirit to PowerStates discussion for entities ? =20 One possibility is to define FULL and Empty as states for a battery similar to ON and OFF for an entity.=20 =20 =20 ------_=_NextPart_001_01CBE97B.B702C6F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all, =

 

Here is my review of =  draft-quittek-eman-battery-mib-00.txt

 

Thanks

Mouli

 

This draft is also well-written. This draft and has a good description of the = MIB objects for battery monitoring.

 

I have a couple of = comments and questions.

 

First, the = batteryIndex  - how can this be associated with an Entity such as PC for which the = battery is providing backup power ?   What if there are two batteries for = a device ?

 

So, for a Data = center use case, they should use the UPS MIB to monitor the UPS capacity to ensure = UPS is not drained out ?

 

I have a basic question on barteryState. You have defined five states = -  full(1),  partiallyCharged(2),  empty(3),  = charging(4),   discharging(5),  unknown(6).  

Isn’t this similar in spirit to PowerStates discussion for entities ?  =

One possibility is to define FULL and Empty as states for a battery similar = to ON and OFF for an entity.

 

 

------_=_NextPart_001_01CBE97B.B702C6F8-- From ietf@quittek.at Wed Mar 23 14:14:04 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BE928C110 for ; Wed, 23 Mar 2011 14:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-4bfqvzODPw for ; Wed, 23 Mar 2011 14:14:03 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id A852228C0E5 for ; Wed, 23 Mar 2011 14:14:02 -0700 (PDT) Received: from [10.54.42.131] (3-254.197-178.cust.bluewin.ch [178.197.254.3]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MOiGM-1Q7TTC2u18-006Axy; Wed, 23 Mar 2011 22:15:33 +0100 References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> In-Reply-To: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-3-485153671 Message-Id: <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at> From: Juergen Quittek Date: Wed, 23 Mar 2011 22:15:00 +0100 To: "Ebner, Fritz" X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:UEEPgctV1iYrhSaRNJdRCPSKgHWk0m+wqRkkJU8Sdca zrPCmqsE5lEbMaIhd1QDmhoijumBwLd5G4NUINjIJOb9jaU7LB kWhCRcgtczT/qNd2lsDjDL1TRPLqPPgN7yMzPgKUSoQYLtV9ug IqDGYELoQ2ExkkJ24yObAN2xWCnUey8bx8fAxjj5JlHqcZCGxp M+E2Lhh0zLze5kU/rzLmA== Cc: eman@ietf.org Subject: Re: [eman] IETF EMAN request to address printers... X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 21:14:04 -0000 --Apple-Mail-3-485153671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Fritz, Thank you for your input. We will consider printers and the document your referred to in the next = revision of the requirements. I don't think many changes will need to be made here. But for the MIB documents, we now have another set of PWG = power/functional states next to DMTF and ACPI states. Thanks, Juergen Am 18.03.2011 um 19:11 schrieb Ebner, Fritz: > Hello, > Please make sure that any power control or monitoring MIBs or drafts = that the EMAN WG produces can cover the use cases, power controls, and = power monitoring features provided in the printer working group. = Details are below: > =20 > The IEEE/ISTO Printer Working Group has published their Candidate = Standard for Power Management and the associate protocol binding for = SNMP. Below are the links to the abstract model and MIB. > =20 > PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0: > =20 > The PWG Power Management Model for Imaging Systems 1.0 specification = was=20 > recently approved as a PWG Candidate Standard and is now available at: >=20 > http://www.pwg.org/standards.html >=20 > and >=20 > = ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf = / doc > =20 > PWG 5106-5 - PWG Imaging System Power MIB v1.0 > =20 > The PWG Imaging System Power MIB v1.0 specification was recently = approved > as a PWG Candidate Standard and is now available at: >=20 > http://www.pwg.org/standards.html >=20 > and >=20 > = ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf= / doc / mib > - PDF, MS Word, and ASN.1 source in plaintext >=20 > = ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib= .pdf > - ASN.1 source in color highlighted PDF > =20 > Thanks, > Fritz Ebner > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-3-485153671 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Fritz,

Thank you for your = input.

We will consider printers and the = document your referred to in the next revision of the = requirements.
I don't think many changes will need to be made = here.

But for the MIB documents, we now have = another set of PWG power/functional states next to DMTF and ACPI = states.

Thanks,

 &n= bsp;  Juergen


Am 18.03.2011 = um 19:11 schrieb Ebner, Fritz:

Hello,
 
 
PWG 5106.4 - PWG Power Management Model for Imaging = Systems 1.0:
 
______________________________________________= _
eman mailing list
eman@ietf.org
; Thu, 24 Mar 2011 05:46:59 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Mar 2011 00:46:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE9E6.E42D0EE2" Date: Thu, 24 Mar 2011 00:46:54 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] Review of draft-quittek-eman-reference-model-01 Thread-Index: AcvoudHSl1HkhIkBTLKSudqKsgpAtAAnlm6QACL9g8A= References: <4D88D2D1.2070306@cisco.com> <4D88DB0B.1000405@cisco.com> From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 24 Mar 2011 05:46:59.0700 (UTC) FILETIME=[E4965B40:01CBE9E6] Subject: Re: [eman] Review of draft-quittek-eman-reference-model-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 05:45:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE9E6.E42D0EE2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I would like to add a comment on Identity. Thanks. Mouli =20 The draft talks about=20 "Identity is basic information about what a device is, in function, in its specific instance of manufacture, and its specific local human- readable name.". =20 Identity of network devices is the topic of the energy aware MIB - Index (Name, unique ID, reference to other MIB index), Context (Role description, Keywords, Importance).=20 =20 The entPhysicalTable of the entity MIB has references to =20 entPhysicalDescr - A textual description of physical entity. This object should contain a string that identifies the manufacturer's name for the physical entity and=20 entPhysicalVendorType is also present - an enterprise-specific registration identifier value indicating the specific equipment type. =20 =20 However, as Dan Romascanu has pointed out in another thread, these variables need to be read by machines (NMS) and those provide translations in human readable form.=20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mouli Chandramouli (moulchan) Sent: Wednesday, March 23, 2011 6:18 PM To: eman mailing list Subject: [eman] Review of draft-quittek-eman-reference-model-01 =20 Hello all, =20 Here is a review of draft-quittek-eman-reference-model-01.=20 =20 Thanks Mouli =20 Firstly, the draft is very well organized and written. The title seems appropriate -a reference diagram for the monitoring scenarios. The second section covers Terminology of energy terms. The third section proposes a - Reference model - the notions of a power source, meter, and device are clearly explained. Internal measurement and the external measurement are illustrated for clarity. Several different monitoring scenarios have been considered. For those scenarios, control is added and illustrated.=20 =20 Firstly, the reference model described as in Figure 1, is an useful as a logical construction. However, in the case of external measurement, it is also possible to get additional information such as power states from end-devices. It is possible that the "Power- Monitor" layer can communicate with the end-device, and report the usage information and the power state information. I think this aspect can be considered in the reference model, for externally powered/ metered devices.=20 =20 While the logical separation of Source, Meter and Device is useful, the measurement at all these points should be the same ? Unless the measurement points are geographically separated in physical distance; in that scenario transmission loss comes in to play.=20 =20 In Section 4- Energy Management Reference Model - If there are 3 shades of Cntrl - Power Source Cntrl, Power Meter Cntrl, and Power State Control, there should be some co-ordination between these actions and cannot be independent. A small nit - the figure after figure 9 is not indexed =20 In Section 4, in Figure 14. 15, how can Power-State be configured ? Similarly, for devices beyond a gateway, as in Figure 16, how can Power-States be configured on the device ?=20 =20 Power Source Terminology - it is not the source of power or generation of power - It is only the power supply feed to the device.=20 =20 Not sure about if we should label Energy Monitoring protocol using SNMP as EMON ?=20 =20 I think there should be some information should be added for Security consideration in view of configuration, =20 =20 The notion of energy management - power-states is it only restricted to ON and OFF ? in which case, the control can reside at the source or switch which can be turn ON or OFF. =20 =20 ------_=_NextPart_001_01CBE9E6.E42D0EE2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I would like to add a comment on Identity.  =  Thanks.  Mouli

 

The draft talks about

“Identity is basic information about what a device = is, in function, in its specific instance of manufacture, and its specific = local human- readable name.”.

 

Identity of network devices is the topic of the energy = aware MIB –  Index (Name, unique ID, reference to other MIB = index),  Context (Role description, Keywords, Importance).

 

The entPhysicalTable of the entity MIB has  = references to   

         &nbs= p;            = ;            =           entPhysicalDescr&n= bsp; - A textual description of physical entity.  This object  should contain a string that identifies the manufacturer's name for the = physical entity and

          =             &= nbsp;           &n= bsp;        entPhysicalVendorType is also present - an enterprise-specific =  registration identifier value indicating the specific  equipment type.  =

          =             &= nbsp;           &n= bsp;    

However, as Dan Romascanu has pointed out in another = thread, these variables need to be read by machines (NMS) and those provide translations in human readable form.

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Mouli Chandramouli (moulchan)
Sent: Wednesday, March 23, 2011 6:18 PM
To: eman mailing list
Subject: [eman] Review of = draft-quittek-eman-reference-model-01

 

Hello all,

 

Here is a review of = draft-quittek-eman-reference-model-01.

 

Thanks

Mouli

 =

Firstly, the draft is very well organized and = written.  The title seems appropriate –a reference diagram for the = monitoring scenarios.  The second section covers Terminology of energy terms. = The third section  proposes a - Reference model  - the notions of = a power source, meter, and  device are clearly explained.  Internal measurement and the external measurement are illustrated for = clarity.  Several different monitoring scenarios have been considered.  For = those scenarios, control is added and illustrated.

 

Firstly, the reference model = described    as in Figure 1, is an useful as a logical construction.  However, in = the case of external measurement, it is also possible to get additional = information such as power states from end-devices.  It is possible that the = “Power- Monitor” layer can communicate with the end-device, and report the = usage information and the power state information. I think this aspect can be = considered in the reference model, for externally powered/ metered devices. =

 

While the logical separation of Source, Meter and Device  is useful, the measurement at all these points should be = the same ? Unless the measurement points are geographically separated in physical distance; in that scenario transmission loss comes in to play. =

 

In Section 4- Energy Management Reference Model = – If there are 3 shades of Cntrl – Power Source Cntrl, Power Meter = Cntrl, and Power State Control, there should be some co-ordination between these = actions and cannot be independent. A small nit -  the figure after figure 9 = is not indexed

 

In Section 4, in Figure 14. 15, how can Power-State = be configured ?  Similarly, for devices beyond a gateway, as in Figure = 16, how can Power-States be configured on the device ?

 

Power Source Terminology – it is not the = source of power or generation of power – It is only the power supply feed to = the device.

 

Not sure about if we should label Energy Monitoring = protocol using SNMP as  EMON ?

 

I think there should be some information should be = added for Security consideration in view of configuration, 

 

The notion of energy management - power-states is = it only restricted to ON and OFF ?  in which case, the control can reside = at the source or switch which can be turn ON or OFF.     =

 =

------_=_NextPart_001_01CBE9E6.E42D0EE2-- From moulchan@cisco.com Thu Mar 24 04:30:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88CF028C0E0 for ; Thu, 24 Mar 2011 04:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8+5LaU033P1 for ; Thu, 24 Mar 2011 04:30:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2137528C0D9 for ; Thu, 24 Mar 2011 04:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=16821; q=dns/txt; s=iport; t=1300966318; x=1302175918; h=mime-version:subject:date:message-id:references:from:to; bh=GI0jz57IKsj15fZwUROEfWoAq0FQfVICYsNpKMCB8TI=; b=Bih7iEynzoQx999qCCoFT/8N/dMK3h01QQc+xFEE2h2wVEm0zQLeJx4k 8yF+/KY4d62Eh3OYLE1d9jBPdppoTKuIlA3O0poZGvXzG023zOhoHBqjt Xo56tG1bgAwGdfGdpnBR7xtm0kbPWLvLGWFStH11wpKAYKQONQQeo+zcI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANvHik2tJXHB/2dsb2JhbACCX6Jkd6VynEOCfYJsBIU3ixA X-IronPort-AV: E=Sophos;i="4.63,236,1299456000"; d="scan'208,217";a="670234495" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-6.cisco.com with ESMTP; 24 Mar 2011 11:31:58 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2OBVvEm008234 for ; Thu, 24 Mar 2011 11:31:57 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Mar 2011 06:31:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEA17.15059313" Date: Thu, 24 Mar 2011 06:31:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-nordman-eman-energy-perspective-01 Thread-Index: AcvoudHSl1HkhIkBTLKSudqKsgpAtAAnlm6QAAjELRAAJOzKoA== References: <4D88D2D1.2070306@cisco.com> <4D88DB0B.1000405@cisco.com> From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 24 Mar 2011 11:31:57.0280 (UTC) FILETIME=[154E6E00:01CBEA17] Subject: [eman] Review of draft-nordman-eman-energy-perspective-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 11:30:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEA17.15059313 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 Here is my review of draft-nordman-eman-energy-perspective-01 =20 Thanks Mouli =20 This document provides a general overview of energy monitoring for a wider audience as indicated in the Introduction. Some general concepts are explained. I would think for applicability statement for EMAN should have some more detail. I think the overall document needs some more tightening up/rewriting for an overview of Energy Monitoring. =20 =20 Here are some specific comments.=20 =20 While the Abstract talks about ANSI, there is no reference in the rest of the document.=20 =20 In Section 1.1. "The same protocol is used whether the NMS is communicating with an intermediate or end use device."=20 =20 This may not be true. Often the protocol between an aggregator / Gateway to the end-points can be proprietary; which is the present-day scenario. =20 =20 In Section 1.1. "The NMS will commonly have an entire single building as its scope, though in some cases will cover only a part of a building, or multiple buildings." =20 There is a confusion notion of EMAN protocol. I would assume that currently SNMP is considered as the mechanism for energy monitoring,=20 which may not preclude other possible choices such as IPFIX or Syslog in future. =20 In that context, the role of NMS should be defined appropriately. This definition NMS is not accurate and notion of buildings does not seem correct "The NMS will commonly have an entire single building as its scope, though in some cases will cover only a part of a building, or multiple buildings". =20 In Section 1.2. Usage Overview - This section is not clear. As the opening sentence "The basic usage of the eman protocol is a building operator installing software for collecting eman informatin on an existing device in the building".=20 =20 As mentioned before, EMAN is not restricted to a building. Secondly, a management MIB framework should be implemented by the devices (PCs, network devices, PCs,). Then a management station can poll those devices to collect the power or energy information.=20 =20 "The NMS then determines how often to query each device for updates to the energy information." vThe frequency of energy measurement collection is configured by the network operator. =20 Section 2 - Terminology either should have a lot more concepts defined or merged with some other section, In particular, a more precise definition of Energy could have been given. Other forms of energy such as Methane, Steam do not seem relevant to this WG.=20 =20 If we are defining the terminology of Building network - it is better to define what it is - what are the components etc.=20 =20 In Section 3 - Use contexts=20 =20 Highly Managed, Lightly Managed describe general concepts. Same with Residential or Commercial buildings.=20 It is not clear why Vehicles should be included for energy monitoring. First, Electric cars are in future and have a battery. Driver of an electric car would want "local" energy status on the car dashboard.=20 =20 Regarding Identity, I had provided my comment in http://www.ietf.org/mail-archive/web/eman/current/msg00417.html =20 =20 =20 =20 ------_=_NextPart_001_01CBEA17.15059313 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = all,

 

Here is my review of draft-nordman-eman-energy-perspective-01

 

Thanks

Mouli

 

This document provides a general overview of energy = monitoring for a wider audience as indicated in the Introduction.

Some general concepts are explained. I would think for applicability statement for EMAN should have some more = detail.

I think the overall document needs some more tightening = up/rewriting for an overview of Energy Monitoring.  

 

Here are some specific comments.

 

While the Abstract talks about ANSI, there is no reference = in the rest of the document.

 

In Section 1.1.  “The same protocol is used = whether the NMS is communicating with an intermediate or end use device.” =

 

This may not be true. Often the protocol between an = aggregator / Gateway to the end-points can be proprietary; which is the present-day scenario.

 

 

In Section 1.1. “The NMS will commonly have = an entire single building as its scope, though

   in some cases = will cover only a part of a building, or multiple = buildings.”

 

There is a confusion notion of EMAN protocol. I would = assume that currently SNMP is considered as the mechanism for energy monitoring, =

which may not preclude other possible choices such as IPFIX = or Syslog in future.

 

In that context, the role of NMS should be defined = appropriately. This definition NMS  is not accurate and notion of buildings does = not seem correct =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;       “The NMS will = commonly have an entire single building as its scope, though in some cases will cover = only a part of a building, or multiple

   = buildings”.

 

In Section 1.2.  Usage Overview  - This section = is not clear.  As the opening sentence “The basic usage of the eman protocol is a building operator

 installing software = for collecting eman informatin on an existing device in the building”. =

 

As mentioned before, EMAN is not restricted to a building. = Secondly, a management MIB framework should be implemented by the devices (PCs, = network devices, PCs,). Then a management station can poll those devices to = collect the power or energy information.

 

 “The NMS then determines how often to = query each device for updates to the energy information.” vThe frequency of energy = measurement collection is configured by the network operator.

 

Section 2 – Terminology either should have a lot more = concepts defined or merged with some other section,  In particular, a more = precise definition of Energy could have been given. Other forms of energy such = as Methane, Steam do not seem relevant to this WG.

 

If we are defining the terminology of  Building = network – it is better to define what it is – what are the components etc. =

 

In Section 3 – Use contexts

 

Highly Managed,  Lightly Managed describe general = concepts. Same with Residential or Commercial buildings.


It is not clear why Vehicles should be included for energy monitoring. = First, Electric cars are in future and have a battery.  Driver of an = electric car would want “local” energy status on the car dashboard. =

 

Regarding Identity, I had provided my comment in  = http://www.ietf.org/mail-archive/web/eman/current/msg00417.html<= /o:p>

 

 

 

 

------_=_NextPart_001_01CBEA17.15059313-- From blueroofmusic@gmail.com Thu Mar 24 08:53:50 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE59B28C0D0 for ; Thu, 24 Mar 2011 08:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbnU5DZktk3t for ; Thu, 24 Mar 2011 08:53:49 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8555D28C0CE for ; Thu, 24 Mar 2011 08:53:48 -0700 (PDT) Received: by fxm15 with SMTP id 15so185643fxm.31 for ; Thu, 24 Mar 2011 08:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OMEieIIwUxK72RJy+TdRpQ0y2nusIF8BSGwTX9cXz/U=; b=EsMYUaiGlwsRCFZ6cMH28E0aBzXo6aDat/CTRgK6PtCe62MhIHAREScjs/1iSSj4eH +uZnxfRCZTxO80lWl03cNJpj8Sf1XmMMqqU4Z9r9ov81nwHFMbfXTtcu/k1GXp5zXBBg MfbmI8+oOD7P6kg+XopdgTsYYH4A+ytEf/dro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hSl54ENMFXFOArqg686N3xXrpCcAovLBbrAqMGS3O5fowhnx4zJSQ7D6xUh8b3GdtL fH/itVL+YlRtUiuIekZp/pDzLY+7hSLPzmIPniQ5eL6ah1IBec7EkVtl7i2JaHq6TgDC wUt1382Nc53dQiHJJH8jvesCxOqYhxzHdkx/o= MIME-Version: 1.0 Received: by 10.223.127.213 with SMTP id h21mr4438378fas.139.1300982111754; Thu, 24 Mar 2011 08:55:11 -0700 (PDT) Received: by 10.223.66.68 with HTTP; Thu, 24 Mar 2011 08:55:11 -0700 (PDT) In-Reply-To: <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at> References: <0131AC21C657A3418A5B6CA168C4C57E0A813EA6@USA7061MS04.na.xerox.net> <23E19EBD-1A1E-47AB-BA8F-47B8E919A2DE@quittek.at> Date: Thu, 24 Mar 2011 11:55:11 -0400 Message-ID: From: Ira McDonald To: Juergen Quittek , Ira McDonald Content-Type: multipart/alternative; boundary=002354530ebca15b9c049f3c80ce Cc: eman@ietf.org, "Ebner, Fritz" Subject: Re: [eman] IETF EMAN request to address printers... X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 15:53:50 -0000 --002354530ebca15b9c049f3c80ce Content-Type: text/plain; charset=ISO-8859-1 Hi Juergen, Speaking as the author of the IEEE-ISTO PWG Power Model (PWG 5106.4) and Power MIB (PWG 5106.5): No, there are not a new set of states to deal with for IETF EMAN. The enumerated states in the PWG Power Model are exactly the DMTF states from the DMTF CIM Power Management Profile (DMTF DSP 1027) multiplied by ten (see section 9.7 of PWG 5106.4), to allow our PWG vendor extension states (that collapse to the base states for CIM mapping). Except that the PWG power states use more common names (e.g., CIM Sleep-Light becomes PWG Standby and CIM Sleep-Deep becomes PWG Suspend). Also the normative mappings to the equivalent ACPI states (and intermediate state transitions for resets) are taken from the DMTF CIM Power Management Profile. The PWG has been an alliance partner with DMTF CIM for some years and coherence with CIM was a primary design requirement for our PWG Power Model. Cheers, - Ira (Technical Lead of PWG Power Management) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Christmas through April: 579 Park Place Saline, MI 48176 734-944-0094 May to Christmas: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Mar 23, 2011 at 5:15 PM, Juergen Quittek wrote: > Hi Fritz, > > Thank you for your input. > > We will consider printers and the document your referred to in the next > revision of the requirements. > I don't think many changes will need to be made here. > > But for the MIB documents, we now have another set of PWG power/functional > states next to DMTF and ACPI states. > > Thanks, > > Juergen > > > Am 18.03.2011 um 19:11 schrieb Ebner, Fritz: > > Hello, > Please make sure that any power control or monitoring MIBs or drafts that > the EMAN WG produces can cover the use cases, power controls, and power > monitoring features provided in the printer working group. Details are > below: > > The IEEE/ISTO Printer Working Group has published their Candidate Standard > for Power Management and the associate protocol binding for SNMP. Below are > the links to the abstract model and MIB. > > PWG 5106.4 - PWG Power Management Model for Imaging Systems 1.0: > > The PWG Power Management Model for Imaging Systems 1.0 specification was > recently approved as a PWG Candidate Standard and is now available at: > > http://www.pwg.org/standards.html > > and > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf / > doc > > PWG 5106-5 - PWG Imaging System Power MIB v1.0 > > The PWG Imaging System Power MIB v1.0 specification was recently approved > as a PWG Candidate Standard and is now available at: > > http://www.pwg.org/standards.html > > and > > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf > / doc / mib > - PDF, MS Word, and ASN.1 source in plaintext > > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf > - ASN.1 source in color highlighted PDF > > Thanks, > Fritz Ebner > _______________________________________________ > 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 > > --002354530ebca15b9c049f3c80ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Juergen,

Speaking as the author of the IEEE-ISTO PWG Power
Mod= el (PWG 5106.4) and Power MIB (PWG 5106.5):

No, there are not a new = set of states to deal with for
IETF EMAN.

The enumerated states i= n the PWG Power Model are
exactly the DMTF states from the DMTF CIM Power
Management Profile (DMTF= DSP 1027) multiplied by
ten (see section 9.7 of PWG 5106.4), to allow = our PWG
vendor extension states (that collapse to the=A0base states for CIM mapping).

Except that the PWG power states use more common <= br>names (e.g., CIM Sleep-Light becomes PWG Standby
and CIM Sleep-Deep b= ecomes PWG Suspend).

Also the normative mappings to the equivalent A= CPI
states (and intermediate state transitions for resets)
are taken from th= e DMTF CIM Power Management
Profile.

The PWG has been an alliance= partner with DMTF CIM
for some years and coherence with CIM was a prim= ary
design requirement for our PWG Power Model.

Cheers,
- Ira (Techni= cal Lead of PWG Power Management)


Ira McDonald (Mu= sician / Software Architect)
Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Desig= nated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
<= a href=3D"http://sites.google.com/site/blueroofmusic" target=3D"_blank">htt= p://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:b= lueroofmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 Saline, MI=A0 48176
= =A0 734-944-0094
May to Christmas:
=A0 PO Box 221=A0 Grand Marais, MI= 49839
=A0 906-494-2434



On Wed, Mar 23, 2011 at 5:15 PM, Juergen= Quittek <ietf@quit= tek.at> wrote:
Hi Fritz,

Thank yo= u for your input.

We will consider printers and th= e document your referred to in the next revision of the requirements.
I don't think many changes will need to be made here.
But for the MIB documents, we now have another set of PWG powe= r/functional states next to DMTF and ACPI states.

Thanks,

=A0=A0 =A0Juergen


Am 18.03.2011 um 19:11 schrieb Ebner, Fritz:

Hello,
Please make sure that any power control or monitoring MIBs or drafts that t= he EMAN WG produces can cover the use cases, power controls, and power moni= toring features provided in the printer working group.=A0 Details are below= :
=A0
The IEEE/ISTO Printer Working Grou= p has published their Candidate Standard for Power Management and the assoc= iate protocol binding for SNMP.=A0 Below are the links to the abstract mode= l and MIB.
=A0
PWG 5106.4 - PWG Power Manag= ement Model for Imaging Systems 1.0:
=A0
The PWG Power Management = Model for Imaging Systems 1.0 specification was=A0
recently= approved as a PWG=A0Candi= date=A0Stand= ard=A0and is now available at:

=A0http://www.pwg.org/standards= .html

and

=A0ftp://ftp.pwg.org/pub/pwg/candidates/cs-w= imspower10-20110214-5106.4.pdf=A0/ doc
=A0
PWG 5106-5 - PWG Imaging System Po= wer MIB v1.0
=A0
The PWG Imaging System Power MIB v1.0 specification was recently approvedas a PWG=A0Candidate=A0Standard=A0and is now available at:

=A0http://www.pwg.org/standards= .html

and

=A0ftp://ftp.pwg.org/pub/pwg/candidates/c= s-wimspowermib10-20110214-5106.5.pdf=A0/ doc / mib
=A0- PDF, MS Word, and ASN.1 source in plaintext

=A0ftp://= ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5-mib.pdf
=A0- ASN.1 source in color highlighted PDF
_______________________________________________
eman mailing lis= t
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman


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


--002354530ebca15b9c049f3c80ce-- From russ@cisco.com Thu Mar 24 16:41:49 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C48728C14C for ; Thu, 24 Mar 2011 16:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWkg5CNdJ0w0 for ; Thu, 24 Mar 2011 16:41:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id ECFA428C11A for ; Thu, 24 Mar 2011 16:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=3172; q=dns/txt; s=iport; t=1301010200; x=1302219800; h=message-id:date:from:mime-version:to:cc:subject; bh=11Av4V8mKduwgdnBZ6ew5FgUfu9Awe2OyAMEmt8b0J4=; b=IHVFAbJMwaxecnVEaX9PDDPyVkNDS+YgLwzasPV+wEJkU+29zL9y+Mbs X0j4lHw13kvPo2HIt9BVUo+h1ln+aiR7lCpxVSVFIg7YzaD8aqGC9OXYW M8/xRDt9t2/GOkEOCSok7QBt2dA6+jfH3eEQbCinz4L/56A2dytyrFrWE E=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG7Wi02tJXG9/2dsb2JhbAClSneoR5xKhWkEjG+DUg X-IronPort-AV: E=Sophos;i="4.63,240,1299456000"; d="asc'?scan'208";a="227462360" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rtp-iport-1.cisco.com with ESMTP; 24 Mar 2011 23:43:19 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2ONhIYZ030136; Thu, 24 Mar 2011 23:43:18 GMT Message-ID: <4D8BD71C.4040202@cisco.com> Date: Thu, 24 Mar 2011 19:43:24 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: bnordman@lbl.gov, rolf.winter@neclab.eu X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig319946833263C7A41DF5527B" Cc: eman@ietf.org Subject: [eman] Some thoughts on: draft-norwin-energy-consider-02.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 23:41:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig319946833263C7A41DF5527B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just a few things that popped into my head while I was reading this: =3D=3D The power level of a device is its current electricity demand. It is an important complement to power mode, providing articulation of power level within the basic mode. It also avoids the need for a large number of named modes. Basic modes are distinguished by important functional differences or power levels. Core power modes are an abstraction from individual implementations. How would you envision the power usage being articulated in a way that makes sense to everyone? IE, some devices use a realyl large amount of power, and others a really small amount. Also, would you want to average the power usage over time, or simply take the current (immediate) usage? Any thoughts on how this piece could be organized to make sense in a wide array of circumstances? =3D=3D A critical feature of the set of basic power states is that they should be universally applicable to any device eman is applied to. This does not mean that each device has every state, but that the model is sufficiently general that it can be applied to all. I think the solution presented on list earlier --having device specific "extensions" or "forks" in the MIB, is probably the way to go here... It might be worth updating the doc to take this type of capability into consideration (?). =3D=3D "Species". This is the fundamental classification that a device is a member of due to its design and capabilities. This property is determined by the manufacturer before it is sold. Examples are server, router, notebook PC, display, TV, refrigerator, light, etc. I'm a little concerned that this type of information will be more, rather than less, difficult to come by. Is a settop box that includes a spinning hard drive (for DVR), a voice gateway, an 802.11 hub or some sort, stateful packet filtering for security, and a vido camera a video device, a router, a switch, a hub, a wireless router, or... ?? =3D=3D 8. Security Considerations None. It seems like there might be security considerations... They might be out of scope for this document, but I would think energy usage is really a "big deal" for some users, at least (?), and might want to be protected information. Don't know if that should be considered here, thou= gh. =3D=3D HTH :-) Russ --------------enig319946833263C7A41DF5527B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2L1x4ACgkQER27sUhU9OQDWQCgmDkD6y8SCaG3NVo/N1La54yw c/kAoNPLb/+HW3NkUH5ht1UOVno+QYX5 =iS7e -----END PGP SIGNATURE----- --------------enig319946833263C7A41DF5527B-- From bclaise@cisco.com Sat Mar 26 07:35:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D462928C0D8 for ; Sat, 26 Mar 2011 07:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbOPtYew7n-L for ; Sat, 26 Mar 2011 07:35:09 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 3B59B28B797 for ; Sat, 26 Mar 2011 07:35:08 -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 p2QEahFZ001457 for ; Sat, 26 Mar 2011 15:36:43 +0100 (CET) Received: from [10.55.90.78] (dhcp-10-55-90-78.cisco.com [10.55.90.78]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2QEaela012156 for ; Sat, 26 Mar 2011 15:36:40 +0100 (CET) Message-ID: <4D8DF9F8.9070001@cisco.com> Date: Sat, 26 Mar 2011 15:36:40 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: eman mailing list Content-Type: multipart/alternative; boundary="------------090404040401060402010904" Subject: [eman] Review of draft-quittek-eman-battery-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 14:35:12 -0000 This is a multi-part message in MIME format. --------------090404040401060402010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Here is my review of the draft-quittek-eman-battery-mib-00.txt draft. This draft is good start. However, I have some feedback: 1. I believe that the connection with the Energy Management Framework draft-ietf-eman-framework-0 should be clarified, as it's not even mentioned. 2. What is the link with the "Energy-aware Networks and Devices MIB" draft-ietf-eman-energy-aware-mib-01 3. I have a concern with this index. batteryIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies a battery for which status is reported. Index values MUST be locally unique. If there is an instance of the entPhysicalTable (defined in the ENTITY-MIB module, see RFC 4133) with individual entries for each battery, then it is RECOMMENDED that values of batteryIndex match the corresponding values of entPhysicalIndex for the batteries. Otherwise, index values may be chosen arbitrarily." ::= { batteryEntry 1 } In draft-claise-energy-monitoring-mib-07, you asked to change the index, because we can't impose that the "Energy-aware Networks and Devices MIB" is present. Fine. I believe that those indexes should be inline. One side, there is a RECOMMENDED, on the other side a MUST pmPowerIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, for each Power Monitor. If an implementation of the ENERGY AWARE MIB module is available in the local SNMP context, then the same index as the one in the ENERGY AWARE MIB MUST be assigned for the identical Power Monitor. In this case, entities without an assigned value for pmIndex cannot be indexed by the pmPowerStateTable. If there is no implementation of the ENERGY AWARE MIB module but one of the ENTITY MIB module is available in the local SNMP context, then the same index of an entity MUST be chosen as assigned to the entity by object entPhysicalIndex in the ENTITY MIB module. In this case, entities without an assigned value for entPhysicalIndex cannot be indexed by the pmPowerStateTable. If neither the ENERGY AWARE MIB module nor of the ENTITY MIB module are available in the local SNMP context, then this MIB module may choose identity values from a further MIB module providing entity identities. In this case the value for each pmPowerIndex must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. In case that no other MIB modules have been chosen for providing entity identities, Power States can be reported exclusively for the local device on which this table is instantiated. Then this table will have a single entry only and an index value of 0 MUST be used." ::= { pmPowerEntry 1 } 4. The previous points 1, 2, and 3, come from the fact that the requirements draft is not too clear about batteries. What about batteries in a PC? How should we monitor it/them? Independently of the PC? From the requirements and the framework, we will then know if those batteries are Power Monitor Children or not? Final question: what if there is a battery in a Power Monitor Child? 5. I'm not too sure regarding the connection with the UPS-MIB. I see the following paragraph: A traditional type of managed device containing batteries is an uninterruptible power supply (UPS) system; these supply other devices with electrical energy when the main power supply fails. There is already a MIB module for managing UPS systems defined in RFC 1628 [RFC1628]. This module includes managed objects for monitoring the batteries contained in an UPS system. However, the information provided by these objects is limited and tailored the particular needs of UPS systems. Do you mean that UPS will _only _implement the UPS MIB, and the batteries will _only_ implement draft-quittek-eman-battery-mib-00.txt? So basically, there is no connection? 6. batteryType OBJECT-TYPE SYNTAX INTEGER { primary(1), rechargeable(2), capacitor(3), other(4), unknown(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the type of battery. It distinguishes between one-way primary batteries, rechargeable secondary batteries and capacitors which are not really batteries but often used in the same way as a battery. The value other(4) can be used if the battery type is known but none of the ones above. Value unknown(5) is to be used if the type of battery cannot be determined." ::= { batteryEntry 2 } You might want to expand on primary/secondary. A sentence such as " primary batteries (disposable batteries), which are designed to be used once and discarded, and secondary batteries (rechargeable batteries)" would help already. I'm not an expert in batteries, but are we covering all types? In other words, do we need an IANA registry? Same question regarding the batteryTechnology. I googled battery type and found http://en.wikipedia.org/wiki/List_of_battery_types, way more than the 17 defined. Is there such a registry somewhere in the industry? - 7 rechargeable battery batteryTechnology OBJECT-TYPE SYNTAX INTEGER { ... } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the technology used by the battery. Values 1-8 are primary battery technologies, values 10-16 are rechargeable battery technologies and value alkaline(9) is used for primary batteries as well as for rechargeable batteries. The value other(18) can be used if the battery type is known but none of the ones above. Value unknown(19) is to be used if the type of battery cannot be determined." ::= { batteryEntry 3 } We have to deduce if a battery is rechargeable from the value range of batteryTechnology. I believe that an boolean object would be more interesting, specifically if this registry grows. - 8 batteryState OBJECT-TYPE SYNTAX INTEGER { full(1), partiallyCharged(2), empty(3), charging(4), discharging(5), unknown(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the current state of the battery. Value full(1) indicates a full battery with a capacity given by onject batteryRemainingCapacity. So batteryRemainingCapacity is not relevant for 2, 4, 5, 6? - 9. Can you elaborate on the relationship between batteryRemainingCapacity and batteryCurrentCharge - 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage read-only? Same question for batteryReplacementAlarmCapacity and batteryReplacementAlarmCycles: do you expect those to be hardcoded by the vendor? - 11. How do we re-arm the batteryLowNotification? Only when a full charge happen? - 12. batteryCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for implementations of the POWER-STATE-MIB module. A compliant implementation MUST implement the objects defined in the mandatory group psmRequiredGroup." MODULE -- this module MANDATORY-GROUPS { batteryDescriptionGroup, batteryStatusGroup, batteryAlarmThresholdsGroup } GROUP batteryNotificationsGroup DESCRIPTION "A compliant implementation does not have to implement the psmNotificationsGroup." psmNotificationsGroup doesn't exist Regards, Benoit (as a contributor) --------------090404040401060402010904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear authors,

Here is my review of the draft-quittek-eman-battery-mib-00.txt draft.
This draft is good start. However, I have some feedback:

1. I believe that the connection with the Energy Management Framework draft-ietf-eman-framework-0 should be clarified, as it's not even mentioned.

2. What is the link with the "Energy-aware Networks and Devices MIB" draft-ietf-eman-energy-aware-mib-01

3.  I have a concern with this index.
   batteryIndex OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This object identifies a battery for which status is
           reported. Index values MUST be locally unique.

           If there is an instance of the entPhysicalTable (defined in
           the ENTITY-MIB module, see RFC 4133) with individual entries
           for each battery, then it is RECOMMENDED that values of
           batteryIndex match the corresponding values of
           entPhysicalIndex for the batteries. Otherwise, index values
           may be chosen arbitrarily."
       ::= { batteryEntry 1 }
In draft-claise-energy-monitoring-mib-07, you asked to change the index, because we can't impose that the "Energy-aware Networks and Devices MIB" is present. Fine. I believe that those indexes should be inline. One side, there is a RECOMMENDED, on the other side a MUST
       pmPowerIndex OBJECT-TYPE
            SYNTAX          Integer32 (0..2147483647)
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
     
              "A unique value, for each Power Monitor.
              If an implementation of the ENERGY AWARE MIB module is
              available in the local SNMP context, then the same index
              as the one in the ENERGY AWARE MIB MUST be assigned for
              the identical Power Monitor. In this case, entities
              without an assigned value for pmIndex cannot be indexed
              by the pmPowerStateTable.
     
              If there is no implementation of the ENERGY AWARE MIB
              module but one of the ENTITY MIB module is available in
              the local SNMP context, then the same index of an entity
              MUST be chosen as assigned to the entity by object
              entPhysicalIndex in the ENTITY MIB module. In this case,
              entities without an assigned value for entPhysicalIndex
              cannot be indexed by the pmPowerStateTable.
     
              If neither the ENERGY AWARE MIB module nor of the ENTITY
              MIB module are available in the local SNMP context, then
              this MIB module may choose identity values from a further
              MIB module providing entity identities. In this case the
              value for each pmPowerIndex must remain constant at least
              from one re-initialization of the entity's network
              management system to the next re-initialization.
     
              In case that no other MIB modules have been chosen for
              providing entity identities, Power States can be reported
              exclusively for the local device on which this table is
              instantiated.  Then this table will have a single entry
              only and an index value of 0 MUST be used."
     
            ::= { pmPowerEntry 1 }
4.  The previous points 1, 2, and 3, come from the fact that the requirements draft is not too clear about batteries. What about batteries in a PC? How should we monitor it/them? Independently of the PC? From the requirements and the framework, we will then know if those batteries are Power Monitor Children or not? Final question: what if there is a battery in a Power Monitor Child?

5. I'm not too sure regarding the connection with the UPS-MIB. I see the following paragraph:

   A traditional type of managed device containing batteries is an
   uninterruptible power supply (UPS) system; these supply other devices
   with electrical energy when the main power supply fails.  There is
   already a MIB module for managing UPS systems defined in RFC 1628
   [RFC1628].  This module includes managed objects for monitoring the
   batteries contained in an UPS system.  However, the information
   provided by these objects is limited and tailored the particular
   needs of UPS systems.
Do you mean that UPS will only implement the UPS MIB, and the batteries will only implement draft-quittek-eman-battery-mib-00.txt? So basically, there is no connection?

6. 
   batteryType OBJECT-TYPE
       SYNTAX      INTEGER {
                       primary(1),
                       rechargeable(2),
                       capacitor(3),
                       other(4),
                       unknown(5)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the type of battery.  It distinguishes
           between one-way primary batteries, rechargeable secondary
           batteries and capacitors which are not really batteries but
           often used in the same way as a battery.

           The value other(4) can be used if the battery type is known
           but none of the ones above.  Value unknown(5) is to be used
           if the type of battery cannot be determined."
       ::= { batteryEntry 2 }

You might want to expand on primary/secondary. A sentence such as " primary batteries (disposable batteries), which are designed to be used once and discarded, and secondary batteries (rechargeable batteries)" would help already.
I'm not an expert in batteries, but are we covering all types? In other words, do we need an IANA registry?
Same question regarding the batteryTechnology.
I googled battery type and found http://en.wikipedia.org/wiki/List_of_battery_types, way more than the 17 defined.
Is there such a registry somewhere in the industry?

- 7 rechargeable battery

   batteryTechnology OBJECT-TYPE
       SYNTAX      INTEGER {
			...
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the technology used by the battery.
           Values 1-8 are primary battery technologies, values 10-16
           are rechargeable battery technologies and value alkaline(9)
           is used for primary batteries as well as for rechargeable
           batteries.

           The value other(18) can be used if the battery type is known
           but none of the ones above.  Value unknown(19) is to be used
           if the type of battery cannot be determined."
       ::= { batteryEntry 3 }
We have to deduce if a battery is rechargeable from the value range of batteryTechnology. I believe that an boolean object would be more interesting, specifically if this registry grows.

- 8
 batteryState OBJECT-TYPE
       SYNTAX      INTEGER {
                       full(1),
                       partiallyCharged(2),
                       empty(3),
                       charging(4),
                       discharging(5),
                       unknown(6)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the current state of the battery.
           Value full(1) indicates a full battery with a capacity
           given by onject batteryRemainingCapacity.

So batteryRemainingCapacity is not relevant for 2, 4, 5, 6?

- 9.  Can you elaborate on the relationship between batteryRemainingCapacity and batteryCurrentCharge

- 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage read-only?
Same question for batteryReplacementAlarmCapacity and batteryReplacementAlarmCycles: do you expect those to be hardcoded by the vendor?

- 11. How do we re-arm the batteryLowNotification? Only when a full charge happen?

- 12. 
  batteryCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for implementations of the
           POWER-STATE-MIB module.

           A compliant implementation MUST implement the objects
           defined in the mandatory group psmRequiredGroup."
       MODULE  -- this module
       MANDATORY-GROUPS {
           batteryDescriptionGroup,
           batteryStatusGroup,
           batteryAlarmThresholdsGroup
       }
       GROUP   batteryNotificationsGroup
       DESCRIPTION
          "A compliant implementation does not have to implement
           the psmNotificationsGroup."
psmNotificationsGroup doesn't exist
 
Regards, Benoit (as a contributor)
--------------090404040401060402010904-- From bnordman@lbl.gov Sat Mar 26 14:34:40 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2FA3A6973 for ; Sat, 26 Mar 2011 14:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dylWEZLh7u8W for ; Sat, 26 Mar 2011 14:34:37 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by core3.amsl.com (Postfix) with ESMTP id 3868C3A684B for ; Sat, 26 Mar 2011 14:34:37 -0700 (PDT) X-Ironport-SBRS: 4.4 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtADADhbjk3RVdQ0kGdsb2JhbACCYJwSAYZrCBQBAQEBCQkNBxQEIYhroE6aE4MWglMEjHaJCzo X-IronPort-AV: E=Sophos;i="4.63,249,1299484800"; d="scan'208";a="37364598" Received: from mail-vw0-f52.google.com ([209.85.212.52]) by ironport4.lbl.gov with ESMTP; 26 Mar 2011 14:36:12 -0700 Received: by mail-vw0-f52.google.com with SMTP id 16so2418214vws.39 for ; Sat, 26 Mar 2011 14:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.92.131 with SMTP id cm3mr3160424vdb.112.1301175370869; Sat, 26 Mar 2011 14:36:10 -0700 (PDT) Received: by 10.52.158.131 with HTTP; Sat, 26 Mar 2011 14:36:10 -0700 (PDT) In-Reply-To: <4D8DF9F8.9070001@cisco.com> References: <4D8DF9F8.9070001@cisco.com> Date: Sat, 26 Mar 2011 22:36:10 +0100 Message-ID: From: Bruce Nordman To: Benoit Claise Content-Type: multipart/alternative; boundary=20cf307f3ad6c56ac4049f697f7b Cc: eman mailing list Subject: Re: [eman] Review of draft-quittek-eman-battery-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 21:34:41 -0000 --20cf307f3ad6c56ac4049f697f7b Content-Type: text/plain; charset=ISO-8859-1 (Benoit's comments excerpted below). On Sat, Mar 26, 2011 at 3:36 PM, Benoit Claise wrote: > Dear authors, > > Here is my review of the draft-quittek-eman-battery-mib-00.txt draft. > This draft is good start. However, I have some feedback: > I agree. Much appreciated since I don't think anyone else wanted to take this on. > > 1. I believe that the connection with the Energy Management Framework > draft-ietf-eman-framework-0 should be clarified, as it's not even mentioned. > Yes. In particular, I think a key feature of this draft is that the MIB content does not overlap with the information that could be reported by the rest of the EMAN MIBs if the battery was reported on as a separate component. That is, figures such as power in or total energy consumed are not included here. This fact should be mentioned. Add a note that very small batteries in systems (e.g. to enable reliable time-keeping) are not in scope. Say something about readily removable batteries, e.g. as in notebooks, that can easily be replaced. I realize this is a huge can of worms, and am not suggesting adding content to the document. Safest would be to say that the effect of battery replacement on the values reported is not defined. Worth noting that only the alarm levels are writeable (actually, they now say read-only but I think should be changed). For number of charging cycles, I am not sure that "age" is the right term, since someone later might actually want to report age. Activity? For the UPS reference, clarify if a UPS should use the battery MIB also, or only the UPS MIB. > > 2. What is the link with the "Energy-aware Networks and Devices MIB" > draft-ietf-eman-energy-aware-mib-01 > I assume no link, which is fine. A device can implement one MIB, the other, or both. Worth stating this. > ... > 4. The previous points 1, 2, and 3, come from the fact that the > requirements draft is not too clear about batteries. What about batteries in > a PC? How should we monitor it/them? Independently of the PC? From the > requirements and the framework, we will then know if those batteries are > Power Monitor Children or not? Final question: what if there is a battery in > a Power Monitor Child? > This MIB is about battery status, not energy management of batteries. A device could report on the power level and energy consumption of an integral battery, or only do so for the entire device. Whether the battery MIB is implemented is independent of this. This point should be made in the requirements - that there is no linkage. I think this deals with these questions. Primary energy reporting for ANY device is the mains power consumption - the effect of any internal batteries is invisible to this reporting. This does raise the point that if components of a device are reported on, then a battery may have negative power consumption. > > 5. I'm not too sure regarding the connection with the UPS-MIB. I see the > following paragraph: > > A traditional type of managed device containing batteries is an > uninterruptible power supply (UPS) system; these supply other devices > with electrical energy when the main power supply fails. There is > already a MIB module for managing UPS systems defined in RFC 1628 > [RFC1628]. This module includes managed objects for monitoring the > batteries contained in an UPS system. However, the information > provided by these objects is limited and tailored the particular > needs of UPS systems. > > Do you mean that UPS will *only *implement the UPS MIB, and the batteries > will *only* implement draft-quittek-eman-battery-mib-00.txt? So basically, > there is no connection? > I think the answer is the same as the above. A device that is a UPS can report the UPS MIB (or not). It also can report only its total energy/power input (and not battery details), or can report on individual components, including the battery in the UPS. > ... > > - 7 rechargeable battery > > batteryTechnology OBJECT-TYPE > ... > > We have to deduce if a battery is rechargeable from the value range of > batteryTechnology. I believe that an boolean object would be more > interesting, specifically if this registry grows. > The type tells us if rechargeable or not. > > ... > > - 9. Can you elaborate on the relationship between > batteryRemainingCapacity and batteryCurrentCharge > I would replace "Remaining" with "Actual" since I first interpreted "Remaining" as being the Current Charge (and I think Benoit may have as well). In all places where "needs to be measured" appears I would delete the phrase. > > - 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage > read-only? > Same question for batteryReplacementAlarmCapacity and > batteryReplacementAlarmCycles: do you expect those to be hardcoded by the > vendor? > I had the same question. Also, there seem to be four thresholds where something bad could happen but only two notifications. Shouldn't there be four notifications? Also, I am not knowledgeable about batteries, but I would think there are other errors, e.g. not taking a charge (my power drill charger tells me that sometimes) and an overcharged condition. We definitely need outside help here. For Voltage, does this change when charging or discharging? I thought that there was a higher voltage applied to charge a battery. Perhaps we need to be more specific than 'the voltage'? For Replacement, units should be "Cycles". For the questions, I would say that percentage should always be for actual and not nominal. Also, I would punt and say that definitions of "full" and "empty" are up to the implementor. Since the % remaining charge can be computed from the other variables, is it necessary to report it? Is the fact that a threshold is dependent on this mean that it should definitely be reported? For very low power devices with no mains power - only battery - is this an appropriate mechanism to signal a low battery condition? I don't know the answer, but whatever it is should probably be mentioned. --Bruce (as a contributor) > > ... > > Regards, Benoit (as a contributor) > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --20cf307f3ad6c56ac4049f697f7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (Benoit's comments excerpted below).

= On Sat, Mar 26, 2011 at 3:36 PM, Benoit Claise <bclaise@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border= -left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> =20 =20 =20
Dear authors,

Here is my review of the draft-quittek-eman-battery-mib-00.txt draft.
This draft is good start. However, I have some feedback:
I agree.=A0 Much appreciated since I don't think anyone el= se wanted to take
this on.
=A0

1. I believe that the connection with the Energy Management Framework draft-ietf-eman-framework-0 should be clarified, as it's not even mentioned.
Yes.=A0 In particular, I= think a key feature of this draft is that the MIB content
does not over= lap with the information that could be reported by the rest of
the EMAN = MIBs if the battery was reported on as a separate component.
That is, figures such as power in or total energy consumed are not included= here.
This fact should be mentioned.

Add a note that very small= batteries in systems (e.g. to enable reliable time-keeping)
are not in = scope.

Say something about readily removable batteries, e.g. as in notebooks, = that can
easily be replaced.=A0 I realize this is a huge can of worms, a= nd am not suggesting
adding content to the document.=A0 Safest would be = to say that the effect of battery
replacement on the values reported is not defined.

Worth noting that= only the alarm levels are writeable (actually, they now say read-only
b= ut I think should be changed).

For number of charging cycles, I am n= ot sure that "age" is the right term, since
someone later might actually want to report age.=A0 Activity?

For th= e UPS reference, clarify if a UPS should use the battery MIB also, or only<= br>the UPS MIB.

2. What is the link with the "Energy-aware Networks and Devices MI= B" draft-ietf-eman-energy-aware-mib-01
I assume= no link, which is fine.=A0 A device can implement one MIB, the other, or b= oth.
Worth stating this.
=A0
...
4.=A0 The previous point= s 1, 2, and 3, come from the fact that the requirements draft is not too clear about batteries. What about batteries in a PC? How should we monitor it/them? Independently of the PC? From the requirements and the framework, we will then know if those batteries are Power Monitor Children or not? Final question: what if there is a battery in a Power Monitor Child?
This MIB is about battery status, not energy management = of batteries.
A device could report on the power level and energy consum= ption of an integral battery,
or only do so for the entire device.=A0 Whether the battery MIB is implemen= ted is independent
of this.=A0 This point should be made in the requirem= ents - that there is no linkage.
I think this deals with these questions= .=A0 Primary energy reporting for ANY device is the mains
power consumption - the effect of any internal batteries is invisible to th= is reporting.
This does raise the point that if components of a device a= re reported on, then a battery
may have negative power consumption.

5. I'm not too sure regarding the connection with the UPS-MIB. I se= e the following paragraph:

   A traditional type of managed device containing batteries is an
   uninterruptible power supply (UPS) system; these supply other devices
   with electrical energy when the main power supply fails.  There is
   already a MIB module for managing UPS systems defined in RFC 1628
   [RFC1628].  This module includes managed objects for monitoring the
   batteries contained in an UPS system.  However, the information
   provided by these objects is limited and tailored the particular
   needs of UPS systems.
Do you mean that UPS will only implement the UPS MIB, and the batteries will only implement draft-quittek-eman-battery-mib-00.txt? So basically, there is no connection?
I think the answer is the same a= s the above.=A0 A device that is a UPS can report the
UPS MIB (or not).= =A0 It also can report only its total energy/power input (and not battery d= etails),
or can report on individual components, including the battery in the UPS.
...

- 7 rechargeable battery

   batteryTechnology OBJECT-TYPE
       ...
We have to deduce if a battery is rechargeable from the value range of batteryTechnology. I believe that an boolean object would be more interesting, specifically if this registry grows.
The type tells us if rechargeable or not.
=A0

...

- 9.=A0 Can you elaborate on the relationship between batteryRemainingCapacity and batteryCurrentCharge
I would replace "Remaining" with "Actual" since I= first interpreted "Remaining" as
being the Current Charge (an= d I think Benoit may have as well).

In all places where "needs to be measured" appears I would de= lete the phrase.

- 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage read-only?
Same question for batteryReplacementAlarmCapacity and batteryReplacementAlarmCycles: do you expect those to be hardcoded by the vendor?
I had the same question.=A0 A= lso, there seem to be four thresholds where something bad
could happen b= ut only two notifications.=A0 Shouldn't there be four notifications? Also, I am not knowledgeable about batteries, but I would think there are o= ther
errors, e.g. not taking a charge (my power drill charger tells me t= hat sometimes)
and an overcharged condition.=A0 We definitely need outsi= de help here.

For Voltage, does this change when charging or discharging?=A0 I though= t that there
was a higher voltage applied to charge a battery.=A0 Perhap= s we need to be more
specific than 'the voltage'?

For Rep= lacement, units should be "Cycles".

For the questions, I would say that percentage should always be for act= ual and
not nominal.=A0 Also, I would punt and say that definitions of &= quot;full" and "empty" are
up to the implementor.

Since the % remaining charge can be computed from the other variables, is i= t
necessary to report it?=A0 Is the fact that a threshold is dependent o= n this mean
that it should definitely be reported?


For very l= ow power devices with no mains power - only battery - is this an
appropriate mechanism to signal a low battery condition?=A0 I don't kno= w the
answer, but whatever it is should probably be mentioned.

--= Bruce (as a contributor)

...
=A0
Regards, Benoit (as a contributor)

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




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

--20cf307f3ad6c56ac4049f697f7b-- From bnordman@lbl.gov Sat Mar 26 18:24:47 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF27728C0CE for ; Sat, 26 Mar 2011 18:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVGBGRAy9zSl for ; Sat, 26 Mar 2011 18:24:45 -0700 (PDT) Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by core3.amsl.com (Postfix) with ESMTP id 8BE103A680D for ; Sat, 26 Mar 2011 18:24:45 -0700 (PDT) X-Ironport-SBRS: 5.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAMKRjk3RVdK0mGdsb2JhbACCYJYGAYYKhmwIFAEBAQEBCAkNBxQlqW2ZXYJ8ARIHglMEjHeJCzqDVw X-IronPort-AV: E=Sophos;i="4.63,249,1299484800"; d="scan'208";a="37895991" Received: from mail-iy0-f180.google.com ([209.85.210.180]) by ironport3.lbl.gov with ESMTP; 26 Mar 2011 18:26:21 -0700 Received: by iyf40 with SMTP id 40so3340273iyf.39 for ; Sat, 26 Mar 2011 18:26:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.165.207 with SMTP id j15mr2473830iby.40.1301189178793; Sat, 26 Mar 2011 18:26:18 -0700 (PDT) Received: by 10.231.146.6 with HTTP; Sat, 26 Mar 2011 18:26:18 -0700 (PDT) Date: Sun, 27 Mar 2011 03:26:18 +0200 Message-ID: From: Bruce Nordman To: eman mailing list Content-Type: multipart/alternative; boundary=000325572a1ec99f26049f6cb60c Subject: [eman] Review of draft-ietf-eman-framework-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 01:24:48 -0000 --000325572a1ec99f26049f6cb60c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have reviewed draft-ietf-eman-framework-01 and have the following comments. I address some overarching topics initially followed by others in order of appearance in the text. These are necessarily entangled with comments on the requirements document. Many comments reflect ideas present in draft-quittek-eman-reference-model-01. I should summarize some key differences in a separate email. I assume consensus on several points as in draft-norwin-energy-consider-02. These are (paraphrased): -Scope: all devices -Identity: needed (details being worked on) -=93power level=94 always refers to W. -devices. These are the basic unit of what consumes energy. =93host=94 is= not the right word since some of these are non-IP. -tracking intervals is the responsibility of the NMS, not a power monitor. -how we present our work to non-IETF audiences will be critical when we get closer to becoming done. -We need to decompose our entities into functions. The current draft does this to some extent, but not as fully as in the Reference Model =96 draft-quittek-eman-reference-model-01 -Simple and Complex devices. Most devices that use the eman framework in the future are likely to be those that report their own information, and report only basic information. We should identify the basic set of key data and ensure that the documents describe that set and show how it is a modest number of variables =96 not burdensome to implement or use. Each of these has implications for the framework draft text. Power States: I think we have three proposals: That outlined in the Architecture document, that proposed recently by Juergen (a registry of power state sets), and a single set of basic sets (on/sleep/off =96 possibly also ready). We don=92= t have agreement but I think we should refine each of these three to move the discussion forward. Once we come to a conclusion, that can be dropped into this document. Time We have not yet discussed this topic much, but I think need to. We had a good discussion about this in a recent Ecma Smart Data Centre meeting. Presumably time values are based on the power monitor=92s clock. If a NMS has a different view of time, it can decide what to do about that. When values are accumulated by an aggregator/collector, we need to consider what it should do. We should also specify what to do if a device cannot account for some of its power consumption (e.g. reset meter and record last time of reset). Also, we need to consider what mobile devices do to us; when a moves within a building or between buildings, huge complications arise. Seems like our best options may be to specify that we make no claim= s when this happens (that is, we might accumulate energy actually consumed elsewhere), or always reset the energy meter to zero when a device is moved= . However, a device may not KNOW that it moved, making the =93no claims=94 position more practical. Do any other MIBs have time issues? Unitary or disaggregated reporting This is a =91reference model=92 issue but I think worth pulling out separately. The Architecture document reads as if all information about a device being monitored moves as a single unit. The Reference Model breaks this into three parts: power level, energy consumed, and power supply. The document often refers to power level and energy, but not supply. Control of power supply is anticipated (via PDUs or PoE switches), so I assume we must monitor this to begin with. So, supply should get equal billing with power and energy. There is much that hinges on this point, and other differences between this draft and the Reference Model draft. Power state of components and collections I know we have had some conversations about power states for entities other than whole devices =96 either components of devices or collections of devic= es. I am inclined to say that in both cases the value is not defined (the same would hold for power supply). Power levels and energy consumption can be specified for components or collections. Meter Domain I think this would be better called a =93Domain=94 (or =93Electricity Dom= ain=94 or =93Energy Domain=94). We may want to control the supply of a domain even i= n cases in which a meter is not present. Also, not all devices in a domain are necessarily metered Powered Device Many references to a power monitor would be better listed as =93powered device=94. For example, a device is part of a domain =96 the monitor simpl= y reports that fact =96 the monitor itself is not part of the domain as it is not using energy. On to the document sections: -Why is the title =93Energy=85Framework=94 and the page heading =93Power=85Architecture=94? I don=92t care which but seems like should be consistent. 0. -for Power Monitor term, I agree to use of term, but I do not think there is yet consensus on its definition. -has anyone suggested that we include generation? That said, if a device reports on components, then its battery will sometimes generate electricity= . I think we can just note that for batteries, the power consumption can be negative, and the energy consumed can drop over time. I think power sources like a generator or solar panel are out of scope (though fine with me if people choose to use our MIBs for them). -I think implementation scenarios should be in the requirements and applicability statement. This document can address how these scenarios are implemented in the architecture, but not repeat details in other documents. -I completely agree =96 not Joules and Coulombs. We do not need to explain conversions. -I think we want to use mW, mA, and mV. Not sure about A and Wh. 1. -The examples should reflect the scope of all devices. Same for section 2. 3. -I think it helpful to separate definitions from commentary on those definitions. The separation can be as simple as a new paragraph. -Explanation and commentary occurs in both sections 3 and 5. It may make sense to move all commentary to section 5. 3.1 -Clarify whether an Aggregator collects data from multiple power monitors, or adds up such data. These are two distinct functions that could reside in the same entity, or in different ones (or the summing function may not be present). -The function of distributing power is separate from aggregating reported data. -Figure 2. Proxying and Aggregating are separate functions. An entity may implement one, the other, or both. -A new section heading should be inserted towards the bottom of page 11 where the discussion turns to protocols. 5.1 -Every power monitor is said to require an index. If a device reports on itself as a single unit, is there any need for an index? Would this always just be =931=94? 5.2 -Issues of power distribution (topologies) should be separated from those of aggregation of reporting, as they do not need to be structure the same way (even as they will commonly have the same structure). 5.3. -The concept of a domain is separate from proxying or aggregation. 5.5 -A new section on Identity should be inserted before 5.5 (which is now on Context). -The examples in this section should be drawn from all building types, not just commercial buildings. 5.7 -Drop paragraph 1 -paragraph 2. Line losses will make the output from one device different from the input power to another one. -paragraph 3. I don=92t think we need the multiplier =96 reporting in mW s= hould be accurate enough for our purposes and we do not span so many orders of magnitude to make the single unit burdensome. 5.9 -I would drop this section (on demand measurement). 5.10 -I would put all mention of the battery MIB in one place, near the beginnin= g of the document, as it is not interactive with the rest of the framework. 6. -Changes we may make in the architecture might suggest changes to the MIB structure, so I am reluctant to make extensive comments at this time. 7. -I don=92t think we want the parent/child concept, but even so, this sectio= n implies that children are always powered from parents, which I do not see as our framework. Certainly this happens sometimes, so can be presented in that light. 8. -The discussion beginning after the bullet points does not seem to be about configuration so should be a different section. 11. -Per above, this should be moved to the Applicability and Requirements documents. I have some individual text edits, but won=92t burden this email with them. Cheers, --Bruce (as a contributor) --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --000325572a1ec99f26049f6cb60c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I have reviewed draft-ietf-eman-framework-01 and hav= e the

following comments.

=A0

I=A0 address some overarchin= g topics initially followed by others

in order of= appearance in the text.=A0

=A0

These are necessarily entangled with comments on the requirements

document.=A0 Many comments reflect ideas present in

=A0=A0=A0 draft-quittek-eman-reference-model-01.

=

I should summarize some key differences in a separat= e email.

=A0

I assume consensus on several points as in draft-nor= win-energy-consider-02.

These are (paraphrased):

-Scope: all devices

-Identity: needed (details being worked on)

-=93power level=94 always refers to W.

-devices.=A0 These are the basic unit of what consumes energy.=A0 =93h= ost=94 is not

=A0the right word since some of these are non-IP.

-tracking intervals is the responsibility of the NMS= , not a power monitor.

-how we present our work to non-IETF audiences will = be critical when we

=A0get closer to becoming done.

-We need to decompose our entities into functions.=A0 The current draft does

=A0this to some extent, but not as fully as in the Reference Model =96

=A0=A0=A0=A0 draft-quittek-eman-reference-model-01

-Simple and Complex devices.=A0 Most devices that use the eman framework in

=A0 the future are likely to be those that report their own information, and report

=A0 only basic information. =A0We should identify the basic set of key data and

=A0 ensure that the documents describe that set and show how it is a modest

=A0 number of variables =96 not burdensome to implement or use.

Each of these has implications for the framework dra= ft text.

=A0

Power States:

=A0 I think we have three proposals: That outlined in the Architecture document,

that proposed recently by Juergen (a registry of pow= er state sets), and a

single set of basic sets (on/sleep/off =96 possibly = also ready).=A0 We don=92t have

agreement but I think we should refine each of these= three to move the

discussion forward.=A0 Once we come to a conclusion, that can be dropped

into this document.

=A0

Time

=A0 We have not yet discussed this topic much, but I think need to.=A0 We had

a good discussion about this in a recent Ecma Smart = Data Centre meeting.

Presumably time values are based on the power monito= r=92s clock.=A0 If a NMS
has a different view of time, it can decide what to do about that.=A0 When

values are accumulated by an aggregator/collector, w= e need to consider

what it should do.=A0 We should also specify what to do if a device cannot

account for some of its power consumption (e.g. rese= t meter and record

last time of reset).=A0 Also, we need to consider what mobile devices do to us;

when a moves within a building or between buildings,= huge complications

arise.=A0 Seems like our best options may be to specify that we make no claims

when this happens (that is, we might accumulate ener= gy actually consumed elsewhere), or always reset the energy meter to zero when= a device is moved.

However, a device may not KNOW that it moved, making= the =93no claims=94
position more practical.

=A0 Do any other MIBs have time issues?

=A0

Unitary or disaggregated reporting

=A0 This is a =91reference model=92 issue but I think worth pulling out separately.

The Architecture document reads as if all informatio= n about a device being

monitored moves as a single unit.= =A0 The Reference Model breaks this into

three parts: power level, energy consumed, and power supply.=A0 The document

often refers to power level and energy, but not supp= ly.=A0 Control of power supply

is anticipated (via PDUs or PoE switches), so I assu= me we must monitor this

to begin with.=A0 So, supply should get equal billing with power and energy.

=A0 There is much that hinges on this point, and other differences between this

draft and the Reference Model draft.

=A0

Power state of components and collections

=A0 I know we have had some conversations about power states for entities other

than whole devices =96 either components of devices = or collections of devices.

I am inclined to say that in both cases the value is= not defined (the same would

hold for power supply).=A0 P= ower levels and energy consumption can be

specified for components or collections.

=A0

Meter Domain

=A0 I think this would be better called a =93Domain=94 (or =93Electricity Domain=94 or

=93Energy Domain=94).=A0 We may want to control the supply of a domain even in

cases in which a meter is not present.=A0 Also, not all devices in a domain are

necessarily metered

=A0

Powered Device

=A0 Many references to a power monitor would be better listed as =93powered

device=94.=A0 For example, a device is part of a domain =96 the monitor simply

reports that fact =96 the monitor itself is not part= of the domain as it is not

using energy.

=A0

=A0

On to the document sections:

-Why is the title =93Energy=85Framework=94 and the p= age heading =93Power=85Architecture=94?=A0 I don=92t care which but seems like should be consistent.

=A0

0. <initial notes>

-for Power Monitor term, I agree to use of term, but= I do not think there

=A0is yet consensus on its definition.

-has anyone suggested that we include generation?=A0 That said, if a device

reports on components, then its battery will sometim= es generate electricity.

=A0I think we can just note that for batteries, the power consumption can be

=A0negative, and the energy consumed can drop over time.=A0 I think power

=A0sources like a generator or solar panel are out of scope (though fine with

=A0me if people choose to use our MIBs for them).

-I think implementation scenarios should be in the requirements and

=A0applicability statement.=A0 This document can address how these scenarios

=A0are implemented in the architecture, but not repeat details in other documents.

-I completely agree =96 not Joules and Coulombs.=A0 We do not need to explain

=A0 conversions.

-I think we want to use mW, mA, and mV.=A0 Not sure about A and Wh.

=A0

1.

-The examples should reflect the scope of all device= s.=A0 Same for section 2.

=A0

3.

-I think it helpful to separate definitions from com= mentary on those definitions.

=A0 The separation can be as simple as a new paragraph.

-Explanation and commentary occurs in both sections = 3 and 5.=A0 It may make

=A0 sense to move all commentary to section 5.

=A0

3.1

-Clarify whether an Aggregator collects data from mu= ltiple power monitors,

=A0 or adds up such data.=A0 These are two distinct functions that could reside in

=A0 the same entity, or in different ones (or the summing function may not be

=A0 present).

-The function of distributing power is separate from aggregating reported data.

-Figure 2. Proxying and Aggregating are separate functions.=A0 An entity may

=A0 implement one, the other, or both.

-A new section heading should be inserted towards th= e bottom of page 11

=A0 where the discussion turns to protocols.

=A0

5.1

-Every power monitor is said to require an index.=A0 If a device reports on itself

as a single unit, is there any need for an index?=A0=A0 Would this always just be =931=94?

=A0

5.2

-Issues of power distribution (topologies) should be separated from those

=A0 of aggregation of reporting, as they do not need to be structure the same

=A0 way (even as they will commonly have the same structure).

=A0

5.3.

-The concept of a domain is separate from proxying o= r aggregation.

=A0

5.5

-A new section on Identity should be inserted before= 5.5 (which is now on Context).

-The examples in this section should be drawn from a= ll building types, not just

=A0 commercial buildings.

=A0

5.7

-Drop paragraph 1

-paragraph 2.=A0 Line losses will make the output from one device different from

=A0 the input power to another one.

-paragraph 3.=A0 I don=92t think we need the multiplier =96 reporting in mW should be

=A0accurate enough for our purposes and we do not span so many orders of

=A0 magnitude to make the single unit burdensome.

=A0

5.9

-I would drop this section (on demand measurement).<= /p>

=A0

5.10

-I would put all mention of the battery MIB in one p= lace, near the beginning of the

=A0 document, as it is not interactive with the rest of the framework.

=A0

6.

-Changes we may make in the architecture might sugge= st changes to the MIB

=A0 structure, so I am reluctant to make extensive comments at this time.

=A0

7.

-I don=92t think we want the parent/child concept, b= ut even so, this section

=A0 implies that children are always powered from parents, which I do not

=A0 see as our framework.=A0 Certainly this happens sometimes, so can be presented

=A0 in that light.

=A0

8.

-The discussion beginning after the bullet points do= es not seem to be

=A0 about configuration so should be a different section.

=A0

11.

-Per above, this should be moved to the Applicabilit= y and Requirements documents.

=A0

I have some individual text edits, but won=92t burde= n this email with them.

=A0

Cheers,

=A0

--Bruce (as a contributor)



--
Bruce NordmanLawrence Berkeley National Laborat= ory
= eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--000325572a1ec99f26049f6cb60c-- From bclaise@cisco.com Sun Mar 27 01:31:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C7E3A69B3 for ; Sun, 27 Mar 2011 01:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgPILG+8wkKn for ; Sun, 27 Mar 2011 01:31:10 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 343813A688F for ; Sun, 27 Mar 2011 01:31:10 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2R8JQWU002510 for ; Sun, 27 Mar 2011 10:19:26 +0200 (CEST) Received: from [10.61.71.159] (ams3-vpn-dhcp1951.cisco.com [10.61.71.159]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2R8JQ7u008713 for ; Sun, 27 Mar 2011 10:19:26 +0200 (CEST) Message-ID: <4D8EF30E.7070805@cisco.com> Date: Sun, 27 Mar 2011 10:19:26 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: eman mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [eman] Slides for Prague X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 08:31:11 -0000 Dear presenter, Please send your slides in advance so that we can post them. For example, before Tuesday noon. Regards, Benoit. From bnordman@lbl.gov Sun Mar 27 15:35:13 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75ACE28C16A for ; Sun, 27 Mar 2011 15:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.923 X-Spam-Level: X-Spam-Status: No, score=-5.923 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm792m28C5Rf for ; Sun, 27 Mar 2011 15:35:10 -0700 (PDT) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by core3.amsl.com (Postfix) with ESMTP id BC55528C0E2 for ; Sun, 27 Mar 2011 15:35:10 -0700 (PDT) X-Ironport-SBRS: 5.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMBAIe6j03RVdy0mGdsb2JhbACCX5t8AYZtCBQBAQEBAQgJDQcUJYhrnUCZT4MWglMEjHeJCzo X-IronPort-AV: E=Sophos;i="4.63,252,1299484800"; d="scan'208";a="37390289" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 27 Mar 2011 15:36:46 -0700 Received: by vxk12 with SMTP id 12so2972373vxk.39 for ; Sun, 27 Mar 2011 15:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.165.227 with SMTP id zb3mr4276730vdb.32.1301265405431; Sun, 27 Mar 2011 15:36:45 -0700 (PDT) Received: by 10.52.158.131 with HTTP; Sun, 27 Mar 2011 15:36:45 -0700 (PDT) In-Reply-To: References: <4D88D2D1.2070306@cisco.com> <4D88DB0B.1000405@cisco.com> Date: Mon, 28 Mar 2011 00:36:45 +0200 Message-ID: From: Bruce Nordman To: "Mouli Chandramouli (moulchan)" Content-Type: multipart/alternative; boundary=bcaec53f92f53fd0de049f7e76f5 Cc: eman mailing list Subject: Re: [eman] Review of draft-quittek-eman-reference-model-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 22:35:13 -0000 --bcaec53f92f53fd0de049f7e76f5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A few comments. On Wed, Mar 23, 2011 at 1:47 PM, Mouli Chandramouli (moulchan) < moulchan@cisco.com> wrote: > Hello all, > > > > Here is a review of draft-quittek-eman-reference-model-01. > > > > Thanks > > Mouli > > > > Firstly, the draft is very well organized and written. The title seems > appropriate =96a reference diagram for the monitoring scenarios. The sec= ond > section covers Terminology of energy terms. The third section proposes a= - > Reference model - the notions of a power source, meter, and device are > clearly explained. Internal measurement and the external measurement are > illustrated for clarity. Several different monitoring scenarios have bee= n > considered. For those scenarios, control is added and illustrated. > > > > Firstly, the reference model described as in Figure 1, is an useful as= a > logical construction. However, in the case of external measurement, it i= s > also possible to get additional information such as power states from > end-devices. It is possible that the =93Power- Monitor=94 layer can comm= unicate > with the end-device, and report the usage information and the power state > information. I think this aspect can be considered in the reference model= , > for externally powered/ metered devices. > That does seem to be an additional possible scenario. > > > While the logical separation of Source, Meter and Device is useful, the > measurement at all these points should be the same ? Unless the measureme= nt > points are geographically separated in physical distance; in that scenari= o > transmission loss comes in to play. > The key point here is that these three functions can be accomplished by the same device, by two devices, or by three (though three is likely to be rare). Having the functionality based on the functions and not the devices makes the framework more flexible and simpler to explain all scenarios. > > > In Section 4- Energy Management Reference Model =96 If there are 3 shades= of > Cntrl =96 Power Source Cntrl, Power Meter Cntrl, and Power State Control, > there should be some co-ordination between these actions and cannot be > independent. A small nit - the figure after figure 9 is not indexed > If one of these is set by control, then the others may well change based on how the device operates, but I don't think that affects the eman model - that is just how the device operates. > > > In Section 4, in Figure 14. 15, how can Power-State be configured ? > Similarly, for devices beyond a gateway, as in Figure 16, how can > Power-States be configured on the device ? > Per section 1.1, the lines without a caret are a protocol not specified by EMAN, so the mechanism is whatever the other protocol provides for. > > > Power Source Terminology =96 it is not the source of power or generation = of > power =96 It is only the power supply feed to the device. > The Power Source concept identifies the control over power source that some PDUs have (and therefore monitoring of the state of that control). I am concerned that many readers will interpret "power supply" as the AC->DC converter inside a device; "power source" avoids that likely confusion. > > > Not sure about if we should label Energy Monitoring protocol using SNMP a= s > EMON ? > I do think we will want some name - other suggestions encouraged. > > > I think there should be some information should be added for Security > consideration in view of configuration, > > > > The notion of energy management - power-states is it only restricted to O= N > and OFF ? in which case, the control can reside at the source or switch > which can be turn ON or OFF. > This is for the state of the power source, not of the powered device. Thanks much, --Bruce > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > > --=20 *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec53f92f53fd0de049f7e76f5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A few comments.

On Wed, Mar 23, 2011 at 1= :47 PM, Mouli Chandramouli (moulchan) <moulchan@cisco.com> wrote:

Hello all,

=A0

Here is a review of dr= aft-quittek-eman-reference-model-01.

=A0

Thanks

Mouli

=A0

Firstly, the draft is = very well organized and written.=A0 The title seems appropriate =96a reference diagram for the monitoring scenarios.=A0 The second section covers Terminology of energy terms. The third section=A0 proposes a - Reference model=A0 - the notions of a power source, meter, and=A0 device are clearly explained.=A0 Internal measurement and the external measurement are illustrated for clarity.=A0 Several different monitoring scenarios have bee= n considered.=A0 For those scenarios, control is added and illustrated.

=A0

Firstly, the reference= model described=A0=A0=A0 as in Figure 1, is an useful as a logical construction.=A0 However, in the case of external measurement, it is also possible to get additional information such as power states from end-devices.=A0 It is possible that the =93Power- Monitor=94 layer can communicate with the end-device, and report the usage information and t= he power state information. I think this aspect can be considered in the refer= ence model, for externally powered/ metered devices.

That does seem to be an additional possible scenario.

=A0

While the logical sepa= ration of Source, Meter and Device=A0 is useful, the measurement at all these points should be the same ? Unless the measurement points are geographically separ= ated in physical distance; in that scenario transmission loss comes in to play. =

The key point here is that these t= hree functions can be accomplished by the same device, by two devices, or b= y three (though three is likely to be rare). Having the functionality based= on the functions and not the devices makes the framework more flexible and= simpler to explain all scenarios.

=A0

In Section 4- Energy M= anagement Reference Model =96 If there are 3 shades of Cntrl =96 Power Source Cntrl, Power Meter Cntrl, and Power State Control, there should be some co-ordination between these actions and cannot be independent. A small nit -=A0 the figure after figure 9 is not indexed

If one of these is set by control, then the others may well chan= ge based on how the device operates, but I don't think that affects the= eman model - that is just how the device operates.

=A0

In Section 4, in Figur= e 14. 15, how can Power-State be configured ?=A0 Similarly, for devices beyond a gateway, as in Figure 16, how can Power-States be configured on the device = ?

Per section 1.1, the lines witho= ut a caret are a protocol not specified by EMAN, so the mechanism is whatev= er the other protocol provides for.

=A0

Power Source Terminolo= gy =96 it is not the source of power or generation of power =96 It is only the power supply feed to the device.

T= he Power Source concept identifies the control over power source that some = PDUs have (and therefore monitoring of the state of that control).=A0 I am = concerned that many readers will interpret "power supply" as the = AC->DC converter inside a device; "power source" avoids that l= ikely confusion.

=A0

Not sure about if we s= hould label Energy Monitoring protocol using SNMP as=A0 EMON ?

<= /blockquote>
I do think we will want some name - other suggestions enco= uraged.

=A0

I think there should b= e some information should be added for Security consideration in view of configuration,=A0

=A0

The notion of energy m= anagement - power-states is it only restricted to ON and OFF ?=A0 in which case, the control can reside at the source or switch which can be turn ON or OFF.=A0=A0=A0=A0

This is for the s= tate of the power source, not of the powered device.

Thanks much,
--Bruce

=A0


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




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

--bcaec53f92f53fd0de049f7e76f5-- From ietf@quittek.at Mon Mar 28 03:28:13 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649613A68D5 for ; Mon, 28 Mar 2011 03:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+g5rdpnsv2m for ; Mon, 28 Mar 2011 03:28:11 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 4D9123A69C0 for ; Mon, 28 Mar 2011 03:28:11 -0700 (PDT) Received: from dhcp-536c.meeting.ietf.org (dhcp-536c.meeting.ietf.org [130.129.83.108]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Lo1CS-1PSvCd0nJw-00g0SW; Mon, 28 Mar 2011 12:29:47 +0200 References: <4D88D2D1.2070306@cisco.com> <4D88DB0B.1000405@cisco.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-10-878438801 Message-Id: From: Juergen Quittek Date: Mon, 28 Mar 2011 12:29:45 +0200 To: Mouli Chandramouli (moulchan) X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:PheJ9887VcgDzLjxKU6drWihFZr7aVZoA4+pJmDWrX3 VIPSjLpo1DDkRvKz5Od3VAQzHFRBeZNvtxrY6ztAS3Dt5KM7MB vusJ7hMrPuafQLl3/uOmDokqMFCz1Thg3jTM61FLccK8J61Lln 5l/abegjH5qHIbq2o8lCrX3H3eMq8xY2Iemqc8dsf+RLEzgrcm Ja5Z1OTDdBozNs7lr0Gdg== Cc: eman mailing list Subject: Re: [eman] Review of draft-quittek-eman-reference-model-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:28:13 -0000 --Apple-Mail-10-878438801 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Mouli, Thank you for the review. Please find replies to your comments inline. Juergen Am 23.03.2011 um 13:47 schrieb Mouli Chandramouli (moulchan): > Hello all, > =20 > Here is a review of draft-quittek-eman-reference-model-01. > =20 > Thanks > Mouli > =20 > Firstly, the draft is very well organized and written. The title = seems appropriate =96a reference diagram for the monitoring scenarios. = The second section covers Terminology of energy terms. The third section = proposes a - Reference model - the notions of a power source, meter, = and device are clearly explained. Internal measurement and the = external measurement are illustrated for clarity. Several different = monitoring scenarios have been considered. For those scenarios, control = is added and illustrated. > =20 > Firstly, the reference model described as in Figure 1, is an useful = as a logical construction. However, in the case of external = measurement, it is also possible to get additional information such as = power states from end-devices. It is possible that the =93Power- = Monitor=94 layer can communicate with the end-device, and report the = usage information and the power state information. I think this aspect = can be considered in the reference model, for externally powered/ = metered devices. Yes, and the text in the draft says so. I should make sure that this becomes more clear. > While the logical separation of Source, Meter and Device is useful, = the measurement at all these points should be the same ? Unless the = measurement points are geographically separated in physical distance; in = that scenario transmission loss comes in to play. Transmission loss is indeed a problem. I do not have a good idea how = relevant it is and how to deal with it. I will mention it in the next revision. > In Section 4- Energy Management Reference Model =96 If there are 3 = shades of Cntrl =96 Power Source Cntrl, Power Meter Cntrl, and Power = State Control, there should be some co-ordination between these actions = and cannot be independent. Yes, there should be coordination. But this is a task of the energy = management system. No need to add this to the references model. > A small nit - the figure after figure 9 is not indexed Only scenarios are indexed, but not other figures, such as the ones in = section 3 > In Section 4, in Figure 14. 15, how can Power-State be configured ? = Similarly, for devices beyond a gateway, as in Figure 16, how can = Power-States be configured on the device ? Well, I just assumed that there will be many powered devices that do not = allow configuring the power state remotely, such as, for example, = several desktop IP phones. Scenarios 14 and 15 just assumes such = devices. But of course there will be also many devices supporting remote = state configuration. For these, you can easily add more scenarios that = extend Scenarios 14 and 15 towards devices that support configuring = their power states. > Power Source Terminology =96 it is not the source of power or = generation of power =96 It is only the power supply feed to the device. We discussed using "power supply" instead of "power source" but found = power source more appropriate. But I am open to use better terms here. What would be your proposal? =20 > Not sure about if we should label Energy Monitoring protocol using = SNMP as EMON ? We can more precisely define 'EMAN' as 'SNMP using EMAN MIB modules'. > I think there should be some information should be added for Security = consideration in view of configuration,=20 Yes, right. But also for monitoring. I add it to the to do list. > The notion of energy management - power-states is it only restricted = to ON and OFF ? in which case, the control can reside at the source or = switch which can be turn ON or OFF. =20 Why would you restrict power states of devices to on and off? The situation is more restricted at the power source, for example at a = PDU.=20 There you often do not have more control beyond switching the supply for = a powered device on and off. > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-10-878438801 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear Mouli,

Thank you for the = review.
Please find replies to your comments = inline.

   =  Juergen

Am 23.03.2011 um 13:47 = schrieb Mouli Chandramouli (moulchan):

Hello all,
Here is a review of = draft-quittek-eman-reference-model-01.
Thanks
 
Firstly, the draft is very well organized and = written.  The title seems appropriate =96a reference diagram for = the monitoring scenarios.  The second section covers Terminology of = energy terms. The third section  proposes a - Reference model  = - the notions of a power source, meter, and  device are clearly = explained.  Internal measurement and the external measurement are = illustrated for clarity.  Several different monitoring scenarios = have been considered.  For those scenarios, control is added and = illustrated.
 
Firstly, the = reference model described    as in Figure 1, is an useful = as a logical construction.  However, in the case of external = measurement, it is also possible to get additional information such as = power states from end-devices.  It is possible that the =93Power- = Monitor=94 layer can communicate with the end-device, and report the = usage information and the power state information. I think this aspect = can be considered in the reference model, for externally powered/ = metered = devices.

Yes, = and the text in the draft says so.
I should make sure that = this becomes more clear.

While the logical separation of Source, = Meter and Device  is useful, the measurement at all these points = should be the same ? Unless the measurement points are geographically = separated in physical distance; in that scenario transmission loss comes = in to = play.

Transmiss= ion loss is indeed a problem. I do not have a good idea how relevant it = is and how to deal with it.
I will mention it in the next = revision.

In Section 4- Energy Management = Reference Model =96 If there are 3 shades of Cntrl =96 Power Source = Cntrl, Power Meter Cntrl, and Power State Control, there should be some = co-ordination between these actions and cannot be independent. =

Yes, = there should be coordination. But this is a task of the energy = management system. No need to add this to the references = model.

A small nit -  the figure after = figure 9 is not = indexed

On= ly scenarios are indexed, but not other figures, such as the ones in = section 3

In Section 4, in Figure 14. 15, how can = Power-State be configured ?  Similarly, for devices beyond a = gateway, as in Figure 16, how can Power-States be configured on the = device = ?

Well, I = just assumed that there will be many powered devices that do not allow = configuring the power state remotely, such as, for example, several = desktop IP phones. Scenarios 14 and 15 just assumes such devices. But of = course there will be also many devices supporting remote state = configuration. For these, you can easily add more scenarios that extend = Scenarios 14 and 15 towards devices that support configuring their power = states.

Power Source Terminology =96 it is not = the source of power or generation of power =96 It is only the power = supply feed to the = device.

We = discussed using "power supply" instead of "power source" but found power = source more appropriate. But I am open to use better terms = here.
What would be your proposal?
 
Not sure about if we should label = Energy Monitoring protocol using SNMP as  EMON = ?

We can = more precisely define 'EMAN' as 'SNMP using EMAN MIB = modules'.

I think there should be some = information should be added for Security consideration in view of = configuration, 

=
Yes, right. But also for monitoring. I add it to the to do = list.

The notion of energy management - = power-states is it only restricted to ON and OFF ?  in which case, = the control can reside at the source or switch which can be turn ON or = OFF.   =  

Why = would you restrict power states of devices to on and off?
The = situation is more restricted at the power source, for example at a = PDU. 
There you often do not have more control beyond = switching the supply for a powered device on and = off.

_______________________________________________
eman = mailing list
eman@ietf.org
Hi Mouli,

Thanks again for = another review!

Please find replies = inline.

   =  Juergen

Am 23.03.2011 um 17:59 schrieb = Mouli Chandramouli (moulchan):

Hello = all,
 
Here is my = review of =  draft-quittek-eman-battery-mib-00.txt
Thanks
 
This draft is = also well-written. This draft and has a good description of the MIB = objects for battery monitoring.
I have a couple of comments and = questions.
 
First, the = batteryIndex  - how can this be associated with an Entity such as = PC for which the battery is providing backup power ?   What if = there are two batteries for a device = ?

The = battery MIB module can be implemented by devices containing batteries. = May be these batteries are used for back-up power, may be for something = else. We do not discuss this. For these batteries, the MIB module offers = means for reporting their states. If you have multiple batteries in your = device, then you will have multiple index values.

So, for a Data center use case, they = should use the UPS MIB to monitor the UPS capacity to ensure UPS is not = drained out = ?

What = is the data center use case?

If you operate a = UPS you have the UPS MIB. If you would like to use the battery MIB in = addition is something we will have to = investigate. 

I have a basic question on = barteryState. You have defined five states -  full(1),  = partiallyCharged(2),  empty(3),  charging(4),   = discharging(5),  = unknown(6).  
Isn=92t this similar in spirit to = PowerStates discussion for entities = ? 

Yes, = it is similar. These are functional states with power = implications.
We can think about using EMAN power states here. = But these need to be states customized for = batteries.

One possibility = is to define FULL and Empty as states for a battery similar to ON and = OFF for an = entity.

What = do you mean with 'similar'?
OFF and EMPTY are different = concepts with different implications.
_______________________________________________
eman = mailing list
eman@ietf.org
3. I have a concern with this index. > batteryIndex OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object identifies a battery for which status is > reported. Index values MUST be locally unique. >=20 > If there is an instance of the entPhysicalTable (defined in > the ENTITY-MIB module, see RFC 4133) with individual = entries > for each battery, then it is RECOMMENDED that values of > batteryIndex match the corresponding values of > entPhysicalIndex for the batteries. Otherwise, index values > may be chosen arbitrarily." > ::=3D { batteryEntry 1 } > In draft-claise-energy-monitoring-mib-07, you asked to change the = index, because we can't impose that the "Energy-aware Networks and = Devices MIB" is present. Fine. I believe that those indexes should be = inline. One side, there is a RECOMMENDED, on the other side a MUST This is an open issue. Let's wait for the outcome of the Entity MIb = discussion. For the Power monitoring MIB I think it should be a MUST to use the = POWER-AWARE or ENTITY MIB indexing when available. For the BATTERY MIB the story is a bit different. But I will have no = problem with changing RECOMMENDED to MUST, if the WG has consensus on = this.=20 > pmPowerIndex OBJECT-TYPE > SYNTAX Integer32 (0..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > =20 > "A unique value, for each Power Monitor. > If an implementation of the ENERGY AWARE MIB module is > available in the local SNMP context, then the same index > as the one in the ENERGY AWARE MIB MUST be assigned for > the identical Power Monitor. In this case, entities > without an assigned value for pmIndex cannot be indexed > by the pmPowerStateTable. > =20 > If there is no implementation of the ENERGY AWARE MIB > module but one of the ENTITY MIB module is available in > the local SNMP context, then the same index of an entity > MUST be chosen as assigned to the entity by object > entPhysicalIndex in the ENTITY MIB module. In this case, > entities without an assigned value for entPhysicalIndex > cannot be indexed by the pmPowerStateTable. > =20 > If neither the ENERGY AWARE MIB module nor of the ENTITY > MIB module are available in the local SNMP context, then > this MIB module may choose identity values from a = further > MIB module providing entity identities. In this case the > value for each pmPowerIndex must remain constant at = least > from one re-initialization of the entity's network > management system to the next re-initialization. > =20 > In case that no other MIB modules have been chosen for > providing entity identities, Power States can be = reported > exclusively for the local device on which this table is > instantiated. Then this table will have a single entry > only and an index value of 0 MUST be used." > =20 > ::=3D { pmPowerEntry 1 } > 4. The previous points 1, 2, and 3, come from the fact that the = requirements draft is not too clear about batteries. What about = batteries in a PC? How should we monitor it/them? Independently of the = PC? =46rom the requirements and the framework, we will then know if = those batteries are Power Monitor Children or not? Final question: what = if there is a battery in a Power Monitor Child? The battery MIB is not a power consumption monitor or a power state = monitor. It is just a MIB module reporting states of batteries in a = device. I don't see this much different to reporting on the processor = status (load) in a PC. And I would like to not treat it much = differently. A MIB module on processor load would also not relate to the = energy management framework or discuss parent child relationships. However, if we model a battery as a component of a PC which we see as = separate entity on which we report power independently, then we can do = so with the power MIB and with the power state MIB. I volunteer to write = a section on dealing with batteries for the framework document. > 5. I'm not too sure regarding the connection with the UPS-MIB. I see = the following paragraph: >=20 > A traditional type of managed device containing batteries is an > uninterruptible power supply (UPS) system; these supply other = devices > with electrical energy when the main power supply fails. There is > already a MIB module for managing UPS systems defined in RFC 1628 > [RFC1628]. This module includes managed objects for monitoring the > batteries contained in an UPS system. However, the information > provided by these objects is limited and tailored the particular > needs of UPS systems. > Do you mean that UPS will only implement the UPS MIB, and the = batteries will only implement draft-quittek-eman-battery-mib-00.txt? So = basically, there is no connection? There is a limited overlap between the two. The UPS MIB just deals with the UPS functionality. I could imagine an UPS implementing the UPS MIB for this purpose=20 and in addition reporting on battery status (e.g. age of the battery)=20 with the Battery MIB. But this story is subject to further discussion. > 6.=20 > batteryType OBJECT-TYPE > SYNTAX INTEGER { > primary(1), > rechargeable(2), > capacitor(3), > other(4), > unknown(5) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the type of battery. It = distinguishes > between one-way primary batteries, rechargeable secondary > batteries and capacitors which are not really batteries but > often used in the same way as a battery. >=20 > The value other(4) can be used if the battery type is known > but none of the ones above. Value unknown(5) is to be used > if the type of battery cannot be determined." > ::=3D { batteryEntry 2 } >=20 > You might want to expand on primary/secondary. A sentence such as " = primary batteries (disposable batteries), which are designed to be used = once and discarded, and secondary batteries (rechargeable batteries)" = would help already. Right. Will do. > I'm not an expert in batteries, but are we covering all types? In = other words, do we need an IANA registry?=20 > Same question regarding the batteryTechnology. Good questions. I do not have an answer at this point in time. I don't think we need it for the types. But probably for the = technologies. >=20 > I googled battery type and found = http://en.wikipedia.org/wiki/List_of_battery_types, way more than the 17 = defined. It's not what we here call type, but it's technologies.=20 Yes, I have seen a similar list when writing the draft. There is a plenty of battery types, But most of them are of academic = nature. iYou can build them, but there are economic or practical reasons = why you would not commercially use them. I removed all baterries from = the long list for which I could find that they are not in commercial = use. > Is there such a registry somewhere in the industry? I have not seen anything like this. Does anyone else know? > - 7 rechargeable battery >=20 > batteryTechnology OBJECT-TYPE > SYNTAX INTEGER { > ... > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the technology used by the battery. > Values 1-8 are primary battery technologies, values 10-16 > are rechargeable battery technologies and value alkaline(9) > is used for primary batteries as well as for rechargeable > batteries. >=20 > The value other(18) can be used if the battery type is = known > but none of the ones above. Value unknown(19) is to be = used > if the type of battery cannot be determined." > ::=3D { batteryEntry 3 } > We have to deduce if a battery is rechargeable from the value range of = batteryTechnology. I believe that an boolean object would be more = interesting, specifically if this registry grows. This was just for explanation. Shall I remove the text on which = technologies belong to which type. Maybe I should just add a sentence as you say: "Whether it is = rechargeable can be retrieved from object batteryType". > - 8 > batteryState OBJECT-TYPE > SYNTAX INTEGER { > full(1), > partiallyCharged(2), > empty(3), > charging(4), > discharging(5), > unknown(6) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the current state of the battery. > Value full(1) indicates a full battery with a capacity > given by onject batteryRemainingCapacity.=20 >=20 > So batteryRemainingCapacity is not relevant for 2, 4, 5, 6? It is valid in all states. I just wanted to clearly define what "full" = means. "Ful" may mean: 100% original capacity or 100% remaining capacity. I am still not sure which alternative is the best one. > - 9. Can you elaborate on the relationship between = batteryRemainingCapacity and batteryCurrentCharge While in use, the capacity of a battery (the maximum energy that you can = store in it) decreases. An old battery typically has a lower capacity than a new one.=20 The current charge relates to the energy currently stored in the = battery. The currentCharge is always less than or equal to the currentCapacity. > - 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage = read-only? > Same question for batteryReplacementAlarmCapacity and = batteryReplacementAlarmCycles: do you expect those to be hardcoded by = the vendor? Good point. I expect that manufacturers will install a reasonable default value for = these objects=20 and that they will allow you to change them via CLI or a GUI, So far, it is a read-only MIb module for monitoring.=20 If we want to open it for configuration, we can discuss doing so. > - 11. How do we re-arm the batteryLowNotification? Only when a full = charge happen? Good question, I have no good answer to this right now. But we need to = give one in the draft. > - 12.=20 > batteryCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for implementations of the > POWER-STATE-MIB module. >=20 > A compliant implementation MUST implement the objects > defined in the mandatory group psmRequiredGroup." > MODULE -- this module > MANDATORY-GROUPS { > batteryDescriptionGroup, > batteryStatusGroup, > batteryAlarmThresholdsGroup > } > GROUP batteryNotificationsGroup > DESCRIPTION > "A compliant implementation does not have to implement > the psmNotificationsGroup." > psmNotificationsGroup doesn't exist Thanks for catching this. It's a copy/paste mistake.=20 Will fix it in the next revision. > Regards, Benoit (as a contributor) > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-15-889910795 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Benoit,

Thank you for the review.
Please find comment inline,

    Juergen

Am 26.03.2011 um 15:36 schrieb Benoit Claise:

Dear authors,

Here is my review of the draft-quittek-eman-battery-mib-00.txt draft.
This draft is good start. However, I have some feedback:

1. I believe that the connection with the Energy Management Framework draft-ietf-eman-framework-0 should be clarified, as it's not even mentioned.

'We will do so in the next update.
However, the main message will be that it is not connected.

2. What is the link with the "Energy-aware Networks and Devices MIB" draft-ietf-eman-energy-aware-mib-01

We need to find out if we need one.

3.  I have a concern with this index.
   batteryIndex OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This object identifies a battery for which status is
           reported. Index values MUST be locally unique.

           If there is an instance of the entPhysicalTable (defined in
           the ENTITY-MIB module, see RFC 4133) with individual entries
           for each battery, then it is RECOMMENDED that values of
           batteryIndex match the corresponding values of
           entPhysicalIndex for the batteries. Otherwise, index values
           may be chosen arbitrarily."
       ::= { batteryEntry 1 }
In draft-claise-energy-monitoring-mib-07, you asked to change the index, because we can't impose that the "Energy-aware Networks and Devices MIB" is present. Fine. I believe that those indexes should be inline. One side, there is a RECOMMENDED, on the other side a MUST

This is an open issue. Let's wait for the outcome of the Entity MIb discussion.
For the Power monitoring MIB I think it should be a MUST to use the POWER-AWARE or ENTITY MIB indexing when available.
For the BATTERY MIB the story is a bit different. But I will have no problem with changing RECOMMENDED to MUST, if the WG has consensus on this. 
       pmPowerIndex OBJECT-TYPE
            SYNTAX          Integer32 (0..2147483647)
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
     
              "A unique value, for each Power Monitor.
              If an implementation of the ENERGY AWARE MIB module is
              available in the local SNMP context, then the same index
              as the one in the ENERGY AWARE MIB MUST be assigned for
              the identical Power Monitor. In this case, entities
              without an assigned value for pmIndex cannot be indexed
              by the pmPowerStateTable.
     
              If there is no implementation of the ENERGY AWARE MIB
              module but one of the ENTITY MIB module is available in
              the local SNMP context, then the same index of an entity
              MUST be chosen as assigned to the entity by object
              entPhysicalIndex in the ENTITY MIB module. In this case,
              entities without an assigned value for entPhysicalIndex
              cannot be indexed by the pmPowerStateTable.
     
              If neither the ENERGY AWARE MIB module nor of the ENTITY
              MIB module are available in the local SNMP context, then
              this MIB module may choose identity values from a further
              MIB module providing entity identities. In this case the
              value for each pmPowerIndex must remain constant at least
              from one re-initialization of the entity's network
              management system to the next re-initialization.
     
              In case that no other MIB modules have been chosen for
              providing entity identities, Power States can be reported
              exclusively for the local device on which this table is
              instantiated.  Then this table will have a single entry
              only and an index value of 0 MUST be used."
     
            ::= { pmPowerEntry 1 }
4.  The previous points 1, 2, and 3, come from the fact that the requirements draft is not too clear about batteries. What about batteries in a PC? How should we monitor it/them? Independently of the PC? From the requirements and the framework, we will then know if those batteries are Power Monitor Children or not? Final question: what if there is a battery in a Power Monitor Child?

The battery MIB is not a power consumption monitor or a power state monitor. It is just a MIB module reporting states of batteries in a device. I don't see this much different to reporting on the processor status (load) in a PC. And I would like to not treat it much differently. A MIB module on processor load would also not relate to the energy management framework or discuss parent child relationships.

However, if we model a battery as a component of a PC which we see as separate entity on which we report power independently, then we can do so with the power MIB and with the power state MIB. I volunteer to write a section on dealing with batteries for the framework document.

5. I'm not too sure regarding the connection with the UPS-MIB. I see the following paragraph:

   A traditional type of managed device containing batteries is an
   uninterruptible power supply (UPS) system; these supply other devices
   with electrical energy when the main power supply fails.  There is
   already a MIB module for managing UPS systems defined in RFC 1628
   [RFC1628].  This module includes managed objects for monitoring the
   batteries contained in an UPS system.  However, the information
   provided by these objects is limited and tailored the particular
   needs of UPS systems.
Do you mean that UPS will only implement the UPS MIB, and the batteries will only implement draft-quittek-eman-battery-mib-00.txt? So basically, there is no connection?

There is a limited overlap between the two.
The UPS MIB just deals with the UPS functionality.
I could imagine an UPS implementing the UPS MIB for this purpose 
and in addition reporting on battery status (e.g. age of the battery) 
with the Battery MIB. But this story is subject to further discussion.

6. 
   batteryType OBJECT-TYPE
       SYNTAX      INTEGER {
                       primary(1),
                       rechargeable(2),
                       capacitor(3),
                       other(4),
                       unknown(5)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the type of battery.  It distinguishes
           between one-way primary batteries, rechargeable secondary
           batteries and capacitors which are not really batteries but
           often used in the same way as a battery.

           The value other(4) can be used if the battery type is known
           but none of the ones above.  Value unknown(5) is to be used
           if the type of battery cannot be determined."
       ::= { batteryEntry 2 }

You might want to expand on primary/secondary. A sentence such as " primary batteries (disposable batteries), which are designed to be used once and discarded, and secondary batteries (rechargeable batteries)" would help already.

Right. Will do.

I'm not an expert in batteries, but are we covering all types? In other words, do we need an IANA registry?
Yes, I have seen a similar list when writing the draft.
There is a plenty of battery types, But most of them are of academic nature. iYou can build them, but there are economic or practical reasons why you would not commercially use them. I removed all baterries from the long list for which I could find that they are not in commercial use.

Is there such a registry somewhere in the industry?

I have not seen anything like this.
Does anyone else know?

- 7 rechargeable battery

   batteryTechnology OBJECT-TYPE
       SYNTAX      INTEGER {
			...
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the technology used by the battery.
           Values 1-8 are primary battery technologies, values 10-16
           are rechargeable battery technologies and value alkaline(9)
           is used for primary batteries as well as for rechargeable
           batteries.

           The value other(18) can be used if the battery type is known
           but none of the ones above.  Value unknown(19) is to be used
           if the type of battery cannot be determined."
       ::= { batteryEntry 3 }
We have to deduce if a battery is rechargeable from the value range of batteryTechnology. I believe that an boolean object would be more interesting, specifically if this registry grows.

This was just for explanation. Shall I remove the text on which technologies belong to which type.
Maybe I should just add a sentence as you say: "Whether it is rechargeable can be retrieved from object batteryType".

- 8
 batteryState OBJECT-TYPE
       SYNTAX      INTEGER {
                       full(1),
                       partiallyCharged(2),
                       empty(3),
                       charging(4),
                       discharging(5),
                       unknown(6)
                   }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object indicates the current state of the battery.
           Value full(1) indicates a full battery with a capacity
           given by onject batteryRemainingCapacity.

So batteryRemainingCapacity is not relevant for 2, 4, 5, 6?

It is valid in all states. I just wanted to clearly define what "full" means.
"Ful" may mean: 100% original capacity or 100% remaining capacity.
I am still not sure which alternative is the best one.

- 9.  Can you elaborate on the relationship between batteryRemainingCapacity and batteryCurrentCharge

While in use, the capacity of a battery (the maximum energy that you can store in it) decreases.
An old battery typically has a lower capacity than a new one. 
The current charge relates to the energy currently stored in the battery.
The currentCharge is always less than or equal to the currentCapacity.

- 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage read-only?
Same question for batteryReplacementAlarmCapacity and batteryReplacementAlarmCycles: do you expect those to be hardcoded by the vendor?

Good point.
I expect that manufacturers will install a reasonable default value for these objects 
and that they will allow you to change them via CLI or a GUI,
So far, it is a read-only MIb module for monitoring. 
If we want to open it for configuration, we can discuss doing so.

- 11. How do we re-arm the batteryLowNotification? Only when a full charge happen?

Good question, I have no good answer to this right now. But we need to give one in the draft.

- 12. 
  batteryCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for implementations of the
           POWER-STATE-MIB module.

           A compliant implementation MUST implement the objects
           defined in the mandatory group psmRequiredGroup."
       MODULE  -- this module
       MANDATORY-GROUPS {
           batteryDescriptionGroup,
           batteryStatusGroup,
           batteryAlarmThresholdsGroup
       }
       GROUP   batteryNotificationsGroup
       DESCRIPTION
          "A compliant implementation does not have to implement
           the psmNotificationsGroup."
psmNotificationsGroup doesn't exist

Thanks for catching this.
It's a copy/paste mistake. 
Will fix it in the next revision.

Regards, Benoit (as a contributor)
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman

--Apple-Mail-15-889910795-- From ietf@quittek.at Mon Mar 28 07:00:34 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494F23A691F for ; Mon, 28 Mar 2011 07:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsyt3dZCE0yZ for ; Mon, 28 Mar 2011 07:00:31 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 72F8B3A6849 for ; Mon, 28 Mar 2011 07:00:30 -0700 (PDT) Received: from [192.168.2.15] ([88.208.109.142]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lxbn5-1PtzhG0SEd-017C1X; Mon, 28 Mar 2011 16:02:05 +0200 References: <4D8DF9F8.9070001@cisco.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-16-891177665 Message-Id: From: Juergen Quittek Date: Mon, 28 Mar 2011 16:02:04 +0200 To: Bruce Nordman X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:LBh5H83XfLiW2k6tU2zLy2OPEamVcyeW8UyZZlzG5Sh O6vxIy2U0aRyW47Az3vHmdR+uSW2BIB/VbfsLWOXGHrv4ZJKzU b2sCiEMNbOTE8o/zHUAA6RV5I6NjP9ljpH+Fxu96AP343tiXzD guAKT5XfZbkUzXfFe3pEGZnlbs303/qbAQlj93fAjuJtdYJ4U+ ecNa+c6PZ2Ef7PaRHxRkA== Cc: eman mailing list Subject: Re: [eman] Review of draft-quittek-eman-battery-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:00:34 -0000 --Apple-Mail-16-891177665 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bruce, Thanks for the second review on this draft. Now we have a lot of input for the next revision=20 and for starting discussions. Juergen Am 26.03.2011 um 22:36 schrieb Bruce Nordman: > (Benoit's comments excerpted below). >=20 > On Sat, Mar 26, 2011 at 3:36 PM, Benoit Claise = wrote: > Dear authors, >=20 > Here is my review of the draft-quittek-eman-battery-mib-00.txt draft. > This draft is good start. However, I have some feedback: > I agree. Much appreciated since I don't think anyone else wanted to = take > this on. > =20 >=20 > 1. I believe that the connection with the Energy Management Framework = draft-ietf-eman-framework-0 should be clarified, as it's not even = mentioned. > Yes. In particular, I think a key feature of this draft is that the = MIB content > does not overlap with the information that could be reported by the = rest of > the EMAN MIBs if the battery was reported on as a separate component. > That is, figures such as power in or total energy consumed are not = included here. > This fact should be mentioned.=20 >=20 > Add a note that very small batteries in systems (e.g. to enable = reliable time-keeping) > are not in scope. Yes. I thought often about it but did not write anything. Will add a clarification in the next revision. > Say something about readily removable batteries, e.g. as in notebooks, = that can > easily be replaced. I realize this is a huge can of worms, and am not = suggesting > adding content to the document. Safest would be to say that the = effect of battery > replacement on the values reported is not defined. OK. I will try to carefully phrase some text. I would not like to add an object indicating the "replaceability". > Worth noting that only the alarm levels are writeable (actually, they = now say read-only > but I think should be changed). Looks like we are getting closer to consensus on this :-) > For number of charging cycles, I am not sure that "age" is the right = term, since > someone later might actually want to report age. Activity? Then rather boringly: numberOfChargingCycles. > For the UPS reference, clarify if a UPS should use the battery MIB = also, or only > the UPS MIB. Will do so, But it will rather be a MAY than a SHOULD. >=20 > 2. What is the link with the "Energy-aware Networks and Devices MIB" = draft-ietf-eman-energy-aware-mib-01 > I assume no link, which is fine. A device can implement one MIB, the = other, or both. > Worth stating this. Wil do it anyway. > ... > 4. The previous points 1, 2, and 3, come from the fact that the = requirements draft is not too clear about batteries. What about = batteries in a PC? How should we monitor it/them? Independently of the = PC? =46rom the requirements and the framework, we will then know if = those batteries are Power Monitor Children or not? Final question: what = if there is a battery in a Power Monitor Child? > This MIB is about battery status, not energy management of batteries. > A device could report on the power level and energy consumption of an = integral battery, > or only do so for the entire device. Whether the battery MIB is = implemented is independent > of this. This point should be made in the requirements - that there = is no linkage. > I think this deals with these questions. Primary energy reporting for = ANY device is the mains > power consumption - the effect of any internal batteries is invisible = to this reporting. > This does raise the point that if components of a device are reported = on, then a battery > may have negative power consumption. >=20 > 5. I'm not too sure regarding the connection with the UPS-MIB. I see = the following paragraph: >=20 > A traditional type of managed device containing batteries is an > uninterruptible power supply (UPS) system; these supply other = devices > with electrical energy when the main power supply fails. There is > already a MIB module for managing UPS systems defined in RFC 1628 > [RFC1628]. This module includes managed objects for monitoring the > batteries contained in an UPS system. However, the information > provided by these objects is limited and tailored the particular > needs of UPS systems. > Do you mean that UPS will only implement the UPS MIB, and the = batteries will only implement draft-quittek-eman-battery-mib-00.txt? So = basically, there is no connection? > I think the answer is the same as the above. A device that is a UPS = can report the > UPS MIB (or not). It also can report only its total energy/power = input (and not battery details), > or can report on individual components, including the battery in the = UPS. > ... >=20 > - 7 rechargeable battery >=20 > batteryTechnology OBJECT-TYPE > ... > We have to deduce if a battery is rechargeable from the value range of = batteryTechnology. I believe that an boolean object would be more = interesting, specifically if this registry grows. > The type tells us if rechargeable or not. > =20 >=20 > ... >=20 > - 9. Can you elaborate on the relationship between = batteryRemainingCapacity and batteryCurrentCharge > I would replace "Remaining" with "Actual" since I first interpreted = "Remaining" as > being the Current Charge (and I think Benoit may have as well). Fine. > In all places where "needs to be measured" appears I would delete the = phrase. I will check all these places. >=20 >=20 > - 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage = read-only? > Same question for batteryReplacementAlarmCapacity and = batteryReplacementAlarmCycles: do you expect those to be hardcoded by = the vendor? > I had the same question. Also, there seem to be four thresholds where = something bad > could happen but only two notifications. Shouldn't there be four = notifications? > Also, I am not knowledgeable about batteries, but I would think there = are other > errors, e.g. not taking a charge (my power drill charger tells me that = sometimes) > and an overcharged condition. We definitely need outside help here. >=20 > For Voltage, does this change when charging or discharging? I thought = that there > was a higher voltage applied to charge a battery. Perhaps we need to = be more > specific than 'the voltage'? Well, I can add a sentence that voltage of batteries changes. Voltage = drops over time when discharging, it increase over time when charging, = and yes, it is different in charging and discharging modes, > For Replacement, units should be "Cycles". Will add. > For the questions, I would say that percentage should always be for = actual and > not nominal. Also, I would punt and say that definitions of "full" = and "empty" are > up to the implementor. But the choice if full related to original capacity or actual capacity = should not be up to the implementor, Otherwise we get ambiguous monitoring results. > Since the % remaining charge can be computed from the other variables, = is it > necessary to report it? Is the fact that a threshold is dependent on = this mean > that it should definitely be reported? Yes, we can omit it. This would also avoid the ambiguities. The only problem we create then is that it is convenient to calculate=20 with percentage values or to create policies with percentage value. > For very low power devices with no mains power - only battery - is = this an > appropriate mechanism to signal a low battery condition? I don't know = the > answer, but whatever it is should probably be mentioned. I need to understand the issue here. Can you elaborate? > --Bruce (as a contributor) >=20 > ... > =20 > Regards, Benoit (as a contributor) >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman >=20 >=20 >=20 >=20 > --=20 > Bruce Nordman > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 >=20 > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-16-891177665 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Bruce,

Thanks for the second review on this = draft.
Now we have a lot of input for the next = revision 
and for starting = discussions.

   =  Juergen

Am 26.03.2011 um 22:36 schrieb = Bruce Nordman:

(Benoit's comments excerpted below).

On Sat, Mar 26, 2011 at 3:36 PM, Benoit Claise = <bclaise@cisco.com> = wrote:
Dear authors,

Here is my review of the draft-quittek-eman-battery-mib-00.txt draft.
This draft is good start. However, I have some = feedback:
I agree.  Much appreciated = since I don't think anyone else wanted to take
this = on.
 

1. I believe that the connection with the Energy Management Framework draft-ietf-eman-framework-0 should be clarified, as it's not even mentioned.
Yes.  In = particular, I think a key feature of this draft is that the MIB = content
does not overlap with the information that could be reported = by the rest of
the EMAN MIBs if the battery was reported on as a = separate component.
That is, figures such as power in or total energy consumed are not = included here.
This fact should be mentioned.

Add a note that = very small batteries in systems (e.g. to enable reliable = time-keeping)
are not in = scope.

Yes. I thought often = about it but did not write anything.
Will add a clarification = in the next revision.

Say something about readily removable = batteries, e.g. as in notebooks, that can
easily be replaced.  I = realize this is a huge can of worms, and am not suggesting
adding = content to the document.  Safest would be to say that the effect of = battery
replacement on the values reported is not = defined.

OK. I will try to = carefully phrase some text.
I would not like to add an object = indicating the "replaceability".

Worth noting that only the = alarm levels are writeable (actually, they now say read-only
but I = think should be = changed).

Looks like we are = getting closer to consensus on this :-)

For number of charging = cycles, I am not sure that "age" is the right term, since
someone later might actually want to report age.  = Activity?

Then rather = boringly: numberOfChargingCycles.

For the UPS reference, = clarify if a UPS should use the battery MIB also, or only
the UPS = MIB.

Will do so, But it will = rather be a MAY than a SHOULD.

2. What is the link with the "Energy-aware Networks and Devices MIB" draft-ietf-eman-energy-aware-mib-01
I = assume no link, which is fine.  A device can implement one MIB, the = other, or both.
Worth stating this.

Wil do it anyway.

...
4.  The previous points 1, 2, and 3, come from the = fact that the requirements draft is not too clear about batteries. What about batteries in a PC? How should we monitor it/them? Independently of the PC? =46rom the requirements and the framework, we will then know if those batteries are Power Monitor Children or not? Final question: what if there is a battery in a Power Monitor = Child?
This MIB is about battery status, not = energy management of batteries.
A device could report on the power = level and energy consumption of an integral battery,
or only do so for the entire device.  Whether the battery MIB is = implemented is independent
of this.  This point should be made = in the requirements - that there is no linkage.
I think this deals = with these questions.  Primary energy reporting for ANY device is = the mains
power consumption - the effect of any internal batteries is invisible to = this reporting.
This does raise the point that if components of a = device are reported on, then a battery
may have negative power = consumption.

5. I'm not too sure regarding the connection with the UPS-MIB. I see the following paragraph:

   A traditional type of managed device containing batteries is =
an
   uninterruptible power supply (UPS) system; these supply other devices
   with electrical energy when the main power supply fails.  There is
   already a MIB module for managing UPS systems defined in RFC 1628
   [RFC1628].  This module includes managed objects for monitoring the
   batteries contained in an UPS system.  However, the information
   provided by these objects is limited and tailored the particular
   needs of UPS systems.
Do you mean that UPS will only implement the UPS MIB, and the batteries will only implement draft-quittek-eman-battery-mib-00.txt? So basically, there is no connection?
I think the answer is the = same as the above.  A device that is a UPS can report the
UPS = MIB (or not).  It also can report only its total energy/power input = (and not battery details),
or can report on individual components, including the battery in the = UPS.
...

- 7 rechargeable battery

   batteryTechnology OBJECT-TYPE
       ...
We have to deduce if a battery is rechargeable from the value range of batteryTechnology. I believe that an boolean object would be more interesting, specifically if this registry = grows.
The type tells us if rechargeable or = not.
 

...

- 9.  Can you elaborate on the relationship between batteryRemainingCapacity and = batteryCurrentCharge
I would replace = "Remaining" with "Actual" since I first interpreted "Remaining" = as
being the Current Charge (and I think Benoit may have as = well).

Fine.

In all places where = "needs to be measured" appears I would delete the = phrase.

I will check all these = places.



- 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage read-only?
Same question for batteryReplacementAlarmCapacity and batteryReplacementAlarmCycles: do you expect those to be hardcoded by the vendor?
I had the same = question.  Also, there seem to be four thresholds where something = bad
could happen but only two notifications.  Shouldn't there be = four notifications?
Also, I am not knowledgeable about batteries, but I would think there = are other
errors, e.g. not taking a charge (my power drill charger = tells me that sometimes)
and an overcharged condition.  We = definitely need outside help here.

For Voltage, does this change when charging or discharging?  I = thought that there
was a higher voltage applied to charge a = battery.  Perhaps we need to be more
specific than 'the = voltage'?

Well, I can add a = sentence that voltage of batteries changes. Voltage drops over time when = discharging, it increase over time when charging, and yes, it is = different in charging and discharging modes,

For Replacement, units = should be "Cycles".

Will = add.

For the questions, I would say that = percentage should always be for actual and
not nominal.  Also, I = would punt and say that definitions of "full" and "empty" are
up to = the implementor.

But the = choice if full related to original capacity or actual capacity should = not be up to the implementor,
Otherwise we get ambiguous = monitoring results.

Since the % remaining charge can be computed from the other variables, = is it
necessary to report it?  Is the fact that a threshold is = dependent on this mean
that it should definitely be = reported?

Yes, we can omit = it. This would also avoid the ambiguities.
The only problem we = create then is that it is convenient to calculate 
with = percentage values or to create policies with percentage = value.

For very low power devices with no mains = power - only battery - is this an
appropriate mechanism to signal a low battery condition?  I don't = know the
answer, but whatever it is should probably be = mentioned.

I need to = understand the issue here. Can you elaborate?

--Bruce (as a = contributor)

...
 
Regards, Benoit (as a contributor)

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




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

_______________________________________________
eman mailing = list
eman@ietf.org
https://www.ietf.org/ma= ilman/listinfo/eman

= --Apple-Mail-16-891177665-- From bclaise@cisco.com Mon Mar 28 07:39:00 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4983F3A690D for ; Mon, 28 Mar 2011 07:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.603 X-Spam-Level: X-Spam-Status: No, score=-3.603 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H26ayPSdDFqx for ; Mon, 28 Mar 2011 07:38:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id ABBB83A6920 for ; Mon, 28 Mar 2011 07:38:58 -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 p2SEao6S019288 for ; Mon, 28 Mar 2011 16:36:50 +0200 (CEST) Received: from [10.61.107.95] (dhcp-10-61-107-95.cisco.com [10.61.107.95]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2SEaokx026056 for ; Mon, 28 Mar 2011 16:36:50 +0200 (CEST) Message-ID: <4D909D02.5020408@cisco.com> Date: Mon, 28 Mar 2011 16:36:50 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: eman mailing list Content-Type: multipart/alternative; boundary="------------070204050705090508080707" Subject: [eman] Webex Meeting invitation: eman X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:39:00 -0000 This is a multi-part message in MIME format. --------------070204050705090508080707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > *From: *IETF Secretariat > > *Date: *March 28, 2011 5:49:46 AM PDT > *To: *amorris@amsl.com > *Subject: **(Forward to attendees) Meeting invitation: eman* > *Reply-To: *amorris@amsl.com > > > **** You can forward this email invitation to attendees **** > > Hello , > > IETF Secretariat invites you to attend this online meeting. > > Topic: eman > Date: Wednesday, March 30, 2011 > Time: 3:00 pm, Europe Summer Time (Rome, GMT+02:00) > Meeting Number: 965 442 365 > Meeting Password: (This meeting does not require a password.) > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://workgreen.webex.com/workgreen/j.php?ED=151928152&UID=0&RT=MiMxNDI%3D > > > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: (This > meeting does not require a password.) > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://workgreen.webex.com/workgreen/j.php?ED=151928152&UID=0&ORT=MiMxNDI%3D > > > > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > amorris@amsl.com > 1-510-492-4081 > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://workgreen.webex.com/workgreen/j.php?ED=151928152&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=bb/U7hp65GxV3c9/IJXLtQIz-973dDpLjJBj/mPoKDE=&RT=MiMxNDI%3D > > > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in > the meeting, please check whether you have the players installed on > your computer by going to > https://workgreen.webex.com/workgreen/systemdiagnosis.php > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. --------------070204050705090508080707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

From: IETF Secretariat <messenger@webex.com>
Date: March 28, 2011 5:49:46 AM PDT
Subject: (Forward to attendees) Meeting invitation: eman


**** You can forward this email invitation to attendees ****

Hello ,

IETF Secretariat invites you to attend this online meeting.

Topic: eman
Date: Wednesday, March 30, 2011
Time: 3:00 pm, Europe Summer Time (Rome, GMT+02:00)
Meeting Number: 965 442 365
Meeting Password: (This meeting does not require a password.)


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://workgreen.webex.com/workgreen/j.php?ED=151928152&UID=0&RT=MiMxNDI%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: (This meeting does not require a password.)
4. Click "Join".

To view in other time zones or languages, please click the link:
https://workgreen.webex.com/workgreen/j.php?ED=151928152&UID=0&ORT=MiMxNDI%3D


-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://workgreen.webex.com/workgreen/mc
2. On the left navigation bar, click "Support".

You can contact me at:
amorris@amsl.com
1-510-492-4081

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://workgreen.webex.com/workgreen/j.php?ED=151928152&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=bb/U7hp65GxV3c9/IJXLtQIz-973dDpLjJBj/mPoKDE=&RT=MiMxNDI%3D

The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com



IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.

--------------070204050705090508080707-- From bclaise@cisco.com Mon Mar 28 07:50:31 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3688B3A67BD for ; Mon, 28 Mar 2011 07:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OeZR2athQwQ for ; Mon, 28 Mar 2011 07:50:30 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 258F83A6863 for ; Mon, 28 Mar 2011 07:50:29 -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 p2SEq7fC020609 for ; Mon, 28 Mar 2011 16:52:07 +0200 (CEST) Received: from [10.61.107.95] (dhcp-10-61-107-95.cisco.com [10.61.107.95]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2SEq6jH013804 for ; Mon, 28 Mar 2011 16:52:06 +0200 (CEST) Message-ID: <4D90A096.6020204@cisco.com> Date: Mon, 28 Mar 2011 16:52:06 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: eman mailing list References: <4D8EF30E.7070805@cisco.com> In-Reply-To: <4D8EF30E.7070805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [eman] Slides for Prague X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:50:31 -0000 Dear presenters, A couple of guidelines for the presentation. - Please don't cover editorial changes unless they're important (we're supposed to have read the drafts ;-) - The WG time should be used to resolve open issues, so keep your presentation time under control - Focus on the explanatory text that give background for open issues Regards, Bruce and Benoit. > > Please send your slides in advance so that we can post them. > For example, before Tuesday noon. > > Regards, Benoit. > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman From bill.mielke@alcatel-lucent.com Mon Mar 28 10:33:30 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE653A689E for ; Mon, 28 Mar 2011 10:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.304 X-Spam-Level: X-Spam-Status: No, score=-6.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGyntlPVV7Vu for ; Mon, 28 Mar 2011 10:33:29 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 05D593A6842 for ; Mon, 28 Mar 2011 10:33:28 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2SHZ4fg021709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Mar 2011 12:35:04 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2SHZ27k010060 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Mar 2011 12:35:04 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 28 Mar 2011 12:35:03 -0500 From: "Mielke, William F (Bill)" To: Benoit Claise Date: Mon, 28 Mar 2011 12:34:56 -0500 Thread-Topic: [eman] MIB-friendly proposal for flexible power states Thread-Index: AcvoeZknJxrZUCc3SCeds5GTvuYyywE9KPWw Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362368@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> <20110318150557.GB19324@cslinux-build01.cyberswitching.local> <20110318154108.GB11947@elstar.local> <20110318160417.GA26516@cslinux-build01.cyberswitching.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A2FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D887510.50507@cisco.com> In-Reply-To: <4D887510.50507@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362368USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:33:30 -0000 --_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362368USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am only now in the process of catching up with the latest EMAN emails. I= agree with Benoit on the following points. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein ________________________________ From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, March 22, 2011 6:08 AM To: Mielke, William F (Bill) Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states Hi William, I like your analysis, and I arrive to the same conclusion in http://www.iet= f.org/mail-archive/web/eman/current/msg00221.html Based on the recent conclusions, I would complement my analysis What I believe the solution is in terms of EMAN: - we must be ready to support multiple power states series - we must be ready to support a new power states series. - the device must report which power states series it supports With - lock the IANA process so that we don't have an explosion of new= power states (series) Regards, Benoit. --_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362368USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am only now in the process of catching up with the = latest=20 EMAN emails.  I agree with Benoit on the following=20 points.

William F.=20 Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200= East=20 Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email:=20 Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628Fax: 614=20 367 5965

"Live like you're going to die tomorrow.
 Learn lik= e=20 you're going to live forever."

    - Albert=20 Einstein

 

From: Benoit Claise [mailto:bclaise@c= isco.com]=20
Sent: Tuesday, March 22, 2011 6:08 AM
To: Mielke, Wi= lliam=20 F (Bill)
Cc: eman mailing list
Subject: Re: [eman]=20 MIB-friendly proposal for flexible power states

Hi William,

I like your analysis, and I arrive to the s= ame=20 conclusion in = http://www.ietf.org/mail-archive/web/eman/current/msg00221.html

= Based on the recent conclusions, I would complement my=20 analysis
What I believe the solution is in terms= of=20 EMAN:
- we must be ready to support mul= tiple=20 power states series
- we must be ready = to=20 support a new power states series.
- t= he=20 device must report which power states series it=20 supports
With
     &nb= sp;   =20 - lock the IANA process so that we don't have an explosion of new power s= tates=20 (series)

Regards, Benoit. --_000_0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362368USNAVSXCHMBSA_-- From ietf@quittek.at Mon Mar 28 15:52:03 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91BE328C138 for ; Mon, 28 Mar 2011 15:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMARB2rasNqH for ; Mon, 28 Mar 2011 15:52:02 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 1811B3A6A90 for ; Mon, 28 Mar 2011 15:52:01 -0700 (PDT) Received: from [192.168.2.34] ([88.208.109.142]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LfFYi-1PbuNE2cwa-00oqDT; Tue, 29 Mar 2011 00:53:37 +0200 References: <16B44850-AFB7-483E-AAD7-C8288B547AF9@quittek.at> <20110316052854.GA2249@elstar.local> <45565870-4E34-4999-8E4E-297C52460A08@quittek.at> <20110317233539.GA2891@cslinux-build01.cyberswitching.local> <20110318091951.GE7027@elstar.local> <20110318150557.GB19324@cslinux-build01.cyberswitching.local> <20110318154108.GB11947@elstar.local> <20110318160417.GA26516@cslinux-build01.cyberswitching.local> <0DEE3BCEE44BFD4EBC3B7DC009C8E792250729A2FE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D887510.50507@cisco.com> <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362368@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362368@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-18-923069209 Message-Id: <290B2ABE-20A0-454C-91AD-51E13BD677B5@quittek.at> From: Juergen Quittek Date: Tue, 29 Mar 2011 00:53:36 +0200 To: "Mielke, William F (Bill)" X-Mailer: Apple Mail (2.1082) X-Provags-ID: V02:K0:cvkDQGHvSweFjSUtrQq0Yp8PN6HfIykEw6fymRDTWMD zysJaUmdqSuMjnRlSim+OVq5fkvL7vMKutaHRSp/vrXFGQ8YcV FRaRqoYDRvJx7M08KtSaKbJndWrN2vAnK7dZJGypCGvNhzAz8x +x+7MqOeUQiXi+z06Gr8bFv4Mt7vCkcocJxiu9U5FFCqv5PIiI heFNbsZiqwaCbESgk38NA== Cc: eman mailing list Subject: Re: [eman] MIB-friendly proposal for flexible power states X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:52:03 -0000 --Apple-Mail-18-923069209 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bill and Benoit, I also agree. This leads to another question:=20 Do we want a device to be able to support more than one series at a = time? Thanks, Juergen Am 28.03.2011 um 19:34 schrieb Mielke, William F (Bill): > I am only now in the process of catching up with the latest EMAN = emails. I agree with Benoit on the following points. > William F. Mielke > Alcatel-Lucent > Distinguished Member of Technical Staff > 6200 East Broad Street > Room: 4B01-1V > Columbus, OH 43213-1530 > Email: Bill.Mielke@alcatel-lucent.com > Phone: 614 367 5628 > Fax: 614 367 5965 >=20 > "Live like you're going to die tomorrow. > Learn like you're going to live forever." >=20 > - Albert Einstein >=20 > =20 >=20 > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > Sent: Tuesday, March 22, 2011 6:08 AM > To: Mielke, William F (Bill) > Cc: eman mailing list > Subject: Re: [eman] MIB-friendly proposal for flexible power states >=20 > Hi William, >=20 > I like your analysis, and I arrive to the same conclusion in = http://www.ietf.org/mail-archive/web/eman/current/msg00221.html >=20 > Based on the recent conclusions, I would complement my analysis > What I believe the solution is in terms of EMAN: > - we must be ready to support multiple power states series > - we must be ready to support a new power states series.=20 > - the device must report which power states series it supports > With > - lock the IANA process so that we don't have an explosion = of new power states (series) >=20 > Regards, Benoit. > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-18-923069209 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Bill and Benoit,

I also agree.

This leads to another question: 
Do we want a device to be able to support more than one series at a time?

Thanks,

    Juergen

Am 28.03.2011 um 19:34 schrieb Mielke, William F (Bill):

I am only now in the process of catching up with the latest EMAN emails.  I agree with Benoit on the following points.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: Bill.Mielke@alcatel-lucent.com
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, March 22, 2011 6:08 AM
To: Mielke, William F (Bill)
Cc: eman mailing list
Subject: Re: [eman] MIB-friendly proposal for flexible power states

Hi William,

I like your analysis, and I arrive to the same conclusion in http://www.ietf.org/mail-archive/web/eman/current/msg00221.html

Based on the recent conclusions, I would complement my analysis
What I believe the solution is in terms of EMAN:
- we must be ready to support multiple power states series
- we must be ready to support a new power states series.
- the device must report which power states series it supports
With
          - lock the IANA process so that we don't have an explosion of new power states (series)

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

--Apple-Mail-18-923069209-- From moulchan@cisco.com Tue Mar 29 00:54:46 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8335F3A6919 for ; Tue, 29 Mar 2011 00:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPGhVci-DIRh for ; Tue, 29 Mar 2011 00:54:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E472E3A6982 for ; Tue, 29 Mar 2011 00:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=10466; q=dns/txt; s=iport; t=1301385381; x=1302594981; h=mime-version:subject:date:message-id:from:to; bh=DKNvNx5y+LzoM7lr64xXSZglQESPRXQz+eKMlEfIxYY=; b=gI/NfrzsE+j+yUTx3EEs2ge0LGJ4TLvRVAsL/hZ10Dh5aX9btx63zmlQ H7qvSLeUEzqP5K4bEJBrtkJoum33cohGrtQD4HNWTRdaWH8teAkyCdKw9 mxoUKgxC8M2YoHtW93a7weIJbnmPxtXaCIfcWEJUg3vaeXMFygLeMubFw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAESQkU2tJV2Z/2dsb2JhbAClRXenWJw+gn2CbQSFPIsg X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208,217";a="326469078" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2011 07:56:20 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2T7uKVS024659 for ; Tue, 29 Mar 2011 07:56:20 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 02:56:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEDE6.CA5EA0B9" Date: Tue, 29 Mar 2011 02:56:18 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-eman-energy-aware-mib-01 Thread-Index: AcvtIGyaO2p/EqdYQJm9ZfkKm0tGwAAxP9SQ From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 29 Mar 2011 07:56:20.0719 (UTC) FILETIME=[CA949FF0:01CBEDE6] Subject: [eman] Review of draft-ietf-eman-energy-aware-mib-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:54:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEDE6.CA5EA0B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all,=20 Here are my comments on the Energy - Aware MIB - draft-ietf-eman-energy-aware-mib-01 Thanks Mouli =20 Energy-Aware MIB focuses on three concepts - the Identity of a device monitored for energy consumption; the context of the device, the notion of Parent/Child.=20 =20 Given that there is extensive email discussion on the possible use of ENTITY MIB - there should be a section on the pros and cons of using Entity MIB modeling.=20 =20 Regarding Parent child relationship - you have introduced some new new MIB variables - pmMgmtMacAddress , pmMgmtAddressType , pmMgmtAddress , pmMgmtDNSName =20 The value of these variables to describe a child should be explained.=20 What if the Layer 2 of the device does not have a MAC address or No IP address (BACNET) ? =20 Similarly, pmAlternateKey - Need more explanation.=20 Secondly, what if there is a conflict between pmKeywords and pmAlternateKeys ? =20 Thanks Mouli ------_=_NextPart_001_01CBEDE6.CA5EA0B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-eman-energy-aware-mib-01

Hello all,

Here = are my comments on the Energy – Aware MIB - = draft-ietf-eman-energy-aware-mib-01

Thanks

Mouli

 

Energy-Aware MIB focuses on three concepts = – the Identity of a device monitored for energy = consumption; the context of the device,  the notion = of Parent/Child.

 

Given = that there is extensive email discussion on the possible use of ENTITY MIB – there should be a section = on the pros and cons of = using Entity MIB = modeling.

 

Regarding Parent child  = relationship  – you have introduced some = new new MIB variables = -      = pmMgmtMacAddress  ,  = pmMgmtAddressType       = ,    =   pmMgmtAddress  ,   pmMgmtDNSName      = ;      

The = value of these variables to describe a child should be = explained. 

What if the Layer 2 = of the device = does not have a MAC = address or  No IP address (BACNET) ?

 

Similarly,  pmAlternateKey   - Need more = explanation. 

Secondly,  what if there is a conflict between = pmKeywords = and pmAlternateKeys ?

 

Thanks

Mouli

------_=_NextPart_001_01CBEDE6.CA5EA0B9-- From bill.mielke@alcatel-lucent.com Tue Mar 29 00:58:22 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47D43A6919 for ; Tue, 29 Mar 2011 00:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.171 X-Spam-Level: X-Spam-Status: No, score=-5.171 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, MANGLED_PILL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkunhsO0D0xc for ; Tue, 29 Mar 2011 00:58:21 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 89FF53A6889 for ; Tue, 29 Mar 2011 00:58:21 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2T7xxhL025047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Mar 2011 02:59:59 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2T7xwss029004 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 29 Mar 2011 02:59:59 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 29 Mar 2011 02:59:59 -0500 From: "Mielke, William F (Bill)" To: eman mailing list Date: Tue, 29 Mar 2011 02:59:49 -0500 Thread-Topic: Comments on draft-ietf-eman-requirements-01 Thread-Index: Acvt50b9erW+MI54RNyu7Dttk5Ox8A== Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E7922507362587@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [eman] Comments on draft-ietf-eman-requirements-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:58:22 -0000 Below please find my comments on draft-ietf-eman-requirements-01. I also h= ave some minor textual formatting or rewording comments which I will provid= e to Benoit directly in a separate email. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein ------------------------------------------- Comments on draft-ietf-eman-requirements-01 ------------------------------------------- Section 1: We should clarify what we mean by "building networks" and "home networks". = For example, do these networks explicitly include or exclude things like e= nvironmental management systems for heating, air conditioning, lighting con= trol, etc? Sections 2.4, 2.5, and 2.6: It occurs to me that sections 2.4, 2.5, and 2.6 are all simply different ex= amples of the same "energy proxying scenario". If we want to call these ou= t as separate and distinct cases perhaps the sections should be updated to = illustrate why they are unique from one another (i.e. for reasons other tha= n simply the domain to which the proxying has been applied). Section 2.8: I am not certain on how best to address this point but I believe that the c= urrent thinking relative to batteries may be too narrow in scope. For exam= ple, telephone switching offices often employ huge banks of batteries which= are used to power the entire office when the grid is unavailable. Another= example is many alternative energy sources also employ batteries as a fund= amental storage facility where accumulated energy can be saved until needs = to be supplied to its connected devices. Both of these examples extend batteries beyond the simple concept of an on-= board battery embedded within a simple device. Is this a separate scenario= (e.g. for "energy storage devices") or an example of how the thinking on t= he battery scenario may need to be broadened? Section 3.4.4 The current text states "These devices can consume energy when turned off o= r to sleep mode, because in these modes they still can charge their batteri= es." >From an energy consumtion point of view this is not technically correct. E= nergy which is used to recharge a battery is not technically consumed (i.e.= used up) but is rather merely transferred and stored for later use. The s= tored energy is only consumed when the device is actually discharging the b= attery. So, the proper way to account for the energy use of a device is: Energy(Consumed) =3D Energy(TransferedFromMains) - Energy(RemainingInBatter= y) Thus, when the device is technically "off" but charging the amount of energ= y actually consumed by the device remains unchanged, and when the main powe= r is off and the device is draining the battery only then is the energy sto= red in the battery actually consumed (and is reflected in the decreasing va= lue of Energy(RemainingInBattery). So I think that we need to be careful in how we define "energy consumption"= . Section 4: The text states: "However, the overhead of pull model monitoring is typical= ly higher than for push model monitoring, particularly when large numbers o= f values are to be collected, such as time series of power values." I would like to better understand why you are asserting this to be true. T= he inherent efficiency of a transfer is not a function of which side initia= tes the transfer (i.e. push or pull). So you must be thinking of something= else or I am misunderstanding the point. Perhaps you are equating "pull mode" with "polling" vs. "push mode" with "e= vent driven". To me these are not equivalent statements so perhaps that is= the source of my concern and/or perhaps I am merely splitting hairs too fi= nely on this distinction. Consider an example where readings are pushed 1 per minunte vs. pulled 5 at= a time every 5 minutes: Time --> +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----= + | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 = | +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----= + | | | | | | | | | | | | | | = | V V V V V V V V V V V V V V = V PU01 PU02 PU03 PU04 PU05 PU06 PU07 PU08 PU09 PU10 PU11 PU12 PU13 PU14 PU= 15 | | = | V V = V PL01 PL06 PL= 11 PL02 PL07 PL= 12 PL03 PL08 PL= 13 PL04 PL09 PL= 14 PL05 PL10 PL= 15 Where PUnn is a push mode transfer and PLnn is a pull mode transfer. Wheth= er I push the values 1 at a time or pull them 5 at a time I still transfer = the same number of values. So it is unclear to me why you are saying that = the push mode approach is inherently more efficient than the pull mode appr= oach. In fact, depending on the transfer protocol being used and the size of the = packets involved I could actually argue that the pull mode approach is more= efficient because it will (or at least it could) involve less network over= head per reading/unit transfered. The text states "The only exceptions are notifications on power state chang= es and high volume time series of energy consumption values." Until I better understand why you believe this is true I respectfully disag= ree that this is a fundamental implication/conclusion. So there is some confusion which may need to be cleared up here and I under= stand that the confusion may be on my part. Either way some additional cla= rification may be needed in the document to justify the main conclusions st= ated there. Section 7.1.2: The text states "For associating the provided information to specific compo= nents of a device, the ENTITY STATE MIB module makes use of the means provi= ded by the ENTITY MIB module [RFC4133]. Particularly, it uses the entPhysic= alIndex for identifying entities.". This is interesting information which seems to be trying to make a specific= point however the point itself has not been articulated and so it lost. A= dd something to explain the implications of these points. This section seems to be articulating that the existing ENITITY STATE MIB f= acilities are insufficient for our larger purpose. This naturally implies = that something additional needs to be defined but it is unclear from the ex= isting text whether extending these existing facilities or defining new one= s is the best approach. Perhaps that decision is left to later documents? From moulchan@cisco.com Tue Mar 29 01:12:02 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67FE13A697A for ; Tue, 29 Mar 2011 01:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4p0xUssuc8U for ; Tue, 29 Mar 2011 01:11:59 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4ECB03A68C1 for ; Tue, 29 Mar 2011 01:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=12363; q=dns/txt; s=iport; t=1301386417; x=1302596017; h=mime-version:subject:date:message-id:from:to; bh=o95sZPwJv+gwsGOOjy/52yWIrP9K20UMGaxClXPf40M=; b=SdwTJYEX5eSoLFNfr29CJfZTjL+Z8DlVKRytF1lAp9q2GNGgOKHCkxHI Lp73p0cNmYDZ2qb1FI4EBXmYXhwpt7QtFoOlvWpKy6g75J7lUM49zLyP/ VLxiqqLP83N+m5edA8yoV6RKkdTvQZpd9a2qO2YuEtpj19usClej+LEOc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGOUkU2tJV2c/2dsb2JhbAClRXenTpxBgnwBgm0EhTyLIIlC X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208,217";a="227904359" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2011 08:13:36 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2T8DaDI032700 for ; Tue, 29 Mar 2011 08:13:36 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 03:13:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Agzl BCZS BVRI CNDw DExY DnZi EcuQ Eh6A E7h0 GG4f GZwV Gi4J HDvt HN8I IHF6 I2Kw; 1; ZQBtAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {16C968FB-C50E-4229-B4FA-9B80B977ADB7}; bQBvAHUAbABjAGgAYQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Tue, 29 Mar 2011 08:13:33 GMT; RgBXADoAIABSAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBlAG0AYQBuAC0AZgByAGEAbQBlAHcAbwByAGsALQAwADEA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEDE9.33BA8C09" x-cr-puzzleid: {16C968FB-C50E-4229-B4FA-9B80B977ADB7} Content-class: urn:content-classes:message Date: Tue, 29 Mar 2011 03:13:33 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-eman-framework-01 Thread-Index: AcvtICvppv5uLMdDQvW8Oz7MNj+nPwAxu2bQ From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 29 Mar 2011 08:13:36.0657 (UTC) FILETIME=[340C3810:01CBEDE9] Subject: [eman] FW: Review of draft-ietf-eman-framework-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:12:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEDE9.33BA8C09 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Here are comments on the draft-ietf-eman-framework-01.=20 Thanks Mouli =20 Abstract should have some context what the document contains. Right now, it is a one line sentence. Terminology section should have a definition of what is an Energy Aware device.=20 =20 Since the MIB variables are not defined in the framework document, the UML diagram seems out of context.=20 I think the purpose of the framework document is to impress on the need 3 - 4 architectural points.=20 Identity of the device - what are the variables needed to identify a device=20 Why is it important to have the notion of Parent/Child and how does this help in energy monitoring scenarios=20 The concept of Power States of device for monitoring and possibly configuration of devices in future=20 Demand measurement. - why is it important=20 =20 Some of the examples can be removed from the framework document.=20 =20 The example scenario of dual powered device provided by Chris Verges has been captured in the requirements and is not needed in the framework document.=20 Section 11 - Implementation scenarios is part of many documents - One possibility is have a detailed section of Use cases in the Applicability Statement document. If other or new use cases for energy monitoring, the applicability statement can be expanded and the requirements document can be updated to see if there are new energy monitoring requirements. =20 For e.g. there are some new use cases from PDU vendors and Printers (power consuming entities which a network connection) =20 If the framework document is trimmed a bit, I think this document will be much better. My 2 cents.=20 =20 Thanks Mouli=20 =20 ------_=_NextPart_001_01CBEDE9.33BA8C09 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: Review of draft-ietf-eman-framework-01

Hello

Here = are comments on the =  draft-ietf-eman-framework-01. =

Thanks

Mouli

 

Abstract should have some context what the document contains. = Right now, it is a one line sentence.

Terminology section should have a definition of what is an Energy Aware = device.

  =

Since = the MIB variables are not defined in the = framework document, the UML diagram seems out of context.

 I = think the purpose of the framework document is to impress = on the need  3 - 4 architectural points.

Identity of the device – what are the variables needed to = identify a device

Why is = it important to have the notion of Parent/Child and how does this help = in energy monitoring scenarios =

The concept of Power States of device for monitoring and possibly = configuration of devices in future

Demand = measurement. – why is it important =

  =

Some of = the examples can be removed from the = framework document.

 

The = example scenario of dual powered device provided by = Chris Verges has been captured = in the requirements and is not needed in the framework document. =

Section = 11 - Implementation scenarios is part of many documents – One = possibility is have a detailed section of Use cases in the Applicability = Statement document.

If = other or new use cases for energy monitoring, the applicability = statement can be expanded and the requirements document can be updated to see if there are = new energy monitoring requirements. 

For = e.g.  there are some new use cases from PDU vendors and Printers = (power consuming entities which a network connection)

 

If = the framework document is trimmed a bit,  I think this document will be = much better. My 2 cents.

 

Thanks

Mouli =

 

------_=_NextPart_001_01CBEDE9.33BA8C09-- From moulchan@cisco.com Tue Mar 29 02:00:26 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1E33A68CE for ; Tue, 29 Mar 2011 02:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gJbx8vsG3PR for ; Tue, 29 Mar 2011 02:00:22 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2042F3A683C for ; Tue, 29 Mar 2011 02:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=7297; q=dns/txt; s=iport; t=1301389320; x=1302598920; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=zMBj1WdN6yLjRtByAD610LwwG//C8Kvg18qY/skW0nE=; b=hYwOaQq2ouPmdwrWx4Evi6Am5POuVW11TMB/+3GUuqHXKH8YdmewQBgo Zpb8D8PbPdhC53E6Kbnikwv21kHzptBqfBnPhSYicAloil8JXvlmhjupT aSnk+X+njHr0gZuPCOh6XTOwApXqn3QoDEyf9nAfTTrH9WtT/LOUw7Q+E 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADqfkU2tJV2c/2dsb2JhbACCYaJld6danESFagSFPIsg X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208,217";a="228309908" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2011 09:01:59 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2T91x9O023200 for ; Tue, 29 Mar 2011 09:01:59 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 04:01:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEDEF.F5FF56CC" Date: Tue, 29 Mar 2011 04:01:58 -0500 Message-ID: In-Reply-To: <4D911668.2010801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-tychon-eman-applicability-statement-01.txt Thread-Index: AcvtnfBU8hut0/kuSq+iifxeyicFXwATKxSQ References: <4D88DBA0.6080909@cisco.com> <4D88F2FB.4060201@cisco.com> <4D911668.2010801@cisco.com> From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 29 Mar 2011 09:01:59.0661 (UTC) FILETIME=[F65F79D0:01CBEDEF] Subject: [eman] Review of draft-tychon-eman-applicability-statement-01.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:00:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEDEF.F5FF56CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello all,=20 =20 Here is my review of draft-tychon-eman-applicability-statement-01.txt=20 =20 Thanks Mouli =20 To an extent, the EMAN WG work started with a requirements draft and then a couple of MIB Modules.=20 Now, we have an applicability statement.=20 In an ideal setting, it would be good to have the applicability statement first, which should feed in to the requirements for energy monitoring and as a result of requirements, the architecture and MIB modules are designed to comply with the requirements. =20 As of now, the applicability statement is a good start in terms of the areas to be covered - Scope of EMAN, Use cases of energy monitoring, and relevant standards in IETF and other standards organizations working on Energy.=20 =20 I would like to suggest the Use cases section be expanded to cover the network scenarios ( 8 or 9 scenarios covered in other drafts) of energy monitoring in detail.=20 Instead of use cases described in all documents, it may be useful to capture the use cases in this in document and other documents shall refer to the use cases.=20 Similarly, In terms of standards section requires some more detail. Section 2 has a description of some standards like IEC and ANSI, .... It would be useful to describe what aspects of those standards are relevant to EMAN and should be captured in EMAN.=20 =20 In summary, the draft needs a revision of Use cases and Energy related standards. There are typos that need to be corrected and I shall send those the authors directly. =20 =20 =20 Thanks Mouli ------_=_NextPart_001_01CBEDEF.F5FF56CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hello all, =

 

Here is my review = of  draft-tychon-eman-applicability-statement-01.txt

 

Thanks

Mouli

 

To an extent, =  the EMAN WG  work started with a requirements draft and then a couple of MIB Modules. =

Now, we have an = applicability statement.

In an ideal setting, = it would be good to have the applicability statement first, which should feed in to = the requirements for energy monitoring and as a result of requirements, the = architecture and MIB modules are designed to comply with the = requirements.

 

As of now, the = applicability statement is a good start in terms of the areas to be covered – = Scope of EMAN, Use cases of energy monitoring, and relevant standards in IETF and = other standards organizations working on Energy.

 

I would like to = suggest the Use cases section be expanded to cover the network scenarios ( 8 or 9 = scenarios covered in other drafts)  of energy monitoring in detail. =

Instead of use cases = described in all documents, it may be useful to capture the use cases in this in = document and other documents shall refer to the use cases.

Similarly, In terms = of standards section requires some more detail. Section 2 has a description of some standards like IEC and ANSI, …. It would be useful to describe = what aspects of those standards are relevant to EMAN and should be captured = in EMAN.

 

In summary, the draft = needs a revision of Use cases and Energy related standards.  There are = typos that need to be corrected and I shall send those the authors directly. =  

 

 

Thanks

Mouli

------_=_NextPart_001_01CBEDEF.F5FF56CC-- From bill.mielke@alcatel-lucent.com Tue Mar 29 10:05:11 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA70C3A6A5E for ; Tue, 29 Mar 2011 10:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QBpMPEr828d for ; Tue, 29 Mar 2011 10:05:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 63B783A6A32 for ; Tue, 29 Mar 2011 10:05:10 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2TH6mja012678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Mar 2011 12:06:48 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2TH6mcR016130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 29 Mar 2011 12:06:48 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 29 Mar 2011 12:06:48 -0500 From: "Mielke, William F (Bill)" To: eman mailing list Date: Tue, 29 Mar 2011 12:06:42 -0500 Thread-Topic: Comments on draft-quittek-eman-battery-mib-00 Thread-Index: AcvuM60vypLsePvKRh6bFOgxIP5zPg== Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E792250736277E@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [eman] Comments on draft-quittek-eman-battery-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 17:05:12 -0000 See below. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein --------------------------------------------- Comments on draft-quittek-eman-battery-mib-00 --------------------------------------------- I queried one of my colleagues, Christophe Grangeat, to review this documen= t and provide some comments. Christophe has a lot of domain expertise with= various battery technologies and the monitoring requirements for them. I = can get back with him if we need further clarification. Here is his response to my query: It is natural that the battery MIB topic is starting with Li-ion batteries,= since they require an embedded control board to operate safely. However, i= t is now required that Hybrid systems with deep cycle lead-acid batteries a= lso need some careful monitoring in order to operate in the most efficient = and sustainable way. These lead-acid batteries would not have their own emb= edded control board but the battery monitoring MIBs would be embedded in th= e controller of the energy management system. NiCd batteries would be manag= ed in the same way as lead-acid. We also observe new battery technologies, = like Sodium or Redox Flow batteries that also require some control electron= ics and which we advocate should be using standardized MIBs.=20 On the document itself, here are a few comments that we would propose at th= is stage: Chapter3 4th =A7 In the static properties we recommend to add the manufacturer's recommended= charging data, such as boost voltage, float voltage, current limitation, m= aximum duration at boost voltage, Chapter 7.1 We consider temperature an important criterion for battery safety and life = time. We would recommend including battery temperature in the MIB, as well = as criteria that allow raising thermal run-away alarms. On the same safety topic, we would recommend to add a "batteryHealth" crite= rion, which can include for example SymetryAlarms for lead-acid technology.= =20 Chapter 7.2 The SoC estimate issues may be sensitive to address for some technologies l= ike lead-acid or NiCd. The group should seek advice from manufacturers.=20 From j.schoenwaelder@jacobs-university.de Wed Mar 30 01:39:57 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2223A6AF5 for ; Wed, 30 Mar 2011 01:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFm-1S04RWaF for ; Wed, 30 Mar 2011 01:39:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 694983A6919 for ; Wed, 30 Mar 2011 01:39:55 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C8AEC0029 for ; Wed, 30 Mar 2011 10:41:33 +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 jO5LonkEgmGJ; Wed, 30 Mar 2011 10:41:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0103C0028; Wed, 30 Mar 2011 10:41:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3693C174D7B6; Wed, 30 Mar 2011 10:41:29 +0200 (CEST) Date: Wed, 30 Mar 2011 10:41:29 +0200 From: Juergen Schoenwaelder To: eman@ietf.org Message-ID: <20110330084129.GA29695@elstar.local> Mail-Followup-To: eman@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [eman] js review of draft-ietf-eman-energy-aware-mib-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:39:57 -0000 Hi, here are my review comments for draft-ietf-eman-energy-aware-mib-01 (ENERGY-AWARE-MIB): - Generally, I suggest to use zero-length string instead of null string. - You can't set pmParentId to a "null string" since the PowerMonitorId type does not allow this. - Is PowerMonitorKeywordList really going to be a binary string? - Is the persistence toggle really global for the pmTable? - It is not clear to me how pmEthPortIndex is to be used. Is the idea that the agent implementing the ENERGY-AWARE-MIB refers to a local port but the measured data is remote? How does PethPsePortIndexOrZero related to the port number of the bridge MIB? How does it related to a physical entity port? - The document talks about the EnergyAwareDeviceMIB, but it seems that this is the ENERGY-AWARE-MIB? - PethPsePortGroupIndexOrZero lacks a reference to RFC 3621 - In general, I am often not sure which objects are local and which are remote or possible remote to the agent. - I note that pmName is read-write while entPhysicalName is read-only, that is entPhysicalName is the machine local generated identifier while pmName seems to be a user selectable. Note that entPhysicalAlias is a writable handle, but more restricted in length. - Is the UUID (pmPowerMonitorId) going to be included in entPhysicalUris? If so, what if someone changes entPhysicalUris? pmPowerMonitorId is read-ony but entPhysicalUris is read-write. - If pmName does not related to entPhysicalAlias, does pmRoleDescription replicate entPhysicalAlias? - What is the intended usage of pmMgmtMacAddress, pmMgmtAddressType, pmMgmtAddress, pmMgmtDNSName? If the idea is to guide further SNMP access, then the information is incomplete. How are these objects populated? Since these are read-only, the information must be discoverable somehow. Why do we need both a pmMgmtDNSName and a pmMgmtAddress? Note that InetAddress can represent DNS names. If both are provided, which one should be used? - How does pmAlternateKey related to entPhysicalName? - How is a component modeled that is both a power meter and consumer? Since pmPowerCategory is an enum, you need two table entries. If so, which objects are going to be equal? How do I find out that multiple entries belong to the same component? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Mar 30 02:10:17 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AA43A6AFB for ; Wed, 30 Mar 2011 02:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkUTNsC3DMl2 for ; Wed, 30 Mar 2011 02:10:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 60EEE3A6949 for ; Wed, 30 Mar 2011 02:10:16 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF496C000B for ; Wed, 30 Mar 2011 11:11:54 +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 RHrtteHg8MZK; Wed, 30 Mar 2011 11:11:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3259EC000D; Wed, 30 Mar 2011 11:11:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9C80E174D867; Wed, 30 Mar 2011 11:11:50 +0200 (CEST) Date: Wed, 30 Mar 2011 11:11:50 +0200 From: Juergen Schoenwaelder To: eman@ietf.org Message-ID: <20110330091150.GB29695@elstar.local> Mail-Followup-To: eman@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [eman] js review of draft-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 09:10:17 -0000 Hi, here are some review comments for draft-claise-energy-monitoring-mib-07. I think some of the introductory material is really helpful to understand the ENERGY-AWARE-MIB - perhaps that material should be moved to the other document. - It seems POWER-MONITOR-MIB does not require implementation of the ENERGY-AWARE-MIB but then it seems all the introductory examples in the document assume the ENERGY-AWARE-MIB to be implemented. This is kind of confusing, see already my initial comments about moving some of this text into the ENERGY-AWARE-MIB document. - What is the persistency of changes to pmPowerState or pmPowerStateEnterReason? - What is the persistency of pmEnergyParametersTable? Should there be a RowStatus column? - Should the pmPowerStateChange notification also contain the pmPowerActualState? Can it be that say pmPowerActualState changes without affecting pmPowerManufacturerActualPowerState? Or can pmPowerManufacturerActualPowerState changes without affecting pmPowerActualState? Right now, the description seems to say the notification is only generated if pmPowerManufacturerActualPowerState changes. Can we perhaps do away with pmPowerManufacturerActualPowerState? This is likely related to the bigger power state discussion... - How fast can pmPowerStateChange notifications be generated? Is there a need to think about a throttling mechanism? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bill.mielke@alcatel-lucent.com Wed Mar 30 03:20:51 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396BA3A6B3A for ; Wed, 30 Mar 2011 03:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luC5WF00Tk7K for ; Wed, 30 Mar 2011 03:20:50 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 95D2D3A6B46 for ; Wed, 30 Mar 2011 03:20:47 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2UAMMZn027307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Mar 2011 05:22:22 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2UAMMap005010 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 30 Mar 2011 05:22:22 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 30 Mar 2011 05:22:22 -0500 From: "Mielke, William F (Bill)" To: eman mailing list Date: Wed, 30 Mar 2011 05:22:17 -0500 Thread-Topic: Comments for draft-quittek-eman-reference-model-01 Thread-Index: AcvuxFivFJz5kGkVTI+Y1KKwZymfCA== Message-ID: <0DEE3BCEE44BFD4EBC3B7DC009C8E79225073629C0@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [eman] Comments for draft-quittek-eman-reference-model-01 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 10:20:51 -0000 See below. I will also forward an annotated PDF to the authors under separ= ate email which includes minor typographical comments. William F. Mielke Alcatel-Lucent Distinguished Member of Technical Staff 6200 East Broad Street Room: 4B01-1V Columbus, OH 43213-1530 Email: Bill.Mielke@alcatel-lucent.com Phone: 614 367 5628 Fax: 614 367 5965 "Live like you're going to die tomorrow. Learn like you're going to live forever." - Albert Einstein ------------------------------------------------- Comments on draft-quittek-eman-reference-model-01 ------------------------------------------------- Overall I find this to be a very good document. It does a very nice job of= cleanly partitioning the target domain into understandable, non-overlappin= g pieces and clearly highlights the relationships between those pieces. It= is concise, understandable, and should serve as a good reference around wh= ich we can organize our on-going discussions. Section 3.2.2. Power Source: I think that we need to discuss a bit further how best to account for the e= nergy which is stored in internal batteries. You have taken the position t= hat charging the battery counts as having "consumed" the energy in question= , and hence when the device is continuing to operate on battery power it is= considered to be no longer consuming energy. This makes sense when you co= nsider a device to be a black box and therefore the presence of an internal= battery is not visible. There is an alternative view which takes a more white box perspective which= accounts for the battery as being a storage device. In this view charging= the battery is not necessarily viewed as being a net "consumption" of the = energy which needs to be accounted for. In this view "consumption" means c= onversion of electrical energy into some form of "useful work". Thus, when= a device stores energy in an internal battery it is not actually convertin= g the electrical energy into useful work. That will only happen at a later= time when the battery is being discharged by the device while it is perfor= ming whatever service it was designed for. It is not clear to me that this is a purely academic distinction. It goes = to the question of how to account for the energy being used and when it sha= ll be considered "consumed" and from whose perspective these terms apply. = Clearly from the perspective of the wall socket charging the battery is "co= nsuming" energy. I would argue that from the perspective of the device per= forming useful work (i.e. that function for which it was designed) merely c= harging the battery is not actually "consuming" the energy. When one considers external rather than internal batteries is charging the = batteries a consumer of energy? Again it depends on one's frame of referen= ce. Clearly from the perspective of the power grid it is drawing power, bu= t in what sense is a battery or any storage device a net consumer of energy= (aside from internal resistances and self-discharging)? I am not advocating for any particular view here. I am merely pointing out= that there is an alternative view which needs to be analyzed, understood, = and rationalized with the final outcome. Section 3.2.4.2. Power Source Monitor: You mention that this will typically only report "on" or "off". I would ex= pect this to also (optionally) provide access to other interesting informat= ion about the source in terms of total available capacity it can supply, th= e electrical parameters it supports in terms of voltage and/or amperage, an= d optionally it may report on the ultimate source of the energy supplied (e= .g. coal, natural gas, nuclear, wind, solar) and some of the key characteri= stics of the source such as cost/KWH, greenhouse gas loading, etc. Section 3.5.6. Power over Ethernet Switch You mention that the PoE switch contains a power source. I think that we n= eed to be careful about our use of the term power source ... or at least we= need to agree on the definition of the term. >From my perspective the PoE switch contains a power SUPPLY which is not the= same thing as a power SOURCE, at least by my definition of SOURCE. The po= wer SUPPLY is merely a fancy part of the power distribution network which t= ransfers energy from the true power SOURCE to the devices it serves. It's = purpose is to provide various conditioning and filtering on the power befor= e it is delivered to the devices but it is not a net source of energy. Given this I think that we may need to crisp up our definition of the term = Power Source. From j.schoenwaelder@jacobs-university.de Wed Mar 30 03:44:18 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20B828C136 for ; Wed, 30 Mar 2011 03:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owK0YIy0Gqbb for ; Wed, 30 Mar 2011 03:44:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D327D28C0DB for ; Wed, 30 Mar 2011 03:44:16 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 511A3C0028 for ; Wed, 30 Mar 2011 12:45:55 +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 8gF1UyBE7ykk; Wed, 30 Mar 2011 12:45:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A91DDC000B; Wed, 30 Mar 2011 12:45:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2754B174DDF1; Wed, 30 Mar 2011 12:45:51 +0200 (CEST) Date: Wed, 30 Mar 2011 12:45:51 +0200 From: Juergen Schoenwaelder To: eman@ietf.org Message-ID: <20110330104550.GB30154@elstar.local> Mail-Followup-To: eman@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [eman] js review of draft-quittek-eman-battery-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 10:44:18 -0000 Hi, here are some review comments for draft-quittek-eman-battery-mib-00: - Is there a special reason for this: entPhysicalIndex Integer32 (1..2147483647) pmIndex Integer32 (1..2147483647) pmPowerIndex Integer32 (0..2147483647) -- why very special 0 ?? batteryIndex Unsigned32 -- what about 0 ?? - Put other and unknown enumeration entries at the top so that in case additions are made, they do not end up somewhere in the middle. - Giving a Counter32 value special semantics frankly seems stretching the usage of counters beyond what I think is legal. What happens if the counter reading 'ffffffff'H? Perhaps this is really a zero based counter instead of a counter? It seems to persistently stick to the device or is this counter reinitialized with the SNMP agent? - psmNotificationsGroup should probably be batteryNotificationsGroup - Why is batteryAlarmThresholdsGroup mandatory while the notifications are optional? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From chrisv@cyberswitching.com Wed Mar 30 07:34:17 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAF63A6936 for ; Wed, 30 Mar 2011 07:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwsDjsMni5yg for ; Wed, 30 Mar 2011 07:34:14 -0700 (PDT) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) by core3.amsl.com (Postfix) with ESMTP id A2F4D3A67EF for ; Wed, 30 Mar 2011 07:34:13 -0700 (PDT) Received: from unknown [207.47.28.34] (EHLO mail03.cyberswitching.local) by p01c12o145.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 7cf339d4.0.25539.00-315.61206.p01c12o145.mxlogic.net (envelope-from ); Wed, 30 Mar 2011 08:35:53 -0600 (MDT) X-MXL-Hash: 4d933fc938e17a59-62363c8b0337d3b93f3af65f372d9891ffe06c46 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEEE7.A59B1573" Date: Wed, 30 Mar 2011 07:34:58 -0700 Message-ID: <68FBE0F3CE97264395875AC1C468F22CF36F2C@mail03.cyberswitching.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Action item to merge draft-verges Thread-Index: Acvu5tqS67uspZX8SDK4NY0HIz9ZrA== From: "Chris Verges" To: X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [207.47.28.34] X-AnalysisOut: [v=1.0 c=1 a=XnmKn_D4YrQA:10 a=BLceEmwcHowA:10 a=1Eql4bHns2] X-AnalysisOut: [NoxN2V9ejGkg==:17 a=3XgjonwM5hAiKo8IjuEA:9 a=K5Fre5TnzSIBq] X-AnalysisOut: [V6dKNvhT2OCn20A:4 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSm] X-AnalysisOut: [OFEACAAAA:8 a=xxje75pKMKiYilVMexAA:9 a=V4r0ZPrMFKinvkfd5Fg] X-AnalysisOut: [A:7 a=JKUgiotCq3vcOWxFP-B8dwh-R-QA:4] Subject: [eman] Action item to merge draft-verges X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:34:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEEE7.A59B1573 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi EMAN list, =20 Excellent discussion in the WG today. Juergen S., thanks especially for the overview of ENTITY-MIB. I'm still a little confused on whether the use of ENTITY-MIB would require EMAN's "index" to be a four-element tuple as described in your presentation, but we can address that further. =20 Thank you all for your understanding in today's presentation method; I wish my travel plans allowed me to make it to Prague, but that is the way of things. If anyone has further questions on draft-verges or the presentation today, I am happy to discuss further here. =20 At the end of the presentation on draft-verges, I proposed merging the object-oriented structure described within the draft with the energy-aware and power-monitoring drafts. Since I was remote, I did not get a good feeling for consensus on this item. Was it adopted? If so, how should we proceed? =20 Thanks, Chris ------_=_NextPart_001_01CBEEE7.A59B1573 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi EMAN list,

 

Excellent discussion = in the WG today.  Juergen S., thanks especially for the overview of = ENTITY-MIB.  I’m still a little confused on whether the use = of ENTITY-MIB would require EMAN’s “index” to be a = four-element tuple as described in your presentation, but we can address = that further.

 

Thank you all for = your understanding in today’s presentation method; I wish my = travel plans allowed me to make it to Prague, but that is the way of = things.  If anyone has further questions on draft-verges or the = presentation today, I am happy to discuss further = here.

 

At the end of the = presentation on draft-verges, I proposed merging the object-oriented = structure described within the draft with the energy-aware and = power-monitoring drafts.  Since I was remote, I did not get a good = feeling for consensus on this item.  Was it adopted?  If so, = how should we proceed?

 

Thanks,

Chris

------_=_NextPart_001_01CBEEE7.A59B1573-- From ietf@quittek.at Thu Mar 31 07:51:23 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E04328B56A for ; Thu, 31 Mar 2011 07:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zQtOpGxeE3A for ; Thu, 31 Mar 2011 07:51:22 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 0982B3A6B38 for ; Thu, 31 Mar 2011 07:51:22 -0700 (PDT) Received: from [10.7.0.92] (mito.netlab.nec.de [195.37.70.39]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MACoT-1QGcqr38XZ-00BTLe; Thu, 31 Mar 2011 16:53:01 +0200 References: <20110330104550.GB30154@elstar.local> In-Reply-To: <20110330104550.GB30154@elstar.local> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Thu, 31 Mar 2011 16:52:59 +0200 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:MOE1jwEDFk7qVL7OjA/GpSer3BTKokwzVezCAfOmuJy fR7YiAsWmV26zFCfhz0HfnyISbJBvhHnLavAN3UDv85rWgS8k5 oIn77NUgUseTKHoH6NmGmQyZ6psF3/HGAmXHV4AwD0SK30HI7N 65tbmxyZ03X78S/yBkwUtko6Ed52FU9pXUqMLBydefYLUdolhF VjnQSnVfcajGcE88rFuJQ== Cc: eman@ietf.org Subject: Re: [eman] js review of draft-quittek-eman-battery-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:51:23 -0000 Hi Juergen, Thank you for the review! Please see replies inline. Am 30.03.2011 um 12:45 schrieb Juergen Schoenwaelder: > Hi, >=20 > here are some review comments for draft-quittek-eman-battery-mib-00: >=20 > - Is there a special reason for this: >=20 > entPhysicalIndex Integer32 (1..2147483647) > pmIndex Integer32 (1..2147483647) > pmPowerIndex Integer32 (0..2147483647) -- why very special 0 ?? > batteryIndex Unsigned32 -- what about 0 ?? No, there is not. This is just a mistake. Will change batteryIndex to Integer32 (1..2147483647). > - Put other and unknown enumeration entries at the top so that in case > additions are made, they do not end up somewhere in the middle. Will do. > - Giving a Counter32 value special semantics frankly seems stretching > the usage of counters beyond what I think is legal. What happens if > the counter reading 'ffffffff'H? Perhaps this is really a zero based > counter instead of a counter? It seems to persistently stick to the > device or is this counter reinitialized with the SNMP agent? The problem with this object is that some devices have no provisioning=20= for counting these cycles. What would be the right solution for this? a) have an additional object indicating whether cycles are counted? b) if there is no counting facility, not implement the object? c) if there is no counting facility, implement the object but return = inconsistentValue(12)? d) return a special counter value? e) anything else? Recommendations are highly appreciated. > - psmNotificationsGroup should probably be batteryNotificationsGroup Yes, that's a copy/paste mistake. Will fix it. > - Why is batteryAlarmThresholdsGroup mandatory while the notifications > are optional? Yes, that's inconsistent. Will fix it in the next revision. Thanks, Juergen Q. > /js >=20 > --=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 Mar 31 08:10:35 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059F328C12B for ; Thu, 31 Mar 2011 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5A43v1OYZyT for ; Thu, 31 Mar 2011 08:10:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4A0F828B56A for ; Thu, 31 Mar 2011 08:10:32 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B254C004F; Thu, 31 Mar 2011 17:12:11 +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 FD-Km2NIPm2A; Thu, 31 Mar 2011 17:12: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 C89F6C0019; Thu, 31 Mar 2011 17:12:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6704B175073F; Thu, 31 Mar 2011 17:12:07 +0200 (CEST) Date: Thu, 31 Mar 2011 17:12:07 +0200 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20110331151207.GA34348@elstar.local> Mail-Followup-To: Juergen Quittek , eman@ietf.org References: <20110330104550.GB30154@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] js review of draft-quittek-eman-battery-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:10:35 -0000 On Thu, Mar 31, 2011 at 04:52:59PM +0200, Juergen Quittek wrote: > > - Giving a Counter32 value special semantics frankly seems stretching > > the usage of counters beyond what I think is legal. What happens if > > the counter reading 'ffffffff'H? Perhaps this is really a zero based > > counter instead of a counter? It seems to persistently stick to the > > device or is this counter reinitialized with the SNMP agent? > > The problem with this object is that some devices have no provisioning > for counting these cycles. > > What would be the right solution for this? > a) have an additional object indicating whether cycles are counted? > b) if there is no counting facility, not implement the object? > c) if there is no counting facility, implement the object but return inconsistentValue(12)? > d) return a special counter value? > e) anything else? > > Recommendations are highly appreciated. A single Counter32 value has no meaning since a Counter32 has no defined initial value. If you want a meaninful Counter32, you need to use ZeroBasedCounter32. That is the simple part. Given your options: a) dobable, requires to pay attention of course and special case code b) in theory the correct approach, not popular though due to some common implementation shortcomings, but getting slowly more accepted as far as I can tell (interface tables just do not report the counters that are not applicable/implemented for a certain interface) c) nope, that is in conflict with RFC 3416 d) nope, does not work since counters by definition use the complete number space e) no idea what that would be >From an SNMP point of view, you just do not implement the objects that do not apply. Correctly written managers will cope with this just fine. We tend to report special "NULL" values whenever this is possible to help not so correctly written management applications along. In case of counters, there simply is no such "NULL" value, so I think the correct thing to do is to not instantiate the object (and to be explicit about this in the DESCRIPTION clause). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@quittek.at Thu Mar 31 09:47:03 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4136B3A6AFD for ; Thu, 31 Mar 2011 09:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ACHa9Ly9CUL for ; Thu, 31 Mar 2011 09:47:02 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 041C93A6A4C for ; Thu, 31 Mar 2011 09:47:02 -0700 (PDT) Received: from dhcp-536c.meeting.ietf.org (dhcp-536c.meeting.ietf.org [130.129.83.108]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lb6lR-1PhFlO2GQj-00kTsm; Thu, 31 Mar 2011 18:48:41 +0200 References: <20110330104550.GB30154@elstar.local> <20110331151207.GA34348@elstar.local> In-Reply-To: <20110331151207.GA34348@elstar.local> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <7185EC7D-DFF8-4817-9833-4EB87255187F@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Thu, 31 Mar 2011 18:48:39 +0200 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:utrgpiYfMj5USZdBXD289wlwR15DBssUmpLbLVd+DBp NwS3s1oBd558DM5PHBFvJ7UnxZyvic6nqITnYczdCDY+2RvjWO Bsuvt8bZAiZnZwMDJJ0TkKYOnnvfoVx5Og35kArlKIgO0aKlBa iISqyOJ6V4uTg+uyOVwIuU1WEanV5R0m0UKw94D9Pl9FpnJqIA 7UytA0/X+QOjve9o+8oIQ== Cc: eman@ietf.org Subject: Re: [eman] js review of draft-quittek-eman-battery-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:47:03 -0000 Thanks, I will go for option b) Juergen Q. Am 31.03.2011 um 17:12 schrieb Juergen Schoenwaelder: > On Thu, Mar 31, 2011 at 04:52:59PM +0200, Juergen Quittek wrote: >=20 >>> - Giving a Counter32 value special semantics frankly seems = stretching >>> the usage of counters beyond what I think is legal. What happens if >>> the counter reading 'ffffffff'H? Perhaps this is really a zero based >>> counter instead of a counter? It seems to persistently stick to the >>> device or is this counter reinitialized with the SNMP agent? >>=20 >> The problem with this object is that some devices have no = provisioning=20 >> for counting these cycles. >>=20 >> What would be the right solution for this? >> a) have an additional object indicating whether cycles are counted? >> b) if there is no counting facility, not implement the object? >> c) if there is no counting facility, implement the object but return = inconsistentValue(12)? >> d) return a special counter value? >> e) anything else? >>=20 >> Recommendations are highly appreciated. >=20 > A single Counter32 value has no meaning since a Counter32 has no > defined initial value. If you want a meaninful Counter32, you need to > use ZeroBasedCounter32. That is the simple part. >=20 > Given your options: >=20 > a) dobable, requires to pay attention of course and special case code > b) in theory the correct approach, not popular though due to some = common > implementation shortcomings, but getting slowly more accepted as far > as I can tell (interface tables just do not report the counters that > are not applicable/implemented for a certain interface) > c) nope, that is in conflict with RFC 3416 > d) nope, does not work since counters by definition use the complete=20= > number space > e) no idea what that would be >=20 > =46rom an SNMP point of view, you just do not implement the objects = that > do not apply. Correctly written managers will cope with this just > fine. We tend to report special "NULL" values whenever this is > possible to help not so correctly written management applications > along. In case of counters, there simply is no such "NULL" value, so I > think the correct thing to do is to not instantiate the object (and to > be explicit about this in the DESCRIPTION clause). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From ietf@quittek.at Thu Mar 31 09:55:29 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F993A6A48 for ; Thu, 31 Mar 2011 09:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKDjc0QyAmYl for ; Thu, 31 Mar 2011 09:55:28 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 6F7DA3A6A33 for ; Thu, 31 Mar 2011 09:55:28 -0700 (PDT) Received: from dhcp-536c.meeting.ietf.org (dhcp-536c.meeting.ietf.org [130.129.83.108]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Mh8wH-1QIrpJ2e7F-00MPjL; Thu, 31 Mar 2011 18:57:06 +0200 References: <20110330104550.GB30154@elstar.local> <20110331151207.GA34348@elstar.local> In-Reply-To: <20110331151207.GA34348@elstar.local> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <73201B8B-63F7-4D7B-AE8E-76FB6353E229@quittek.at> Content-Transfer-Encoding: quoted-printable From: Juergen Quittek Date: Thu, 31 Mar 2011 18:57:04 +0200 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:T69RwZoH++QWBRcTgVA+8FvHt+IibPhJXISHurCh2Ms pAuTW3w1xXtAeUyee1NQZqnE6Z6DybMIkWIHwoXZA1H42nw3tm 5VD4eECo2xmv667h/jEARESgiqKT+LUB33rj8dgx0Pmc8h+z29 dHsAAzkwXCIse3J6Et3j+WkL//hcQjTA9p8YPV9p0mc7qhP48R O1ZbemA5rtJGl6pIqA2Kg== Cc: eman@ietf.org Subject: Re: [eman] js review of draft-quittek-eman-battery-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:55:29 -0000 Hi Juergen, Sprry, I have a follow-up question on option b). This option says "don't implement the counter object if you cannot count = cycles". What if I have two batteries where I have count values for one and but = not for the other one. Would I then implement the object in one conceptual row, but = not in=20 the other one? Would this be OK for management systems browsing the MIB? Thanks, Juergen Am 31.03.2011 um 17:12 schrieb Juergen Schoenwaelder: > On Thu, Mar 31, 2011 at 04:52:59PM +0200, Juergen Quittek wrote: >=20 >>> - Giving a Counter32 value special semantics frankly seems = stretching >>> the usage of counters beyond what I think is legal. What happens if >>> the counter reading 'ffffffff'H? Perhaps this is really a zero based >>> counter instead of a counter? It seems to persistently stick to the >>> device or is this counter reinitialized with the SNMP agent? >>=20 >> The problem with this object is that some devices have no = provisioning=20 >> for counting these cycles. >>=20 >> What would be the right solution for this? >> a) have an additional object indicating whether cycles are counted? >> b) if there is no counting facility, not implement the object? >> c) if there is no counting facility, implement the object but return = inconsistentValue(12)? >> d) return a special counter value? >> e) anything else? >>=20 >> Recommendations are highly appreciated. >=20 > A single Counter32 value has no meaning since a Counter32 has no > defined initial value. If you want a meaninful Counter32, you need to > use ZeroBasedCounter32. That is the simple part. >=20 > Given your options: >=20 > a) dobable, requires to pay attention of course and special case code > b) in theory the correct approach, not popular though due to some = common > implementation shortcomings, but getting slowly more accepted as far > as I can tell (interface tables just do not report the counters that > are not applicable/implemented for a certain interface) > c) nope, that is in conflict with RFC 3416 > d) nope, does not work since counters by definition use the complete=20= > number space > e) no idea what that would be >=20 > =46rom an SNMP point of view, you just do not implement the objects = that > do not apply. Correctly written managers will cope with this just > fine. We tend to report special "NULL" values whenever this is > possible to help not so correctly written management applications > along. In case of counters, there simply is no such "NULL" value, so I > think the correct thing to do is to not instantiate the object (and to > be explicit about this in the DESCRIPTION clause). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 31 11:19:27 2011 Return-Path: X-Original-To: eman@core3.amsl.com Delivered-To: eman@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C654E3A6B14 for ; Thu, 31 Mar 2011 11:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG55OyrVIbcD for ; Thu, 31 Mar 2011 11:19:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2D473A6B38 for ; Thu, 31 Mar 2011 11:19:26 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15D14C004F; Thu, 31 Mar 2011 20:21:06 +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 V2Q0GDy1CWmM; Thu, 31 Mar 2011 20:21:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57399C006D; Thu, 31 Mar 2011 20:21:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 55B921750C55; Thu, 31 Mar 2011 20:21:01 +0200 (CEST) Date: Thu, 31 Mar 2011 20:21:00 +0200 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20110331182059.GA34836@elstar.local> Mail-Followup-To: Juergen Quittek , eman@ietf.org References: <20110330104550.GB30154@elstar.local> <20110331151207.GA34348@elstar.local> <73201B8B-63F7-4D7B-AE8E-76FB6353E229@quittek.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73201B8B-63F7-4D7B-AE8E-76FB6353E229@quittek.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org Subject: Re: [eman] js review of draft-quittek-eman-battery-mib-00 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 18:19:27 -0000 On Thu, Mar 31, 2011 at 06:57:04PM +0200, Juergen Quittek wrote: > This option says "don't implement the counter object if you cannot > count cycles". What if I have two batteries where I have count > values for one and but not for the other one. Would I then implement > the object in one conceptual row, but not in the other one? You "instantiate" the object for those batteries where it makes sense. > Would this be OK for management systems browsing the MIB? This is what happens with the ifTable today on major routers. Here is a typical example (showing live data retrieved via SNMP): scli $ show interface stats INTERFACE STATUS I-BPS O-BPS I-PPS O-PPS I-ERR O-ERR I-DIS O-DIS I-UNK DESCRIPTION [...] 15 DDNN ---- ---- ---- ---- ---- ---- ---- ---- ---- ATM0-atm layer 16 DDNN ---- ---- ---- ---- ---- ---- ---- ---- ---- ATM0.0-atm subif 17 DDNN 0 0 0 0 0 ---- 0 0 0 ATM0-aal5 layer 18 DDNN 0 0 0 0 0 ---- 0 0 0 ATM0.0-aal5 layer 19 DDNN ---- ---- ---- ---- ---- ---- ---- ---- ---- ATM0-adsl You can see that some interface types have no counters at all, some layers have no output error counters. And you can always create such holes by configuring access control rules. Management systems that can't deal with this are kind of broken. And such systems already today have a problem to display the ifTable - so I assume that most systems should do this correctly meanwhile. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103