From bclaise@cisco.com Tue May 3 02:05:57 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D45E0756 for ; Tue, 3 May 2011 02:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu6CFicZMP8H for ; Tue, 3 May 2011 02:05:55 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BB89FE06AA for ; Tue, 3 May 2011 02:05: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 p4395rHm001831 for ; Tue, 3 May 2011 11:05:53 +0200 (CEST) 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 p4395oiw006213 for ; Tue, 3 May 2011 11:05:50 +0200 (CEST) Message-ID: <4DBFC56E.2020908@cisco.com> Date: Tue, 03 May 2011 11:05: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="------------060409050501030602090901" Subject: [eman] Two NMS configuring the Power Monitor with two different Power State Series X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 09:05:57 -0000 This is a multi-part message in MIME format. --------------060409050501030602090901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Let's discuss the following situation: what if we have 2 NMS', and they speak different Power State Series for a specific Power Monitor? Should this be allowed by the [EMAN-REQ]? Tentative definitions for Power States Series and Power State are defined below. They should help the discussion (further discussion on these definitions will have to take place in the future): Power State Series A Power State Series is defined as a well known sequence of incremental energy saving modes of a device. This can be viewed as an interface for the underlying device-implemented power settings. Examples include DTMF, ACPI, etc... Power State A Power State is a uniform way to classify power settings on a Power Monitor (e.g., shut, hibernate, sleep, high).The Power State is composed of a Power State Series and a specific state within the series. Actually this requirement has got some implications in terms of the MIB design (taking http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07 into account) - If the answer is yes, then we need to have an extra index in the power pmPowerTable. This index must abe a new TC, which is only for the Power State Series. Note: the table needs to redesigned because the common variable (caliber, nameplate, etc...) are common per Power State Series. Then we can have a new table, for discovery, that will only contain two indices: pmPowerMonitorIndex and the new TC-defined pmPowerStateSeries. - If the answer is no, then there is the risk that NMS1 will set the DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the Power Monitor supports both the DMTF and the EMAN Power State Series), and there is a ping-pong game between two NMS's that don't synchronize between the two. The alternative is that the first NMS would say: I will speak to the Power Monitor with the DMTF Power State Series, and then all the other NMS's will have to speak the same language (i.e. DMTF). Somehow, the trade-off is the following: - We ease the live of the NMS (they can speak the "language" of their choice) at the cost of slight more complex MIB (one extra index) - We ease the live of the Power Monitor by simplifying the MIB design. Conclusion: we have to clearly define what the requirements are. Regards, Benoit. --------------060409050501030602090901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Let's discuss the following situation: what if we have 2 NMS', and they speak different Power State Series for a specific Power Monitor? Should this be allowed by the [EMAN-REQ]?

Tentative definitions for Power States Series and Power State are defined below. They should help the discussion (further discussion on these definitions will have to take place in the future):

Power State Series

 

A Power State Series is defined as a well known sequence of incremental energy saving modes of a device.  This can be viewed as an interface for the underlying device-implemented power settings. Examples include DTMF, ACPI, etc...

Power State

A Power State is a uniform way to classify power settings on a Power Monitor (e.g., shut, hibernate, sleep, high).  The Power State is composed of a Power State Series and a specific state within the series.



Actually this requirement has got some implications in terms of the MIB design (taking http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07 into account)
 
- If the answer is yes, then we need to have an extra index in the power pmPowerTable. This index must abe a new TC, which is only for the Power State Series.  Note: the table needs to redesigned because the common variable (caliber, nameplate, etc…) are common per Power State Series. Then we can have a new table, for discovery, that will only contain  two indices: pmPowerMonitorIndex and the new TC-defined pmPowerStateSeries.
- If the answer is no, then there is the risk that NMS1 will set the DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the Power Monitor supports both the DMTF and the EMAN Power State Series), and there is a ping-pong game between two NMS's that don't synchronize between the two.

The alternative is that the first NMS would say: I will speak to the Power Monitor with the DMTF Power State Series, and then all the other NMS's will have to speak the same language (i.e. DMTF).

Somehow, the trade-off is the following:
- We ease the live of the NMS (they can speak the "language" of their choice) at the cost of slight more complex MIB (one extra index)
- We ease the live of the Power Monitor by simplifying the MIB design.

Conclusion: we have to clearly define what the requirements are.

Regards, Benoit.
--------------060409050501030602090901-- From j.schoenwaelder@jacobs-university.de Tue May 3 02:29:08 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F7CE06E1 for ; Tue, 3 May 2011 02:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.165 X-Spam-Level: X-Spam-Status: No, score=-103.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6mLzn8Ojydm for ; Tue, 3 May 2011 02:29:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 16940E06AA for ; Tue, 3 May 2011 02:29:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63E5F20A01; Tue, 3 May 2011 11:29:03 +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 u4JjdIhuVs1S; Tue, 3 May 2011 11:29:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A450720979; Tue, 3 May 2011 11:29:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1603118585ED; Tue, 3 May 2011 11:28:55 +0200 (CEST) Date: Tue, 3 May 2011 11:28:55 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20110503092855.GA3772@elstar.local> Mail-Followup-To: Benoit Claise , eman mailing list References: <4DBFC56E.2020908@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DBFC56E.2020908@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] Two NMS configuring the Power Monitor with two different Power State Series X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 09:29:08 -0000 On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote: > Let's discuss the following situation: what if we have 2 NMS', and > they speak different Power State Series for a specific Power > Monitor? Should this be allowed by the [EMAN-REQ]? Traditionally, it was always assumed that an SNMP management system can more easily adapt to devices than the other way round. > Actually this requirement has got some implications in terms of the > MIB design (taking > http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07 > into account) > > - If the answer is yes, then we need to have an extra index in the > power pmPowerTable. This index must abe a new TC, which is only for > the Power State Series. Note: the table needs to redesigned because > the common variable (caliber, nameplate, etc...) are common per > Power State Series. Then we can have a new table, for discovery, > that will only contain two indices: pmPowerMonitorIndex and the new > TC-defined pmPowerStateSeries. > - If the answer is no, then there is the risk that NMS1 will set the > DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the > Power Monitor supports both the DMTF and the EMAN Power State > Series), and there is a ping-pong game between two NMS's that don't > synchronize between the two. If two management systems make changes without coordination, you always have a chance for ping-pong effects, even within a Power State Series. That said, it might be possible to provide guidelines such as if a device is reporting a value of a given Power State Series (e.g. DMTF:3), a management application should adapt and use DMTF power states. > The alternative is that the first NMS would say: I will speak to the > Power Monitor with the DMTF Power State Series, and then all the > other NMS's will have to speak the same language (i.e. DMTF). I think that is a reasonably assumption to make if the number of different Power State Series is kept limited (that is we prevent that every vendor/organization comes up with its own creative series of power states). A large number of different Power State Series will be hindering interoperability, with or without ping-pong effects. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From moulchan@cisco.com Wed May 4 03:37:32 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E651E0727 for ; Wed, 4 May 2011 03:37: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QioPzWyz+tQd for ; Wed, 4 May 2011 03:37:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id D8C9CE073A for ; Wed, 4 May 2011 03:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=28992; q=dns/txt; s=iport; t=1304505445; x=1305715045; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=NXnNJMrTECZD+UMHXUoS0Z/md4dDlJjivmFR6fxv7dY=; b=j2aSRlr/YSSD1P33YtxUiICiGtUuFf9xx9Mhy0KV9Z6T6HPbrBQNjdEr RQw65qqcGZLe/3TjMaYBo8nggnZ0CzBBXALoD8Yx3dOEqhZey2G4MkFCQ DYvSHoqsObt29Tu7opCctWJ7nDd+W5kKiFp/uWt6Kp1+qEMDATHds3YSm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8BAPErwU2tJXG+/2dsb2JhbACCYZUojg53pgKeJ4YHBIYvjSuKMw X-IronPort-AV: E=Sophos;i="4.64,313,1301875200"; d="scan'208,217";a="441425459" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 04 May 2011 10:37:24 +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 p44AbOpt027909; Wed, 4 May 2011 10:37:24 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, 4 May 2011 05:37:24 -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_01CC0A47.41322C5E" Date: Wed, 4 May 2011 05:37:20 -0500 Message-ID: In-Reply-To: <0B4397E7-292C-43ED-8904-D87B3CE49381@quittek.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] I-D Action:draft-ietf-eman-battery-mib-00.txt Thread-Index: Acv2DmAhTcPCf+V8TjC/5KIHTVicFwUNOh4w References: <20110408164501.12446.19644.idtracker@localhost> <0B4397E7-292C-43ED-8904-D87B3CE49381@quittek.at> From: "Mouli Chandramouli (moulchan)" To: "Juergen Quittek" , X-OriginalArrivalTime: 04 May 2011 10:37:24.0261 (UTC) FILETIME=[415F1D50:01CC0A47] Subject: Re: [eman] I-D Action:draft-ietf-eman-battery-mib-00.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 10:37:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0A47.41322C5E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Here is a quick review of the battery MIB.=20 =20 1. Firstly, given that the battery provides backup power for a device and there should be a reference (index) to the device for which the battery is providing back-up power.=20 Otherwise, the MIB module seems as a standalone in terms battery power monitoring for some device ?=20 =20 There is a link of the batteryIndex to the entPhysicalIndex ; where do you assume that the entityMIB implemented ? Note that entityMIB does not list battery as one of the entPhysicalClass.=20 =20 2. The reference to be updated. [I-D.ietf-eman-framework] "Claise, B., Parello, J., and L. Silver, "Energy Management Framework", draft-ietf-eman-framework-01 (work in progress), March 2011."=20 =20 =20 3. The context seems to be missing (some text needed) before the bullets=20 =20 o the current charge of a battery, o the age of a battery (charging cycles), o the state of a battery (e.g. being re-charged), o last usage of a battery, o maximum energy provided by a battery (remaining and total capacity). =20 4. A small nit is battery temperature - is this relevant for EMAN ? +-- r-n Integer32 batteryTemperature(14) =20 =20 5. First the name of the object can be renamed - batteryCurrentCurrent ? =20 Secondly, it is not clear, what is the purpose of this MIB object or the distinction between this object and batteryCurrentCharge ? =20 6. The notion of batteryType - primary (not being rechargeable) is confusing - and the secondary Is only rechargeable ? =20 How would the batteryChargingstate be reflected for a primary battery ? Will a primary battery be charged when it is drained out ?=20 =20 Thanks Mouli =20 =20 From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek Sent: Friday, April 08, 2011 10:30 PM To: eman@ietf.org list Subject: Re: [eman] I-D Action:draft-ietf-eman-battery-mib-00.txt =20 Dear all, =20 As you can see from the previous posting, we now have a WG draft on the battery MIB.=20 =20 It is a revision of draft-quittek-eman-batter-mib-00. Changes are based on comments received as four reviews on the mailing list and at our session in Prague. Please find a summary of all changes at the end of this message.=20 =20 I look forward to your comments and questions on the new version. =20 And I would be grateful for proposals on how to solve the remaining open issues listed in Section 8. =20 Changes between draft-quittek-eman-battery-mib-00 and draft-ietf-eman-battery-mib-00 are: =20 - addressed relation to eman-framework - addressed monitoring of multiple batteries in a device - clarified that CMOS batteries are not explicitly in scope - change use of Entity MIB index from RECOMMENDED to REQUIRED - moved battery types from enumeration to IANA registration - this required some new text in new section 4 and in the IANA considerations - moved enumeration values 'unknown' and 'other' to the top of all enumerations - renamed batteryState to batteryChargingState - removed battery stated 'full' and 'empty' - mentioned that primary batteries are not re-chargeable - renamed batteryRemainingCapacity to batteryActualCapacity - fixed data types o some managed objects - added object batteryTemperature - removed object batteryCurrentChargePercentage - just using batteryCurrentCharge should be sufficient - changed object batteryLowAlarmPercentage to batteryLowAlarmCharge - changed MAX-ACCESS of all four objects with notifications thresholds from read-only to read-write - batteryLowAlarmCharge - batteryLowAlarmVoltage - batteryReplacementAlarmCapacity - atteryReplacementAlarmCycles - made implementation of batteryAlarmThresholdsGroup optional - fixed wrong group names in compliance statements - removed all old open issues except "Define Charging Cycle" - added new open issues - Writable Notification Thresholds - Re-arming batteryLowNotification - Add Charging Data of Batteries? - Add batteryHealth? - Battery Identifier =20 Thanks, =20 Juergen =20 =20 Am 08.04.2011 um 18:45 schrieb Internet-Drafts@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Energy Management Working Group of the IETF. Title : Definition of Managed Objects for Battery Monitoring Author(s) : J. Quittek, et al. Filename : draft-ietf-eman-battery-mib-00.txt Pages : 22 Date : 2011-04-08 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eman-battery-mib-00.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. _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman =20 ------_=_NextPart_001_01CC0A47.41322C5E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Here = is a quick review of the battery MIB.

 

1.      = Firstly,  given that the battery  provides backup power for a device and there should be a reference (index)  to the device  for which the battery is = providing back-up power.

Otherwise, the MIB module seems as a standalone in terms battery power monitoring = for some device ?

 

There is a link of the batteryIndex to the entPhysicalIndex ; where do you assume = that the entityMIB implemented ?   Note that entityMIB does not = list battery as one of the entPhysicalClass.

 

2.      = The reference to be updated. =   [I-D.ietf-eman-framework]   “Claise, B., Parello, J., and L. Silver, "Energy = Management  Framework", draft-ietf-eman-framework-01 (work in  progress), = March 2011.”

 

 

3.      = The context seems to be = missing  (some text needed) before the bullets

 

   o  the current charge of a battery,

   o  the age of a battery (charging cycles),

   o  the state of a battery (e.g. being = re-charged),

   o  last usage of a battery,

   o  maximum energy provided by a battery (remaining and = total

      capacity).

 

4.      = A small nit is battery = temperature – is this relevant for EMAN ?   +-- r-n = Integer32   batteryTemperature(14) 

 

5.      = First the name of the object = can be renamed - batteryCurrentCurrent  ? 

Secondly, it is not clear, what is the purpose of this MIB object or the = distinction between this object and batteryCurrentCharge ?

 

6.      = The notion of batteryType = – primary (not  being rechargeable) is confusing – and the = secondary Is  only rechargeable ?  

How would the batteryChargingstate be reflected for a primary battery  = ?  Will a primary battery be charged when it is drained out ? =

 

Thanks

Mouli

 

 

From:= eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Juergen Quittek
Sent: Friday, April 08, 2011 10:30 PM
To: eman@ietf.org list
Subject: Re: [eman] I-D = Action:draft-ietf-eman-battery-mib-00.txt

 

Dear all,

 

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

 <= /p>

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

 <= /p>

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

 <= /p>

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

 <= /p>

Changes between draft-quittek-eman-battery-mib-00

and draft-ietf-eman-battery-mib-00 are:

 <= /p>

  - addressed relation to eman-framework

  - addressed monitoring of multiple batteries in a = device

  - clarified that CMOS batteries are not explicitly in = scope

  - change use of Entity MIB index from RECOMMENDED to = REQUIRED

  - moved battery types from enumeration to IANA = registration

      - this required some new text in new section 4 and = in

        the IANA considerations

  - moved enumeration values 'unknown' and 'other' to the = top

    of all enumerations

  - renamed batteryState to batteryChargingState

  - removed battery stated 'full' and 'empty'

  - mentioned that primary batteries are not = re-chargeable

  - renamed batteryRemainingCapacity to = batteryActualCapacity

  - fixed data types o some managed objects

  - added object batteryTemperature

  - removed object batteryCurrentChargePercentage

      - just using batteryCurrentCharge should be = sufficient

  - changed object batteryLowAlarmPercentage to

    batteryLowAlarmCharge

  - changed MAX-ACCESS of all four objects with = notifications

    thresholds from read-only to read-write

      - batteryLowAlarmCharge

      - batteryLowAlarmVoltage

      - batteryReplacementAlarmCapacity

      - atteryReplacementAlarmCycles

  - made implementation of batteryAlarmThresholdsGroup = optional

  - fixed wrong group names in compliance statements

  - removed all old open issues except "Define Charging = Cycle"

  - added new open issues

      - Writable Notification Thresholds

      - Re-arming batteryLowNotification

      - Add Charging Data of Batteries?

      - Add batteryHealth?

      - Battery Identifier

 <= /p>

Thanks,=

 <= /p>

    Juergen

 <= /p>

 <= /p>

Am 08.04.2011 um 18:45 schrieb Internet-Drafts@ietf.org:



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


        &n= bsp;   Title           : Definition = of Managed Objects for Battery Monitoring
        &n= bsp;   Author(s)       : J. Quittek, et al.
        &n= bsp;   Filename        : = draft-ietf-eman-battery-mib-00.txt
        &n= bsp;   Pages           : 22
        &n= bsp;   Date            : = 2011-04-08

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

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

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

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

 

------_=_NextPart_001_01CC0A47.41322C5E-- From duanxiaoling@huawei.com Wed May 11 18:35:30 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBA2E08A4 for ; Wed, 11 May 2011 18:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kds7RnNtGpTg for ; Wed, 11 May 2011 18:35:29 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4B9E0873 for ; Wed, 11 May 2011 18:35:29 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200B9Y73419@szxga04-in.huawei.com> for eman@ietf.org; Thu, 12 May 2011 09:35:28 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200BH2734P8@szxga04-in.huawei.com> for eman@ietf.org; Thu, 12 May 2011 09:35:28 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 09:35:19 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.9.178]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Thu, 12 May 2011 09:35:28 +0800 Date: Thu, 12 May 2011 01:35:26 +0000 From: Duanxiaoling X-Originating-IP: [10.70.38.155] To: "bclaise@cisco.com" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5mw+Ywd9N/seb1S9nbsphQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: two questions to draft-claise-power-management-arch-02 draft Thread-index: AQHMEEGPY+x/sA54z0abzWr6eayCaA== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: eman mailing list Subject: [eman] two questions to draft-claise-power-management-arch-02 draft X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 01:35:30 -0000 --Boundary_(ID_5mw+Ywd9N/seb1S9nbsphQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT 1,The protocol between NMS and device is SNMP, but how about other protocol, such as FTP, TL1 or Qx ? Is these protocol prohibited or out of eman's scope? Now lots of SDH, MSTP devices is managed by NMS in protocol Qx or TL1. Also, lots of core network device is managed by NMS in protocol MML, and so on. Will our draft fit for these devices(wireless device, core network device, transfer device )? 2,The power level is defind in the draft is [0...12], how will we use it? All device must have all the power level? or different NE can select different part of them. For example, A can select [0...7], B can select [8,10,12], and so on. How about other memeber's thought? best regards! email:duanxiaoling@huawei.com Phone number:+086-0755-13751010110 ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** --Boundary_(ID_5mw+Ywd9N/seb1S9nbsphQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT

1,The protocol between NMS and device is SNMP, but how about other protocol, such as FTP, TL1 or Qx ?  Is these protocol prohibited  or out of eman's scope?  Now lots of SDH, MSTP devices is managed by NMS in protocol Qx or TL1. Also, lots of core network device is  managed by NMS in protocol MML, and so on.  Will our draft fit for these devices(wireless device, core network device, transfer device )?

2,The power level is defind in the draft is [0...12], how will we use it? All device must have all the power level? or different NE can select different part of them. For example, A can select [0...7], B can select [8,10,12], and so on.

 

How about other memeber's thought?

 

best regards!
email:duanxiaoling@huawei.com
Phone number:+086-0755-13751010110
******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************
 
--Boundary_(ID_5mw+Ywd9N/seb1S9nbsphQ)-- From bschoening@noveda.com Thu May 12 14:18:42 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54D7E0694 for ; Thu, 12 May 2011 14:18:42 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRK7N7A17zNh for ; Thu, 12 May 2011 14:18:40 -0700 (PDT) Received: from cal3-mh481-a.smtproutes.com (cal3-mh481-a.smtproutes.com [208.70.89.235]) by ietfa.amsl.com (Postfix) with ESMTP id D13ABE066E for ; Thu, 12 May 2011 14:18:40 -0700 (PDT) X-Katharion-ID: 1305235093.29283.cal3-mh481 Received: from ex01.noveda.com ([66.198.105.170]) by cal3-mh481.smtproutes.com [(208.70.89.155)] with ESMTP via TCP; 12 May 2011 14:18:13 -0700 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Thu, 12 May 2011 17:18:13 -0400 From: Brad Schoening To: Duanxiaoling , "bclaise@cisco.com" Thread-Topic: [eman] two questions to draft-claise-power-management-arch-02 draft Thread-Index: AQHMEEGPY+x/sA54z0abzWr6eayCaJSJrbsA Date: Thu, 12 May 2011 21:18:09 +0000 Message-ID: <22B2909DCC2E62418BE369A1F104889937A00FA0@ex01.noveda.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_22B2909DCC2E62418BE369A1F104889937A00FA0ex01novedacom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] two questions to draft-claise-power-management-arch-02 draft X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 21:18:42 -0000 --_000_22B2909DCC2E62418BE369A1F104889937A00FA0ex01novedacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, the EMAN data model uses the Simple Network Management Protocol (SNMP)= . Our draft management information base (MIB) inherits data types and text= ual conventions from the SNMP standard. It's not really adaptable to other= protocols that don't support SNMP data types. There is no standard data format for FTP, hence its not useful by itself as= a data transfer protocol without another layer of interpretation such as a= n XML schema or CSV format. As for the other protocols you mention, they s= eem to be domain specific, but I'm not familiar with them. Regards, Brad Schoening From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Dua= nxiaoling Sent: Wednesday, May 11, 2011 9:35 PM To: bclaise@cisco.com Cc: eman mailing list Subject: [eman] two questions to draft-claise-power-management-arch-02 draf= t 1,The protocol between NMS and device is SNMP, but how about other protocol= , such as FTP, TL1 or Qx ? Is these protocol prohibited or out of eman's = scope? Now lots of SDH, MSTP devices is managed by NMS in protocol Qx or T= L1. Also, lots of core network device is managed by NMS in protocol MML, a= nd so on. Will our draft fit for these devices(wireless device, core netwo= rk device, transfer device )? 2,The power level is defind in the draft is [0...12], how will we use it? A= ll device must have all the power level? or different NE can select differe= nt part of them. For example, A can select [0...7], B can select [8,10,12],= and so on. How about other memeber's thought? best regards! email:duanxiaoling@huawei.com Phone number:+086-0755-13751010110 ***************************************************************************= *************** This email and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, b= ut not limited to, total or partial disclosure, reproduction, or disseminat= ion) by persons other than the intended recipient(s) is prohibited. If you = receive this e-mail in error, please notify the sender by phone or email im= mediately and delete it! **************************************************************************= *************** --_000_22B2909DCC2E62418BE369A1F104889937A00FA0ex01novedacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, the = EMAN data model uses the Simple Network Management Protocol (SNMP).  O= ur draft management information base (MIB) inherits data types and textual = conventions from the SNMP standard.  It’s not really adaptable t= o other protocols that don’t support SNMP data types.

 

There is no standard data format for FTP, hence its not use= ful by itself as a data transfer protocol without another layer of interpre= tation such as an XML schema or CSV format.  As for the other protocol= s you mention, they seem to be domain specific, but I’m not familiar = with them.

 

Regards,

 

Brad Schoening

 

From: eman-bounc= es@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Duanxiaoling=
Sent: Wednesday, May 11, 2011 9:35 PM
To: bclaise@cisc= o.com
Cc: eman mailing list
Subject: [eman] two questio= ns to draft-claise-power-management-arch-02 draft

 

1,The p= rotocol between NMS and device is SNMP, but how about o= ther protocol, such as FTP, TL1 or Qx ?  Is these protocol prohib= ited  or out of eman's scope?  Now lots of SDH, MSTP de= vices is managed by NMS in protocol Qx or TL1. Also, lots of=  core network device is  managed by NMS in protoco= l MML, and so on.  Will our draft fit for these devices(wireless devic= e, core network device, transfer device )?

2,The power level is defind in the draft is [0...12], how will we use it? = All device must have all the power level? or different NE can select d= ifferent part of them. For example, A can select [0...7], B can select [8,1= 0,12], and so on.

 

<= p>How about other memeber's thought?

 

best regar= ds!
email:duanxiaoling@huawei.com

Phone number:+086-0755-13751010110
******************= ************************************************************************ This email and its attachments contain confidential information from= HUAWEI, which is intended only for the person or entity whose address is l= isted above. Any use of the information contained herein in any way (includ= ing, but not limited to, total or partial disclosure, reproduction, or diss= emination) by persons other than the intended recipient(s) is prohibited. I= f you receive this e-mail in error, please notify the sender by phone or em= ail immediately and delete it!
 ***********************************= ******************************************************
 

= --_000_22B2909DCC2E62418BE369A1F104889937A00FA0ex01novedacom_-- From fletchj@us.ibm.com Thu May 12 15:04:08 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0D1E0674 for ; Thu, 12 May 2011 15:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh9+xv-q-G0b for ; Thu, 12 May 2011 15:04:07 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id A860813000E for ; Thu, 12 May 2011 15:04:07 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4CLwFX2030597 for ; Thu, 12 May 2011 15:58:15 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p4CM3R1t139332 for ; Thu, 12 May 2011 16:03:37 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4CG3EOs016871 for ; Thu, 12 May 2011 10:03:14 -0600 Received: from d03nm120.boulder.ibm.com (d03nm120.boulder.ibm.com [9.17.195.146]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4CG3DxJ016777 for ; Thu, 12 May 2011 10:03:14 -0600 Auto-Submitted: auto-generated From: Jim Fletcher To: eman@ietf.org Message-ID: Date: Thu, 12 May 2011 16:03:13 -0600 X-MIMETrack: Serialize by Router on D03NM120/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/12/2011 16:03:13 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF21DDFEAA2768f9e8a93df938690918c08BBF21DDFEAA276" Content-Disposition: inline Subject: [eman] AUTO: Jim fletcher is out of the office on vacation with minimal email or cell phone -- returning Friday afternoon May 13 (returning 05/13/2011) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 22:04:08 -0000 --0__=08BBF21DDFEAA2768f9e8a93df938690918c08BBF21DDFEAA276 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 05/13/2011. for technical issues see my team and for management issues see Jim Cros= skey -- if needed call my cell and leave voicemail Note: This is an automated response to your message "eman Digest, Vol = 10, Issue 4" sent on 5/12/11 13:00:05. This is the only notification you will receive while this person is awa= y.= --0__=08BBF21DDFEAA2768f9e8a93df938690918c08BBF21DDFEAA276 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 05/13/2011.

for technical issues see my team and for manage= ment issues see Jim Crosskey -- if needed call my cell and leave voicem= ail


Note: This is an automated re= sponse to your message "eman Digest, V= ol 10, Issue 4" sent= on 5/12/11 13:00:05.

This is the only notification= you will receive while this person is away.= --0__=08BBF21DDFEAA2768f9e8a93df938690918c08BBF21DDFEAA276-- From duanxiaoling@huawei.com Tue May 17 19:03:28 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A669EE06D7 for ; Tue, 17 May 2011 19:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=-3.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2cRRN1b9aoj for ; Tue, 17 May 2011 19:03:27 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 37B27E0659 for ; Tue, 17 May 2011 19:03:27 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD006KXCDPWR@szxga04-in.huawei.com> for eman@ietf.org; Wed, 18 May 2011 10:03:26 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD002WLCDP1K@szxga04-in.huawei.com> for eman@ietf.org; Wed, 18 May 2011 10:03:25 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 18 May 2011 10:03:22 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.9.178]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Wed, 18 May 2011 10:03:25 +0800 Date: Wed, 18 May 2011 02:03:24 +0000 From: Duanxiaoling In-reply-to: <22B2909DCC2E62418BE369A1F104889937A00FA0@ex01.noveda.com> X-Originating-IP: [10.70.38.155] To: Brad Schoening , "bclaise@cisco.com" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_854yuH7HCPlCRHwurJZ5uQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [eman] two questions to draft-claise-power-management-arch-02 draft Thread-index: AQHMEO1a21MqgtlGJUCnXUvvIxTvxJSR28ed X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <22B2909DCC2E62418BE369A1F104889937A00FA0@ex01.noveda.com> Cc: eman mailing list Subject: Re: [eman] two questions to draft-claise-power-management-arch-02 draft X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 02:03:28 -0000 --Boundary_(ID_854yuH7HCPlCRHwurJZ5uQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 VGhhbmtzIGZvciB5b3VyIGFuc3dlciENCg0KSSByZWNvZ25pemUgdGhhdCBvdGhlciBwcm90b2Nv bHMgYmVzaWRlcyBTTk1QIGFyZSBub3QgaW4gb3VyIHNjb3BlIGZyb20geW91ciBhbnN3ZXIuDQoN CkJ1dCBob3cgYWJvdXQgdGhlIHNlY29uZCBxdWVzdGlvbj8gV291bGQgeW91IGxpa2UgdG8gZ2l2 ZSB1cyBhbiBhbnN3ZXI/DQoNCg0KDQpUaGFua3MhDQoNCg0KDQoNCg0KYmVzdCByZWdhcmRzIQ0K bm90ZXM6ZHVhbnhpYW9saW5nIDAwMTYwNjYyQG5vdGVzbWFpbC5odWF3ZWkuY29tDQpQaG9uZSBu dW1iZXI6MTM3NTEwMTAxMTANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KIFRo aXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBv ciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90 IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBv ciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lw aWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5 IGFuZCBkZWxldGUgaXQhDQogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogQnJhZCBTY2hvZW5pbmcgW2Jz Y2hvZW5pbmdAbm92ZWRhLmNvbV0NCreiy83KsbzkOiAyMDExxOo11MIxM8jVIDU6MTgNCrW9OiBE dWFueGlhb2xpbmc7IGJjbGFpc2VAY2lzY28uY29tDQpDYzogZW1hbiBtYWlsaW5nIGxpc3QNCtb3 zOI6IFJFOiBbZW1hbl0gdHdvIHF1ZXN0aW9ucyB0byBkcmFmdC1jbGFpc2UtcG93ZXItbWFuYWdl bWVudC1hcmNoLTAyIGRyYWZ0DQoNClllcywgdGhlIEVNQU4gZGF0YSBtb2RlbCB1c2VzIHRoZSBT aW1wbGUgTmV0d29yayBNYW5hZ2VtZW50IFByb3RvY29sIChTTk1QKS4gIE91ciBkcmFmdCBtYW5h Z2VtZW50IGluZm9ybWF0aW9uIGJhc2UgKE1JQikgaW5oZXJpdHMgZGF0YSB0eXBlcyBhbmQgdGV4 dHVhbCBjb252ZW50aW9ucyBmcm9tIHRoZSBTTk1QIHN0YW5kYXJkLiAgSXShr3Mgbm90IHJlYWxs eSBhZGFwdGFibGUgdG8gb3RoZXIgcHJvdG9jb2xzIHRoYXQgZG9uoa90IHN1cHBvcnQgU05NUCBk YXRhIHR5cGVzLg0KDQpUaGVyZSBpcyBubyBzdGFuZGFyZCBkYXRhIGZvcm1hdCBmb3IgRlRQLCBo ZW5jZSBpdHMgbm90IHVzZWZ1bCBieSBpdHNlbGYgYXMgYSBkYXRhIHRyYW5zZmVyIHByb3RvY29s IHdpdGhvdXQgYW5vdGhlciBsYXllciBvZiBpbnRlcnByZXRhdGlvbiBzdWNoIGFzIGFuIFhNTCBz Y2hlbWEgb3IgQ1NWIGZvcm1hdC4gIEFzIGZvciB0aGUgb3RoZXIgcHJvdG9jb2xzIHlvdSBtZW50 aW9uLCB0aGV5IHNlZW0gdG8gYmUgZG9tYWluIHNwZWNpZmljLCBidXQgSaGvbSBub3QgZmFtaWxp YXIgd2l0aCB0aGVtLg0KDQpSZWdhcmRzLA0KDQpCcmFkIFNjaG9lbmluZw0KDQpGcm9tOiBlbWFu LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplbWFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBEdWFueGlhb2xpbmcNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDExLCAyMDExIDk6MzUgUE0N ClRvOiBiY2xhaXNlQGNpc2NvLmNvbQ0KQ2M6IGVtYW4gbWFpbGluZyBsaXN0DQpTdWJqZWN0OiBb ZW1hbl0gdHdvIHF1ZXN0aW9ucyB0byBkcmFmdC1jbGFpc2UtcG93ZXItbWFuYWdlbWVudC1hcmNo LTAyIGRyYWZ0DQoNCg0KMSxUaGUgcHJvdG9jb2wgYmV0d2VlbiBOTVMgYW5kIGRldmljZSBpcyBT Tk1QLCBidXQgaG93IGFib3V0IG90aGVyIHByb3RvY29sLCBzdWNoIGFzIEZUUCwgVEwxIG9yIFF4 ID8gIElzIHRoZXNlIHByb3RvY29sIHByb2hpYml0ZWQgIG9yIG91dCBvZiBlbWFuJ3Mgc2NvcGU/ ICBOb3cgbG90cyBvZiBTREgsIE1TVFAgZGV2aWNlcyBpcyBtYW5hZ2VkIGJ5IE5NUyBpbiBwcm90 b2NvbCBReCBvciBUTDEuIEFsc28sIGxvdHMgb2YgY29yZSBuZXR3b3JrIGRldmljZSBpcyAgbWFu YWdlZCBieSBOTVMgaW4gcHJvdG9jb2wgTU1MLCBhbmQgc28gb24uICBXaWxsIG91ciBkcmFmdCBm aXQgZm9yIHRoZXNlIGRldmljZXMod2lyZWxlc3MgZGV2aWNlLCBjb3JlIG5ldHdvcmsgZGV2aWNl LCB0cmFuc2ZlciBkZXZpY2UgKT8NCg0KMixUaGUgcG93ZXIgbGV2ZWwgaXMgZGVmaW5kIGluIHRo ZSBkcmFmdCBpcyBbMC4uLjEyXSwgaG93IHdpbGwgd2UgdXNlIGl0PyBBbGwgZGV2aWNlIG11c3Qg aGF2ZSBhbGwgdGhlIHBvd2VyIGxldmVsPyBvciBkaWZmZXJlbnQgTkUgY2FuIHNlbGVjdCBkaWZm ZXJlbnQgcGFydCBvZiB0aGVtLiBGb3IgZXhhbXBsZSwgQSBjYW4gc2VsZWN0IFswLi4uN10sIEIg Y2FuIHNlbGVjdCBbOCwxMCwxMl0sIGFuZCBzbyBvbi4NCg0KDQoNCkhvdyBhYm91dCBvdGhlciBt ZW1lYmVyJ3MgdGhvdWdodD8NCg0KDQpiZXN0IHJlZ2FyZHMhDQplbWFpbDpkdWFueGlhb2xpbmdA aHVhd2VpLmNvbQ0KUGhvbmUgbnVtYmVyOiswODYtMDc1NS0xMzc1MTAxMDExMA0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQogVGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRz IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCBpcyBp bnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxp c3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBp biBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlh bCBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMg b3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlv dSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCiAqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KDQo= --Boundary_(ID_854yuH7HCPlCRHwurJZ5uQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Thanks for your answer!

I recognize that other protocols besides SNMP are not in our scope from = your answer.

But how about the second question? Would you like to give us an answer?<= /p>

 

Thanks!

 

 

best regards!
notes:duanxiaoling 00160662@notesmail.huawei.com
Phone number:13751010110
***************************************************************************= ***************
 This email and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is li= sted above. Any use of the information contained herein in any way (includi= ng, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the inte= nded recipient(s) is prohibited. If you receive this e-mail in error, pleas= e notify the sender by phone or email immediately and delete it!
 *********************************************************************= ********************
 
=B7=A2=BC=FE=C8=CB: Brad Schoening [bschoe= ning@noveda.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C213=C8=D5 5:18
=B5=BD: Duanxiaoling; bclaise@cisco.com
Cc: eman mailing list
=D6=F7=CC=E2: RE: [eman] two questions to draft-claise-power-managem= ent-arch-02 draft

Yes, the EMAN data model uses the Simple N= etwork Management Protocol (SNMP).  Our draft management information b= ase (MIB) inherits data types and textual conventions from the SNMP standard.  It=A1=AFs not really adaptable t= o other protocols that don=A1=AFt support SNMP data types.

 

There is no standard data format for FTP, = hence its not useful by itself as a data transfer protocol without another = layer of interpretation such as an XML schema or CSV format.  As for the other protocols you mention, they s= eem to be domain specific, but I=A1=AFm not familiar with them.

 

Regards,

 

Brad Schoening

 

From: eman-bounces@ietf.org [mailto:eman-bounces@iet= f.org] On Behalf Of Duanxiaoling
Sent: Wednesday, May 11, 2011 9:35 PM
To: bclaise@cisco.com
Cc: eman mailing list
Subject: [eman] two questions to draft-claise-power-management-arch-= 02 draft

 

1,The protocol between NMS and device is SNMP, but = ;how about other protocol, such as FTP, TL1 or Qx ?  Is thes= e protocol prohibited  or out of eman's scope?  Now lot= s of SDH, MSTP devices is managed by NMS in protocol Qx or TL1. Also,= lots of core network device is  managed by NMS in= protocol MML, and so on.  Will our draft fit for these devices(wirele= ss device, core network device, transfer device )?

2,The power level is defind in the draft is [0...12], how will we= use it? All device must have all the power level? or different NE can= select different part of them. For example, A can select [0...7], B can select [8,10,12], and so on.

 

How about other memeber's thought?

 

best regards!
email:duanxiaoling@huawei.com

Phone number:+086-0755-13751010110
***************************************************************************= ***************
 This email and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is li= sted above. Any use of the information contained herein in any way (includi= ng, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the inte= nded recipient(s) is prohibited. If you receive this e-mail in error, pleas= e notify the sender by phone or email immediately and delete it!
 *********************************************************************= ********************
 

--Boundary_(ID_854yuH7HCPlCRHwurJZ5uQ)-- From bschoening@noveda.com Tue May 17 19:38:45 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E891DE06F0 for ; Tue, 17 May 2011 19:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[AWL=-3.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r471Qo2F5ZFA for ; Tue, 17 May 2011 19:38:45 -0700 (PDT) Received: from cal3-mh481-a.smtproutes.com (cal3-mh481-a.smtproutes.com [208.70.89.235]) by ietfa.amsl.com (Postfix) with ESMTP id DACCFE0696 for ; Tue, 17 May 2011 19:38:44 -0700 (PDT) X-Katharion-ID: 1305686304.29619.cal3-mh481 Received: from ex01.noveda.com ([66.198.105.170]) by cal3-mh481.smtproutes.com [(208.70.89.155)] with ESMTP via TCP; 17 May 2011 19:38:24 -0700 Received: from EX01.noveda.com ([::1]) by ex01.noveda.com ([::1]) with mapi; Tue, 17 May 2011 22:38:23 -0400 From: Brad Schoening To: Duanxiaoling , "bclaise@cisco.com" Thread-Topic: [eman] two questions to draft-claise-power-management-arch-02 draft Thread-Index: AQHMEEGPY+x/sA54z0abzWr6eayCaJSJrbsAgAh0WQD//8EdoA== Date: Wed, 18 May 2011 02:38:21 +0000 Message-ID: <22B2909DCC2E62418BE369A1F104889937A033BA@ex01.noveda.com> References: <22B2909DCC2E62418BE369A1F104889937A00FA0@ex01.noveda.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_22B2909DCC2E62418BE369A1F104889937A033BAex01novedacom_" MIME-Version: 1.0 Cc: eman mailing list Subject: Re: [eman] two questions to draft-claise-power-management-arch-02 draft X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 02:38:46 -0000 --_000_22B2909DCC2E62418BE369A1F104889937A033BAex01novedacom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIHBvd2VyIGxldmVscyBhcmUgZGVzaWduZWQgdG8gYmUgc3BhcnNlLiAgIFNvLCB5b3VyIHBs YXRmb3JtIGNhbiBpbXBsZW1lbnQgdGhvc2UgRU1BTiBsZXZlbHMgMS4uMTIgd2hpY2ggbWFkZSBz ZW5zZSBmb3IgaXQuICBGaWd1cmUgNiBvZiB0aGUgRU1BTiBGcmFtZXdvcmsgdi0wMSBnaXZlcyBh biBleGFtcGxlIG9mIHRoaXMgbWFwcGluZyB0byBhIGRldmljZSBzdXBwb3J0aW5nIGZvdXIgZmlj dGl0aW91cyBwb3dlciBzdGF0ZXM6DQoNCiAgICAgICAgICAgICAgUG93ZXIgU3RhdGUgLyBOYW1l ICAgICAgIE1hbnVmYWN0dXJlciBQb3dlciBTdGF0ZSAvIE5hbWUNCiAgICAgICAgICAgICAgIDEg LyBNZWNoIE9mZiAgICAgICAgICAgICAwIC8gbm9uZQ0KICAgICAgICAgICAgICAgMiAvIFNvZnQg T2ZmICAgICAgICAgICAgIDAgLyBub25lDQogICAgICAgICAgICAgICAzIC8gSGliZXJuYXRlICAg ICAgICAgICAgMCAvIG5vbmUNCiAgICAgICAgICAgICAgIDQgLyBTbGVlcCwgU2F2ZS10by1SQU0g ICAwIC8gbm9uZQ0KICAgICAgICAgICAgICAgNSAvIFN0YW5kYnkgICAgICAgICAgICAgIDAgLyBu b25lDQogICAgICAgICAgICAgICA2IC8gUmVhZHkgICAgICAgICAgICAgICAgMSAvIHNob3J0DQog ICAgICAgICAgICAgICA3IC8gTG93TWludXMgICAgICAgICAgICAgMSAvIHNob3J0DQogICAgICAg ICAgICAgICA4IC8gTG93ICAgICAgICAgICAgICAgICAgMSAvIHNob3J0DQogICAgICAgICAgICAg ICA5IC8gTWVkaXVtTWludXMgICAgICAgICAgMiAvIHRhbGwNCiAgICAgICAgICAgICAgIDEwIC8g TWVkaXVtICAgICAgICAgICAgICAyIC8gdGFsbA0KICAgICAgICAgICAgICAgMTEgLyBIaWdoTWlu dXMgICAgICAgICAgIDMgLyBncmFuZGUNCiAgICAgICAgICAgICAgIDEyIC8gSGlnaCAgICAgICAg ICAgICAgICA0IC8gdmVudGkNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNjog TWFwcGluZyBFeGFtcGxlIDMNCg0KVGhpcyBpcyBzaW1pbGFyIHRvIHRoZSBETVRGIGFuZCBBQ1BJ IG1vZGVscyB3aGljaCBkZWZpbmUgbWFueSBzdGF0ZXMsIGJ1dCBkZXZpY2VzIGFyZSBub3QgcmVx dWlyZWQgdG8gaW1wbGVtZW50IHRoZW0gYWxsLg0KDQpSZWZlcmVuY2U6DQoNCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZW1hbi1mcmFtZXdvcmstMDENCg0KRnJvbTogRHVh bnhpYW9saW5nIFttYWlsdG86ZHVhbnhpYW9saW5nQGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5 LCBNYXkgMTcsIDIwMTEgMTA6MDMgUE0NClRvOiBCcmFkIFNjaG9lbmluZzsgYmNsYWlzZUBjaXNj by5jb20NCkNjOiBlbWFuIG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IFtlbWFuXSB0d28gcXVl c3Rpb25zIHRvIGRyYWZ0LWNsYWlzZS1wb3dlci1tYW5hZ2VtZW50LWFyY2gtMDIgZHJhZnQNCg0K DQpUaGFua3MgZm9yIHlvdXIgYW5zd2VyIQ0KDQpJIHJlY29nbml6ZSB0aGF0IG90aGVyIHByb3Rv Y29scyBiZXNpZGVzIFNOTVAgYXJlIG5vdCBpbiBvdXIgc2NvcGUgZnJvbSB5b3VyIGFuc3dlci4N Cg0KQnV0IGhvdyBhYm91dCB0aGUgc2Vjb25kIHF1ZXN0aW9uPyBXb3VsZCB5b3UgbGlrZSB0byBn aXZlIHVzIGFuIGFuc3dlcj8NCg0KDQoNClRoYW5rcyENCg0KDQoNCg0KYmVzdCByZWdhcmRzIQ0K bm90ZXM6ZHVhbnhpYW9saW5nIDAwMTYwNjYyQG5vdGVzbWFpbC5odWF3ZWkuY29tDQpQaG9uZSBu dW1iZXI6MTM3NTEwMTAxMTANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KIFRo aXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBv ciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90 IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBv ciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lw aWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5 IGFuZCBkZWxldGUgaXQhDQogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogQnJhZCBTY2hvZW5pbmcgW2Jz Y2hvZW5pbmdAbm92ZWRhLmNvbV0NCreiy83KsbzkOiAyMDExxOo11MIxM8jVIDU6MTgNCrW9OiBE dWFueGlhb2xpbmc7IGJjbGFpc2VAY2lzY28uY29tDQpDYzogZW1hbiBtYWlsaW5nIGxpc3QNCtb3 zOI6IFJFOiBbZW1hbl0gdHdvIHF1ZXN0aW9ucyB0byBkcmFmdC1jbGFpc2UtcG93ZXItbWFuYWdl bWVudC1hcmNoLTAyIGRyYWZ0DQpZZXMsIHRoZSBFTUFOIGRhdGEgbW9kZWwgdXNlcyB0aGUgU2lt cGxlIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbCAoU05NUCkuICBPdXIgZHJhZnQgbWFuYWdl bWVudCBpbmZvcm1hdGlvbiBiYXNlIChNSUIpIGluaGVyaXRzIGRhdGEgdHlwZXMgYW5kIHRleHR1 YWwgY29udmVudGlvbnMgZnJvbSB0aGUgU05NUCBzdGFuZGFyZC4gIEl0oa9zIG5vdCByZWFsbHkg YWRhcHRhYmxlIHRvIG90aGVyIHByb3RvY29scyB0aGF0IGRvbqGvdCBzdXBwb3J0IFNOTVAgZGF0 YSB0eXBlcy4NCg0KVGhlcmUgaXMgbm8gc3RhbmRhcmQgZGF0YSBmb3JtYXQgZm9yIEZUUCwgaGVu Y2UgaXRzIG5vdCB1c2VmdWwgYnkgaXRzZWxmIGFzIGEgZGF0YSB0cmFuc2ZlciBwcm90b2NvbCB3 aXRob3V0IGFub3RoZXIgbGF5ZXIgb2YgaW50ZXJwcmV0YXRpb24gc3VjaCBhcyBhbiBYTUwgc2No ZW1hIG9yIENTViBmb3JtYXQuICBBcyBmb3IgdGhlIG90aGVyIHByb3RvY29scyB5b3UgbWVudGlv biwgdGhleSBzZWVtIHRvIGJlIGRvbWFpbiBzcGVjaWZpYywgYnV0IEmhr20gbm90IGZhbWlsaWFy IHdpdGggdGhlbS4NCg0KUmVnYXJkcywNCg0KQnJhZCBTY2hvZW5pbmcNCg0KRnJvbTogZW1hbi1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86ZW1hbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRHVhbnhpYW9saW5nDQpTZW50OiBXZWRuZXNkYXksIE1heSAxMSwgMjAxMSA5OjM1IFBNDQpU bzogYmNsYWlzZUBjaXNjby5jb20NCkNjOiBlbWFuIG1haWxpbmcgbGlzdA0KU3ViamVjdDogW2Vt YW5dIHR3byBxdWVzdGlvbnMgdG8gZHJhZnQtY2xhaXNlLXBvd2VyLW1hbmFnZW1lbnQtYXJjaC0w MiBkcmFmdA0KDQoNCjEsVGhlIHByb3RvY29sIGJldHdlZW4gTk1TIGFuZCBkZXZpY2UgaXMgU05N UCwgYnV0IGhvdyBhYm91dCBvdGhlciBwcm90b2NvbCwgc3VjaCBhcyBGVFAsIFRMMSBvciBReCA/ ICBJcyB0aGVzZSBwcm90b2NvbCBwcm9oaWJpdGVkICBvciBvdXQgb2YgZW1hbidzIHNjb3BlPyAg Tm93IGxvdHMgb2YgU0RILCBNU1RQIGRldmljZXMgaXMgbWFuYWdlZCBieSBOTVMgaW4gcHJvdG9j b2wgUXggb3IgVEwxLiBBbHNvLCBsb3RzIG9mIGNvcmUgbmV0d29yayBkZXZpY2UgaXMgIG1hbmFn ZWQgYnkgTk1TIGluIHByb3RvY29sIE1NTCwgYW5kIHNvIG9uLiAgV2lsbCBvdXIgZHJhZnQgZml0 IGZvciB0aGVzZSBkZXZpY2VzKHdpcmVsZXNzIGRldmljZSwgY29yZSBuZXR3b3JrIGRldmljZSwg dHJhbnNmZXIgZGV2aWNlICk/DQoNCjIsVGhlIHBvd2VyIGxldmVsIGlzIGRlZmluZCBpbiB0aGUg ZHJhZnQgaXMgWzAuLi4xMl0sIGhvdyB3aWxsIHdlIHVzZSBpdD8gQWxsIGRldmljZSBtdXN0IGhh dmUgYWxsIHRoZSBwb3dlciBsZXZlbD8gb3IgZGlmZmVyZW50IE5FIGNhbiBzZWxlY3QgZGlmZmVy ZW50IHBhcnQgb2YgdGhlbS4gRm9yIGV4YW1wbGUsIEEgY2FuIHNlbGVjdCBbMC4uLjddLCBCIGNh biBzZWxlY3QgWzgsMTAsMTJdLCBhbmQgc28gb24uDQoNCg0KDQpIb3cgYWJvdXQgb3RoZXIgbWVt ZWJlcidzIHRob3VnaHQ/DQoNCg0KYmVzdCByZWdhcmRzIQ0KZW1haWw6ZHVhbnhpYW9saW5nQGh1 YXdlaS5jb20NClBob25lIG51bWJlcjorMDg2LTA3NTUtMTM3NTEwMTAxMTANCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KIFRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBj b250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMgaW50 ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0 ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4g YW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwg ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90 aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5 IHBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQogKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCg0K --_000_22B2909DCC2E62418BE369A1F104889937A033BAex01novedacom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

The power= levels are designed to be sparse.   So, your platform can implem= ent those EMAN levels 1..12 which made sense for it.  Figure 6 of the = EMAN Framework v-01 gives an example of this mapping to a device supporting= four fictitious power states:

 

 &= nbsp;            Pow= er State / Name       Manufacturer Power Stat= e / Name

 &nbs= p;             = 1 / Mech Off          &nb= sp;  0 / none

=              &n= bsp; 2 / Soft Off         = ;    0 / none

           = ;    3 / Hibernate       =      0 / none

    &= nbsp;          5 / Standby&nbs= p;             = 0 / none

 &nbs= p;             = 6 / Ready           =      1 / short

          = ;     7 / LowMinus      &= nbsp;      1 / short

        =        8 / Low     &= nbsp;            1 /= short

  =              9 = / MediumMinus          2 / tal= l

   = ;            10 / Me= dium            = ;  2 / tall

&n= bsp;            = ;  11 / HighMinus         = ;  3 / grande

=             &nb= sp;  12 / High         &n= bsp;      4 / venti

    

<= p class=3DMsoNormal style=3D'page-break-before:always'>       = ;            &n= bsp;      Figure 6: Mapping Example 3

 

This is similar to the DMTF and ACPI models which de= fine many states, but devices are not required to implement them all.<= /o:p>

 

Reference:

 

http://tools.ietf.org/h= tml/draft-ietf-eman-framework-01

 

From:<= /b> Duan= xiaoling [mailto:duanxiaoling@huawei.com]
Sent: Tuesday, May 17,= 2011 10:03 PM
To: Brad Schoening; bclaise@cisco.com
Cc: eman mailing list
Subject: Re: [eman] two questions to draft-cl= aise-power-management-arch-02 draft

 

Thanks for your answer!

I recognize that other protocols besides SNMP are = not in our scope from your answer.

But how abou= t the second question? Would you like to give us an answer?

 

Thanks!

 

 <= /span>

best regards!
notes:duanxia= oling 00160662@notesmail.huawei.com
Phone number:13751010110
********= ***************************************************************************= *******
 This email and its attachments contain confidential inform= ation from HUAWEI, which is intended only for the person or entity whose ad= dress is listed above. Any use of the information contained herein in any w= ay (including, but not limited to, total or partial disclosure, reproductio= n, or dissemination) by persons other than the intended recipient(s) is pro= hibited. If you receive this e-mail in error, please notify the sender by p= hone or email immediately and delete it!
 *************************= ****************************************************************
 =

=B7= =A2=BC=FE=C8=CB: Brad Schoening [bschoenin= g@noveda.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4= =C213=C8=D5 5:18
=B5=BD: Duanxiaol= ing; bclaise@cisco.com
Cc: eman mailing list
=D6=F7=CC=E2<= b>: RE: [eman] two questions to draft-claise-power-manag= ement-arch-02 draft

Yes, the EMAN data model uses the Simple Network Management Protoco= l (SNMP).  Our draft management information base (MIB) inherits data t= ypes and textual conventions from the SNMP standard.  It=A1=AFs not re= ally adaptable to other protocols that don=A1=AFt support SNMP data types. =

 

There is no standard data format for FTP, hence its not useful = by itself as a data transfer protocol without another layer of interpretati= on such as an XML schema or CSV format.  As for the other protocols yo= u mention, they seem to be domain specific, but I=A1=AFm not familiar with = them.

 

Regards,

 

Brad Schoening

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org]= On Behalf Of Duanxiaoling
Sent: Wednesday, May 11, 2011 9= :35 PM
To: bclaise@cisco.com
Cc: eman mailing list
<= b>Subject: [eman] two questions to draft-claise-power-management-arch-0= 2 draft

 <= /p>

1,The protocol between NMS and device is SNMP= , but how about other protocol, such as FTP, TL1 or Qx ?&nbs= p; Is these protocol prohibited  or out of eman's scope?&nbs= p; Now lots of SDH, MSTP devices is managed by NMS in protoc= ol Qx or TL1. Also, lots of core network device is  managed&= nbsp;by NMS in protocol MML, and so on.  Will our draft fit for t= hese devices(wireless device, core network device, transfer device )?<= /span>

2,The power level is defind in the draft is [0...= 12], how will we use it? All device must have all the power level? or diffe= rent NE can select different part of them. For example, A can select [= 0...7], B can select [8,10,12], and so on.

 

How about other memeber's thought?

&nb= sp;

best regards!email:duanxiaoling@huawei.com

Phone number:+086-0755-137= 51010110
***************************************************************= ***************************
 This email and its attachments contain= confidential information from HUAWEI, which is intended only for the perso= n or entity whose address is listed above. Any use of the information conta= ined herein in any way (including, but not limited to, total or partial dis= closure, reproduction, or dissemination) by persons other than the intended= recipient(s) is prohibited. If you receive this e-mail in error, please no= tify the sender by phone or email immediately and delete it!
 *****= ***************************************************************************= *********
 

= --_000_22B2909DCC2E62418BE369A1F104889937A033BAex01novedacom_-- From panfengbin@huawei.com Tue May 17 20:28:38 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2094E0795 for ; Tue, 17 May 2011 20:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.449 X-Spam-Level: ** X-Spam-Status: No, score=2.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n88jDroGMnq for ; Tue, 17 May 2011 20:28:38 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1328AE0776 for ; Tue, 17 May 2011 20:28:38 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD006N6G8MST@szxga03-in.huawei.com> for eman@ietf.org; Wed, 18 May 2011 11:26:46 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD00BQRG8MZJ@szxga03-in.huawei.com> for eman@ietf.org; Wed, 18 May 2011 11:26:46 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 18 May 2011 11:26:42 +0800 Received: from SZXEML512-MBX.china.huawei.com ([169.254.11.29]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Wed, 18 May 2011 11:26:46 +0800 Date: Wed, 18 May 2011 03:26:45 +0000 From: Panfengbin In-reply-to: X-Originating-IP: [10.70.45.126] To: "eman@ietf.org" Message-id: <71FB630396E5014C95FF36BA7538581E0C37F5AE@szxeml512-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: eman Digest, Vol 10, Issue 6 Thread-index: AQHMFQTRuatRy9vywEqofh5JYGTbDZSR6VVk X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: [eman] =?gb2312?b?tPC4tDogZW1hbiBEaWdlc3QsIFZvbCAxMCwgSXNzdWUg?= =?gb2312?b?Ng==?= X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 03:28:38 -0000 U28sIGlmIHRoZXJlIGlzIG9ubHkgU05NUCwgbWFueSBlcXVpcG1lbnRzIGxpa2UgdHJhbnNwb3J0 ZXIgaW4gY29tbXVuaWNhdGlvbiBuZXR3b3JrIHdpbGwgbm90IGJlIG1hbmFnZWQsIGJlY2F1c2Ug aXQgYXBwbHkgUXggcHJvdG9jb2wuIE91ciB3b3JrIGFuZCBhaW0gIHdpbGwgYmUgYWJhdGVkIGxp a2VseS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjL OiBlbWFuLWJvdW5jZXNAaWV0Zi5vcmcgW2VtYW4tYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBlbWFu LXJlcXVlc3RAaWV0Zi5vcmcgW2VtYW4tcmVxdWVzdEBpZXRmLm9yZ10NCreiy83KsbzkOiAyMDEx xOo11MIxOMjVIDEwOjM4DQq1vTogZW1hbkBpZXRmLm9yZw0K1vfM4jogZW1hbiBEaWdlc3QsIFZv bCAxMCwgSXNzdWUgNg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGRpZ2VzdCB3aXRob3V0 IGFsbCB0aGUgaW5kaXZpZHVhbCBtZXNzYWdlDQphdHRhY2htZW50cyB5b3Ugd2lsbCBuZWVkIHRv IHVwZGF0ZSB5b3VyIGRpZ2VzdCBvcHRpb25zIGluIHlvdXIgbGlzdA0Kc3Vic2NyaXB0aW9uLiAg VG8gZG8gc28sIGdvIHRvDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZW1hbg0KDQpDbGljayB0aGUgJ1Vuc3Vic2NyaWJlIG9yIGVkaXQgb3B0aW9ucycgYnV0dG9uLCBs b2cgaW4sIGFuZCBzZXQgIkdldA0KTUlNRSBvciBQbGFpbiBUZXh0IERpZ2VzdHM/IiB0byBNSU1F LiAgWW91IGNhbiBzZXQgdGhpcyBvcHRpb24NCmdsb2JhbGx5IGZvciBhbGwgdGhlIGxpc3QgZGln ZXN0cyB5b3UgcmVjZWl2ZSBhdCB0aGlzIHBvaW50Lg0KDQoNCg0KU2VuZCBlbWFuIG1haWxpbmcg bGlzdCBzdWJtaXNzaW9ucyB0bw0KICAgICAgICBlbWFuQGlldGYub3JnDQoNClRvIHN1YnNjcmli ZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtYW4NCm9yLCB2aWEgZW1haWws IHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KICAgICAgICBl bWFuLXJlcXVlc3RAaWV0Zi5vcmcNCg0KWW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5n IHRoZSBsaXN0IGF0DQogICAgICAgIGVtYW4tb3duZXJAaWV0Zi5vcmcNCg0KV2hlbiByZXBseWlu ZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYw0K dGhhbiAiUmU6IENvbnRlbnRzIG9mIGVtYW4gZGlnZXN0Li4uIg== From panfengbin@huawei.com Tue May 17 20:57:54 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0598DE07CB for ; Tue, 17 May 2011 20:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.449 X-Spam-Level: ** X-Spam-Status: No, score=2.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAwO2dra4Mml for ; Tue, 17 May 2011 20:57:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4240CE0795 for ; Tue, 17 May 2011 20:57:53 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD00434HOERN@szxga04-in.huawei.com> for eman@ietf.org; Wed, 18 May 2011 11:57:51 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD00KVUHOEFV@szxga04-in.huawei.com> for eman@ietf.org; Wed, 18 May 2011 11:57:50 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 18 May 2011 11:57:47 +0800 Received: from SZXEML512-MBX.china.huawei.com ([169.254.11.29]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Wed, 18 May 2011 11:57:50 +0800 Date: Wed, 18 May 2011 03:57:49 +0000 From: Panfengbin In-reply-to: X-Originating-IP: [10.70.45.126] To: "eman@ietf.org" Message-id: <71FB630396E5014C95FF36BA7538581E0C37F5AB@szxeml512-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: eman Digest, Vol 10, Issue 6 Thread-index: AQHMFQTRuatRy9vywEqofh5JYGTbDZSR6T7j X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: [eman] =?gb2312?b?tPC4tDogZW1hbiBEaWdlc3QsIFZvbCAxMCwgSXNzdWUg?= =?gb2312?b?Ng==?= X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 03:57:54 -0000 U28sIGlmIHRoZXJlIGlzIG9ubHkgU05NUCwgbWFueSBlcXVpcG1lbnRzIGxpa2UgdHJhbnNwb3J0 ZXIgaW4gY29tbXVuaWNhdGlvbiBuZXR3b3JrIHdpbGwgbm90IGJlIG1hbmFnZWQsIGJlY2F1c2Ug aXQgYXBwbHkgUXggcHJvdG9jb2wuIE91ciB3b3JrIGFuZCBhaW0gIHdpbGwgYmUgYWJhdGVkIGxp a2VseS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iyzog ZW1hbi1ib3VuY2VzQGlldGYub3JnIFtlbWFuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gZW1hbi1y ZXF1ZXN0QGlldGYub3JnIFtlbWFuLXJlcXVlc3RAaWV0Zi5vcmddDQq3osvNyrG85DogMjAxMcTq NdTCMTjI1SAxMDozOA0Ktb06IGVtYW5AaWV0Zi5vcmcNCtb3zOI6IGVtYW4gRGlnZXN0LCBWb2wg MTAsIElzc3VlIDYNCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBh bGwgdGhlIGluZGl2aWR1YWwgbWVzc2FnZQ0KYXR0YWNobWVudHMgeW91IHdpbGwgbmVlZCB0byB1 cGRhdGUgeW91ciBkaWdlc3Qgb3B0aW9ucyBpbiB5b3VyIGxpc3QNCnN1YnNjcmlwdGlvbi4gIFRv IGRvIHNvLCBnbyB0bw0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vt YW4NCg0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0IG9wdGlvbnMnIGJ1dHRvbiwgbG9n IGluLCBhbmQgc2V0ICJHZXQNCk1JTUUgb3IgUGxhaW4gVGV4dCBEaWdlc3RzPyIgdG8gTUlNRS4g IFlvdSBjYW4gc2V0IHRoaXMgb3B0aW9uDQpnbG9iYWxseSBmb3IgYWxsIHRoZSBsaXN0IGRpZ2Vz dHMgeW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC4NCg0KDQoNClNlbmQgZW1hbiBtYWlsaW5nIGxp c3Qgc3VibWlzc2lvbnMgdG8NCiAgICAgICAgZW1hbkBpZXRmLm9yZw0KDQpUbyBzdWJzY3JpYmUg b3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCiAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbWFuDQpvciwgdmlhIGVtYWlsLCBz ZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCiAgICAgICAgZW1h bi1yZXF1ZXN0QGlldGYub3JnDQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0 aGUgbGlzdCBhdA0KICAgICAgICBlbWFuLW93bmVyQGlldGYub3JnDQoNCldoZW4gcmVwbHlpbmcs IHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRo YW4gIlJlOiBDb250ZW50cyBvZiBlbWFuIGRpZ2VzdC4uLiI= From fletchj@us.ibm.com Tue May 17 21:03:55 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FA2E0701 for ; Tue, 17 May 2011 21:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGLi7ajnMkji for ; Tue, 17 May 2011 21:03:54 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7C46CE0681 for ; Tue, 17 May 2011 21:03:54 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4I3ua3Y013618 for ; Tue, 17 May 2011 21:56:36 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4I43dch140566 for ; Tue, 17 May 2011 22:03:40 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4I48kNI028528 for ; Tue, 17 May 2011 22:08:46 -0600 Received: from d03nm120.boulder.ibm.com (d03nm120.boulder.ibm.com [9.17.195.146]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4I48kZq028513 for ; Tue, 17 May 2011 22:08:46 -0600 Auto-Submitted: auto-generated From: Jim Fletcher To: eman@ietf.org Message-ID: Date: Tue, 17 May 2011 22:03:38 -0600 X-MIMETrack: Serialize by Router on D03NM120/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/17/2011 22:03:39 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF207DF85C8C18f9e8a93df938690918c08BBF207DF85C8C1" Content-Disposition: inline Subject: [eman] AUTO: Jim fletcheris traveling with sporadic email access -- returning Friday morning May 20 (returning 05/19/2011) X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 04:03:55 -0000 --0__=08BBF207DF85C8C18f9e8a93df938690918c08BBF207DF85C8C1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 05/19/2011. For urgent technical issues see my team members - Note: This is an automated response to your message "eman Digest, Vol = 10, Issue 6" sent on 5/17/11 20:38:46. This is the only notification you will receive while this person is awa= y.= --0__=08BBF207DF85C8C18f9e8a93df938690918c08BBF207DF85C8C1 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 05/19/2011.

For urgent technical issues see my team members= -


Note: This is an automated re= sponse to your message "eman Digest, V= ol 10, Issue 6" sent= on 5/17/11 20:38:46.

This is the only notification= you will receive while this person is away.= --0__=08BBF207DF85C8C18f9e8a93df938690918c08BBF207DF85C8C1-- From jparello@cisco.com Wed May 18 09:03:59 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C08E06CB for ; Wed, 18 May 2011 09:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.304 X-Spam-Level: X-Spam-Status: No, score=-3.304 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OilKoh9R8eiA for ; Wed, 18 May 2011 09:03:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id BCA05E06A8 for ; Wed, 18 May 2011 09:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=2810; q=dns/txt; s=iport; t=1305734638; x=1306944238; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=qN44CRVIgBjj2LtQqc1LmTh5g9y50grKhnnRu+4TEA0=; b=VgAcrxdb86xnWG40XhrSjNbSMnpmo1J21+MRfF+68eHu3c7KBhpypTJc hyVpCwamTNmylXxjUlycYtq57GkJtivuSv22YZe9bd/u2qA4BruzUHFTs BRTXeqkZCGQ5Ac+wGNu7WlLt465gSwDUHCku70OcppqdmX3091cDbFTiC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAJXt002rRDoG/2dsb2JhbACEWZJ1jk13qR+MfQiQfoEng2eBCwSGUI15il0 X-IronPort-AV: E=Sophos;i="4.65,231,1304294400"; d="scan'208";a="450114264" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 18 May 2011 16:03:58 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4IG3wK9000578; Wed, 18 May 2011 16:03:58 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, 18 May 2011 09:03:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 09:03:08 -0700 Message-ID: In-Reply-To: <71FB630396E5014C95FF36BA7538581E0C37F5AE@szxeml512-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?GB2312?B?W2VtYW5dILTwuLQ6IGVtYW4gRGlnZXN0LCBWb2wgMTAsIElzc3VlIDY=?= Thread-Index: AQHMFQTRuatRy9vywEqofh5JYGTbDZSR6VVkgADTmiA= References: <71FB630396E5014C95FF36BA7538581E0C37F5AE@szxeml512-mbx.china.huawei.com> From: "John Parello (jparello)" To: "Panfengbin" , X-OriginalArrivalTime: 18 May 2011 16:03:58.0329 (UTC) FILETIME=[32211E90:01CC1575] Subject: Re: [eman] =?gb2312?b?tPC4tDogZW1hbiBEaWdlc3QsIFZvbCAxMCwgSXNzdWUg?= =?gb2312?b?Ng==?= X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 16:03:59 -0000 Hi, I completely agree and think we are handling this via the WG. In the framework draft we submitted we define a parent child pattern = that covers scenarios of deployments. A parent could be a switch with PoE endpoints or it could be a building = controller with lighting banks. The protocol between the parent and child devices need not be SNMP. So = that leaves a place to handle protocols like BACNET, MODBUS, Zigbee etc. This WG could surely work on other protocols than SNMP. The first step = though is creating a common EMAN information model.=20 A MIB definition of the information model used via SNMP could easily be = a basis for other protocols. In implementations I've worked on the first step toward a running system = was getting a common information model based on a parent child pattern. = That included a well defined interface to power states for control = (discussed in previous email). The transport protocol followed from = that. So I completely agree with your statement and think our work here is a = prerequisite. Jp -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of = Panfengbin Sent: Tuesday, May 17, 2011 8:27 PM To: eman@ietf.org Subject: [eman] =B4=F0=B8=B4: eman Digest, Vol 10, Issue 6 So, if there is only SNMP, many equipments like transporter in = communication network will not be managed, because it apply Qx protocol. = Our work and aim will be abated likely. ________________________________________ =B7=A2=BC=FE=C8=CB: eman-bounces@ietf.org [eman-bounces@ietf.org] = =B4=FA=B1=ED eman-request@ietf.org [eman-request@ietf.org] =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C218=C8=D5 10:38 =B5=BD: eman@ietf.org =D6=F7=CC=E2: eman Digest, Vol 10, Issue 6 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/eman Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send eman mailing list submissions to eman@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/eman or, via email, send a message with subject or body 'help' to eman-request@ietf.org You can reach the person managing the list at eman-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of eman digest..." _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Thu May 19 10:27:49 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBD2E0665 for ; Thu, 19 May 2011 10:27:49 -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.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-X1YQ8wWmmA for ; Thu, 19 May 2011 10:27:47 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 77AA0E0658 for ; Thu, 19 May 2011 10:27: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 p4JHRjVk022964; Thu, 19 May 2011 19:27:46 +0200 (CEST) Received: from [10.61.83.71] (ams3-vpn-dhcp4936.cisco.com [10.61.83.71]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4JHRiHN006275; Thu, 19 May 2011 19:27:44 +0200 (CEST) Message-ID: <4DD55310.7050904@cisco.com> Date: Thu, 19 May 2011 19:27:44 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: eman mailing list Content-Type: multipart/alternative; boundary="------------070304060506080607080002" Cc: Katherine Voss Subject: [eman] ODVA feedback on the requirements draft X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 17:27:50 -0000 This is a multi-part message in MIME format. --------------070304060506080607080002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, With permission from the authors, I'm forwarding feedback on the "Requirements for Energy Management (draft-ietf-eman-requirements-01)." from the two ODVA SIG co-chairs. Regards, Benoit. _Overall _ A very good effort. We mutually believe that the efforts of ODVA CIP Energy SIG and the IETF are parallel and touch each other at important points. It would be beneficial to each party to cross-pollinate. _In Specific_ 1.Introduction: The addition of a bullet point enumerating "Industrial Networks" as a network type that the IETF EMAN standards could be applied to would be appropriate. 2.Section 2: Perhaps the IETF might consider an additional scenario for industrial control systems and EMS.Industrial EMS tend to be more unique and customized to an application than commercial building EMS, which tends to be pretty standardized and configurable. A bi-directional gateway would allow coordination so that, for instance, a network EMS would not reduce network data rates when an industrial control system is doing a lot of hi-speed I/O comms. An industrial system could communicate low energy stets (breaks, downtimes, system restorations) to the network EMS to optimize energy usage without inadvertently constraining otherwise independent systems. I believe the best results will be obtained with independent but collaborative systems to manage energy in the network, building and industrial control domains. Sharing best practices between the domains is always a good thing. 3.Section 2.2, line 3: (nitpicky comment) I think they meant PoE rather than PoW in line 3 of 2.2. 4.Section 2.5, scenario 5: I see value in a bi-directional link between a network EMS and a building EMS. There may be times the building mgmt system needs the network at high performance. There may be times when the network infrastructure needs the BMS at high functionality. I see less call for building EMS functions to be performed by a network EMS. 5.Section 3.4.3: a more current standard for power quality is EN 50160. 6.The recommendation to use the accuracy classes in IEC 61850 is of interest. (But) It doesn't really apply to the industrial domain. --------------070304060506080607080002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

With permission from the authors, I'm forwarding feedback on the "Requirements for Energy Management (draft-ietf-eman-requirements-01).” from the two ODVA SIG co-chairs.

Regards, Benoit.

 

Overall 

A very good effort. We mutually believe that the efforts of ODVA CIP Energy SIG and the IETF are parallel and touch each other at important points. It

would be beneficial to each party to cross-pollinate.

In Specific

1.  Introduction: The addition of a bullet point enumerating "Industrial Networks" as a network type that the IETF EMAN standards could be applied to would be appropriate.

2.  Section 2:  Perhaps the IETF might consider an additional scenario for industrial control systems and EMS.Industrial EMS tend to be more unique and customized to an application than commercial building EMS, which tends to be pretty standardized and configurable. A bi-directional gateway would allow coordination so that, for instance, a network EMS would not reduce network data rates when an industrial control system is doing a lot of hi-speed I/O comms. An industrial system could communicate low energy stets (breaks, downtimes, system restorations) to the network EMS to optimize energy usage without inadvertently constraining otherwise independent systems. I believe the best results will be obtained with independent but collaborative systems to manage energy in the network, building and industrial control domains. Sharing best practices between the domains is always a good thing.

3.  Section 2.2, line 3:  (nitpicky comment) I think they meant PoE rather than PoW in line 3 of 2.2.

4.  Section 2.5, scenario 5:  I see value in a bi-directional link between a network EMS and a building EMS. There may be times the building mgmt system needs the network at high performance. There may be times when the network infrastructure needs the BMS at high functionality. I see less call for building EMS functions to be performed by a network EMS.

5.  Section 3.4.3: a more current standard for power quality is EN 50160.

6.  The recommendation to use the accuracy classes in IEC 61850 is of interest. (But) It doesn't really apply to the industrial domain.

 

--------------070304060506080607080002-- From zhang.jingwei@yahoo.com.cn Sun May 22 17:50:09 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A50E06EB for ; Sun, 22 May 2011 17:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.805 X-Spam-Level: *** X-Spam-Status: No, score=3.805 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_EXTRA_CLOSE=2.809, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snkD1JvcVk7s for ; Sun, 22 May 2011 17:50:08 -0700 (PDT) Received: from n4f.bullet.cnb.yahoo.com (n4f.bullet.cnb.yahoo.com [203.209.230.24]) by ietfa.amsl.com (Postfix) with SMTP id DB975E06A6 for ; Sun, 22 May 2011 17:50:07 -0700 (PDT) Received: from [202.43.217.101] by n4.bullet.cnb.yahoo.com with NNFMP; 23 May 2011 00:50:02 -0000 Received: from [202.165.102.48] by t1.bullet.cnb.yahoo.com with NNFMP; 23 May 2011 00:50:02 -0000 Received: from [127.0.0.1] by omp102.mail.cnb.yahoo.com with NNFMP; 23 May 2011 00:50:02 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 408269.47698.bm@omp102.mail.cnb.yahoo.com Received: (qmail 62602 invoked by uid 60001); 23 May 2011 00:50:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1306111801; bh=6UYGVR4lWo0Ygjr8XrvIFT9z+bJnOzbtUJq1o/xNWf4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Mj6gYmQEJkpfAnoUwM+SMeQGaPhdWlNe/aJbyhw5LPM5Fgdx0RqpnADWKNbxBhzZ4vA8KhI4zGJkO1Ik940oWu/kcJIcS5OK4BmauIi5Rht/if4HNZ1snoA1E+BrqSxKreBDclo+bDmvuIRihU0m/sObKMBVd5WUWd3sp6CZYvo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=gd7Dms0QzXQETC+Fs3IZ52CxuHPEpNZUBciZKGczedXV4tKjkFMzPAEV7fy7f0fNtcY9xhPLyT1HQCEOXAPFN+XCbe6Fmj8L8y0e5rVJmiyE9hhCN+WXid7FgjB/V4VOqUgBjRcEOgSIsSRhlWRdWFH9ti1od7YqIPpy93IJlEM=; Message-ID: <509444.62267.qm@web15808.mail.cnb.yahoo.com> X-YMail-OSG: T5WW8a8VM1noWQ0pcik.TeGCgTPOvg1li0fDCm1O1mA_scU o0oUTJLjw Received: from [59.64.159.245] by web15808.mail.cnb.yahoo.com via HTTP; Mon, 23 May 2011 08:50:00 CST X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.303096 Date: Mon, 23 May 2011 08:50:00 +0800 (CST) From: Jingwei Zhang To: rolf.winter@neclab.eu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1608081927-1306111800=:62267" Cc: eman@ietf.org Subject: [eman] questions to draft-quittek-power-mib-02 draft X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 00:50:09 -0000 --0-1608081927-1306111800=:62267 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, =C2=A0 I noticed=C2=A0 "loadBasedEstimation (4)", "deviceBasedEstimation (5)" is d= efined in "energyMeasurementMethod", which is in the energy MIB of [draft-q= uittek-power-mib-02]. I am a student interested in energy consumption estim= ation of PCs, wondering if there are some theoretical bases about energy co= nsumption estimation.=20 =C2=A0 Recently, I am doing some implementations based on eman architecture , part= of the work is about energy consumption estimation of the PCs, but I wonde= r if this work is valuable. Comments are expected. =C2=A0 Ps: EnergyEntry ::=3D =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SEQUENCE { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 energyConsumerId=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Integ= er32, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 energyConsumerOid=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OBJECT IDEN= TIFIER, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 energySensorOperStat= us=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EntitySensorStatus, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 energyNominalSupplyV= oltage=C2=A0=C2=A0 Unsigned32, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 energyElectricSupply= Type=C2=A0=C2=A0=C2=A0=C2=A0 INTEGER, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 energyTotalEnergy=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Unsigned32, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 energyEnergyUnitMult= iplier=C2=A0=C2=A0 UnitMultiplier, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 energyEnergyPrecisio= n=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Integer32, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 energyMeasurementMet= hod=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTEGER, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E3=80=82=E3=80=82= =E3=80=82=E3=80=82=E3=80=82=E3=80=82 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0 energyMeasurementMethod OBJECT-TYPE =C2=A0=C2=A0=C2=A0=C2=A0 SYNTAX INTEGER { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directEnergyMeasu= rement(1), =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0powerOversampling= (2), =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 powerSampling(3), =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 loadBasedEstimati= on(4), =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 deviceBasedEstima= tion(5), =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unknown(6) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0 Best Regards --0-1608081927-1306111800=:62267 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =

Hi,

=  

I noticed  "loadBasedEstimation (4)", "device= BasedEstimation (5)" is defined in "energyMeasurementMethod", which is in t= he energy MIB of [draft-quittek-power-mib-02]. I am a student interested in= energy consumption estimation of PCs, wondering if there are some theoreti= cal bases about energy consumption estimation.

=  

Recently, I am doing some implementations based on= eman architecture , part of the work is about energy consumption estimatio= n of the PCs, but I wonder if this work is valuable. Comments are expected.=

=  

Ps:

EnergyEntry ::=3D

    &nbs= p;  SEQUENCE {

        &n= bsp; energyConsumerId         =     Integer32,

        &n= bsp; energyConsumerOid         = ;   OBJECT IDENTIFIER,

        &n= bsp; energySensorOperStatus       EntitySenso= rStatus,

        &n= bsp; energyNominalSupplyVoltage   Unsigned32,

        &n= bsp; energyElectricSupplyType     INTEGER,

        &n= bsp; energyTotalEnergy         = ;   Unsigned32,

        &n= bsp; energyEnergyUnitMultiplier   UnitMultiplier,

        &n= bsp; energyEnergyPrecision        Intege= r32,

       &n= bsp;  energyMeasurementMethod  &n= bsp;   INTEGER,

       &n= bsp;  =E3=80=82=E3=80=82=E3=80=82=E3=80=82=E3=80=82=E3=80=82=

       }

=  

energyMeasurementMethod OBJECT-TYPE<= /DIV>

     SYN= TAX INTEGER {

        &n= bsp;            = ;  directEnergyMeasurement(1),

        &n= bsp;            &nbs= p; powerOversampling(2),

        &n= bsp;            = ;  powerSampling(3),

       &n= bsp;            = ;   loadBasedEstimation(4),=

    = ;            &n= bsp;      deviceBasedEstimation(5),

        &n= bsp;            = ;  unknown(6)

       &n= bsp;    }

 

Best Regards

--0-1608081927-1306111800=:62267-- From moulchan@cisco.com Tue May 24 00:45:03 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD11E06CE for ; Tue, 24 May 2011 00:45: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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HztDGteizjZf for ; Tue, 24 May 2011 00:45:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 88211E06D4 for ; Tue, 24 May 2011 00:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=18948; q=dns/txt; s=iport; t=1306223101; x=1307432701; h=mime-version:subject:date:message-id:from:to; bh=SO+OJaMo2+O6wz5mQwvOSEnSA60KuyUTAEPW5JtDhpo=; b=lygxi/Oai+3liPx36IVac5kcs+Jxd21fNo5CgSyXkZkqDx0LFBmE9+5D jeQwG5NWHAc6Rmq0XTW3Y8z/AOErE66D61BMmBloBZLIDwpkkIKjnkaRJ Wk4RS4vz4tStEfuZ0QWnaOMvl2A6VreghaHPFQNGRz4lgHZK6OwGoTR3K g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKph202tJXG+/2dsb2JhbACCZqM+d6oZgR2eEoYbBIZWjgaKYg X-IronPort-AV: E=Sophos;i="4.65,260,1304294400"; d="scan'208,217";a="322207769" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 24 May 2011 07:45:00 +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 p4O7j0Jx027304 for ; Tue, 24 May 2011 07:45:00 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, 24 May 2011 02:45:00 -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_01CC19E6.7BF85D6D" Date: Tue, 24 May 2011 02:44:55 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-claise-energy-monitoring-mib-08.txt Thread-Index: AcwZ5nlnt8xEvGoHTGe+39dysJDvNg== From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 24 May 2011 07:45:00.0164 (UTC) FILETIME=[7C122C40:01CC19E6] Subject: [eman] draft-claise-energy-monitoring-mib-08.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 07:45:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC19E6.7BF85D6D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all,=20 =20 Based on the conclusions from the EMAN WG meeting at Prague, http://www.ietf.org/proceedings/80/minutes/eman.txt , a major revision of the merged Monitoring MIB draft has been submitted and the new version can be found at http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-08 The diff can be seen at http://tools.ietf.org/rfcdiff?url2=3Ddraft-claise-energy-monitoring-mib-0= 8 .txt . =20 =20 Among other changes, the draft provides support for multiple Power State Series and an IANA considerations section describing the procedure for adding new Power State Series and Power States within the series. Many thanks to all who provided comments. =20 Changes: =20 - Definition of Power State and Power State Series Terminology=20 o 3 Power State Series - IEEE1621, DMTF and EMAN have been proposed o Description of the Power States in IEEE1621 and DMTF Power State Series =20 - A new section on IANA considerations for adding new Power State Series and Power States within the series=20 o Textual convention for PowerStateSeries (that can be administered by IANA) =20 - Use cases section has been moved to EMAN Applicability Statement draft and a sample scenario is presented in this draft =20 - MIB OID content o MIB OID Tree is presented - to be inline with the EMAN battery MIB o UML diagram for the EMAN Monitoring MIB - to be inline with EMAN Energy-Aware-MIB =20 - A section on discovery Power States supported by a device - with/without implementation of Energy-Aware-MIB =20 - pmPowerTable indexed by pmPowerIndex and pmPowerStateSeriesIndex o pmPowerRequestedState renamed as pmPowerAdminState; pmPowerActualState renamed as pmPowerOperState - to be inline with the ifTable in RFC2863 o pmPowerManufacturerActualPowerState and pmPowerManufacturerMappingId have been removed=20 o since there are 3 Power States Series, the Manufacturer Power States have been removed and as a consequence, the pmPowerStateMappingTable has been removed=20 =20 - pmPowerStateTable indexed by pmPowerIndex, pmPowerStateSeriesIndex and pmPowerStateIndex =20 - Notifications generated whenever there is change in pmPowerStateSeries, pmPowerAdminState, pmPowerOperState, pmPowerStateEnterReason=20 =20 - Many rewording to improve readability =20 - Once EMAN-REQ draft has been submitted, this draft may be revised.=20 =20 Your comments welcome. =20 Thanks Mouli =20 =20 ------_=_NextPart_001_01CC19E6.7BF85D6D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all, =

 

Based on the = conclusions from the EMAN WG meeting at Prague, http://www.i= etf.org/proceedings/80/minutes/eman.txt  ,

a major = revision of the merged Monitoring MIB draft has been submitted and the new version can = be found at  http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-08

The diff can = be seen at  http://tools.ietf.org/rfcdiff?url2=3Ddraft-claise-energy-m= onitoring-mib-08.txt  .

 

 

Among other = changes, the draft provides support for multiple Power State Series and an IANA considerations section describing the procedure for adding new Power = State Series and Power States within the series. Many thanks to all who = provided comments.

 

Changes:

 

-    Definition of Power State and Power State Series Terminology

o   3 Power = State Series – IEEE1621, DMTF and EMAN have been = proposed

o   Description of the Power States in IEEE1621 and DMTF Power State = Series

 

-    A new = section on IANA considerations for adding new Power State Series and Power States = within the series

o   Textual convention for PowerStateSeries (that can be administered by = IANA)

 

-    Use = cases section has been moved to EMAN Applicability Statement draft and a sample = scenario is presented in this draft

 

-    MIB OID = content

o   MIB OID = Tree is presented - to be inline with = the EMAN battery MIB

o   UML = diagram for the EMAN Monitoring MIB - to be = inline with EMAN Energy-Aware-MIB

 

-    A = section on discovery Power States supported by a device – with/without implementation = of Energy-Aware-MIB

 

-    pmPowerTable indexed by pmPowerIndex and = pmPowerStateSeriesIndex

o   pmPowerRequestedState renamed as pmPowerAdminState; pmPowerActualState renamed as = pmPowerOperState - to be inline with the ifTable in = RFC2863

o   pmPowerManufacturerActualPowerState and pmPowerManufacturerMappingId have been removed =

o   since = there are 3 Power States Series, the Manufacturer Power States have been removed and = as a consequence, the pmPowerStateMappingTable has been removed

 

-    pmPowerStateTable indexed by pmPowerIndex, pmPowerStateSeriesIndex and = pmPowerStateIndex

 

-    Notifications generated whenever there is change in pmPowerStateSeries, = pmPowerAdminState, pmPowerOperState, pmPowerStateEnterReason

 

-    Many = rewording to improve readability

 

-    Once = EMAN-REQ draft has been submitted, this draft may be revised. =

 

Your comments welcome.

 

Thanks

Mouli

 

 <= /p>

------_=_NextPart_001_01CC19E6.7BF85D6D-- From bclaise@cisco.com Tue May 24 01:10:02 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C92E070A for ; Tue, 24 May 2011 01:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[AWL=-2.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqTZpHwoO8BN for ; Tue, 24 May 2011 01:09:57 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 71DD9E06E5 for ; Tue, 24 May 2011 01:09:57 -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 p4O81nsv028159; Tue, 24 May 2011 10:01:50 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4O81lDA004428; Tue, 24 May 2011 10:01:48 +0200 (CEST) Message-ID: <4DDB65EB.7060502@cisco.com> Date: Tue, 24 May 2011 10:01:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: zdz References: <22B2909DCC2E62418BE369A1F104889937A033BA@ex01.noveda.com> <22B2909DCC2E62418BE369A1F104889937A00FA0@ex01.noveda.com> <2bb09550.2434.13017dcb116.Coremail.hustzdz@126.com> In-Reply-To: <2bb09550.2434.13017dcb116.Coremail.hustzdz@126.com> Content-Type: multipart/alternative; boundary="------------090205090708050109060508" Cc: eman mailing list Subject: Re: [eman] two questions to draft-claise-power-management-arch-02 draft X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 08:10:02 -0000 This is a multi-part message in MIME format. --------------090205090708050109060508 Content-Type: text/plain; charset=x-gbk; format=flowed Content-Transfer-Encoding: 8bit Hi, At our last meeting, we decided to go for multiple power states series. Therefore, the Manufacturer Power State are not necessary any longer. This has been reflected in the latest version of the MIB (still an individual draft), i.e. draft-claise-energy-monitoring-mib-08 Regards, Benoit. > > The "Manufacturer Power State" described at the device, however, is it > necessary to map that to "12 levels state"? > > If there is a "short" state, what is the precise "power state(12 > levle)"? Either 7 or 8 will be OK? > > > ÔÚ2011-05-18 10:38:21£¬"Brad Schoening" дµÀ£º > > The power levels are designed to be sparse. So, your platform can > implement those EMAN levels 1..12 which made sense for it. Figure > 6 of the EMAN Framework v-01 gives an example of this mapping to a > device supporting four fictitious power states: > > Power State / Name Manufacturer Power State / Name > > 1 / Mech Off 0 / none > > 2 / Soft Off 0 / none > > 3 / Hibernate 0 / none > > 4 / Sleep, Save-to-RAM 0 / none > > 5 / Standby 0 / none > > 6 / Ready 1 / short > > 7 / LowMinus 1 / short > > 8 / Low 1 / short > > 9 / MediumMinus 2 / tall > > 10 / Medium 2 / tall > > 11 / HighMinus 3 / grande > > 12 / High 4 / venti > > Figure 6: Mapping Example 3 > > This is similar to the DMTF and ACPI models which define many > states, but devices are not required to implement them all. > > Reference: > > http://tools.ietf.org/html/draft-ietf-eman-framework-01 > > *From:*Duanxiaoling [mailto:duanxiaoling@huawei.com > ] > *Sent:* Tuesday, May 17, 2011 10:03 PM > *To:* Brad Schoening; bclaise@cisco.com > *Cc:* eman mailing list > *Subject:* Re: [eman] two questions to > draft-claise-power-management-arch-02 draft > > Thanks for your answer! > > I recognize that other protocols besides SNMP are not in our scope > from your answer. > > But how about the second question? Would you like to give us an > answer? > > Thanks! > > best regards! > notes:duanxiaoling 00160662@notesmail.huawei.com > > Phone number:13751010110 > ****************************************************************************************** > This email and its attachments contain confidential information > from HUAWEI, which is intended only for the person or entity whose > address is listed above. Any use of the information contained > herein in any way (including, but not limited to, total or partial > disclosure, reproduction, or dissemination) by persons other than > the intended recipient(s) is prohibited. If you receive this > e-mail in error, please notify the sender by phone or email > immediately and delete it! > ***************************************************************************************** > > > ------------------------------------------------------------------------ > > *·¢¼þÈË**:*Brad Schoening [bschoening@noveda.com > ] > *·¢ËÍʱ¼ä**:*2011Äê5ÔÂ13ÈÕ5:18 > *µ½**:*Duanxiaoling; bclaise@cisco.com > *Cc:* eman mailing list > *Ö÷Ìâ**:*RE: [eman] two questions to > draft-claise-power-management-arch-02 draft > > Yes, the EMAN data model uses the Simple Network Management > Protocol (SNMP). Our draft management information base (MIB) > inherits data types and textual conventions from the SNMP > standard. It¡¯s not really adaptable to other protocols that don¡¯t > support SNMP data types. > > There is no standard data format for FTP, hence its not useful by > itself as a data transfer protocol without another layer of > interpretation such as an XML schema or CSV format. As for the > other protocols you mention, they seem to be domain specific, but > I¡¯m not familiar with them. > > Regards, > > Brad Schoening > > *From:*eman-bounces@ietf.org > [mailto:eman-bounces@ietf.org ] *On > Behalf Of *Duanxiaoling > *Sent:* Wednesday, May 11, 2011 9:35 PM > *To:* bclaise@cisco.com > *Cc:* eman mailing list > *Subject:* [eman] two questions to > draft-claise-power-management-arch-02 draft > > 1,The protocol between NMS and device is SNMP, but how about other > protocol, such as FTP, TL1 or Qx ? Is these protocol prohibited or > out of eman's scope? Now lots of SDH, MSTP devices is managed by > NMS in protocol Qx or TL1. Also, lots of core network device is > managed by NMS in protocol MML, and so on. Will our draft fit for > these devices(wireless device, core network device, transfer device )? > > 2,The power level is defind in the draft is [0...12], how will we > use it? All device must have all the power level? or different NE > can select different part of them. For example, A can select > [0...7], B can select [8,10,12], and so on. > > How about other memeber's thought? > > best regards! > email:duanxiaoling@huawei.com > > Phone number:+086-0755-13751010110 > ****************************************************************************************** > This email and its attachments contain confidential information > from HUAWEI, which is intended only for the person or entity whose > address is listed above. Any use of the information contained > herein in any way (including, but not limited to, total or partial > disclosure, reproduction, or dissemination) by persons other than > the intended recipient(s) is prohibited. If you receive this > e-mail in error, please notify the sender by phone or email > immediately and delete it! > ***************************************************************************************** > > > > --------------090205090708050109060508 Content-Type: text/html; charset=x-gbk Content-Transfer-Encoding: 8bit Hi,

At our last meeting, we decided to go for multiple power states series.
Therefore, the Manufacturer Power State are not necessary any longer.
This has been reflected in the latest version of the MIB (still an individual draft), i.e. draft-claise-energy-monitoring-mib-08

Regards, Benoit.

The "Manufacturer Power State" described at the device, however, is it necessary to map that to "12 levels state"?

If there is a "short" state, what is the precise "power state(12 levle)"? Either 7 or 8 will be OK?


ÔÚ2011-05-18 10:38:21£¬"Brad Schoening" <bschoening@noveda.com> дµÀ£º

The power levels are designed to be sparse.   So, your platform can implement those EMAN levels 1..12 which made sense for it.  Figure 6 of the EMAN Framework v-01 gives an example of this mapping to a device supporting four fictitious power states:

 

              Power State / Name       Manufacturer Power State / Name

               1 / Mech Off             0 / none

               2 / Soft Off             0 / none

               3 / Hibernate            0 / none

               4 / Sleep, Save-to-RAM   0 / none

               5 / Standby              0 / none

               6 / Ready                1 / short

               7 / LowMinus             1 / short

               8 / Low                  1 / short

               9 / MediumMinus          2 / tall

               10 / Medium              2 / tall

               11 / HighMinus           3 / grande

               12 / High                4 / venti

    

                          Figure 6: Mapping Example 3

 

This is similar to the DMTF and ACPI models which define many states, but devices are not required to implement them all.

 

Reference:

 

http://tools.ietf.org/html/draft-ietf-eman-framework-01

 

From: Duanxiaoling [mailto:duanxiaoling@huawei.com]
Sent: Tuesday, May 17, 2011 10:03 PM
To: Brad Schoening; bclaise@cisco.com
Cc: eman mailing list
Subject: Re: [eman] two questions to draft-claise-power-management-arch-02 draft

 

Thanks for your answer!

I recognize that other protocols besides SNMP are not in our scope from your answer.

But how about the second question? Would you like to give us an answer?

 

Thanks!

 

 

best regards!
notes:duanxiaoling 00160662@notesmail.huawei.com
Phone number:13751010110
******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************
 

·¢¼þÈË: Brad Schoening [bschoening@noveda.com]
·¢ËÍʱ¼ä: 2011Äê5ÔÂ13ÈÕ 5:18
µ½: Duanxiaoling; bclaise@cisco.com
Cc: eman mailing list
Ö÷Ìâ: RE: [eman] two questions to draft-claise-power-management-arch-02 draft

Yes, the EMAN data model uses the Simple Network Management Protocol (SNMP).  Our draft management information base (MIB) inherits data types and textual conventions from the SNMP standard.  It¡¯s not really adaptable to other protocols that don¡¯t support SNMP data types.

 

There is no standard data format for FTP, hence its not useful by itself as a data transfer protocol without another layer of interpretation such as an XML schema or CSV format.  As for the other protocols you mention, they seem to be domain specific, but I¡¯m not familiar with them.

 

Regards,

 

Brad Schoening

 

From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Duanxiaoling
Sent: Wednesday, May 11, 2011 9:35 PM
To: bclaise@cisco.com
Cc: eman mailing list
Subject: [eman] two questions to draft-claise-power-management-arch-02 draft

 

1,The protocol between NMS and device is SNMP, but how about other protocol, such as FTP, TL1 or Qx ?  Is these protocol prohibited  or out of eman's scope?  Now lots of SDH, MSTP devices is managed by NMS in protocol Qx or TL1. Also, lots of core network device is  managed by NMS in protocol MML, and so on.  Will our draft fit for these devices(wireless device, core network device, transfer device )?

2,The power level is defind in the draft is [0...12], how will we use it? All device must have all the power level? or different NE can select different part of them. For example, A can select [0...7], B can select [8,10,12], and so on.

 

How about other memeber's thought?

 

best regards!
email:duanxiaoling@huawei.com

Phone number:+086-0755-13751010110
******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************
 




--------------090205090708050109060508-- From bclaise@cisco.com Tue May 24 01:20:09 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F194E0716 for ; Tue, 24 May 2011 01:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keq8s+XpW506 for ; Tue, 24 May 2011 01:20:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 28A33E0703 for ; Tue, 24 May 2011 01:20: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 p4O7xltY027786; Tue, 24 May 2011 09:59:47 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4O7xlMI001825; Tue, 24 May 2011 09:59:47 +0200 (CEST) Message-ID: <4DDB6573.6030800@cisco.com> Date: Tue, 24 May 2011 09:59:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Duanxiaoling References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010506020502000308020002" Cc: eman mailing list Subject: Re: [eman] two questions to draft-claise-power-management-arch-02 draft X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 08:20:09 -0000 This is a multi-part message in MIME format. --------------010506020502000308020002 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Hi, Please comment on the official EMAN document, i.e. http://tools.ietf.org/html/draft-ietf-eman-framework-01 draft-claise-power-management-arch-02 draft is old. Let me addresse your questions below > > 1,The protocol between NMS and device is SNMP, but how about other > protocol, such as FTP, TL1 or Qx ? Is these protocol prohibited or out > of eman's scope? Now lots of SDH, MSTP devices is managed by NMS in > protocol Qx or TL1. Also, lots of core network device is managed by > NMS in protocol MML, and so on. Will our draft fit for these > devices(wireless device, core network device, transfer device )? > The decision for the WG was to create MIB modules, to be used with SNMP. However, if we do our job right in terms of information modelling, multiple data models could be deduced from it. Reference: RFC3444 > > 2,The power level is defind in the draft is [0...12], how will we use > it? All device must have all the power level? or different NE can > select different part of them. For example, A can select [0...7], B > can select [8,10,12], and so on. > Yes, EMAN doesn't impose that you support all power states. Regards, Benoit > > How about other memeber's thought? > > best regards! > email:duanxiaoling@huawei.com > Phone number:+086-0755-13751010110 > ****************************************************************************************** > This email and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, > please notify the sender by phone or email immediately and delete it! > ***************************************************************************************** > > --------------010506020502000308020002 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 7bit Hi,

Please comment on the official EMAN document, i.e. http://tools.ietf.org/html/draft-ietf-eman-framework-01
draft-claise-power-management-arch-02 draft is old.
Let me addresse your questions below

1,The protocol between NMS and device is SNMP, but how about other protocol, such as FTP, TL1 or Qx ?  Is these protocol prohibited  or out of eman's scope?  Now lots of SDH, MSTP devices is managed by NMS in protocol Qx or TL1. Also, lots of core network device is  managed by NMS in protocol MML, and so on.  Will our draft fit for these devices(wireless device, core network device, transfer device )?

The decision for the WG was to create MIB modules, to be used with SNMP.
However, if we do our job right in terms of information modelling, multiple data models could be deduced from it.
Reference: RFC3444

2,The power level is defind in the draft is [0...12], how will we use it? All device must have all the power level? or different NE can select different part of them. For example, A can select [0...7], B can select [8,10,12], and so on.

Yes, EMAN doesn't impose that you support all power states.

Regards, Benoit

 

How about other memeber's thought?

 

best regards!
email:duanxiaoling@huawei.com
Phone number:+086-0755-13751010110
******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************
 

--------------010506020502000308020002-- From moulchan@cisco.com Wed May 25 01:18:29 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9D7E06E1 for ; Wed, 25 May 2011 01:18: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ErvVtEoHEWF for ; Wed, 25 May 2011 01:18:28 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id DC15CE06D5 for ; Wed, 25 May 2011 01:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=3600; q=dns/txt; s=iport; t=1306311508; x=1307521108; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=8e8BPnDiRmXMiXyeZqZ0u+wSiMfWf7BZkilPhLeza1k=; b=mgql6rZFkZvbW71kol1YYYPCENzRZ6qZkYIAAlsnGg7HAoF9xrK84Np7 JyW/G40KjeFS/XJvutKKhO3orI8vRYfgJ9c3zWoHm73hH1+BlI3pOSZr4 ho+vKp7MWmVXg6/Vt2/Uf3KnTnfIN1+d5vvyYym7U1og5Yju8rAH2sBbK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAF663E2tJV2a/2dsb2JhbACXZY5FeKgVnXgCgy+CawSGW44TimU X-IronPort-AV: E=Sophos;i="4.65,266,1304294400"; d="scan'208";a="323067255" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-3.cisco.com with ESMTP; 25 May 2011 08:18:28 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4P8ISkO004963; Wed, 25 May 2011 08:18:28 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, 25 May 2011 03:18: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: Wed, 25 May 2011 03:18:23 -0500 Message-ID: In-Reply-To: <20110330091150.GB29695@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] js review of draft-claise-energy-monitoring-mib-07 Thread-Index: Acvuuof+esBUQDiKQruMKBAa8kaXqArMuhpw References: <20110330091150.GB29695@elstar.local> From: "Mouli Chandramouli (moulchan)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 25 May 2011 08:18:27.0922 (UTC) FILETIME=[53337B20:01CC1AB4] Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 08:18:29 -0000 Hi Juergen, Thanks for your feedback on draft-claise-energy-monitoring-mib-07.=20 Please provide us feedback on this updated version draft-claise-energy-monitoring-mib-08.=20 As you have pointed out, POWER-MONITOR-MIB does not require the implementation of ENERGY-AWARE-MIB.=20 The first question is pmPowerIndex and that is determined with or without the implementation of ENERGY-AWARE-MIB as explained in the DESCRIPTION clause of this MIB object.=20 Secondly, in Section 6, explains the discovery of Power States supported by a device with / without the implementation of ENERGY-AWARE-MIB. The use cases, have been moved out Of this draft. Changes to pmPowerState now modified to pmPowerOperState and pmPowerStateEnterReason are not persisted.=20 pmEnergyParametersTable is not persisted and all the objects in that table are read-create objects. Regarding the RowStatus comment, I have seen MIB designs with RowStatus and=20 an explicit StorageType (default - Volatile). There are other examples of MIBs with Syntax - RowStatus - without StorageType. http://tools.ietf.org/html/draft-ietf-psamp-mib-06 As you have pointed out, with changes in the MIB design, pmPowerStateChange notifications are modified now - whenever there are changes in the following MIB objects - pmPowerStateSeries, pmPowerStateSeries, pmPowerAdminState, pmPowerOperState, pmPowerStateEnterReason.=20 We do not foresee a need to throttle notifications as of now, unless, these are notifications are seen as a bottleneck. Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, March 30, 2011 2:42 PM To: eman@ietf.org Subject: [eman] js review of draft-claise-energy-monitoring-mib-07 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 --=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 moulchan@cisco.com Wed May 25 01:18:51 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88874E06F3 for ; Wed, 25 May 2011 01:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bHr7cRugOi8 for ; Wed, 25 May 2011 01:18:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7CDE06D5 for ; Wed, 25 May 2011 01:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1572; q=dns/txt; s=iport; t=1306311531; x=1307521131; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1PtAzuoSeYBReTrxN/7hc5R4aNacp2QeX3cIqqHSvQM=; b=EC7wm95WWRjWiB5t6/8pJDlapg5N2rYui0/8gKJaz49V98qdVTn9vH3y A0/KFLFjbjYGRnlL0/bGWaPqy0qdSsGrkvRjDwajaemGyPgkYvj9mZHCs YD+2ZDIOm9wh173+TEhQEfTqDWYMnaHLR/KKLwbVPUA3BFZqyHNQZd79V g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAKa63E2tJXG//2dsb2JhbACXZY5FeKgLnXiGHASGW44TimU X-IronPort-AV: E=Sophos;i="4.65,266,1304294400"; d="scan'208";a="363792250" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-2.cisco.com with ESMTP; 25 May 2011 08:18:48 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4P8ImuC021683 for ; Wed, 25 May 2011 08:18:48 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 May 2011 03:18:48 -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, 25 May 2011 03:18:46 -0500 Message-ID: In-Reply-To: <4D9C7B36.2000407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] DRAFT EMAN minutes from IETF 80 Thread-Index: Acv0aqKLpfj6BzBPSwiBiFIhYvsSUwlmbUPg References: <4D9B2B68.7040801@cisco.com> <4D9C7B36.2000407@cisco.com> From: "Mouli Chandramouli (moulchan)" To: "eman mailing list" X-OriginalArrivalTime: 25 May 2011 08:18:48.0470 (UTC) FILETIME=[5F72DB60:01CC1AB4] Subject: Re: [eman] DRAFT EMAN minutes from IETF 80 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 08:18:51 -0000 - Chris Verges (jabber): - On pmPowerIndex, this seems like a complex if/else-if/else schema=20 that isn't structurally enforced in the MIB. What NMS or end user=20 confusion might occur as a result of this? Regarding this comment from WG meeting @ Prague -=20 This point is explained in the DESCRIPTION clause of the pmPowerIndex MIB object in the pmPowerTable http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-08 on how this Index value is set/determined depending on which MIB is implemented. You can also look at Section 6. Discovery - which explains in detail the discovery of the number of Power States on a device.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Benoit Claise (bclaise) Sent: Wednesday, April 06, 2011 8:10 PM To: eman mailing list Subject: Re: [eman] DRAFT EMAN minutes from IETF 80 Dear all, Editorial changes from Bill Mielke and Georgios Karagiannis inserted and uploaded Thanks and Regards, Bruce and Benoit > Dear all > > Here are the draft minutes of our EMAN meeting. > http://www.ietf.org/proceedings/80/minutes/eman.txt > > Please send me any corrections, changes, etc as soon as possible. > > Regards, Bruce and Benoit. > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Wed May 25 02:36:51 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF0E07D4 for ; Wed, 25 May 2011 02:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAewBiVhmkPn for ; Wed, 25 May 2011 02:36:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B7D22E07CF for ; Wed, 25 May 2011 02:36:49 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C13DB20C8D; Wed, 25 May 2011 11:36:48 +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 6p93Sf-fjKqH; Wed, 25 May 2011 11:36:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6C4220CCE; Wed, 25 May 2011 11:36:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D8E2418B6673; Wed, 25 May 2011 11:36:47 +0200 (CEST) Date: Wed, 25 May 2011 11:36:47 +0200 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20110525093647.GA2777@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , eman mailing list References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman mailing list Subject: Re: [eman] draft-claise-energy-monitoring-mib-08.txt X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:36:51 -0000 On Tue, May 24, 2011 at 02:44:55AM -0500, Mouli Chandramouli (moulchan) wrote: > Among other changes, the draft provides support for multiple Power State > Series and an IANA considerations section describing the procedure for > adding new Power State Series and Power States within the series. Many > thanks to all who provided comments. PowerStateSeries ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "PowerStateSeries is a TC that describes the Power State Series a Power Monitor supports. IANA has created a registry of Power State Series supported by a Power Monitor entity and IANA shall administer the list of Power State Series. One byte is used to represent the Power State Series. field octets contents range ----- ------ -------- ----- 1 1 Power State Series 1..255 Note: the value of Power State Series in network byte order 1 in the first byte indicates IEEE1621 Power State Series 2 in the first byte indicates DMTF Power State Series 3 in the first byte indicates EMAN Power State Series REFERENCE "http://www.iana.org/assignments/eman" "RFC EDITOR NOTE: please change the previous URL if this is not the correct one after IANA assigned it." SYNTAX OCTETSTRING (SIZE(1)) Why is this an OCTET STRING (SIZE(1)) and not simply an enumerated INTEGER? And if this is to be maintained by IANA, why not create a IANA-POWER-SERIES-TC MIB module so that one can simply fetch the latest version from IANA? New assignments in Power State Series require a Standards Action [RFC5226], i.e., they are to be made via Standards Track RFCs approved by the IESG. This raises the bar pretty high. If some future organization defines popular power states, do you think someone is going to go through the trouble of producing a standards-track specification for this? I also do not see why all objects in the pmPowerEntry are necessarily indexed by power series - some appear to me to be rather a property of the monitor and not the power state series the monitor happens to support. I also like to see more text moved from the document into DESCRIPTION clauses. This in particular concerns the actual power state values. There is no way to find out what power state 2 in power state series 1 means if all you have are MIB modules. And lastly, I still prefer a design where the power states are simply enumerated. Since you require a standard-track action to allocate a new series and you reserved 8 bits for power state series, I fail to see why a simple TC can not do the job equally well. Since I started looking at the IANA considerations, I believe this text needs to be removed: Additions to the MIB modules are subject to Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested MIB objects for completeness and accuracy of the description. Requests for MIB objects that duplicate the functionality of existing objects SHOULD be declined. The smallest available OIDs SHOULD be assigned to the new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in Section 10. and MUST be published using a well-established and persistent publication medium. IETF MIB modules are not modified by Expert Review. This text looks inconsistent with existing practice in maintaining IETF MIB modules. /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 May 25 04:46:12 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269FDE0657 for ; Wed, 25 May 2011 04:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT4bcVQun+Zf for ; Wed, 25 May 2011 04:46:11 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 57334E0722 for ; Wed, 25 May 2011 04:46:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHnp3E2HCzI1/2dsb2JhbACmKXiIcKFVAps+hhwElQKKNQ X-IronPort-AV: E=Sophos;i="4.65,266,1304308800"; d="scan'208";a="281682239" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 May 2011 07:46:08 -0400 X-IronPort-AV: E=Sophos;i="4.65,266,1304308800"; d="scan'208";a="655978971" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 May 2011 07:46:08 -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, 25 May 2011 13:46:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] js review of draft-claise-energy-monitoring-mib-07 Thread-Index: Acvuuof+esBUQDiKQruMKBAa8kaXqArMuhpwADjc7yA= References: <20110330091150.GB29695@elstar.local> From: "Romascanu, Dan (Dan)" To: "Mouli Chandramouli (moulchan)" , "Juergen Schoenwaelder" , Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:46:12 -0000 Hi Mouli,=20 You did not answer Juergen's question. How fast can pmPowerStateChange notifications be generated? How do you assess if they are a bottleneck. Note that the concern is not that much at the agent, as at the management application that may connect to hundreds, thousands or more agents and potentially receive notifications from all or many of these.=20 Regards, Dan=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Mouli Chandramouli (moulchan) .... >=20 > We do not foresee a need to throttle notifications as of now, unless, > these are notifications are seen as a bottleneck. >=20 > Thanks > Mouli >=20 >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder ... >=20 > - How fast can pmPowerStateChange notifications be generated? Is > there a need to think about a throttling mechanism? >=20 > /js >=20 From moulchan@cisco.com Wed May 25 05:03:06 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DB9E0690 for ; Wed, 25 May 2011 05:03:06 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CutVZz479ui for ; Wed, 25 May 2011 05:03:05 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id AAC7AE0618 for ; Wed, 25 May 2011 05:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=1877; q=dns/txt; s=iport; t=1306324985; x=1307534585; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=5AWjPgyqZV0Vkndqc19UdFU4q6dQA5/9e22kEAesVe0=; b=BKumvTe0WsxXxm4K32n4b1aTmG401N0I6c50OHL3hEC0NtGDTYYZWL8t tK50vtcrgNudhWAeKldZuxoknsOtp84ffQK1N26eWV6euN7++CIo7mzgK ES5HINAJOhzsb+4SiLTE7QqiTu27PNDnL5doglWHneJ2OsG4r0BbK2sL5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAGXv3E2tJV2d/2dsb2JhbACXZY5FeIhwnxqeBYYcBIZbjhOKZQ X-IronPort-AV: E=Sophos;i="4.65,266,1304294400"; d="scan'208";a="234624955" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2011 12:03:04 +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 p4PC330V005964; Wed, 25 May 2011 12:03:03 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, 25 May 2011 07:03:03 -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, 25 May 2011 07:03:00 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] js review of draft-claise-energy-monitoring-mib-07 Thread-Index: Acvuuof+esBUQDiKQruMKBAa8kaXqArMuhpwADjc7yAAAGaf8A== References: <20110330091150.GB29695@elstar.local> From: "Mouli Chandramouli (moulchan)" To: "Romascanu, Dan (Dan)" , "Juergen Schoenwaelder" , X-OriginalArrivalTime: 25 May 2011 12:03:03.0231 (UTC) FILETIME=[B31C74F0:01CC1AD3] Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:03:06 -0000 Hi Dan, Whenever, the power state of a device changes - there shall be a notification.=20 The underlying assumption is that the time scale of power state change of devices would be in hours.=20 If there are time-of-day based policies for power state change of devices, there can be synchronization of notifications leading to flash crowd type of scenario=20 at the management station. In that case, there would a need for throttling the notifications sent to the management application. There are some techniques to handle that scenario, I think.=20 Thanks Mouli -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Wednesday, May 25, 2011 5:16 PM To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder; eman@ietf.org Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07 Hi Mouli,=20 You did not answer Juergen's question. How fast can pmPowerStateChange notifications be generated? How do you assess if they are a bottleneck. Note that the concern is not that much at the agent, as at the management application that may connect to hundreds, thousands or more agents and potentially receive notifications from all or many of these.=20 Regards, Dan=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Mouli Chandramouli (moulchan) .... >=20 > We do not foresee a need to throttle notifications as of now, unless, > these are notifications are seen as a bottleneck. >=20 > Thanks > Mouli >=20 >=20 >=20 > -----Original Message----- > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder ... >=20 > - How fast can pmPowerStateChange notifications be generated? Is > there a need to think about a throttling mechanism? >=20 > /js >=20 From dromasca@avaya.com Wed May 25 05:19:45 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8741E06B5 for ; Wed, 25 May 2011 05:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.308 X-Spam-Level: X-Spam-Status: No, score=-103.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07r6umXLikzZ for ; Wed, 25 May 2011 05:19:45 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4F0E0720 for ; Wed, 25 May 2011 05:19:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAN7y3E3GmAcF/2dsb2JhbACXZY5FeKo4AptChhwElQKKNQ X-IronPort-AV: E=Sophos;i="4.65,266,1304308800"; d="scan'208";a="281687363" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 May 2011 08:18:56 -0400 X-IronPort-AV: E=Sophos;i="4.65,266,1304308800"; d="scan'208";a="626010722" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 May 2011 08:18:55 -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, 25 May 2011 14:18:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] js review of draft-claise-energy-monitoring-mib-07 Thread-Index: Acvuuof+esBUQDiKQruMKBAa8kaXqArMuhpwADjc7yAAAGaf8AAA0G9Q References: <20110330091150.GB29695@elstar.local> From: "Romascanu, Dan (Dan)" To: "Mouli Chandramouli (moulchan)" , "Juergen Schoenwaelder" , Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:19:45 -0000 Hi Mouli,=20 If the typical rate of change is measured in hours there is no reason of concern and no need to build in a throtttling mechanism.=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Wednesday, May 25, 2011 3:03 PM > To: Romascanu, Dan (Dan); Juergen Schoenwaelder; eman@ietf.org > Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07 >=20 > Hi Dan, >=20 > Whenever, the power state of a device changes - there shall be a > notification. > The underlying assumption is that the time scale of power state change > of devices would be in hours. >=20 > If there are time-of-day based policies for power state change of > devices, there can be synchronization of notifications leading to flash > crowd type of scenario > at the management station. In that case, there would a need for > throttling the notifications sent to the management application. There > are some techniques to handle that scenario, I think. >=20 > Thanks > Mouli >=20 >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, May 25, 2011 5:16 PM > To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder; eman@ietf.org > Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07 >=20 >=20 >=20 > Hi Mouli, >=20 > You did not answer Juergen's question. How fast can pmPowerStateChange > notifications be generated? How do you assess if they are a bottleneck. > Note that the concern is not that much at the agent, as at the > management application that may connect to hundreds, thousands or more > agents and potentially receive notifications from all or many of these. >=20 > Regards, >=20 > Dan >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of > > Mouli Chandramouli (moulchan) >=20 > .... >=20 > > > > We do not foresee a need to throttle notifications as of now, unless, > > these are notifications are seen as a bottleneck. > > > > Thanks > > Mouli > > > > > > > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of > > Juergen Schoenwaelder >=20 > ... >=20 > > > > - How fast can pmPowerStateChange notifications be generated? Is > > there a need to think about a throttling mechanism? > > > > /js > > From blueroofmusic@gmail.com Wed May 25 08:01:17 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029B0E07D9 for ; Wed, 25 May 2011 08:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k59wQclLMeLL for ; Wed, 25 May 2011 08:01:16 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8A71E07F5 for ; Wed, 25 May 2011 08:01:15 -0700 (PDT) Received: by fxm15 with SMTP id 15so6128193fxm.31 for ; Wed, 25 May 2011 08:01:14 -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=TbXvlc/6zS0Bv86FQO4tpk9kejAs0Ns7fQrJTQtq/Kg=; b=X43GJtrtJClTwG9al5d+sqN1m0g9FYOoLrD+leaVGPV/9i2dvDa44b6LR9Mj0GGnxl Y73ID98vUmjatdj/jyoePslZELtN5Pf4kkHyXKhDcVXMy+SXehLvdGFvCxIBzZpp7HXY b8eSUImuyyXezhEZjHpCSOQm4A1+t6Mia1A+g= 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=aSywtqaK9aNUyJUXBDyjzvGaEjwpcV9CjlyeUDSEetoMNWaqO9k0UfhGUpk/CjJN/Z 0T3VXWcxTXd1L3O/Fp0pt9bAck+JVbowHpXMTpGFETvvvHioAEFtyH+rO60J1GPqzu6i 7ba73wz1IfdbaaoK2VEMChht3Stw74Y/1ne34= MIME-Version: 1.0 Received: by 10.223.100.2 with SMTP id w2mr5190878fan.87.1306335674760; Wed, 25 May 2011 08:01:14 -0700 (PDT) Received: by 10.223.121.142 with HTTP; Wed, 25 May 2011 08:01:14 -0700 (PDT) In-Reply-To: References: <20110330091150.GB29695@elstar.local> Date: Wed, 25 May 2011 11:01:14 -0400 Message-ID: From: Ira McDonald To: "Romascanu, Dan (Dan)" , Ira McDonald Content-Type: multipart/alternative; boundary=20cf30433ea0da00d104a41af9da Cc: eman@ietf.org Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:01:17 -0000 --20cf30433ea0da00d104a41af9da Content-Type: text/plain; charset=ISO-8859-1 Hi, FWIW - Network printers and multifunction devices typically go into a low power mode (light sleep) after a few minutes idle. Then into a lower power mode (deep sleep) after a few more minutes. When combined with frequent network print/fax jobs, this results in power state transitions (and notifications) every few minutes for each device. OTOH - Never mind - networks (that are monitoring power) are fast and we're not talking seconds here. 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, May 25, 2011 at 8:18 AM, Romascanu, Dan (Dan) wrote: > > > Hi Mouli, > > If the typical rate of change is measured in hours there is no reason of > concern and no need to build in a throtttling mechanism. > > Thanks and Regards, > > Dan > > > -----Original Message----- > > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > > Sent: Wednesday, May 25, 2011 3:03 PM > > To: Romascanu, Dan (Dan); Juergen Schoenwaelder; eman@ietf.org > > Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07 > > > > Hi Dan, > > > > Whenever, the power state of a device changes - there shall be a > > notification. > > The underlying assumption is that the time scale of power state change > > of devices would be in hours. > > > > If there are time-of-day based policies for power state change of > > devices, there can be synchronization of notifications leading to > flash > > crowd type of scenario > > at the management station. In that case, there would a need for > > throttling the notifications sent to the management application. > There > > are some techniques to handle that scenario, I think. > > > > Thanks > > Mouli > > > > > > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Wednesday, May 25, 2011 5:16 PM > > To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder; > eman@ietf.org > > Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07 > > > > > > > > Hi Mouli, > > > > You did not answer Juergen's question. How fast can pmPowerStateChange > > notifications be generated? How do you assess if they are a > bottleneck. > > Note that the concern is not that much at the agent, as at the > > management application that may connect to hundreds, thousands or more > > agents and potentially receive notifications from all or many of > these. > > > > Regards, > > > > Dan > > > > > -----Original Message----- > > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > > Of > > > Mouli Chandramouli (moulchan) > > > > .... > > > > > > > > We do not foresee a need to throttle notifications as of now, > unless, > > > these are notifications are seen as a bottleneck. > > > > > > Thanks > > > Mouli > > > > > > > > > > > > -----Original Message----- > > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > > Of > > > Juergen Schoenwaelder > > > > ... > > > > > > > > - How fast can pmPowerStateChange notifications be generated? Is > > > there a need to think about a throttling mechanism? > > > > > > /js > > > > > _______________________________________________ > eman mailing list > eman@ietf.org > https://www.ietf.org/mailman/listinfo/eman > --20cf30433ea0da00d104a41af9da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

FWIW - Network printers and multifunction devices typically
g= o into a low power mode (light sleep) after a few minutes idle.

Then= into a lower power mode (deep sleep) after a few more
minutes.

When combined with frequent network print/fax jobs, this
results in powe= r state transitions (and notifications) every
few minutes for each devi= ce.

OTOH - Never mind - networks (that are monitoring power)
are fast and we're not talking seconds here.

Cheers,
- Ira

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



On Wed, May 25, 2011 at 8:18 AM, Romasca= nu, Dan (Dan) <d= romasca@avaya.com> wrote:


Hi Mouli,

If the typical rate of change is measured in hours there is no reason of concern and no need to build in a throtttling mechanism.

Thanks and Regards,

Dan

> -----Original Message-----
> From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com]
> Sent: Wednesday, May 25, 2011 3:03 PM
> To: Romascanu, Dan (Dan); Juergen Schoenwaelder; eman@ietf.org
> Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07=
>
> Hi Dan,
>
> Whenever, the power state of a device changes - there shall be a
> notification.
> The underlying assumption is that the time scale of power state change=
> of devices would be in hours.
>
> If there are time-of-day based policies for power state change of
> devices, there can be synchronization of notifications leading to
flash
> crowd type of scenario
> at the management station. In that case, there would a need for
> throttling the notifications sent to the management application.
There
> are some techniques to handle that scenario, I think.
>
> Thanks
> Mouli
>
>
>
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: Wednesday, May 25, 2011 5:16 PM
> To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder;
eman@ietf.org
> Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07=
>
>
>
> Hi Mouli,
>
> You did not answer Juergen's question. How fast can pmPowerStateCh= ange
> notifications be generated? How do you assess if they are a
bottleneck.
> Note that the concern is not that much at the agent, as at the
> management application that may connect to hundreds, thousands or more=
> agents and potentially receive notifications from all or many of
these.
>
> Regards,
>
> Dan
>
> > -----Original Message-----
> > From: eman-bounces@ietf.= org [mailto:eman-bounces@ietf.= org] On Behalf
> Of
> > Mouli Chandramouli (moulchan)
>
> ....
>
> >
> > We do not foresee a need to throttle notifications as of now,
unless,
> > these are notifications are seen as a bottleneck.
> >
> > Thanks
> > Mouli
> >
> >
> >
> > -----Original Message-----
> > From: eman-bounces@ietf.= org [mailto:eman-bounces@ietf.= org] On Behalf
> Of
> > Juergen Schoenwaelder
>
> ...
>
> >
> > - How fast can pmPowerStateChange notifications be generated? Is<= br> > > =A0 there a need to think about a throttling mechanism?
> >
> > /js
> >

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

--20cf30433ea0da00d104a41af9da-- From j.schoenwaelder@jacobs-university.de Wed May 25 08:53:06 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839E1E067C for ; Wed, 25 May 2011 08:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl3KY-G49TQm for ; Wed, 25 May 2011 08:53:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E4ADEE0618 for ; Wed, 25 May 2011 08:53:05 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 235D920D51; Wed, 25 May 2011 17:53:05 +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 kcN5Zx4qgxNN; Wed, 25 May 2011 17:53:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62CC120D48; Wed, 25 May 2011 17:53:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 09F9C18BA5F5; Wed, 25 May 2011 17:53:03 +0200 (CEST) Date: Wed, 25 May 2011 17:53:03 +0200 From: Juergen Schoenwaelder To: Ira McDonald Message-ID: <20110525155303.GA20245@elstar.local> Mail-Followup-To: Ira McDonald , "Romascanu, Dan (Dan)" , "Mouli Chandramouli (moulchan)" , eman@ietf.org References: <20110330091150.GB29695@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-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:53:06 -0000 On Wed, May 25, 2011 at 11:01:14AM -0400, Ira McDonald wrote: > > FWIW - Network printers and multifunction devices typically > go into a low power mode (light sleep) after a few minutes idle. > > Then into a lower power mode (deep sleep) after a few more > minutes. > > When combined with frequent network print/fax jobs, this > results in power state transitions (and notifications) every > few minutes for each device. > > OTOH - Never mind - networks (that are monitoring power) > are fast and we're not talking seconds here. Interesting would be situations where network activity causes many systems to change state simulaneously and even worse causes subsequent synchronization of the following power state changes. /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 Wed May 25 14:19:49 2011 Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B581E075D for ; Wed, 25 May 2011 14:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[AWL=3.647, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZI+06rSkt+E for ; Wed, 25 May 2011 14:19:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 09100E06A0 for ; Wed, 25 May 2011 14:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jparello@cisco.com; l=3484; q=dns/txt; s=iport; t=1306358387; x=1307567987; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=o9uER1JsBlHIKUNzqFbq9KLsKX7Dhw+eZuzov4x4g1g=; b=LZR4gbYhvcfZxddeODTer5khvyzqmkqGpclbqY678G1KjfofPZ+mNHoY yMW4x7vbEL++dIcUomXZ7TuAlma5elibD5aIbi53tcMqeS7bz2Gg3y+4s bdHMbP2sPNyJ0Fat7mP67isEEC++k6LSS6egtWUwy+OmrX5NME3y62MMB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAGtx3U2rRDoH/2dsb2JhbACXb45EeKgmnWCGHASGW44Uimc X-IronPort-AV: E=Sophos;i="4.65,268,1304294400"; d="scan'208";a="703394738" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 25 May 2011 21:19:47 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4PLJlYj009411; Wed, 25 May 2011 21:19:47 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); Wed, 25 May 2011 14:19:47 -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, 25 May 2011 14:18:34 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [eman] js review of draft-claise-energy-monitoring-mib-07 Thread-Index: Acvuuof+esBUQDiKQruMKBAa8kaXqArMuhpwADjc7yAAAGaf8AAA0G9QABKyxtA= References: <20110330091150.GB29695@elstar.local> From: "John Parello (jparello)" To: "Romascanu, Dan (Dan)" , "Mouli Chandramouli (moulchan)" , "Juergen Schoenwaelder" , X-OriginalArrivalTime: 25 May 2011 21:19:47.0715 (UTC) FILETIME=[79BC3530:01CC1B21] Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07 X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:19:49 -0000 One way to mitigate this that I've done with similar implementation is that the notification is defined as the configured state change. If the device drops to a lower state on its own as described in the thread no change is send. Define it as policy change. That reduces it to measured in hours or days based on policy. If the other transitions are needed (non -policy change) it's expected to be hours and worse case minutes so I think we're fine without explicit throttling and can rely on simple correlation to reduce this further upstream. Jp=20 -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, May 25, 2011 5:19 AM To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder; eman@ietf.org Subject: Re: [eman] js review of draft-claise-energy-monitoring-mib-07 Hi Mouli,=20 If the typical rate of change is measured in hours there is no reason of concern and no need to build in a throtttling mechanism.=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com] > Sent: Wednesday, May 25, 2011 3:03 PM > To: Romascanu, Dan (Dan); Juergen Schoenwaelder; eman@ietf.org > Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07 >=20 > Hi Dan, >=20 > Whenever, the power state of a device changes - there shall be a > notification. > The underlying assumption is that the time scale of power state change > of devices would be in hours. >=20 > If there are time-of-day based policies for power state change of > devices, there can be synchronization of notifications leading to flash > crowd type of scenario > at the management station. In that case, there would a need for > throttling the notifications sent to the management application. There > are some techniques to handle that scenario, I think. >=20 > Thanks > Mouli >=20 >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, May 25, 2011 5:16 PM > To: Mouli Chandramouli (moulchan); Juergen Schoenwaelder; eman@ietf.org > Subject: RE: [eman] js review of draft-claise-energy-monitoring-mib-07 >=20 >=20 >=20 > Hi Mouli, >=20 > You did not answer Juergen's question. How fast can pmPowerStateChange > notifications be generated? How do you assess if they are a bottleneck. > Note that the concern is not that much at the agent, as at the > management application that may connect to hundreds, thousands or more > agents and potentially receive notifications from all or many of these. >=20 > Regards, >=20 > Dan >=20 > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of > > Mouli Chandramouli (moulchan) >=20 > .... >=20 > > > > We do not foresee a need to throttle notifications as of now, unless, > > these are notifications are seen as a bottleneck. > > > > Thanks > > Mouli > > > > > > > > -----Original Message----- > > From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf > Of > > Juergen Schoenwaelder >=20 > ... >=20 > > > > - How fast can pmPowerStateChange notifications be generated? Is > > there a need to think about a throttling mechanism? > > > > /js > > _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman